"Платформа 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!
 

Комментарии

Страницы

Аватар пользователя Настоящий Полковник
>>mike (old student)

19 ноября 2007 года, 10:24

>>>Объем только pas-файлов 11Мбайт, 208 файлов. ...Есть вещи, которые просто так не переписываются.

>>Так вам, паскалистам, и надо!

Все мои попытки перейти на C++ Builder когда-то не приводили ни к чему. Причны:

глюки с работой MIDAS, медленный компилятор, нестабильность. Увы. А так я бы тоже растопыривал пальцы, говоря, что проекты на C++. ;)

>>>не бойтесь переходить на C#, он очень легок в изучении после Object Pascal

>>Особено зная заброшенный C++.

Я тоже не вижу проблем. Но пока нет смысла. Только что заказчикам рассказывать сказки о своей крутости. ;)

Аватар пользователя Настоящий Полковник
>>Реальный Пацан

19 ноября 2007 года, 02:07

Совсем забыл о еще одной любопытной вещи. Проект базируется на BDE. ;) GПредставьте себе - на той самой оплеванной технологии доступа к СУБД. Но вопреки всеобщим крикам о кривости - весьма уневерсальной и стабильной. Правда в проекте еще используется в ресурсоемких bulk-операциях ADO и OCI (для Oracle). Вот ADO-драйвер Oracle кривой и неполнофункциональный. Пришлось OCI вводить. Но BDE хоть и проигрывает ADO по скорости в некоторых операциях, зато не требует никаких "плясок с бубном". ;)

Аватар пользователя Настоящий Полковник
Я уже приготовился послушать разгромные речи. ;)
Аватар пользователя Настоящий Полковник
Никто ничего не пишет... А я так ждал. ;)

>>Жесть... это ж в среднем больше 50к кода на файл.

Еще один момент: я на именах переменных и методов не экономлю. Если нужна читабельность, то и 30 символов в имени метода нормально. А не как некоторые делают: a1, a2, a3: string. Потом никто не понимает, что, где и для чего нужно. ;) А таблички в базе с полями так именовать - вообще извращение. ;)

Аватар пользователя Boba22
Я участвовал и в Delphi и в C# проектах - и по моему программисту безразлично на чем писать типичные программы. Для бизнес-программирования эти языки достаточно близки. Ну а если коснуться наследования визуальных компонент, и прочей мишуры - то тут C# дает программеру выеживаться по полной. В C# мне понравилось, что разработчики практически полностью слизали IDE и VCL после этого Delphi уже не смотрится так, как рядом с Visual 6.

За счет хорошего пиара Microsoft обеспечивает популярность C# и пополняет ряды рабочих обезьянок из EPAM любителями трехзвенной архитектуры и Active Directory.

Местному рынку эти технологии не будут нужны еще лет 5.

Аватар пользователя Реальный Пацан
>>Настоящий Полковник

Это хорошо, что вы знаете о существовании или многое даже использовали в работе. Это вам только в +, к сожалению, у меня по-крайней мере сложилось такое впечатление от общения с дельфистами, что многие из них клепают только бухгалтерию и склады, и дальше этого мирка никогда не вылазили.

про Remote Data Module не в курсе, имел опыт работы на VC с COM (лет 7 назад), про DCOM и Корбу имею самое общее представление. Не понравилось, не использую, ушел и от C++ и от Microsoft-овских технологий. Слишком большие издержки получаются, а выхлоп - минимальный.

Ну, если у вас 11мб кода получается генерацией всяких хидеров и стабов, то понятно откуда файлы по 50к :-) Если же ручками в файле 50к писано, за такое надо бить ремнем.

>>Кстати, пришлось вот свой репликатор базы сделать, чтобы не привязываться к определенной используемой СУБД. А использоваться может и Oracle, и MSSQL, и Sybase. Без перепрограммрования. ;)

У меня вообще все приложения не зависят от вендора БД, хотя предпочитаю использовать более продвинутые чем MySQL: PostgreSQL, Oracle. Там хоть deffered constraints check есть и транзакции отродясь были.

За три недели (по 2-3 часа в день) написал достаточно гибкий импорт из тектовых tabular files (csv) в БД, с поддержкой иерархических структур, автогенерируемых id (связь записей по произвольному полю), поддержкой любой кодировки, опять же без привязки к конкретной субд (абы транзакции поддерживала). На С++ я бы это год писал. Сейчас вот посмотрел, написать пришлось чуть меньше 20к кода, остальное взял из open-source фреймворков и чуть доработал напильником. Чем мне не нравится С++ это излишняя сложность, которая отвлекает от главного - написание бизнес-логики приложения, приходится постоянно воевать с указателями, памятью, отсутствием нормального reflection, aop proxy и т.д.

Аватар пользователя mike
>я бы тоже растопыривал пальцы, говоря, что проекты на C++...

Полковник, вы не поняли. Неинтерфейсная часть (она же бОльшая) - на неделфи (т.е. это м.б. и "обжект паскаль", и C#, и C++, кто во что горазд). "Делфи/билдер" заточены под интерфейсы, особенно c БД. Остальное - ручками. Если у вас по-другому - рад за вас.

Аватар пользователя Вадим Станкевич
>>НП, решпект. Кстати, в "КВ" не было ни одной статьи про это. Вам тема, пишущая братия!

Майк, и сколько человек это будет читать? Эта тема хороша для RSDN.ru, а не для КВ.

Аватар пользователя Настоящий Полковник
>>Boba22 (починяю примус)

Минск, 19 ноября 2007 года, 13:36

>>Я участвовал и в Delphi и в C# проектах - и по моему программисту безразлично на чем писать типичные программы. Для бизнес-программирования эти языки достаточно близки.

+5.

>>Ну а если коснуться наследования визуальных компонент, и прочей мишуры - то тут C# дает программеру выеживаться по полной.

Бесспорно. Только это палко о двух концах - множественное наследование. Иногда разработчики так "занаследуют", что потом сами не могут разобраться и баг найти.

>> В C# мне понравилось, что разработчики практически полностью слизали IDE и VCL после этого Delphi уже не смотрится так, как рядом с Visual 6.

Когда-то Microsoft пыталась купить у Borland его C++ Builder. Видимо о чем-то договрились.

>>За счет хорошего пиара Microsoft обеспечивает популярность C# и пополняет ряды рабочих обезьянок из EPAM любителями трехзвенной архитектуры и Active Directory.

Что ж вы так грубо о работниках? ;)

И что плохого в трехзвенной архитектуре? ;)

>>Местному рынку эти технологии не будут нужны еще лет 5.

Местному - возможно. Но это не показатель. Есть еще внешние рынки.

--------------------------------------------------------------------------------

>>Реальный Пацан

19 ноября 2007 года, 14:14

>>>>Настоящий Полковник

>>Это хорошо, что вы знаете о существовании или многое даже использовали в работе. Это вам только в +

Спасибо. Я этим занимаюсь вот уже 15 лет достаточно успешно. ;)

>>, к сожалению, у меня по-крайней мере сложилось такое впечатление от общения с дельфистами, что многие из них клепают только бухгалтерию и склады, и дальше этого мирка никогда не вылазили.

Это только ваше субъективное мнение.

>>про Remote Data Module не в курсе, имел опыт работы на VC с COM (лет 7 назад), про DCOM и Корбу имею самое общее представление.

Вот тот самый Remote Data Module базируется на DCOM и CORBA. ;)

>>Не понравилось, не использую, ушел и от C++ и от Microsoft-овских технологий.

Во-первых, CORBA - не майкрософтовская технология. Учите матчасть.

Во-вторых, ушли и куда пришли? ;)

>>Слишком большие издержки получаются, а выхлоп - минимальный.

На Java лучше? ;) Или на PHP? ;););)

>>Ну, если у вас 11мб кода получается генерацией всяких хидеров и стабов, то понятно откуда файлы по 50к :-) Если же ручками в файле 50к писано, за такое надо бить ремнем.

Один зpas-файл (Remote Data Module) "весит" 1,5Мбайта. И что?

А ремнем своих приятелей отхаживайте.

>>>>Кстати, пришлось вот свой репликатор базы сделать, чтобы не привязываться к определенной используемой СУБД. А использоваться может и Oracle, и MSSQL, и Sybase. Без перепрограммрования. ;)

>>У меня вообще все приложения не зависят от вендора БД,

Мне смешно. Одна табличка и использование select, insert, update, delete? Тогда действительно не зависит. ;););)

>>хотя предпочитаю использовать более продвинутые чем MySQL:

О да! MySQL - это круто. ;)

>>PostgreSQL, Oracle.

Особенно сравнение MySQL и Oracle. ;) Да и последняя тоже монстроидальная сиситема. Зато хватстаться можно. ;)

>>Там хоть deffered constraints check есть и транзакции отродясь были.

В MySQL начиная с 4-й версии, кажется, уже есть транзакции. Вы не слышали? ;)

>>За три недели (по 2-3 часа в день) написал достаточно гибкий импорт из тектовых tabular files (csv) в БД,

с поддержкой иерархических структур, автогенерируемых id (связь записей по произвольному полю), поддержкой любой кодировки, опять же без привязки к конкретной субд (абы транзакции поддерживала).

Круто! ;) Большое "достижение".

>>На С++ я бы это год писал.

А на чем вы это сделали? Я так и не увидел в ваших постах.

>>Сейчас вот посмотрел, написать пришлось чуть меньше 20к кода, остальное взял из open-source фреймворков и чуть доработал напильником. Чем мне не нравится С++ это излишняя сложность, которая отвлекает от главного - написание бизнес-логики приложения, приходится постоянно воевать с указателями, памятью, отсутствием нормального reflection, aop proxy и т.д.

А для этого головой думать надо. А не в тупую на Garbage Collector надеяться. ;)

--------------------------------------------------------------------------------

>>mike (old student)

19 ноября 2007 года, 16:18

>>>я бы тоже растопыривал пальцы, говоря, что проекты на C++...

>>Полковник, вы не поняли. Неинтерфейсная часть (она же бОльшая) - на неделфи (т.е. это м.б. и "обжект паскаль", и C#, и C++, кто во что горазд). "Делфи/билдер" заточены под интерфейсы, особенно c БД.

Согласен.

>>Остальное - ручками. Если у вас по-другому - рад за вас.

У меня другая специфика. Нет необходимости.

Я говорил совсем о другом. Если есть система, ей заинтересовался заказчик, то лучше, чтобы она была написана на "Не Delphi", так как у многих сложилось весьма устойчивое мнение-миф о несерьезности среды разработки. В этом повинны в основном расплодившиеся "клепальщики форм и кнопок, что на Delphi действительно делается просто. Но ведь сложный код писать никто не отменял, правда? ;)

--------------------------------------------------------------------------------

>>Вадим Станкевич

Минск, 19 ноября 2007 года, 17:43

>>>>НП, решпект. Кстати, в "КВ" не было ни одной статьи про это. Вам тема, пишущая братия!

>>Майк, и сколько человек это будет читать? Эта тема хороша для RSDN.ru, а не для КВ.

Вас никто не заставляет. Это очень специфичная тема, о которой большинство даже и не догадывается. ;)

Аватар пользователя mike
>тема хороша для RSDN.ru, а не для КВ.

М.б. Просто я, рангутан эдакий, ламер-самоучка, иногда думаю - а что же это такое - репликатор БД? Да что там репликатор! Что такое код репликации? Вообщем, я рад за комповый народ: баранов вроде меня мало, и писать для них нефиг.

Страницы