C VS DELPHI.

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

Итак, клан С/С++ защищает TanaT. Клан Delphi защищает Horrific.

Правила боя следующие:

1. Битва происходит до первой пущенной капли крови.

2. Холодное оружие в ход не пускать, зубы и половые органы холодным оружием не считаются :).

3. Сзади и ниже пояса не бить, особенно половыми органами :).

4. Обсуждать только Си и Delphi и ничего больше.

Право первого удара по жеребьёвке получает TanaT. Итак, представителей кланов просьба занять места в углах ринга .... ФАС!!!

РАУНД ПЕРВЫЙ.

TanaT: Язык Си является стандартом, поэтому он существует практически во всех ОС, а Delphi только для Windows и Linux, и то, Linux поддерживается только последних версий. Старые ОС просто позабыты и позаброшены (проступают капли слёз на глазах :)).

HORRIFIC: Ничего, всё ещё впереди. Delphi - быстро развивающийся язык и когда он получит должную распространённость, его варианты будут на всех ОС.

TanaT: Благодаря стандартизации Си, каждый, кто захочет создать свой компилятор, обязан как минимум придерживаться установленных норм. А вот с Delphi каждый может делать всё, что захочет.

HORRIFIC: Стандарт - это круто. А ты не думал, что языки программирования развиваются слишком быстро, и в них постоянно что-то меняется. Производителям компиляторов Си приходится тащить за собой ворох старья, которое стандартизировано ещё в 70-е годы, а в Delphi просто обрубили всё это дело и создали новый язык, отдалённо похожий на Pascal. Точно так же дядя Борман поступил и с C++ Builder, который обладает той же визуальностью и мощью, что и Delphi, но в большинстве своём нарушает стандарт на язык Си. Благодаря отказу от стандарта, компиляторы от дяди Бормана смогли получить свою полную визуальность и при этом удобство разработки.

TanaT: Знаю я вашу визуальность!!! Сидишь как полный лам и расставляешь пимпочки по формам!!! А где же сам процесс кодинга? Расставлять фигурки можно научить и обезьяну, а вот кодить как настоящий мужик дано не каждому.

HORRIFIC: Ты чё меня за ламера пингуешь :) ? Если такой крутой, то пиши на ассемблере или лучше в машинных кодах. Вот тут тебе будет процесс кодинга и соединение с космосом в одном флаконе :). Только не забудь пивом запастись на ближайшую пятилетку, потому что даже простейшую утилу написать в машинных кодах, это тебе не красотку чмокнуть :).

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

TanaT: Ты давно у зубного был?

HORRIFIC: Да я как-то на зубы не жалуюсь.

TanaT: Сейчас пожалуешься :)!!! Возьмём, например, Visual C++. У него есть достаточно удобные мастера, которые могут создать тебе шаблоны будущих прог. Ты просто выбираешь, что тебе надо и Visual C++ без проблем генерирует тебе нужный код. После этого ты только добавляешь то, что нужно и прога готова.

HORRIFIC: Знаю я твоих мастеров. Только и успеваешь кликать дальше, дальше, дальше, а в итоге глупейшее окно. И всё равно все необходимые элементы управления приходится создавать вручную.

TanaT: А ты ни разу не слышал про редакторы ресурсов? Или ты с детства глухой на оба уха :)? В Visual C++ любое диалоговое окно можно создать, визуально расставляя все необходимые элементы управления!!!

HORRIFIC: Ну-ну. Я такую визуальность проходил в первом классе. В Visual C++ при визуальном проектировании диалогов ты можешь использовать только чуть больше десятка стандартных компонентов. Всё остальное это будут OCX компоненты, которые требуют регистрации в системе, а это тебе грозит:

1. Настоящим геморром при переносе кода на другую машину.

2. Приходится писать инсталлятор, который будет устанавливать прогу, устанавливать OCX файлы и регистрировать всё это.

3. Количество файлов увеличивается и уже невозможно создать программу из одного файла.

4. OCX компоненты могут потребовать у пользователя перезагрузку компа, а это не многим понравится.

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

TanaT: Ну и пускай прога тянет за собой вагон дополнительных файлов, зато запускной файл получается меньше. А если у тебя руки выросли из заднего прохода и ты не можешь написать инсталлятор, то это твои проблемы и Си не виноват, что ты родился с ошибкой в коде ДНК :). Попробуй сдаться учёным, и пускай они попробуют расшифровать твою ДНК? Из-за грубейшей ошибки, они не смогут расшифровать её даже за 100 лет :).

HORRIFIC: Ой как смешно!!! Ты чё мне решил порты просканировать :)? Если мне надо будет уменьшить код проги, я все лишние компоненты могу убрать в DLL файл и потом обращаться к ним. И я так же получу вагон файлов и минимальный запускной файл. А инсталляторы писать мы умеем. Для Delphi хорошо адаптированный Install Shield, который без проблем умеет регистрировать в системе любые OCX компоненты и всё остальное фуфло.

TanaT: Стоять Мурка, вот тут мы подошли к хорошей теме. На Delphi невозможно создать прогу очень маленького размера, даже если абсолютно всё выкинуть в DLL.

HORRIFIC: Приплыли!!! Ты где был последние пять лет? Тебя случайно зовут не Маугли или Тарзан? На Delphi возможно практически всё и мизерный код не исключение. Ты просто отказываешься от визуальности и не используешь объектную библиотеку VCL, а пишешь на чистом API. Точно так же и в Си. Если хочешь получить маленький код, то откажись от MFC и ощути все прелести кодинга на чистом WinAPI. Вот тут уже геморра получишь и ты.

TanaT: Вот я как раз таки и не получу. У меня есть мастера, которые хоть чуть-чуть да помогают.

HORRIFIC: Ну и что этот мастер может? Все его варианты минимальных приложений сводятся к двум или трём разным видам. Просто создай такие шаблоны на Delphi и используй.

TanaT: Так вот тебе ещё создавать надо, а у меня всё уже готово. Только пару раз кликни и готовый шаблон перед глазами.

HORRIFIC: Я не понял. Ты же сам кричал, что это круто создавать код руками. Вот и создавай его в Delphi. Аааа схавал :)?

TanaT: Ну а ты же говорил про визуальность, какая она крутая!!! Что же ты будешь ручками бедный работать, локти пачкать? Аааа подавился :)?

HORRIFIC: Но потребность в мизирных прогах возникает очень редко. Чаще приходится создавать проги с каким-то интерфейсом, где размер кода не так важен?

ГОЛОС РАЗУМА: Брейк!!! Первый раунд можно считать оконченным. И тут можно подвести одину маленькую черту. При кодинге программ напичканных окнами и разными элементами управления, Delphi становится наиболее удобным. Программы можно создать быстрей, чем даже при использовании мастеров на Visual C++. Но при кодинге маленьких утил, которые должны незаметно сидеть в памяти и занимать мало места все преимущества визуального кодинга исчезают. Даже можно сказать, что у Visual C++ появляется небольшое преимущество в удобстве. Пусть оно маленькое, но оно всё же есть.

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

РАУНД ВТОРОЙ.

TanaT: Нас, кодеров на Си, всегда будет больше чем вас! Знаешь почему? Потому что за нас еще дядя Билл. Хотя почти все его системы немного страдают на голову :), его языки, входящие в состав Visual Studio, является основным средством разработки.

HORRIFIC: Уаууу!!! Нашёл чем гордиться. Если ты будешь кодить на Visual C++, то ты лишаешься всех прелестей демократии. Придётся использовать только то, что навязывает M$, а попытки воспользоваться чем-то другим будут встречены таким геморром, что пожалеешь о том, что тебя мама родила.

Корпорация Borland, как бы является независимым разработчиком. Чем это грозит? Давай взглянём на ту же технологию CORBA, которая предназначена для организации распределённых вычислений. CORBA великолепно работает как на UNIX, так и на оконных системах, а значит ты из своих окошек сможешь в полном объёме использовать вычислительную мощь *nix. Ты думаешь, это нравится Microsoft? Ну, конечно же, нет. У неё есть своя технология COM+, которая работает только под Windows (попытки перенести её под *nix пока что неудачны). Так что если ты работаешь под Visual C++, то ты не сможешь использовать CORBA и для распределённых вычислений придётся ставить только оконные сервера. А тут ты уже должен догадаться, чем всё это грозит.

TanaT: Благодаря дяде Гейтсу, ненавидящему Delphi, все описания системных Win API функций идут с синтаксисом и примерами на Си. Ты посмотри сейчас, что творится в любой виртуальной библиотеке или обычной книжке: все с названием "Азбука Win API" или "Системное программирование под Win32" связано отнюдь не с Delphi! DDK и SDK взаимодействуют тоже не с этим как его, а черт, вот Delphi!

HORRIFIC: Во-первых, Билл с удовольствием полюбил бы Delphi, но он просто очень сильно любит Basic. Ты наверно слышал о существовании этого выкидыша? Так вот, Билл и дядя Борман в своё время заключили соглашение, по которому Borland отказывается от разработок своих компиляторов Basic, а MS не трогает Pascal.

Во-вторых, описания API функций действительно идёт с синтаксисом Си. Мне трудно признаться, но помощь по Delphi идёт в нормальном варианте, а помощь по WinAPI просто копия из Си. Дядя Борман просто получил разрешение на поставку со своими средами разработки этой помощи. Возможно, что он переписал бы её с учётом синтаксиса Delphi, но он этого не делает. Возможно, тут действует какое-то очередное давление со стороны Билла или ещё одно негласное соглашение. Но мы привыкли. Не так уж сложно смотреть на Си и писать всё то же самое на Delphi. Просто нужно запомнить, что тип int в Си равен типу Integer в Delphi, ну и ещё пару отличий.

TanaT: Чё ты меня флудишь :)? Ты вообще слышал про новый язык С#, связавший лучшее от С++ и Java, являющийся самым новым и перспективнм средством разработки приложений технологии .NET, продолжает линию С++. И при этом Microsoft не забросила разработку Visual C++, основной рабочей лошадки любого серьезного :) кодера.

HORRIFIC: Я вижу, что ты решил меня забрутфорсить. Вот тут как раз и сказываются недостатки стандарта Си. Просто MS задолбалась тянуть старьё и решила поступить как дядя Борман - отбросить всё старое и создать новый язык. А вот про технологию .NET флудить меня не надо. Что там есть такого нового и революционного? А нового там только реклама. Очередной трюк Билла и чемодан громких слов, а не технология .NET.

TanaT: Не правда! Не правда! Техннология .NET от Microsoft включаетя себя помимо всякого хлама еще и мощнейшую связку: C# и Visual Java++, которая в ближайшем будущем будет заменена на мощнейшую Visual Java#. Язык Delphi с самого начала не разрабатывался как средство WEB программирования! Конечно, в него потом вошли мощные средства разработки, но их не сравнить с Java! А Си-кодер как раз и использует мощь всей Visual Studio. А основное, это Java, альтернативы которой у Бормана нет и никогда не будет. А Си и тем более С# дружат с Java, в отличие от Delphi.

HORRIFIC: Java не может дружить с C#, если не нарушать все правила виртуальной машины Java. Заметь, что ты говоришь про Visual Java#, а не читый Java, который создала Sun. Я больше чем уверен, что Java# потеряет переносимость и универсальность, а значит, что ей грошь цена. Ну ладо, это пока только намётки. Посмотрим, что получится на деле. Мы можем долго спорить о том, чего ещё нет. Вот когда появится Visual Studio .NET, вот тогда и вернёмся к разговору.

Ну я понимаю, что ты рад хоть какому-то обновлению, потому что Visual C++ не обновлялась уже с 1998 года, а последняя версия Delphi датируется 2001-м годом. Чувствуешь разницу в три года? Visual Studio не изменялся уже около 4 лет. А теперь прочувствуй, сколько всего изменилось за это время? Вот именно. В Delphi 6 уже есть многое из того, чего нет в Visual Studio. Так что если захочешь использовать новинки в VC++, то придётся искать/скачивать обновления. А в Delphi всё это уже интегрировано.

TanaT: Я согласен, действительно давно не было новых версий этого дистрибутива, но недавно Мелкомягкая пригласила Стенли Лимпмана (он участвовал в создании оригинального С++) в компанию разработчиков Visual C++. Вот выйдет новый релиз Visual C++, посмотрю как вы все запоете!

HORRIFIC: Жду и разминаю горло. Вот только думаю, какую бы песню выучить к этому моменту? Наверно что-нибудь из серии "Ты ж мэнэ спидманула" :).

А что ты скажешь по поводу надёжности твоих проектов. Во-первых, в прогах на Delphi количество кода во много раз меньше, чем на Visual C++. Это значит, что нужно на много меньше времени на отладку программы и вероятность ошибок в самых простых местах практически ничтожна.

TanaT: В принципе ты прав, но в Visual Studio существует собственный мощнейший отладчик. По этому отладчику существует туева хуча документации, а также любая книжка, типа: "Отладка Windows-приложений", повествует именно об этом отладчике. К тому же не стоит забывать и помощь со стороны дяди Билла, а именно Visual Studio, DDK и SDK. В SDK есть прекрасный ядровый отладчик, по-моему, он называется windebug. К тому же и в DDK и в SDK есть огромное количество средств отладки, всяких инспекторов и еще куча такого хлама. Так что про отладку, я бы на твоем месте не заикался.

HORRIFIC: В Delphi возможности исключительных ситуаций значительно превосходят те же возможности в Visual С++. Это значит, что ты можешь ограничить сомнительные участки, чтобы они не привели к краху всей системы. В Visual С++ исключительные ситуации выполнены коряво.

TanaT: И в чем же корявость Visual С++? Там тоже есть исключительные ситуации?

HORRIFIC: Да, в Visual С++ они есть и ты можешь их использовать. Только вот твой любимый Билл не использует их. Да и внутри самой библиотеки MFC не используется эта возможность. То есть, если ошибка произойдёт внутри MFC из-за неправильно переданных пользователем параметров, то крах неизбежен. А это значит, что перед каждым использованием возможностей MFC, ты должен проверить на корректность введённой пользователем инфы.

В Delphi, библиотека VCL уже защищена от таких проблем, и я могу не заниматься лишними проверками. Поэтому приложения на Delphi вылетают, а окошки не трогают. А если вылетит прога написанная на Visual C++, то Windows может полететь следом.

ГОЛОС РАЗУМА: Надёжность окошек мы тут не обсуждаем. За нарушение правил битвы, Horrific наказывается одним годом исправительных работ в компьютерном клубе с компьютерами на базе процессора Windows 95 :).

TanaT: Давай вернёмся к DDK. Что-то я не слышал, чтоб на Delphi драйвера писали! Может ты, что знаешь? Нет. Не так, типа:

BEGIN
ASM
.....
END
END.  

Так ты писал про асм-вставки в статье "Супер возможности Delphi" Х за ноябрь 2001 г. Ты там, кстати, рассказал, как отказаться от использования VCL, тоже мне супер возможности. Так вот, на чем я остановился? Ах да. На Visual C++ вполне можно создавать, например VxD драйвера, без асм-вставок вообще. Про это было написано в "Компьютер Пресс", по-моему, в феврале 2001 г. Каково?

HORRIFIC: То, что на Delphi не пишут драйверы, так это не значит, что это нереально. Зайди сюда http://www.adwin.ru/dinfo/materials/vxd.phtml и почитай, как всё это просто. Правда, там действительно используются вставки на asm, но для настоящего кодера это не страшно. В статье описан очень хороший шаблончик, который можно написать только один раз и потом использовать без проблем в любых драйверах.

TanaT: Кстати, наш дядя Билл (наш потому что ненавидит Delphi) выступает "законодателем моды". Недавно взял вот и создал WinXP. А система та не простая (и не золотая, слава богу), а 64-битная. И доки сразу в MSDN появились, мол 64-битные приложения это круто потому то потому то (и звучит все убедительно), а программировать эти 64-битники надо так то. И опять то все на Си.

И среда разработки и средства отладки и примеры кода и вся теория по 64-битному кодингу - все на Си. Вообще почти вся вселенная вокруг Си вращается. Кстати, я забыл сказать, про Delphi в дркументах MSDN не упоминается! :) И что ты, Horrific, будешь делать, когда все юзеры поменяют свою Windows 2000 на Win XP Professional? Надеешься на новый релиз от своего Бормана?

Такими темпами, скоро версии Delphi превысят наше летоисчесление! Прикольно тебе будет кодить, к примеру на Delphi 2136!

HORRIFIC: Ну я же тебе сказал, что есть такое соглашение, по которому дядя Билл не лезет в душу в Delphi. Поэтому и нет никаких упоминаний. А про 64-бита, так это ты торопишься. WinXP пока что ещё 32-х битный. Остальные 32 появятся позже. А доки действительно появляются раньше и заранее вешают лапшу на уши бедных кодеров.

А теперь вспомним недавнее заявление Билла, что он отказывается от технологии MDI (Multiple Document Interface). Теперь Word и Excel будут построены по новой технологии, которую и советуют использовать. А в Win2000 мол не будет больше многодокументных приложений. А вот теперь запусти в Win2000 консоль MMC. Посмотри, по какой технологии она построена? Вас причесали, как маленьких, а вы довольны, что расчёска не нужна. MDI жила, живёт и будет жить потому что она удобна!!!

Вопрос: "Зачем Билл делал такое заявление?". Всё очень просто. Он же законодатель моды (супермодель, которой только в кино сниматься) и все ему верят. После этой лапши все конкуренты бросились переделывать свои проги, отказываясь от MDI, а Билл в это время движется дальше. Так что из Билла модница некудышняя.

TanaT: Но дядя Борман, он то ведь тоже не против Си. Он за меня, так же как и за тебя. А его Borland C++ Builder отнял у тебя почти все козыри. Теперь хочешь, создавай мелкие приложения, не критичные к размерам, на Borland C++ Builder; хочешь программь на Visual C++ драйвера или DLL-ки.

HORRIFIC: В C++ Builder от чистого Си остались только рожки да ножки. И дядя Борман больше за меня, потому что C++ Builder всегда выходит как минимум на 3 месяца позже, чем Delphi. И это не потому, что компилятор Си сложнее и требует больше времени, а потому что дядя Борман сам же и душит Си. Его козырь это Delphi. А C++ Builder - это всего лишь копия Delphi c синтаксисом Си. И направлена она только на тех, кто хочет ощутить мощь Delphi, но кого причесали Си-шники в корявости языка Pascal.

На мой взгляд, C++ Builder - это всего лишь промежуточное звено для перехода от Си к Delphi и я как раз по этому пути и прошёл (о чём не жалею). Благодаря C++ Builder я ощутил всю мощь Delphi.

ГОЛОС РАЗУМА: В какой-то степени Horrific прав. Корпорация Borland действительно слишком мало внимания уделяет C++ Builder. Если бы она немного потопталась, то могла бы продвинуть его. Ведь эта среда могла бы стать золотой серединой для кодеров на Си и Delphi. Но об этом позже.

TanaT: Си намного лучше интегрирован с ассемблером. Во-первых, TASM загнулся на версии 5 и уже давно, а MASM развился уже до 6.15 версии и является помощнее последнего TASM'а раз в 5 минимум. Во-вторых, используя асм в Delphi, ты используешь только асм от дяди Бормана. А используя в Си, хочешь от Бормана, хочешь от Гейтса. А от последнего он явно покруче. В Inline процедурах качество ассемблера очень важно. Таким образом, разработка низкоуровневого ПО остается только за Си.

ГОЛОС РАЗУМА: Протестую!!! Какой asm круче - это очень спорный вопрос и к нашей теме не относиться. Поэтому эта претензия с обсуждения снимается. Ещё одно нарушение правил, и TanaT будет посажен на пожизненное программирование под MS-DOS.

HORRIFIC: Зайка моя, я твой тазик. К проектам на Delphi можно подключать не только модули на MASM, но и на Си. А вот к Си подключить модули на Delphi проблематично. Так что любую твою работу я могу использовать, а то, что сделаю я, к Visual C++ не пришпандолишь :).

TanaT: При разработке приложений для WEB, программист, использующий Visual C++ 7, входящий в состав пакета для разработки приложений технологии .NET, имеет намного больше преимуществ перед Delphi-кодером, так на него работает почти весь состав Visual Studio 7, а на Delphi только компилятор Бормана.

HORRIFIC: Не вижу преимущества. Точно так же я могу перефразировать, что когда я пишу на Delphi, то на меня работает почти весь состав среды разработки Delphi, а на Си-шника работает только Visual Studio 7. Если ты имеешь ввиду, что ты можешь в C# подключать модули из Visual Studio, то это конечно же круто. Только я тебе напоминаю, что я могу подключать и твои модули на Си. А это значит, что на Delphi кодера работает не только Delphi но и любой Си-шник. А вот на Си-шника дельфист работать никогда не будет :). 

ИТОГИ МАТЧА!!!

Как видишь, у каждого языка есть свои преимущества. И если бы хотя бы один из языков ушёл в значительное отставание, то он бы умер. Тут проблема в другом, просто они направлены на решение различных задач. Оболочка Delphi больше подходит для написания офисных приложений, утилит и любых программ использующих окна и элементы управления. Язык Си удобнее там, где визуального интерфейса нет. Если ты программируешь игры, драйверы или какие-нибудь сервисы без окон, но выполняющие какие-то задачи, то твой выбор - Visual C++. 

Говоря о том, что какой-то язык больше подходит для решения определённой задачи, нельзя сказать, что на нём нельзя делать что-то другое. На Delphi так же можно создавать игры (и есть реальные примеры), драйверы и маленькие утилиты. Просто тут он не так удобен. Точно так же дело обстоит и с Visual C++, который так же можно использовать для написания простых утилит и офисных приложений. Просто тут расходы будут больше, как умственные, так и временные :). 

Какой выбор сделать тебе? Скорей всего выбирать придётся из того, что чаще придётся писать. 

Идеального языка программирования нет, и не может быть. У каждого есть свои преимущества и недостатки. 

Многие кодеры надеялись, что споры прекратятся с выходом C++ Builder от фирмы Borland, но переход на него почему-то слишком тормознутый. Те, кто сделал это, оказались в большом преимуществе, потому что они используют самый распространённый язык Си и самую мощную визуальность от Borland. Но и у этого языка есть недостатки - на нём ещё слишком мало кодят и достать под него модули или компоненты немного сложнее. Да и очередные версии выходят немного позже, чем у Delphi. Но если кодеры обратят свой взгляд на C++ Builder, то наступит время примирения, потому что эта оболочка может воспринимать в одном проекте модули на С++ и модули написанные на Delphi. То есть мы получаем два языка под одной оболочкой. Круто!!!

З.Ы. Несмотря на такой кровавый бой, оба представителя после матча поблагодарили друг друга за беседу. Так и должно быть, ведь несмотря на разногласия в языках программирования, у них очень много общего - ПИВО :). 

Внимание!!! Если ты копируешь эту статью себе на сайт, то оставляй ссылку непосредственно на эту страницу. Спасибо за понимание