Интервью с Владимиром Кладовым, автором библиотеки 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, а текстовый редактор с вызовом внешнего компилятора, не более. А отладчик - это очень серьёзная задача.
- Спасибо. Думаю, читатели присоединятся к моим пожеланиям всяческих успехов.
Интервью провёл Вадим СТАНКЕВИЧ
Комментарии
Страницы
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. Потом никто не понимает, что, где и для чего нужно. ;) А таблички в базе с полями так именовать - вообще извращение. ;)
За счет хорошего пиара 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 и т.д.
Полковник, вы не поняли. Неинтерфейсная часть (она же бОльшая) - на неделфи (т.е. это м.б. и "обжект паскаль", и C#, и C++, кто во что горазд). "Делфи/билдер" заточены под интерфейсы, особенно c БД. Остальное - ручками. Если у вас по-другому - рад за вас.
Майк, и сколько человек это будет читать? Эта тема хороша для RSDN.ru, а не для КВ.
Минск, 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, а не для КВ.
Вас никто не заставляет. Это очень специфичная тема, о которой большинство даже и не догадывается. ;)
М.б. Просто я, рангутан эдакий, ламер-самоучка, иногда думаю - а что же это такое - репликатор БД? Да что там репликатор! Что такое код репликации? Вообщем, я рад за комповый народ: баранов вроде меня мало, и писать для них нефиг.
Страницы