Интервью с Владимиром Кладовым, автором библиотеки KOL
Владимир Кладов - автор библиотек KOL и MCK, о которых "Компьютерные вести" недавно уже рассказывали. Этот человек широко известен среди армии пользователей своих библиотек, хотя и другим людям, которые имеют представление о том, что такое Delphi, его взгляд на этот язык программирования, а также связанные с ним вещи и их будущее, будет небезынтересен. Так что не буду затягивать и сразу начну задавать Владимиру вопросы.
- Ну, во-первых, каковы, по-Вашему,
перспективы KOL?
- Перспективы KOL - хорошие. В долгосрочном плане есть реальная возможность поддержать и Linux/Unix, и любую другую платформу.
- Но в настоящий момент рабочая платформа KOL-приложений - Win32. И в недалёком будущем она, похоже, будет вытеснена, во-первых, 64-битными версиями Windows, а во-вторых, конкурирующими системами. Каково Ваше мнение по поводу будущего Win32?
- Платформа Win32 так просто не уйдёт, у неё большая инерция массы ПО. По крайней мере, ещё лет 10, а то и все 50 просуществует. Даже если железо станет совсем другим, оно всё равно будет иметь, как минимум, режим совместимости, чтобы и дальше можно было использовать тонны наработанного софта.
- Ну хорошо, тогда остаётся ещё один столп, на котором покоится библиотека KOL, - это Delphi. А будущее этих среды и языка программирования выглядит не таким уж и радужным, верно?
- Если даже что-то случится с Delphi, есть Free Pascal, а он более многоплатформенный, и это извиняет даже его неоптимальный код и некоторую сырость исполнения. Но Delphi тоже так просто не уйдёт. И, опять же, из-за огромной массы наработанного софта, БД, отчётов, всевозможных АСУ - на Delphi их лепить на порядок проще, чем на том же C++. А вот в его долгожительстве как раз стоит посомневаться, его как раз сама мама-Майкрософт очень даже пытается "подвинуть", заменяя на Delphi-подобный и VB-подобный C# и иже с ним. И "налеплено" на Delphi немало, всегда проще адаптировать старый код с прежнего Delphi на новый Delphi + новую ось, чем полностью переписать на тот же C#. Кстати, в реальном производстве (мне не повезло?) ни разу за последние 10 лет не было такого, чтобы производственные задачи делались на С++ или VB. Везде и всюду Delphi, доля рынка которого якобы "столь ничтожно мала", по сравнению с С++. Два раза видел использование С-подобных решений, но в одном случае речь шла о чуждой платформе (процессор на сканере штрих-кодов), и то - это была пара сотен строк кода, а остальные несколько тысяч снова на Delphi. А в другом случае - сопряжение с WinCC, который каким-то хитро закрученным образом куда-то, опять же, встроен и должен общаться с БД, ведомой, опять же, "всеми забытым" и "никому ненужным" Delphi.
- Раз уже разговор пошёл, так сказать, вширь, то давайте поговорим о перспективах всей IT-отрасли.
- Моё предположение такое, что если в ближайшие лет 15 не появится ИИ (искусственный интеллект), а он с огромной вероятностью не появится, по крайней мере, еще лет 50, то около половины работоспособного населения всего мира будут хоть как-то уметь программировать. То есть будут работниками этой самой IT. Даже если по должности будут ещё кем-то: агрономами, физиками, архитекторами дизайнерами, биологами... Это, опять же, плюс для Delphi, кстати, и его перспектив. Научиться работать в этой среде все-таки проще, и не надо себе забивать голову слишком большим количеством специальных знаний, касающихся исключительно программирования. Можно оставить больше места, то есть посвятить больше времени своей предметной области. Я даже подозреваю, что потенциально возможно появление "упрощённого" Delphi - упрощённого именно с целью облегчить его изучение и использование. Моё поверхностное знакомство с языком C#, кстати, не дало мне ощущения, что этот язык прост. А еще мне не понравилось и то, что он пока что привязан к некой платформе .NET, которая еще не доказала свою жизнеспособность на самом-то деле.
Кстати, насчёт цифр и вероятностей. Это не совсем мой прогноз. Есть такая теория, которая позволяет судить о наиболее вероятном ответе на вопрос о том, сколько времени просуществует некоторое явление или событие, на основании известных данных о том, сколько времени это явление уже существует. Теория утверждает, что, с огромной вероятностью, мы наблюдаем как раз половину времени существования явления. Т.е. если 50 лет назад мы полетели в космос и до сих пор не достигли Луны, то с огромной вероятностью не достигнем еще 50 лет. И, что удивительно, до сих пор эта теория оказывалась очень даже совпадающей с реальными фактами, т.е. она действительно работает:). Так что KOL + MCK с огромной вероятностью просуществуют еще 10 лет, и, согласно этой же теории, через 10 лет они будут находиться всё еще где-то посередине своего времени существования :)).
- Если так, то что нового в последнее время произошло в мире KOL и MCK?
- В конце октября - начале ноября добавилась поддержка MCK для BDS 2005-2007, возможно, Turbo-Delphi. Но я не проверял Turbo, у меня её нет, я вообще консерватор и предпочитаю до последней возможности использовать старое. Например, сейчас использую Delphi6 и не испытываю никакой потребности в BDS или Turbo. Я бы и Delphi5 обошёлся, если бы в нем была поддержка MMX-инструкций.
- Хотелось бы ещё узнать Ваше мнение по поводу потенциала использования KOL для, так сказать, отраслевого программирования (АСУ и прочее), а также узнать мысли по поводу сравнения в этой области KOL+MCK с VCL.
- Люди делают на нём работу с БД. Мне только не очень понятно, зачем. Для этих-то задач компактность вообще не требуется. Компонент KOLOdbc, который я сделал для KOL, - это вообще-то практически тот же, которым я с успехом пользуюсь в VCL, и он годится для работы с любой БД. Отчёты KOLReport - тот же NormalReport для VCL. Гридами и DB-контролами я не пользуюсь ни в KOL, ни в VCL. Это избавляет от очень многих непонятных проблем с их кривостью, которая обнаруживается в совершенно ненужных местах и только тормозит работу. Так что, в принципе, всё один в один.
- Нет ли планов сделать IDE для KOL, чтобы не было необходимости использовать MCK, а можно было напрямую взаимодействовать с KOL-компонентами?
- Нет, IDE делать не собираюсь. Народ, связанный с Free Pascal (Юрий Сидоров), участвует и в разработке Лазаруса. Так что "наши" пожелания по поддержке KOL в этом компиляторе и в этом IDE постоянно приемлются и совместимость обеспечивается и MCK в нём работает. IDE - это, прежде всего, отладчик на уровне исходного кода. Иначе это не IDE, а текстовый редактор с вызовом внешнего компилятора, не более. А отладчик - это очень серьёзная задача.
- Спасибо. Думаю, читатели присоединятся к моим пожеланиям всяческих успехов.
Интервью провёл Вадим СТАНКЕВИЧ
Комментарии
Страницы
Да.
>Гарантирует. Иногда. Так как не только есть алгоритмы и обертки.
Верно. Если какая-то мощная библиотека вокруг которой делается обертка встроена в операционную систему, то 100% портируемости на Mac/*nix добиться не удастся. Но Java в такой ситуации тоже не поможет, потому что функциональные возможности этой среды ограничены.
>Виртуальная машина - гарантия более-менее нормальной портируемости.
С++ это такая же гарантия портируемости (stlport, boost).
>Не всегда. А куда все библиотеки деваются? На том же VC++ куча в уже dll лежит.
По аналогии - вес JVM. А в С++ даже если линковать статически, то размер программы будет небольшим.
>>С++ это такая же гарантия портируемости (stlport, boost).
В Java еще и обертка портируется. Это существенное преимущество.
>>>Не всегда. А куда все библиотеки деваются? На том же VC++ куча в уже dll лежит.
>>По аналогии - вес JVM. А в С++ даже если линковать статически, то размер программы будет небольшим.
По сегодняшним меркам - "вес" JRE весьма скромный.
Например:
Qt Designer,
Visual Studio .NET,
wxForms -- (для wxWidgets - integrated form designer plugin for Borland C++ Builder that helps you to create cross platform applications for Windows, Mac OSX , Linux (gtk) using single source base)
можно делать интерфейс как html - htmlayout (http://terrainformatica.com/htmlayout/) - кстати, это очень интересная идея. Но было бы ещё удобнее для дизайна интерфейсов софта вместо html использовать какой-нибудь более лаконичный язык разметки.
>И как потом слепить GUI с ядром?
Желательно (но не обязательно) алгоритм ядра кодировать независимо от реализации интерфейса, с помощью врапперов. А можно и как в Дельфи, всё реализовывать монолитно. Хотя я не сторонник такого подхода.
Так опыт то не пропьешь! ;-)
А поодержка. А разработка. А на хр..?
А каких кросс-платформенных библиотек не хватает в C++ ?
Было: знатный "дед лок" тот "пацан" сработал. Эх, и я был молот, работал по 10 часов в сутки на дядю. Счас тоже на дядю, но от силы 3. И не увольняет, паскуда.
>Этот языко (C++) обладает _избыточной_ для многих задач гибкостью.
Действительно: зачем cgi на Си, если на Пёрле быстрее? Но УЧИТЬ Пёрл ради пары эпизодов?!
23 ноября 2007 года, 16:40
>>>>А внутренности на чем?
>>Например:
Qt Designer,
>>Visual Studio .NET,
>>wxForms -- (для wxWidgets - integrated form designer plugin for Borland C++ Builder that helps you to create cross platform applications for Windows, Mac OSX , Linux (gtk) using single source base)
Ваш пост?
"Инкогнито
23 ноября 2007 года, 13:20
Насчет GUI - полная свобода выбора. Начиная от MFC, VCL, .NET заканчивая Qt и wxWidgets."
"MFC, VCL, .NET заканчивая Qt и wxWidgets" - гремучая смесь у вас была. Вы б тогда лучше как-то разделяли на группы. А то сначала в одну кучу все свалили, а потом выдедлили.
Давайте так: берем инструмент для ядра многоплатвофренный, а к нему список оберток тоже многоплатформенных. Чтобы уже действительно о настоящей портируемости говорить. И чтобы они стыковались нормально.
>>можно делать интерфейс как html - htmlayout (http://terrainformatica.com/htmlayout/) - кстати, это очень интересная идея.
Ага, а что к web-серверу? cgi?
>>Но было бы ещё удобнее для дизайна интерфейсов софта вместо html использовать какой-нибудь более лаконичный язык разметки.
Ох, как у вас все просто. если бы я статеек начитался рекламных - тоже бы сказал, что все просто.
>>>И как потом слепить GUI с ядром?
>>Желательно (но не обязательно) алгоритм ядра кодировать независимо от реализации интерфейса, с помощью врапперов.
Вы это делали самостоятельно? Или только прочитали об этом?
>>А можно и как в Дельфи, всё реализовывать монолитно. Хотя я не сторонник такого подхода.
Это просто самый простой и быстрый способ разработки систем.
--------------------------------------------------------------------------------
>>Логик
23 ноября 2007 года, 16:40
>>Настоящий Полковник > На Oracle с теми же подходами, как в FoxPro. ;)
>>Так опыт то не пропьешь! ;-)
Это точно. ;)
--------------------------------------------------------------------------------
>>Логик
23 ноября 2007 года, 16:41
>>Настоящий Полковник > Не такие уж большие деньги. А если нет - то и выпендриваться не надо - оракул покупать. Есть и дешевле, и не хуже. А даже получше.
>>А поодержка. А разработка. А на хр..?
Главное - выпендриться. Мол, а у нас Oracle и все тут. Rulez forever. ;) если на Oracle, то a priori все просто, быстро и круто. ;)
--------------------------------------------------------------------------------
>>Инкогнито
23 ноября 2007 года, 16:57
>>>В Java еще и обертка портируется. Это существенное преимущество.
>>А каких кросс-платформенных библиотек не хватает в C++ ?
Вы их сначала найдите (можно достаточно быстро найти), поюзайте (здесь времени может уйти очень много), выберите оптимальный вариант (ох, и нетривиальная же задача - все просмотреть, попробовать, прототипировать, проверить и пр.), а потом деньги заплатить (бывает весьма существенные). Пример? Rogue Wave. Круто? Да. Сложно? Да. Дорого? Да.
Только о всяких поделках не надо говорить.
"Наиболее сильная сторона Rogue Wave — наборы программных компонентов на языке C++ для различных областей: Tools.h++, Tools.h++ Professional, DBTools.h++, DBTools.h++ XA, Threads.h++, Standard C++ Library, Analytics.h++, LAPACK.h++, Math.h++, Money.h++. Они работают на всех основных платформах (Windows, Windows CE, Windows NT, коммерческие варианты Unix и Linux, AS/400 и OS/390).
Линия продуктов Rogue Wave особенно заметно пополнилась после приобретения два года назад компании Stingray Software, завоевавшей определенные позиции у разработчиков Windows-приложений: Objective Toolkit PRO, Objective Grid, Objective Chart и Objective Views (ранее Objective Diagram). Эти программные продукты работают только под Windows. Поскольку одна из основных задач компании — облегчить разработчикам интеграцию разнородных, разноплатформенных приложений, предусмотрена развитая поддержка таких технологий, как Java, CORBA, XML, COM.
Программное обеспечение, которое предлагает Rogue Wave, недешево. В «Аргуссофт» подчеркивают, что «покупают его те, кто либо не считает деньги, либо очень хорошо считает». Например те, кто просчитал экономию в человеко-днях, выгоду от быстрого выхода на рынок или оценил возможные издержки от некачественного, трудно поддерживаемого кода."
Страницы