"Платформа 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
Логик, Ассемблер - просто удобная запись опкодов, Вы это не хуже меня знаете.
Аватар пользователя Инкогнито
SF

>Универсальным языком считаться может только низкоуровневый - сиречь Ассемиблер.

Полностью согласен, что Assembler самый универсальный язык. Когда-то во времена DOS было очень интересно писать на нем программы. Да и сейчас иногда делают вставки. Но при написаннии программ на Asm есть существенные недостатки по сравнению с С:

1. Программы на ассемблере зависят от реализации инструкций конкретного типа процессоров. Программы на C не зависят от типа процессора. Кроме этого при переходе из 32bit в 64bit - на С гораздо меньше подводных камней.

2. Есть две традиции программирования - ПЕРВАЯ: хакерская традиция (относится к некоторым линуксоидам, также к сожалению часто всё ещё пропагандируется в ВУЗах) и

ВТОРАЯ: традиция проектирования легкочитаемого удобного кода (паттерны, рефакторинг). Если первая игнорирует человеческий фактор, призывая писать неочевидный, запутанный код в понимании среднего/слабого программиста, используя "криптоподход", то вторая - делает на человеческом факторе главный акцент -- код должен быть максимально простым, легко воспринимаемым, понятным.

Простые примеры:

- программист хакерской традиции на С++ будет писать A+=B желая "сэкономить" пару байт длины кода

- программист традиции проектирования с учётом человеческого фактора будет писать только A = А + B

- программист хакерской традиции будет использовать сокращения при написании навания функций, структур, именно из хакерской традиции появилось например такое уродство как strcpy

- программист традиции проектирования с учётом человеческого фактора создаст либо отдельный удобный класс String в котором спрячет эту функцию, либо переименует ее с помощью макросов в StringCopy

По поводу источника рождения мифа о "сложности" С++:

Не скрою, есть у меня масса претензий к тому как спроектирован STL в C++. Библиотека красивая, но опять же создана в хакерской традиции, и при её использовании часто приходится писать врапперы только с целью учета человеческого фактора.

Посмотрите как, например, удобно спроектированы функции Майкрософта из .NET или в Delphi - это и есть наглядный пример ВТОРОЙ традиции. Именно так надо было проектировать стандартные библиотеки C++.

Но не смотря на это, С++ язык очень гибкий, и позволяет полностью избавиться от остатков хакерского подхода, хотя далеко не каждый может сообразить что можно просто проигнорировать навязанные концепции и начать писать на C++ в совершенно другом стиле.

Программы на ассемблере тоже можно абстрагировать от конкретной платформы. Но если заняться написание программ на asm всерьёз используя принципы ВТОРОЙ традиции (проектирования легкочитаемого кода), то так или иначе придешь к выводу что удобнее применять макросы, вроде языка PLM. А если эволюционировать язык PLM, то он превратится в C.

С/C++ - это наиболее эффективный инструмент для сторонников ВТОРОЙ традиции. Золотая середина для тех кто любит ассемблер, но не может смириться с недостатками хакерской традиции и проблемами портирования. Эффективный потому, что с одной стороны есть желание писать максимально быстрый код, с другой стороны - максимально удобный код для воспринятия программистом средней подготовки, а также есть желание абстрагироваться/не зависеть от конкретного типа процессора, и более очевидным способом создавать кросс-платформенные врапперы.

Java/С# - это следующий шаг по пути ВТОРОЙ традиции. Но здесь эффективность уже сильно теряется. Это, можно сказать, среда для фанатов ВТОРОЙ традиции, которые отказываются даже самостоятельно работать с памятью. Конечно, каждому своё. Некоторым достаточно С++ для полного комфорта программировани, а некоторым ещё нужен дополнительный сборщик мусора.

На счет разницы между C++ и C:

C++ просто более завершенная/расширенная версия языка C. Более удобная для проектирования (ООП), получается меньше повторений кода. Но некоторые используют чистый C - и могу с ними полностью согласиться, что во многих случаях такой выбор действительно оправдан.

Аватар пользователя Инкогнито
Savely

Извините, стихами не занимаюсь.

В стихотворной форме кодировать на C# настоятельно не рекомендую. Хотя не удивлюсь, если новые менеджеры Microsoft в ближайшем будущем предложат что-нибудь похожее.

Как и говорил, использование C++ даёт программисту полную свободу, независимость от всех негативных непредсказуемых тенденций на рынке информационных технологий.

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

Да. Конкуренция c Java - это тоже одна из причин раскрутки C#. Но я более склонен считать что главная причина такого широкомасштабного пиара, это всё же C++ (об этом просто реже упоминают в СМИ). Заметьте, он был даже создан похожим, с целью переманить программистов C++.

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

Аватар пользователя Инкогнито
Только что наткнулся на интересные статьи по поводу сборщика мусора в C++.

Кому интересно, привожу ссылки:

Статья 2007 года: Transparent Programmer-Directed Garbage

Collection for C++

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2310.pdf

Статья 2006 года: Transparent Garbage Collection for C

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1943.pdf

A simple Garbage Collector for C++

http://www.devx.com/assets/sourcecode/9928.pdf

То есть если это правда, то похоже что у Java/С# вообще нет никаких преимуществ. Сейчас будем читать.

Как видите собаки лают, а караван идёт. Язык С++ активно используется серьезными специалистами, а способы применения этого языка постоянно совершенствуются.

Аватар пользователя mike
Хотя иксов не люблю, но это тот редкий случай, когда - "браво" иксу. От себя добавлю: C/C++ сильно укрепился, когда производители микроконтроллеров дружно выбрали эту языковую платформу в качестве БАЗОВОЙ. А что до .NET, то C++.NET тоже имеется.
Аватар пользователя Настоящий Полковник
Парни, есть специфика решаемых задач. Исходя из этой специфики выбирается инструмент. Можно применять универсальный C++ в любой задаче. Но иногда это просто нецелесообразно. Тем более, решение специфических задач еще определяется функциональностью инструмента, библиотек, скоростью разработки именно той специфической задачи.

Смысл спорить? Или везде надо пизвть то, что нравится? Несерьезно это.

Еще раз повторюсь: нужна гетерогенная бизнес-система с максимальной портируемостью - Java. То же самое. но с web-интерфейсом - снова Java.

Под Windows бизнес-системы - можно Delphi. О недостатках C++ Builder (аналог Delphi, но с C++) я уже Майку писал.

Системные вещи - однозначно лучше C/C++.

Микроконтроллеоы - без разговоров C/C++. Это стандарт и де факто, и де юре.

Бизнес- и web-системы можно на C++, прир условии наличия подходящего инструмента и готовых библиотек.

Все. Попробуйте поспорить. ;)

Аватар пользователя Инкогнито
>нужна гетерогенная бизнес-система

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

Аватар пользователя Настоящий Полковник
Портируемая. Которая может работать и в Windows, и в Unix.
Аватар пользователя SF
Полковник, +1 !

Страницы