Статья написана для сообщества Паскаль програмистов с целью стимулирования перехода программистов, работающих с Delphi на Java. В статье описываются основные недостатки Delphi и первые впечатления автора этой статьи при изучении Java.

Я решил написать эту статью по той простой причине, что все таки мир работает не только на Си и Си-подобных языках - все таки как ни крути еще существуют программисты, никак упорно не желающие перелазить на Си и самозабвенно программирующие на многочисленных разновидностях Паскаля и Обьектного-Паскаля (Turbo Pascal, Delphi (Object-Pascal), Modula-2, Oberon и т.д.). Естественно появление нового языка Java в мире Паскаля не прошло незамеченным - народ интересуется, что это и насколько похоже на Си.  Чтобы помочь разобраться в этом, я и решил написать эту статью.

Для понятия сначала расскажу о себе - программирую с 1989 года - причем именно на Паскале (начинал с Turbo Pascal 3.0). Сейчас преимущественно занимаюсь профессиональной разработкой компонент в среде программирования Delphi версии 5.0 (естественно на языке Object Pascal). Вопрос о том, почему в свое время я выбрал Паскаль, а не Си поднимать не буду - и так всех достали многомегабайтные конференции типа "Си/Паскаль рулез". Скажу только, что Паскаль меня привлек из за своей простоты в изучении, строгих правил, приучающих программиста к аналитическому и последовательному стилю программирования и быстрым компилятором (в те времена все таки на ЕС 1841 разогнаться сложновато было). Вот тут то меня и можно подловить вопросом - "Если все так хорошо в Пасакале - то на кой ты залез на сайт, посвященный Jave, про которую говорят, что она наследует многие качества от Си ?" . Однако как мне кажется ответ на этот вопрос довольно таки не простой и делится на 2 ответа: во первых - мало ли что говорят, а во вторых - никто и не говорил, что на данный момент развития Обьектный Паскаль решает весь необходимый круг задач. Начнем с этого пункта:

(Для облегчения сравнения я буду говорить о среде программирования Delphi с встроенным языком Object Pascal, как наиболее продвинутой среди Паскаль-систем в Windows с довольно навороченной библиотекой компонентов. Чтобы программисты, знающие Java не обвинили меня в полном невежестве, я также хочу заметить, что написал я эту статью изучив именно концепцию Java и ее технологии, а не ее синтаксис, так как любому Паскаль программисту Си синтаксис иногда очень неприятен и эти впечатления могли бы исказить мою оценку Java - как говорится - у меня еще все впереди по части отвыкания от begin ... end и привыкания к { ... })

Что можно сказать на данный момент о Delphi - мне кажется, что к сожалению Borland сбилась с верного пути и в целях выживания фактически начала искажать собственные же концепции, заложенные Delphi. Грустно - но это факт - начиная с версии Delphi 4.0 компания стала буквально впихивать новые технологии в этот продукт, махнув рукой при этом на 3 главных качества, всегда присущих Паскалю, то есть это простота, надежность и скорость. Паскаль в ней стал все более и более приближаться к Си, надежность программ в результате постоянных переделок компонентых библиотек самой Borland стала постепенно сползать к нулю, а про скорость компиляции и требования к аппаратной части я могу лишь грустно умолчать. Да простят меня поклонники Delphi - но от этих фактов никуда не скрыться - все мы получаем многочисленные Access Violation, глюки самой VCL и BDE и все подолгу ждем, пока Delphi прокрутит компилятор на 64 мегабайтах памяти. Не думаю, что Си в этом плане чем то лучше - это наглядно доказывают нам программы, выпущенный самой Microsoft, да и сторонних производителей программы просто пестрят разноцветными ошибками. По моему опыту я считаю, что все эти процесы можно смело назвать "снежным комом" - что Си, что Паскаль - оба языка ведут свое начало из тех глубоких Досовских и Юниковских времен, когда все играли по своим правилам и каждая программа чувствовала себя хозяином компьютера и работала по принципу - "Что хочу, то ворочу". Поэтому я и не удивляюсь, что многие программисты так и не смогли с Си перелезть на Си++, проповедующий концепции обьектно-ориентированного программирования. В этом плане нам, работающим на Паскале, повезло больше - уже начиная с Turbo Pascal 5.5 мы попали в мир обьектно-ориентированных программ - помню свои радостные чувства, когда изучив этот замечательный продукт я накатал собственную библиотеку работы с базами данных в виде обьектов и смог спокойненько забросить куда подальше DBase. Что и говорить - много утекло воды с тех времен, а вот проблемы не только остались, но и стали побольше. Говорить, что мне нравится в Delphi я не буду, об этом можно спросить любого Паскаль-программиста, а лучше я расскажу о том, что в Delphi меня на данный момент не устраивает:

В самых главных меня не устраивает позиция Borland, фактически забросившая работы по развитию Delphi и наверное поставившая на нем крест - все разговоры о Delphi 6.0 и о ее работе на Linux у меня вызывают только смех сквозь слезы - для Windows версию до ума не довели, а теперь вот их понесло на Linux - можно подумать там все лучше работать будет. К слову сказать я слышал, что разработчики Delphi, можно сказать те люди, которые сделали чудо, перебрались в команду разработчиков Borland Java Builder и именно поэтому я ее недавно установил на своей машине в ознакомительных целях. Не даром же Орлик теперь пишет книги и статьи не про Delphi, а про Java - что то наверное в этом есть.

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

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

Не устраивает меня и жесткая ориентация на Windows-платформы - пусть клиенты, работающие на моих программах и работают на ней, а вот себе бы я бы поставил что-нибудь получше и понадежнее (типа OS/2 или BeOS). Ну не нравится мне принцип - "На чем работает клиент, на том придется работать и мне".

Многопоточность в Delphi есть, можно сказать, что это самый простой, но не самый удобный и правильный способ реализации многопоточности процессов приложения.

Хоть Object Pascal и можно считать модульным языком, однако модульность эта довольно относительная - можно сказать она больше работает в пределах одного приложения, чем для многих - коллективная разработка программ на Delphi все таки вызывает головную боль - хотя конечно при строгом соблюдении правил проектирования проекта и выполнении всех обязательств разработчики могут коллективно разрабатывать проекты.

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

В Delphi реализованна поддержка интерфейсов, что могло бы значительно облегчить жизнь программистов и сделать разработку компонент и приложений более удобным и приятным занятием. К сожалению сама Borland никак не хочет реагировать на эту технологию и продолжает катать компонентную библиотеку в своем старом добром иеархическом наследовании классов, что и приводит к множественному накоплению ошибок и ее разрастанию из за все более расхождения между базовыми классами и невозможности использовать одновременно все их возможности в сторонних компонентах (так же я считаю, что множественное наследование введенное в С++ тоже не является верным решением этой проблемы).

Delphi на заре своего появления прекрасно доказало, что наиболее удобная среда для программиста, эта та среда которую программист способен дописать до необходимого уровня. На данный момент для Delphi создано огромное количество компонент, обеспечивающих круг очень широких задач. К сожалению из за отсутствия надежности как в Обьектном Паскале, так и на уровне VCL такие компоненты не возможно использовать в серьезных проектах, потому что нет гарантии, что они правильно работают и что при повторном очередном изменении стандартной библиотеки компонентов их авторы доработают и выпустят новую версию компонент. Получается парадоксальная ситуация - среда для разработки компонент есть, а вот пользоваться чужими страшно - в итоге нет ничего удивительного, что каждый программист на Delphi имеет собственную довольно обширную библиотеку компонент и каждый раз при решении  нетривиальной задачи изобретает новый велосипед.

Очень удивляет, что разработчики Delphi никак не хотят полностью перестроить VCL на обьектно-ориентированный уровень - исходные тексты библиотек пестрят обращениями к динамической памяти, указателям, служебные классы, такие как TList реализованны криво, и навевают мысли, что программисты Borland никак не могут забыть Turbo Pascal и Дос со своими ограничениями в 64 кб.

Очень не хватает встроенной возможности документации компонент - к сожалению собственная библиотека компонент растет довольно таки быстро, а вот писать на нее Help времени не хватает - гораздо было бы проще комментировать необходимые обьекты прямо в программе и потом по ним собирать помощь.

Почти остановилось обновление драйверов для BDE - MS SQL 7 вышел уже давно, а вот нормального драйвера под него Borland так и не сделала.

Это как говориться далеко не полный список жалоб на Delphi. Просто я перечислил наиболее важные недостатки Delphi с моей точки зрения. Только пусть программисты, работающие на Си не радуются - у них их еще больше - это можно сказать общие недостатки языков, имеющих свое происхождение с времен динозавров. С учетом того, что все таки я не мазохист, естественно я начал искать другие концепции, которые более удовлетворяли бы моим потребностям программиста. Во время выхода Java как и все Паскаль-программисты мне достаточно было только услышаьт краем уха, что она похоже на Си, чтобы испугаться и отойти подальше (о чем я сейчас очень жалею - видать у страха глаза велики). Поэтому естественно как ученик и последователь Вирта я обратился к его трудам. Не удивительно, что Оберон, сделанный аж еще по моему в 1991 году вызвал у меня благовейное удивление и досаду, почему ранее я о нем ничего не слышал. Технологии программирования, предложенные в нем были подозрительно знакомыми - вот уже почти 10 лет, как все это воплощается в Windows (COM, OLE ...) и других операционках (OpenDoc в IBM). Оберон виртуальная машина генерировала байт код, что позволяло приложению не зависить от среды выполнения. Сборщик мусора полностью снимал заботу о выделении памяти. Система модулей, заимствованная у предшественника Оберона Модулы-2 позволяла строить приложение на уровне компонентного программирования, где каждый тип (Вирт не захотел путанницы и вместо классов все таки решил называть их типами) динамически подгружался и связывался на этапе выполнения приложения, а не компиляции. В общем не вдаваясь в подробности (сайты, посвященные Оберону в Интернете есть), можно сказать, что я обнаружил то, чего мне хотелось и отсутствовало в Delphi. Единственная проблема, не позволяющая перейти на Оберон- это отсутствие коммерческих продуктов на его основе и поддержки крупных фирм разработчиков. Если Borland сделало Оберон версию продукта в те времена, то возможно сейчас весь интернет давно бы базировался на нем и Microsoft не занимала бы такое прочное положение на рынке программных продуктов. Но факт остается фактом - Оберон остался как академический язык, а на таком языке писать серьезные проекты нельзя. На сайте Оберона я прочитал, что разработчики Java оказывается перед ее созданием были у Вирта, довольно много с ним общались и даже купили его версию Оберон-машины. И вот освоив Оберон я решил взяться за Java и перейти на нее, как на основной язык написания приложений и компонент. Я был приятно удивлен, как много разработчики из Sun взяли от Oberon - фактически можно сказать что Oberon с Паскаль-синтаксисом  равен Java с Си-синтаксисом. Конечно в отличие от Oberon Java развивался дальше, как разработчику компонент мне сразу понравилась его концепция JavaBeans, надежность, многоплатформенность и многозадачность просто впечатлили, а главное сразу обрадовало, что для него есть средство разработки Borland Java Builder (все таки как не крути, а приятней переходить на знакомую платформу и интерфейс). Если учесть, что все проблемы в Delphi описанные мной выше, просто не существуют в Java, то этот язык идельно мне подходит для быстрого создания распределенных приложений, работающих на любой платформе и в интернете. Просто чтобы понять Java Паскаль программисту совсем неплохо покапаться в Oberon - потом переход на Java становится не таким болезненным.

И что еще я хочу сказать моим коллегам:

Ребята - Java как раз по духу и концепциям ближе именно к Паскалю, а не к Си, вот они (программисты на Си) и хают Java и плюются на все стороны. А то что синтаксис на Си похож - ну ничего ... привыкнем и к { } и к другим странностям - это ведь не главное в языке. До встречи в сообществе Java ... думаю наше будующее в этом хорошо продуманном настоящим обьектно-ориентированном языке.