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

Комментарии

Страницы

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

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

+5.

Аватар пользователя mike
>Майк, Вы меня огорчаете.

Знаю. И прошу простить. Это от фекалий, атаковавших комп в период моей отлучки. И что характерно - как и при переходе на 8 байт - никто не отвечает!

Аватар пользователя SF
Specially 4 Полковник. Я не знаю насчёт тех особенностей БД в Лазарусе, которые Вы спрашивали, так как использовал FIBL и работал с Firebird. Но есть русскоязычный сайт http://freepascal.ru/, и там можно спросить это всё на форуме.
Аватар пользователя Настоящий Полковник
SF, спасибо.
Аватар пользователя Инкогнито
>>За счет продуманного кэширования на стороне application server тот же хибернейт разделывает JDBC под орех. И прикрутить кэш к хибернейту на порядок проще чем к JDBC.

НП>После этой фразы разговор закончен. No comments.

Весьма конструктивный ответ с вашей стороны. Что ж стройте из себя умника и дальше :-)

Аватар пользователя Настоящий Полковник
>>продуманного кэширования на стороне application server

База на, допустим, 10 миллионов объектов (пусть клиентов) - и никакое кэширование не поможет.

Помню, когда на одном проекте, в котором использовалась еще EJB 1.1, я задал банальный вопрос: а как отсортировать, допустим, миллион записей в бине? Если кто знает, то в EJB 1.1 не было поддержки "order by". И никто не задумывался об этом. Ну, EJB - rulez forever же. Но ответ я получил: жавой будеи сортировать. Я говорю: вы что - обалдели? Ответ: ну.... тогда пусть кастомер купит себе кластер. На что я ответил, что на месте кастомера послал бы таких ламеров далеко и надолго еще до заключения контракта.

Конструктивный ответ? ;)

Аватар пользователя Инкогнито
Glen, ты наивный человек. Есть масса пишущих программы физиков, инженеров, экономистов - просто они пишут специфический софт, а не массовый, вот они и не на слуху.
Аватар пользователя Настоящий Полковник
>>Инкогнито

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

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

Glen прав в большинстве случаев. Есть исключения, но они достаточно редкие.

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

Думаю, это - наследие периода поздней перестройки и раннего капитализма (:-)) - где-то с конца 80-х до начала 2000-х. Тогда множество учёных и инженеров разом оказались невостребованными и вынужденно переквалифицировались в управдомы - то есть в программисты.

Страницы