"Платформа Win32 так просто не уйдёт"

Интервью с Владимиром Кладовым, автором библиотеки 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, а текстовый редактор с вызовом внешнего компилятора, не более. А отладчик - это очень серьёзная задача.

- Спасибо. Думаю, читатели присоединятся к моим пожеланиям всяческих успехов.

Интервью провёл Вадим СТАНКЕВИЧ

Версия для печатиВерсия для печати

Номер: 

46 за 2007 год

Рубрика: 

Эксклюзивное интервью
Заметили ошибку? Выделите ее мышкой и нажмите Ctrl+Enter!
 

Комментарии

Страницы

Аватар пользователя Инкогнито
>Так не мешало бы всегда делать на любом инструменте.

Да.

>Гарантирует. Иногда. Так как не только есть алгоритмы и обертки.

Верно. Если какая-то мощная библиотека вокруг которой делается обертка встроена в операционную систему, то 100% портируемости на Mac/*nix добиться не удастся. Но Java в такой ситуации тоже не поможет, потому что функциональные возможности этой среды ограничены.

>Виртуальная машина - гарантия более-менее нормальной портируемости.

С++ это такая же гарантия портируемости (stlport, boost).

>Не всегда. А куда все библиотеки деваются? На том же VC++ куча в уже dll лежит.

По аналогии - вес JVM. А в С++ даже если линковать статически, то размер программы будет небольшим.

Аватар пользователя Настоящий Полковник
>>>Виртуальная машина - гарантия более-менее нормальной портируемости.

>>С++ это такая же гарантия портируемости (stlport, boost).

В Java еще и обертка портируется. Это существенное преимущество.

>>>Не всегда. А куда все библиотеки деваются? На том же VC++ куча в уже dll лежит.

>>По аналогии - вес JVM. А в С++ даже если линковать статически, то размер программы будет небольшим.

По сегодняшним меркам - "вес" JRE весьма скромный.

Аватар пользователя SF
Класс... Опять войны остроконечников с тупоконечниками. Вообще, должен, сказать, солидарен с Коттом, потому и пошёл в своё время на физфак БГУ. А с теми, кто любит везде совать С++, позволю себе не согласиться. Этот языко обладает _избыточной_ для многих задач гибкостью.
Аватар пользователя Инкогнито
>А внутренности на чем?

Например:

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 с ядром?

Желательно (но не обязательно) алгоритм ядра кодировать независимо от реализации интерфейса, с помощью врапперов. А можно и как в Дельфи, всё реализовывать монолитно. Хотя я не сторонник такого подхода.

Аватар пользователя Логик
Настоящий Полковник > На Oracle с теми же подходами, как в FoxPro. ;)

Так опыт то не пропьешь! ;-)

Аватар пользователя Логик
Настоящий Полковник > Не такие уж большие деньги. А если нет - то и выпендриваться не надо - оракул покупать. Есть и дешевле, и не хуже. А даже получше.

А поодержка. А разработка. А на хр..?

Аватар пользователя Инкогнито
>В Java еще и обертка портируется. Это существенное преимущество.

А каких кросс-платформенных библиотек не хватает в C++ ?

Аватар пользователя mike
>Уволил [бы] и взял "настоящего пацана"?

Было: знатный "дед лок" тот "пацан" сработал. Эх, и я был молот, работал по 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, недешево. В «Аргуссофт» подчеркивают, что «покупают его те, кто либо не считает деньги, либо очень хорошо считает». Например те, кто просчитал экономию в человеко-днях, выгоду от быстрого выхода на рынок или оценил возможные издержки от некачественного, трудно поддерживаемого кода."

Страницы