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

Комментарии

Страницы

Аватар пользователя SF
Полковник, в Лазарусе, конечно, нет АДО и Мидаса, но там есть свои аналоги. Кросс-платформенные, кстати.
Аватар пользователя mike
Вообще-то, "быстрые" системы разработки хороши только для интерфейсов. При разработке "потрохов" всё равно спускаешься в дебри. Вот замутил монитор котельщика, так одих "некомпонентных" драйверов по обмену с железом по объёму кода на порядок больше, чем интерфейсов. И если вин32 умрёт - не смертельно, просто перепишутся интерфейсы.
Аватар пользователя Savely
Кстати, вопрос - какие именно 64битные системы позволяют ставить неподписанные драйвера? XP 64 - позволяет, 2003 Server 64 - вроде тоже... В списке "неправильных" - только Vista x64? Или я ошибаюсь?

Неохота платить бабки за подпись...

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

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

>>Полковник, в Лазарусе, конечно, нет АДО и Мидаса, но там есть свои аналоги. Кросс-платформенные, кстати.

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

Аватар пользователя Настоящий Полковник
SF, меня особенно интересуют полноценные компоненты типа DataSet, какие СУБД поддерживаются. Далее, реализация аналога TRemoteDataModule, поддержка в нем TThreadingModel = tmApartment, соответственно TDataSetProvider к используемым DataSet? аналог TClientdataSet со свойством PackedRecords.

Заранее спасибо.

Аватар пользователя Настоящий Полковник
И конечно реализация двунаправленных курсоров, чего, например, в Kylix, насколько я помню, не было.
Аватар пользователя mike
>какие именно 64битные системы позволяют ставить неподписанные драйвера?

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

Во, подсчитал. Мой проект (не 1-ый, кстати) скромнее: ок. 80 тыс. строк и только 4 тыс. имеют отношение к компонентам. Последних <40. Если ОЧЕНЬ занадобится, то они могут быть заменены частично на MS-овские классы, частично на "из Сети", частично на самопальные. Проект от этого только выиграет. Поэтому не вижу причины митинговать "так просто не уйдёт". Уйдёт, не хлопая дверями.

Аватар пользователя Настоящий Полковник
Не все так просто, Майк.

У меня проект уже порядка 300 000 строк (не уверен, конечно, так как считал одной программулькой чужой). Объем только pas-файлов 11Мбайт, 208 файлов.

Есть вещи, которые просто так не переписываются, хотя все сторонние компоненты только в исходниках.

Аватар пользователя Степанов Дмитрий
Добрый день! Я начал программировать на Delphi c версии Delphi 1.0 (16 битная) и программировал до BDS 2006. Тогда, много лет назад, я был поражен, что можно так легко создавать приложения. Я тогда забросил Borland C++ 3.0 и перешел на Delphi.

Сейчас я программирую на VS2005 C# и просто удивляюсь, зачем я так долго не хотел открывать глаза на .NET. Мне смешно слушать, что .NET сырой и т.д... он уже давно не такой сырой, как хотелось бы разработчикам Delphi Win32.

Просто хочу сказать, не бойтесь переходить на C#, он очень легок в изучении после Object Pascal. Сначала я программировал на C# только сетевые приложения ASP.NET, а на Delphi локальные. Но вот теперь я перешел и при разработке локальных приложений на C#. В качестве БД использую Firebird.

Не бойтесь перемен... удачи и успехов.

Аватар пользователя Andy
Уважаемый Степанов Дмитрий. Если я правильно понял, вы передлагаете всем поголовно переваливать на C#, потому-что он легок в изучении и уже не сырой?

Но мне кажется, что пока еще нет идеального универсального языка, и в различных применениях у каждого языка есть свои преимущества и недостатки. Я много лет работаю с C#, еще дольше - с Delphi, и мне никогда не придет в голову писать настольное DB-приложение на Шарпе, потому-что Delphi для подобных задач пока еще значительно удобнее и генерирует на выходе машинный код. А поскольку приложение будет затем продано сотням клиентов, мне не надо запариваться, какая операционка стоит у конкретного клиента и есть ли в ней DotNet. Сейчас занимаюсь трехзвенкой, и серверная часть, понятно, реализуется как Web-сервис на Шарпе - вот здесь он хорош!, но клиент все равно на Delphi по причинам, указанным выше.

Страницы