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

Комментарии

Страницы

Аватар пользователя AlexeyT
Спасибо, все-таки белорусские сайты часто интереснее наших, российских.

Вот такую статью врядли бы напечатали какие-нибудь CNews.

Аватар пользователя User
НП, Вы слишком много треплетесь, и слишком много смайликов. Завязывайте. :)
Аватар пользователя Настоящий Полковник
>>Из вашей фразы могу следать вывод, что у вас знания о Java и EJB 5-летней давности, т.к. никому сейчас не придет в голову связывать SQL, доменную модель и EJB чуть ли не в одном предложении.

Идите курите матчасть. Если вы навешали лапши на уши кастомеру - поздравляю. Но я бы на месте кастомера послал давно и далеко таких "специалистов".

Аватар пользователя Настоящий Полковник
>>У вас есть какие-нибудь доказательства проблем у GC, связанных с утечкой памяти? Или только голословные утверждения?

Да. И я лучше приведу цитату с одного из форумов. С некоторыми нюансами можно не соглашаться (там описана ситуация с Java ME), но в целом картина описана верно.

"В Java, как известно, lazy механизм освобождения памяти и срабатывания garbage collector'а (GC). Отсюда часто вытекает ряд неожиданных проблем. Внутри MIDP библиотеки (которая находится внутри Nokia) с вероятностью 90% вполне может быть так, что при загрузке изображения ему выделяется какой-то дескиптор (system handle) который может быть связан

Так вот вполне вероятен следущий сценарий:

Когда вызывается интенсивный "batch"-процесс, и вся эта система нагружается большим количеством работы, не успевает отработать GC, и/или хип фрагментируется (я не только про java-heap). В памяти скапливаются объекты, каждый из которыйх держит хэндл некоего ресурса телефона (скажем zlib-декомпрессора). Объекты могут скапливаться еще и потому,

что скорее всего в процессе загрузки картинок нигде нет небольшого Thread.sleep(), и данный поток загрузки картинок "забивает" собой все потоки. Соответсвенно, память выделяется столь интенсивно, что хэндлы кончаются прежде чем отработает GC."

Вот поэтому и говорю, что думать надо. Это никто не отменял. И для тех, кто привых аккуратно работать с памятью - проблем не возникает.

Так же, как когда-то множество людей были "испорчены" всевозможными системами для разработки на dbf. Типа Clipper, FoxPro и пр. И эти люди продолжали работать с SQL СУБД перебороми записей. О транзакциях не слышали и уже не хотели слышать. Так же как куча людей "испорчена" Windows: скопировать файл в командной строке не сопсобны, загрузочный диск - то же нет.

И я очень рад, что когда-то (92 год) начинал с C++ и Btrieve (пусть даже не SQL-вариант на тот момент).

Удачи, ребята в вашем "трудном" деле.

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

Те, кто изначально понимают проблемы, используют только Session Bean. Entity заменяют на свои, например DAO, где пишут нормальный скоростной SQL ручками.

Те, кто не в курсе, сначала активно используют Entity Bean. Затем, когда проект разрастается и возникают проблемы реализации сложной функциональности и производительности, следуют по тому же пути, что и первые.

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

Аватар пользователя mike
>Вы предлагали, если я правильно помню, что-то вроде "как написать универсальный репликатор"...

Неверно. Я подразумевал рассказ о том, и что такое репликтор БД, и что такое репликация. Большинство на спецкурсы не ходило.

>...тема вполне для КВ.

ООООО! Счастье!

Аватар пользователя Вадим Станкевич
Майк, Вы меня огорчаете.
Аватар пользователя Реальный Пацан
>>Из вашей фразы могу следать вывод, что у вас знания о Java и EJB 5-летней давности, т.к. никому сейчас не придет в голову связывать SQL, доменную модель и EJB чуть ли не в одном предложении.

НП>Идите курите матчасть. Если вы навешали лапши на уши кастомеру - поздравляю. Но я бы на месте кастомера послал давно и далеко таких "специалистов".

Лапши про что? Выражайтесь яснее, а то догадываться про что вы там думаете очень сложно. Повторю еще раз, сейчас Entity Beans используется только в старых проектах, где надо поддерживать уже существующий код писаный, еще при царе горохе.

В новых проектах все используют легкие POJO-based фреймворки Hibernate, JPA, JDO в связке со Spring. Там где очень критична производительность используется обычный JDBC или Spring JDBC, но это далеко не основная часть кода. При умелом использовании (спрятять весь Data Layer в DAО) бизнес-логика никак ни привязывается к конкретной технологии работы с БД.

Кстати, насчет EJB.

>Те, кто изначально понимают проблемы, используют только Session Bean. Entoty заменяют на свои, например DAO, где пишут нормальный скоростной SQL ручками.

DAO это хорошо, но уже давно ручками почти не пишут "нормальный скоростной SQL", только в случаях, когда это действительно может быть оправдано. За счет продуманного кэширования на стороне application server тот же хибернейт разделывает JDBC под орех. И прикрутить кэш к хибернейту на порядок проще чем к JDBC.

Почитайте про основные отличия Entity Beans и Hibernate, чем последний лучше голого JDBC. А то все про какую-то лапшу...

Аватар пользователя Настоящий Полковник
>>За счет продуманного кэширования на стороне application server тот же хибернейт разделывает JDBC под орех. И прикрутить кэш к хибернейту на порядок проще чем к JDBC.

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

Аватар пользователя Glen
"То есть будут работниками этой самой IT. Даже если по должности будут ещё кем-то: агрономами, физиками, архитекторами дизайнерами, биологами"

Не верю в такой прогноз, и вот почему: он не сбывался минимум дважды. Один раз, когда в 50-х годах изобрели первый язык программирования - Fortran. Тогда все возликовали, что в программистах более нет нужды, ибо "любой математик и физик способны будут запрограммировать на Fotran-е всё, что им надо".

Второй такой ошибочный прогноз был сделан в начале 90-х, когда появились средства RAD. Тоже горячие головы поверили, что сейчас любой непрофессионал сможет "что-то" написать, точнее, нарисовать в RAD :-)

По прошествии многих лет мы видим: программированием занимаются профессионалы и только профессоналы. Конечно, разные по уровню: один пишет на JScript проферку правильности заполнения формы в Интернет-магазине; второй пишет на C ядро операционки. Но ни одного пишущего прораммы биолога или физика не наблюдается.

Страницы