Про споры о языках программирования.
Я часто вижу (в конференциях) и слышу (среди знакомых, друзей, коллег) споры
о том какой язык программирования лучше, к сожалению в этих спорах, часто путают
понятия, т.е. божий дар с яичницей.
Самый частый спор на наших просторах это что же лучше C/C++ или Delphi.
Давайте пойдем последовательно, если уж говроить чисто о языках
программирования, то мы имеем дело с совершенно разными понятиями.
C это стрктурированный язык программирования, основной целью которого было
создание переносимых программ в основном системного уровня, т.е. этот язык
имеет все возможности для управления программой, создание пользотельских типов
(как и интегральных так и сложных - структур), создание функций, использование
внешних библиотек и их создание, т.е. все что присуще языкам 3GL и значить
позволявшим решать задачи из любой отрасли знаний. Однако язык предоставлял
достаточно низкоуровневые возможности по доступу к области памяти и арифметику
над указателями, что в общем то возможно только если вы используете ассемблер.
И т.о. C позволяет решать задачи свзанные с достаточно низкоуровневыми, скажем требованиями, особенно при написания ОС, драйверов, программ работающих в
реальном времени, специфических программ для обработки аудио и видео, в общем
там где часто требуется работать на прямую с памятью, с портами ввода-вывода, использовать прерывания, DMA, специфические команды микропроцессора.
С++ это с одной стороны, эволюционное развитие C и вместе с тем это реализация
совершенно другой парадигмы программирования - объектно-ориентированной. Сам по
себе C++ в конструкциях выглядит как C, однако есть ужесточение по типам
данных, что резко уменьшило колличесвто трудно-отлавливаемых ошибок еще на
этапе компиляции. Но самое главное это появление сначало классов, а затем и
шаблонов.
Pascal, одно из детищ Н. Вирта, это язык изначально разработанный для быстрого изучения основ информатики в студенческой среде - это и хорошо и плохо. Хорошо - простой и понятный синтаксис позволяет быстро освоить язык и соотвественно построить очень быстрый компилятор. Плохо - язык изначально не подходит для решение каких либо специфических задач связанных с оборудованием, имеет минимум ввода-вывода.
Delphi - это эволюционное развитие Pascal, если кто помнит Turbo Pascal от
Borland начиная с версии 6.0 предложил совершенно новый язык Object Pascal, в
сущности сам Pascal остался таким же и это хорошо, добавились классы и язык стал
поддерживать объектно ориентированную парадигму.
После очень краткого описания языков по которым в основном и идет сыр-бор, хочется сказать конечно об инструментарии т.е. среде разработки, библиотеках и различных дополнительных средств.
В большинстве спорах о языках программирования, спорящие начинают говорить
именно о превосходстве средств разработке. В общем это правильно несмотря на то
какой бы не был язык изящным без инструментария он представляет скажем так
только теоритический интерес, а не практический. Т.е. если вам предложат
написать приложение с пользовательским интерфейсом и доступом например к СУБД,
на вашем любимом языке программирования без среды разработки, библиотек
(компонентов) - то на это подпишутся только энтузиасты. Все мы прекрасно
понимаем программирование это средство зарабатывания денег - быстрее пишешь,
быстрее получаешь дивиденты. Постороить свою инфраструктуру библиотек,
компонентов и т.п. может позволить себе не каждый, именно из-за временных мерок.
Другое дело, если у вас было время между проектами и постепенно вы постороили
себе необходимые библиотеки и компоненты.
Исходя из вышесказанного ценность представляет именно во первых среда
разработки. Во вторых насколько она "набита" готовыми классами, компонентами -
которые помогут вам в нелегком и порой неблагодарном деле разработки ПО. В третьих насыщен ли рынок библиотеками и компонентами выпускаемых другими
компаниями.
Давайте вспомним, что представил Borland на рынок, как альтернативу Visual
Basic от M$ - это был первый релиз Delphi еще 16-битный. Delphi был представлен
как RAD - rapid application development. Для меня это был в общем то шок -
настолько быстрой разработки GUI приложений с поддержкой СУБД - я еще не видел.
Кроме того прибавте быстрый компилятор, т.е. походу кодирования вы чатенько давите Ctrl+F9 и чувствуете себя спокойно от того, что вы очень быстро получаете сообщения о наличии/отсуствия ошибок. Поддержка всего этого - это библиотека VCL предполагающая, что компоненты могут находиться как в Run-Time,
так в Design режимах, и естественно среда дающая вам палитру и холст где вы и ваяете изредка описывая чтото в коде (F11-F12).
Что мы имели в то время под Win3.1 для С++ это M$ Visual C++ 2.0 достаточно
удобная среда разработки и библиотеку Application Framework - Afx (то что потом
станет MFC). Разработка GUI основанна на класическом рисовании диалогового окна
в Resource Editor после чего вы связывали ресурс с классом и создавали
обработчики событий от управляющих элементов.
Borland C++ 4.0 содержал "волшебные" Application Expert и Class Expert и
библиотеку Owl (не сова - а object windows library), которые помогали создать
приложение (классически SDI, MDI и Dialog) после чего вы работали с конкретными
классами, через class expert, опять же декларируя (мышкой) необходимые
обработчики сообщений.
Если Afx предлагал классы CRecordset и связывал "контролы" в вашем диалоге с полями в вашем recordset-е, то Owl не предлагал ничего, а с поставлемым BDE необходимо было работать через BDE API, скорее всего Borland уже работала над C++Builder поэтому никаких вложений в C++ (4.5 5.0) не было, что в общем то и отодвинуло продукты от Borland для С++ на второй план.
Watcom C++ 9.0 - один из лучших компиляторов, не удобная среда разработки,
большое колличество поддерживаемых платформ (Win16, Win32, OS/2, DOS 32 bit
extenders DOS4GW и Pharlap, NetWare NLM), поддержка M$ MFC, как RAD постовлялся
продукт Blue Sky Programmer - генерировавший код на MFC. В целом для быстрой
разработки не очень здорово.
Самое главное отличие среды Delphi и сред которые предоставлялись для С++ это
поддержка вашего кода потом, т.е. если в Delphi добавить/убрать обработчик
события - это было простым делом, то в средах для С++ приходилось это делать
вручную в коде (причем не забыть сделать это в h и cpp файлах), что конечно не
очень удобно. То же самое касается и самого приложения - однажды
сгенерированный код с использованием MFC или OWL нуждался в правке, если вам
нужно было чтото изменить (название,иконку и т.п.), что не может не раздражать.
Deplhi - сделал как бы полезную вещь реализовав компонентный подход в VCL, M$
предложил конечно чтото более масштабное дав миру OCX компоненты (Active-X),
т.е. такая идеология два режима проектирование/работа, использовать можно где
угодно (т.е. любое приложение готовое стать контейнером) однако эта всеяднасть,
немного отделяет ваш код от компонента, конечно в среде Visual C++
автоматически генерируются классы оболочки для таких компонентов о вот вы
работаете с ними, как с C++ классами - удобно, по мне не очень чтото было не
уютно както, особенно когда проект доходил по "деплоя" - необходимо было также
установить массу OCX компонентов на машину клиента. Часто все кончалось просто
"крахом" из за несовместимости или из-за не дальновидности разработчика
компонента. Все вышесказанное это мое личное.
Поэтому на мой взгляд Delphi иделаьно подходит для on-site проектов (т.е.
создающихся прямо на стороне закзачика), когда интерфейс меняется каждый день,
функции добавляются удалются, "деплой" новых версий делается каждый день.
Что же скажет читатель нет хороших сред для С++, нет есть все что было и есть
оно прекрастно - но подход немного другой. Если Delphi в принципе позволяет вам
начать писать даже не зная VCL - если не доходить до токних вещей. То Visuаl
C++ предполагает, что вы обладаете достаточными знаниями как Win32 API, так и
MFC. Что из этого можно сказать, что большинство компаний могут посадить за
разработку GUI приложений в общем то не очень квалифицированных людей или
вообще неквалифицированных. Что позволит занять квалифицированный персонал
заняться более сложными задачами.
Что дальше - все зависит от человека. Большинство так и продолжают ковать
приложения на Delphi с неуклюжим и порой ужасным кодом, с без конечным copy and
paste. Эти приложения работают и люди работают - сам видел. Часто много времени уходит на просмотр VCL компонентов в инете. Это уже не разработчики - а
builder-ы какието. Однако случаются и проблемы. Приложения "пухнут" с каждым
днем, пользователи хотят нового и получают, приложения просто "гигантские",
напичканные невероятным колличеством компонентов (...а ты
TCoolBarAdvanceDBButton юзал!... вау...), и массой ошибок не всегда удаются
адекватно "поправить" весь copy and paste. Люди не учаться думать - VCL не очень склонна к этому. Никто не пытается разработать свои классы, покапаться в VCL - некогда. Это замкнутый круг.
Используя C++ человек растет - вынужден. Нужно освоить библиотеку классов
которую используеш. Необходимо узнать тонкости ОС для которой пишешь. Начинаешь
создовать свои библиотеки для того чтобы уйти от copy and paste. Среда сурова -
многие не выдерживают, чтож остаются самые стойкие. Пытаешься найти для себя
полезные библиотеки - примеры нужно строить и разобраться в них - запоминаешь,
становишся на ступеньку выше изучая код написанный не тобой. Делаешь массу
выводов для себя. Дополнительный инструментарий осиленный с таким трудом, если
еще он оказался достаточно полезным, становится просто напросто другом. Ты не
меняешь его с каждым днем. Твои приложения становятся стабильными и при этом
удовлетворяют пользователя. Конец - нет. Ты идешь дальше изучаешь шаблоны
проектирования, улучшаешь свой код и библиотеки, твой код становится чище и
яснее. Начинаешь документировать. Понимаешь что тесты возникают раньше чем твой
код. Становишся профессионалом.
Не буду говорить, что так обстоит со всеми и везде, но имеет место быть.
Насчет многоплатформенности, в общем то не столь важно GUI приложения в
большинстве создаются для M$ Windows, поэтому Delphi оправдан, а с C++ с
подобными задачами не частое применение. В большинтсве это касется двух
платформ M$ Windows и UNIX и с использование шаблонов проектирования все очень
изящно решается. Если нужно GUI то есть GTK и QT.
Далее перейдем к другим языкам.
Мое мнение, которое сложилось именно из практики и опыта, желательно знать не
один язык программирования. Часто видишь как "крутой" си-шник решает задачу по
разбору текстового файла с помощью C/C++, хотя для perl это часто одна-пять
строк кода. Бывают задачи одноразовые которые не требуют от вас хитростей и
тонкостей и премудростей ООП. Для таких целей всегда подойдет скриптовый язык, будь то какой нибудь unix shell, perl, python, или WSH если уж вы так любите M$.
Пользователи просят чтото сделать вас в Excel - держите при себе знания о VBA,
конечно если задача сложная попросите специалиста - объектные модели приложений
M$ Office это целая отрасль знаний.
Если вы создаете realtime приложения то иногда без ассемблера просто не
обойтись. Хотите писать для микроконтроллеров (PIC,AVR,51 и др.) - ассемблер
просто необходим. Есть конечно C и даже Basic но вот размеры PROM-ов не
безграничны и скорость будет не удовлетворять.
Нужнен Web. Так это целое слияние. Вам понадобиться чтото на сервере это
может быть php, perl, java однако чтобы оживить клиента без JavaScript ни куда.
Каждый выбирает чтото для себя. Конечно есть основной интсрументарий и вы в нем
как рыба в воде. Но условия могут поменяться. Ваш работодатель сменит платформу
разработки, вы найдете другую работу и там другие требования.
Поэтому если есть время уделяйте внимание хотя бы паре-тройке других языков
программирования. Не спорю это трудно тем более другой язык предполагает
и технологию и средство разработки и все что за этим тянется. Например те же языки под .NET предполагают, что вы будете также изучать и технологию.
Java красивый, использующий виртуальную машину язык, т.о. переносимый на любые платформы для которых есть виртуальная java машина. Весь API построен на
классах и использует все стандартные шаблоны проектирования (GOF), что само по себе облегчает разработку приложений. Благодаря невероятному кол-ву API практически не требует поиска сторонних классов по крайней мере для повседневных задач. А заглянув на sourceforge вы просто будете потрясены какое кол-во проектов сделано для java. Кроме того используя технологию J2EE вы можете писать приложения уровня предприятия используя для начала бесплатный jBoss (а дальше раскрутите заказчика на покупку промышленного сервера приложений). А как чудесно и изящно можно использовать скриптовы языки благодаря проектам jython или bsh.
Хочется отдельно сказать про сборку мусора. Програмисты это все от ваших ошибок. Забыли освободить указатель - начались утечки. Через час нужно перезагружать приложение. Пользователи жалуются. Кто то добрый предложил собирать потом - это просто ужас. Используйте smart,shared,auto pointer-ы и вот собсвенно проблем то и нет. Все ленятся. Но пора бы и остановиться что я все о
технологиях. Так вот видимо ну никак без них.
И все таки С++. Целью ООП было как можно сильнее абстрагироваться от ЯП и делать
задачу в терминах области для которой вы создаете ПО. ЯП который наиболее
сильно отвечает таким требованиям, кроме С++, пока еще не было. Во основном это
достигается за счет перегрузки операторов и использованию шаблонов. Всегда
получается элегантный и хорошо читаемый код.
-------------------------------------------------------------------------------
Вообще о спорах - приведу следующею цитату:
Н. Вирт: "Многие люди относятся к стилям и языкам программирования как к религиозным конфессиям: если вы принадлежите к одной из них, то не можете принадлежать к другой. Но это ложная аналогия, и она сознательно поддерживается по причинам коммерческого порядка"
Войти
Регистрация
Наверх
