Владимир Лось
дата публикации 27-12-1999 00:00 К вопросу о выборе языка программирования. Часть II Данный материал написан как ответ на многочисленные отклики на статью Владимира Лоса от 21 декабря 1999г.
Он содержит непосредственно комментарии к полученным письмам и завершающую статью автора по заявленной теме.
Сначала письмо.
Уважаемый Владимир,
Очень интересно было прочитать Вашу статью. Я хотел бы ответить.
Я согласен, что C++ сложен как в концептуальном, так и в синтаксическом плане.
Однако это язык для прфессионалов, а профессионалам куда удобнее запомнить
все тонкости синтаксиса, чем бесконечно печатать невыразительные "BEGIN",
"END", "THEN", "PROCEDURE" и решать все проблемы путем функциональной декомпозиции.
C++ поддерживает как минимум пять концептуально разных моделей программирования
(в том числе и Паскалевскую). Используйте ту модель, котроая вам удобнее.
Не используйте те возможности, которые вам не нужны или котрых вы не знаете.
Пишите так, как пишите на Паскале, пока не поймете, что возможны другие пути.
Язык это позволяет. Ну и наконец, C++ способствует созданию чрезвычайно эффективного
кода, он удобен как для работы с "железом", так и для высокоуровневых манипуляций в
терминах объектов классов предметной области. То есть C++ сложный универсальный язык,
предназначеный в первую очередь для решения реальных сложных задач.
Паскаль и подобные языки великолепно подходят для обучения, так как они достаточно
просты (кстати простой и примитивный одно и тоже, в этом нет ничего унизительного),
то есть содержат минимальный набор средств, необходимых программисту
Как показывает мой опыт, качество программы большей частью определяется человеческими
качествами аналитика, проектировщика и программиста, и в меньшей степени выбранным
языком реализации. C++ мощный инструмент, но только не в руках дилетанта, где вся
эта мощь невостребована и часто опасна. На осознание и восприятие объектного
анализа/проектирования/программирования и языка C++ могут потребоваться годы,
о оно того стоит.
Если Вы со мной не согласны, пишите ответ.
В. Н.
P. S. Признаюсь, не уловил связи между революцией в полупрводниковой технике и
отказом от наследования "в общеархитектурном смысле". Эти вещи совершенно не
связаны. Думаю, Вы погорячились...
Отвечаю...
Самое опасное в такой полемике - перейти на личности. Это письмо не первое (и надеюсь - не последнее). В некоторых письмах уже появилась интересная информация относительно моих умственных способностей, родителей и национальности. Оставим эти злопыхания на совести авторов писем. Это письмо было отобрано мной потому, что здесь собраны типичные аргументы приверженцев С/С++. Итак, начнем разбирать по косточкам.
Я согласен, что C++ сложен как в концептуальном, так и в синтаксическом плане. Однако это язык для прфессионалов, а профессионалам куда удобнее запомнить все тонкости синтаксиса, чем бесконечно печатать невыразительные "BEGIN", "END", "THEN", "PROCEDURE" и решать все проблемы путем функциональной декомпозиции.
Радует признание сложности С++. Но ни к чему меня не обязывает и ничего не объясняет. В частности, не объясняет причину появления этой сложности. Дальше идет интересное высказывание, дающее косвенное определение показателя профессионализма: « ... профессионалам куда удобнее запомнить все тонкости синтаксиса, чем бесконечно печатать невыразительные "BEGIN", "END", "THEN", "PROCEDURE"... ». Во-первых в виртовских языках проблемы с тонкостью синтаксиса нет (и даже новичок поймет, что имел в виду программист со стажем, когда писал ту или иную последовательность операторов - естественно новичка необходимо ввести в контекст проблемы :о)). Во вторых, по-моему, более выразительны адовские END IF, EXIT LOOP, чем безликие '}' и, неизвестно к чему относящиеся break, расставленные во множестве по тексту программы. Кстати, насчет BEGIN. В последних языках Вирта их колличество значительно поубавилось (это для ленивых) - теперь они обозначают только начала главного блока модуля и процедуры и, между прочим, исчезла проблема «неопределенного ELSE». Пример в нотации С:
if (a)
if (b) c;
else d;
if (a)
{
if(b) c;
}
else d;
Надеюсь, все поняли, о чем идет речь... Хорошо, если у вас один-два оператора разделе ИСТИНА, а если больше?... В Компонентном Паскале же (дальше - КП) любой IF, WHILE и FOR ОБЯЗАТЕЛЬНО должны оканчиваться END-ом. Теперь, подобного рода проблем вообще не возникает. Да и, потом, за долгую практику работы на Паскале, Модуле и Обероне ключевые слова как бы «замыливаются», структура программы формируется (при восприятии текста программы) почти на подсознательном уровне, а ключевые слова «всплывают» только если встретился неординарный случай построения последовательности операторов.
Далее интересное высказывание: «...и решать все проблемы путем функциональной декомпозиции. ». Знаете, была Керниганом в 70-х годах написана статья с названием вроде «Почему Паскаль не является моим любимым языком программирования» (за точность названия статьи не ручаюсь). Так вот многие критики Паскаля ссылаются на эту статью, но делать это - все равно, что критиковать их любимый С++ ссылаясь на его самую первую версию (помните: наследования множественного нет, перегрузка операций с помощью препроцессора...). Такое впечатление, что нынешние приверженцы Паскаля эдакие ортодоксы - ни на шаг в сторону, и все новые веяния касаются только С++. Полезно будет напомнить, что перегрузка операций и параметризация возникли именно в языках линии Паскаля (Ада и, забытый ныне, CLU). Ну а если бы все проблемы решались только «путем функциональной декомпозиции», то не было бы, например, графической оболочки на Маке, которая изначально обкатывалась на ThinkPascal-е и Object Pascal-е (детище Вирта - не путать с нынешним дельфийским вариантом!). Ребята! Вирт - это не книжный червь, безвылазно сидящий в своей Швейцарии. Корни его изысканий растут из той самой знаменитой Palo Alto Research Center (Xerox), где он работал некоторе время. По-моему это о многом говорит. Почитайте его выступление на вручении ему премии Тьюринга.
Дальше.
...C++ поддерживает как минимум пять концептуально разных моделей программирования (в том числе и Паскалевскую).
Каких пять?
Кстати название «паскалевская» модель есть, а вот модель С++ я что-то не встречал...
Используйте ту модель, котроая вам удобнее.
А мне казалось, что программа отражает модель предметной области.... А не модель предметной области притягивается к удобной модели программирования....
Не используйте те возможности, которые вам не нужны или котрых вы не знаете.
ТЕ ВОЗМОЖНОСТИ, О КОТОРЫХ Я НЕ ЗНАЮ НЕ МОГУТ БЫТЬ МНЕ НУЖНЫ. Это одно, а второе - вы где нибудь встречали руководство по С++, где бы не было при описании какого-нибудь средства длинного списка ограничений и частных случаев, примеров исключений...
К теме: объем руководства по Паскалю - 50 страниц, Модула-2 - 35 страниц, Оберон-2 - 30 страниц, Компонентный Паскаль - 20 страниц.
Пишите так, как пишите на Паскале, пока не поймете, что возможны другие пути.
Куда?
В царство сонмища тулсов для отслеживания правильности распределения/освобождения памяти? Так уменя этой проблемы ВООБЩЕ нет! А на остальное - начхать, уж поверьте мне!
Ну и наконец, C++ способствует созданию чрезвычайно эффективного кода, он удобен как для работы с "железом", так и для высокоуровневых манипуляций в терминах объектов классов предметной области.
Не смешите меня! Можно конечно выдвинуть аргументом работу компиляторов Watcom, но опять «НО». А вы что-нибудь слышали о новосибирской фирме XDS (www.xds.ru)? Сходите, посмотрите...
Ведь тут еще один аспект: код, получаемый из С++ будет очень эффективным на машинах лини DEC. Именно там команды, подобные *а ++ = *в ++ будут переводится в минимальное количество инструкций прцессора, но никак (без оптимизационной работы) на архитектуре х86. Собственно сам синтаксис С/С++ обязан своим рождением набору команд PDP-11. А в самой Интел до недавнего времени использовался PL/M, который ну никак на С не смахивает. Более строго, семантический разрыв между набором команд Интелов и С шире чем между PDP и С. А, следовательно и работы компиляторам, для преодоления этого разрыва приходится делать больше (и времени затрачивать на компиляцию). А теперь подумайте о том, что на Паскале таких наворотов нет... Еще один момент: С(С++) на низком уровне опирается на конкретный вычислительный механизм (по признанию автора) - указатели, регистры, возможность доступа к результатам последней операции и т.д. Паскаль же в этом отношении более абстрактен и не привязан к архитектуре компьютера.
Мне известны только две операционки, написанные ИЗНАЧАЛЬНО ПОЛНОСТЬЮ на языке высокого уровня - и это не UNIX. Почитайте где-нибудь о Лиллит и Оберон.
Ну а про возможность «высокоуровневых манипуляций» - КП, собственно, для этого и проектировался.
То есть C++ сложный универсальный язык, предназначеный в первую очередь для решения реальных сложных задач.
О том как на нем решаются задачи создания ОС линии Win32 мы с вами свидетели уже вот скоро как 10 лет. И я так понимаю, что процесс в развитии.... О качестве, соотвественно....
Паскаль и подобные языки великолепно подходят для обучения, так как они достаточно просты (кстати простой и примитивный одно и тоже, в этом нет ничего унизительного), то есть содержат минимальный набор средств, необходимых программисту
Простой и примитивный - не одно и тоже. Автомат Калашникова - простой. Дубина - примитивна. Кстати, если проводить параллели, АК - Паскаль, М-16 - С++ (особенно в части сочленения магазина и коробки - но это уже для спецов...).
Как показывает мой опыт, качество программы большей частью определяется человеческими качествами аналитика, проектировщика и программиста, и в меньшей степени выбранным языком реализации.
ЧЕЛОВЕЧЕСКИЕ качества важны для организации здоровых отношений в коллективе. На счет выбранного языка реализации: одной кафедре нужно было засветиться в оборонном ведомстве одной из эсенгешных держав. Необходимо было сделать (очень быстро!) пилот-проект с достаточно навороченным интерфейсом пользователя. Это был 1993 год. Технику помните? Безденежье? Решили интерфейс делать на турбо-вижине. Скомпилировали одну из демонстрашек на Паскале - 23 секунды. Тот же пример на С++ - 45 минут. Вопросов ни у кого не было... А преодолевать подобного рода трудности наращиванием мегабайт и мегагерц - экстенсивный путь (собственно по нему и шагаем - так меньше мозгами шевелить необходимость....). Кстати шевеление мозгами интересные результаты дает: вы слышали о прецессоре в 40 мегагерц, который и сделан на технологии хуже интеловской, а обгоняет на некоторых задачах обработки видеоизображений Пентиум ММХ 400 МГц В ПЯТЬ раз. Это люди в Московском НТЦ «Модуль» учудили. Процессор называется NM6403. Но это так, к слову...
C++ мощный инструмент, но только не в руках дилетанта, где вся эта мощь невостребована и часто опасна.
Знаете, есть шутка: чем отличается хороший программист от плохого? Хороший программист пишет хорошие программы, плохой их не пишет. Дилетантов (с опытом) в программировании нет. Есть те кто начинает. Я знаю много людей, которые с удовольствием писали бы только на Паскале, если бы не то, что рынок «диктовал свои законы», а просто начальство рогом не упиралось. Но, будем честными, что такое это самое начальство? Они что, большие спецы? Где вы видели мастера, давящего на клаву и карабкающегося по служебной лестнице? Ни один из известных мне профи не стал ни крупным бизнесменом, ни сколь-нибудь выдающимся (высоким) начальником (по своей инициативе).
Еще одна мысль возникает, мол, все, кто не пишет на С++ - дилетанты. (или это уже манечка?). Вирт - дилетант. Ребята из XDS и xTech - дилетанты... И дилетанты из Nortel-а их нанимают самые ответственные вещи проектировать! Ну а про дилетантов из NASA, даже разговор заводить не хочется.
На осознание и восприятие объектного анализа/проектирования/программирования и языка C++ могут потребоваться годы, но оно того стоит.
Не путайте ООА/ООП2 с программированием на конкретном языке. На первое ГОДЫ уходят по причине новизны и продолжающегося процесса формирования самих взглядов и подходов. На второе тратятся годы по причине искуственно привнесенной сложности, перегруженности и распухнутости (есть такое слово?) (и непомерных амбиций?).
Первое конечно стоит, чтобы его изучать!
Второе... Ну не знаю. Изучать набор исключений и помнить о всех нюансах и частных случаях вместо того, чтобы освоить простой набор легко запоминающихся, логичных правил?
P. S. Признаюсь, не уловил связи между революцией в полупрводниковой технике и отказом от наследования "в общеархитектурном смысле". Эти вещи совершенно не связаны. Думаю, Вы погорячились...
Абсолютно связаны! И именно то, что в С++ такие навороты - часть процесса преодоления семантического разрыва между предметной областью и архитектурой Фон-Неймана. Последняя хороша для СЧЕТНЫХ задач. В последнее же время народ все больше приходит к выводу, что процессор (или то, что его заменит) должен играть роль некоего коммутатора интерфейсов и ресурсов, предоставляемых специализированными блоками (программными и аппаратными). Здесь и многозадачность сама собой решается, и распределенность объектов, и еще много кое чего.... Если хорошо подумать, то и наследование в этих условиях поглощается более общим случаем, приобретения и потери объектами неких свойств (интерфейсов). Кстати именно это качество (на мой взгляд) попытались получить разработчики С++, реализовав множественное наследование.
С уважением, Владимир.
Письмо Сергея Герасина
C/С++, Pascal, Java и иже - объединяйтесь!
(Ответ на статью Владимира Лоса от 21 декабря)
Начну с того, что я не обладаю всем опытом Владимира. Я всего лишь
студент пятого курса специальности "Информационные системы в экономике".
Поэтому меня можно легко "закидать шапками" в споре с крутым
специалистом. И тем не менее, удержаться от ответа на статью не могу.
Во-первых, мне обидно как студенту, что нашего брата там немилосердно
поливают всякой #$%@$#ью, а во-вторых, мне непонятна цель написания
статьи. Это что, панегирик Паскалю? Чем тогда он отличается от
панегириков C++, VB, Java и т.п., поющихся на кажодм углу? Главное, чего
нет в статье - понимания необходимости создания средств программирования
различной направленности, с различными характеристиками и -
предназначенных для решения различных задач! И причем тут "поклонники
C/C++ сейчас на коне"? Ведь есть еще и Java, и Delphi, и VB, наконец!
Ну как же не ясно, что создание языков программирования не является
чьей-то прихотью, а обусловлено различными требованиями в различных
областях применения компьютерной техники? Решение задач, имеющих четкое
математическое описание - одна область, функциональное, информационное и
поведенческое моделирование систем (не математизируемое в принципе) -
совсем другая, создание операционных систем - третья, программирование
для Интернет - четвертая... Каждый может дополнить этот список своими
примерами. А что, многоуважаемый Владимир, понятие баз данных перестало
существовать? И какие же средства, например, проектирования, создания и
поддержки баз данных может предложить BlackBox с "исполняемым файлом 78
кило"? Жаловаться на отсутствие у студентов стремления самостоятельного
поиска решений и тут же предлагать "универсальное" решение всех
проблем...
Не совсем понятна также и угроза очередной революции в области
полупроводниковой техники. Откуда следует, что перестанут существовать
современные нам принципы построения программ (в частности,
объектно-ориентированная парадигма, на которую сделана нападка)? Что
такое программа, записанная на каком-то языке программирования? Это есть
нижний уровень детализации описания некоей системы реального мира. И
объектно-ориентированная парадигма, заложенная в большинство современных
языков программирования, опирается именно на строение и организацию
реальных систем реального мира. Это и придает ей невероятную гибкость!
Так почему при изменении архитектуры ЭВМ должны изменяться принципы
построения этих систем? Речь здесь может идти лишь о реализации той же
парадигмы новыми средствами, возможно, с какими-то изменениями,
отражающими изменение взглядов на мир и модификацию архитектуры ЭВМ. С
этой точки зрения BlackBox тоже ОБЯЗАТЕЛЬНО будет перестроен. А вот
насчет проверенной и устойчивой линии Вирта... Система застывшая,
неизменяемая может уже считаться мертвой. У нее нет будущего, поскольку
одним из важнейших свойств любой системы является ее адаптируемость к
изменениям внешней среды и приспособление к новым условиям
существования. Это в полной мере относится и к среде программирования.
Как же обеспечит математически детерминированная система такие
возможности? Может, я что-то не так понимаю?
Тут еще нападки на неудавшуюся совместимость средств разработки... Надо
ведь понять и такую вещь: уже давно не существует языков
программирования, как "вещей в себе", полностью самоопределенных и
самодостаточных. Упоминая какой-то язык программирования, мы всегда
ассоциируем его с какой-то средой программирования, вне которой он не
может уже существовать. Это относится ко всем современным языкам,
включая и Паскаль. Следовательно, изменение самой среды программирования
также может повлиять на язык. Что касается совместимости, о которой так
небрежно-язвительно было упомянуто... А зачем нам поддерживать
совместимость на уровне исходного кода? Совместимость средств
разработки? Это что, жестко необходимо? Можно ведь поступить более гибко
- организовать совместимость на уровне интерфейсов! Добавим возможность
использования неизвестных заранее интерфейсов с возможностью динамически
их получать и модифицировать - и мы получим ту самую COM (OLE 2.0),
которая удачно "опущена" в статье. Не видно, откровенно говоря, такой
гибкости у приложений, созданных в BlackBox...
Таким образом, главным критерием выживаемости той или иной "линии
языков" является отнюдь не строгость ее математического описания и
обоснования, а то, насколько она отвечает строению реальной предметной
области. А правда, господа такова: все большему и большему числу людей
приходит в голову понимание того, что мы живем не в строго
детерминированном мире, который можно полностью описать с помощью
математики. Даже наоборот: большинство систем реального мира не
математизируемы принципиально! И претензии математики на истину в высшей
инстанции, мягко говоря, необоснованны... Так что расхваленная система
Черного Ящика (исходя из описания, приведенного Владимиром), пригодна
лишь для реализации определенных задач, для которых удается построить
строгую математическую модель, а таких задач, увы, не так уж и много...
При выборе того или иного языка программирования для реализации
какой-либо задачи необходимым условием является возможно более легкая
стыковка его со средствами формального описания систем - теми же DF или
SADT диаграммами, например. И здесь решающую роль играет уже не столько
объем кода, сколько имеющиеся средства (либо опыт и наработки) стыковки
верхних уровней детализации описания систем с нижним - программой. Да,
возможно, Паскаль - хорошее средство как для описания системы, так и для
программирования (но что-то не очень верится - Паскаль-то я вроде знаю).
Возможно, BlackBox хорошо стыкуется с CASE. Но меня смутило предложение
отказаться от поддержки предыдущих версий и вообще от понятия
совместимости. Как соотносится предлагаемое решение на основе BlackBox с
нашей российской реальностью, когда "правила игры" для субъектов,
например, экономической системы, могут совершенно непредсказуемо
меняться в течение относительно коротких промежутков времени? Ведь любое
изменение условий функционирования системы, реализованной предложенным
образом, приведет к потере данных, накопленных на этапах эксплуатации
предыдущих версий... А при переходе со старых программных средств на
новые - что, прикажете, игнорировать все накопленные данные и сделанные
наработки, начинать с нуля? Тогда какой смысл в такой "автоматизации"?
Я давно заметил стремление любого человека с математическим складом ума
математизировать все явления реального мира - детерминировать их,
подчинить строгим законам математики... И стремление все проблемы решать
так же, математически: существует проблема поддержки старых версий - ей
можно пренебречь, оставив заботы ее пользователям. А мы сделаем нечто
совсем новое, то, что удобно НАМ ЗАПРОГРАММИРОВАТЬ, а не то, что УДОБНО
ИСПОЛЬЗОВАТЬ. Позвольте напомнить результаты такого подхода в области
железа - печально изестную платформу Be, создатели которой рассуждали
примерно так же: мы создадим приниципиально новую платформу, а о
совместимости пусть заботятся пользователи, не наша эта проблема. Взяв
хороший старт и сорвав все положенные бонусы, проект заглох... Потому
что эволюционное развитие в нашем мире преобладет и является единственно
возможным. Революции в любой области всегда приводят не к тому, на что
были направлены. И не надо мне приводить в пример "революционный"
характер развития самой компьютерной техники - ее основы были заложены
еще в 50-е годы, и с тех пор принципиально мало что изменилось в
технологии - менялись лишь ее количественные характеристики, но никак не
качественные... Вот вам и революция.
Позабавила меня история о разработке системы частью на Delphi, частью на
BC++. Если Delphi, то почему в соединении с ненавистным BC++? Почему не
C++ Builder, построенный на тех же библиотеках, что и Delphi, и имеющий
те же приниципы работы? А перечисление достоинств Black Box очень сильно
напоминает стишок "А у нас на кухне газ...". Если я здесь начну
перечислять достоинства C++ Builder, которые отсутствуют в BlackBox, то,
боюсь, читатель устанет это читать...
Какой вывод хотелось бы сделать? А он очевиден: рассказывая о своей
преподавательской работе, Владимир забыл упомянуть об одной чрезвычайно
важной вещи, которой в первую-то очередь надо учить студента: умению
выбрать для решения задачи адекватные средства. Не давать ему некую
концепцию в качестве основной и направляющей, а познакомить с
большинством существующих и научить выбирать наиболее подходящие для
решения различных типов задач. Именно это умение - умение
сориентироваться в имеющихся средствах и выбрать наиболее подходящее
(либо, если таковое не найдено - создать новое!), и определяет качества
хорошего специалиста, а отнюдь не знание конкретной среды
программирования. И спрос на средства программирования определяет не
рынок. Его определяет адекватность языка предметной области. Специалист
же, не сумевший обосновать свой выбор средств программирования перед
заказчиком, не может, собственно, считаться таковым...
Паскаль - это уже история. Попытка сделать его объектно-ориентированным
откровенно не удалась. Провалив проект Borland Pascal 7.0, фирма Борланд
создала Дельфи - систему программирования, получившую широчайшее
распространение именно благодаря своей среде, а не языку. Это
подтверждается тем, что все большее и большее число программистов в
Дельфи сейчас переходит на C++ Builder, который имеет в своей основе
универсальный, великолепно, до мелочей, продуманный язык, с очень
последовательно и логично реализованной объектно-ориентированной
парадигмой... Именно боязнь окончательного провала Объектного Паскаля
заставила фирму Борланд выпустить Builder 1-й версии на два (даже,
по-моему, три) года позже Дельфи...
Слушая (читая) рассуждения о том, какой язык лучше, я вспоминаю неплохо
реализованный эмулятор Unix под Windows 98, написанный... Вы стоите?
Сядьте! На JavaScript!!!!! И эта реализация позволяет получить вполне
адекватное начальное представление об эмулируемой системе... Какой вывод
можно сделать из этого? Для настоящего программиста выбор языка, по
большому счету, неважен! Он сможет реализовать то, что нужно, любыми
средствами. Определяющим фактором является лишь время... Так что, может,
не будем спорить, а начнем работать?
P.S. К сожалению, Владимир не указал своего отчества, и мне несколько
неудобно обращаться к нему по имени, поскольку, судя по приведенной им
информации о себе, он минимум лет на 15 старше меня. Прошу за это
прощения.
NO COMMENTS! ! !
C уважением, Владимир Лос.
Уважаемые коллеги! Давящая на батоны братва!
Вынужден признать, что по сути своей, начатая мною дискуссия на страницах Королевства ни к чему не ведет. Она неконструктивна. Я был ее инициатором - я же ее и прекращаю. Я признаю свое поражение. Пусть это греет душу приверженцам Си/Си++. Дальше они могут не читать. Всего хорошего, спокойной ночи.
Для остальных же сообщаю, что существует два варианта перевода одной замечательной фразы из Библии. Первый вариант: кто не со мной - тот против меня. Второй: кто не против меня - тот со мной. Каждый выбирает в соответствии со своими наклонностями и по своим убеждениям.
В принципе, я надеялся на ответы, но в таком количестве!... Естественно, ответы были разные. Ответно, с теплым чувством (возникшим после прочтения послания), жму руку Михаилу Дьячкову, чье письмо в Королевство и комментарии-ответы на него, заставили меня на едином выдохе накатать свой опус. А так же всем авторам конструктивной части посланий. Остальные делились на тех, кому просто надо было на ком-то сорваться и людей, убежденных в своей правоте (на основании собственного опыта) и фанатично преданных Си/Си++, но уважающих чужое мнение. На первой группе останавливаться не будем, здесь клиника достаточно четкая и ясная. А вот письма последних двух категорий позволили заново взглянуть на мои излюбленные виртовские языки. Что же такого в них, что при моем достаточно большом опыте работы с Си++, заставляет возвращаться к Вирту? Почему, не смотря на массированный антивиртовский и антипаскалевский прессинг, часть людей продолжает избирать для себя Паскаль (и его наследников) основным инструментом воплощения результатов своей интеллектуальной деятельности. Не знаю отвечу ли я на этот вопрос, но результатами размышлений явились следующие мысли. (Наверняка не буду оригинален.)
Вирту необходимо было создать язык для обучения. Вирт всегда был сторонником минимализма - сделай как только можно просто, но не проще этого! Это значит, что в языке должны были остаться средства минимально необходимые для описания вычислительного алгоритма, жесткая типизация данных и идея абстракции. Не подумайте, что я цитатчик, но лучше самого Вирта, наверное, никто не скажет:
(Niklaus Wirth «From Modula to Oberon» Institute for Computer Systems, ETH, Zurich, Technical Pa-per. © 1990, N.Wirth. Перевод: Никлаус Вирт «От Модулы к Оберону» © 1998. ИнфоАрт)
«...язык должен определяться в терминах математических, абстрактных концепций без ссылки на какой бы то ни было вычислительный механизм (выделение мое - Л.В.). И только, если язык удовлетворяет этому критерию, он может считаться высокоуровневым. Решительно никакая синтаксическая глазурь не в силах заставить обойтись язык без этого атрибута.
Описание языка должно быть строгим и лаконичным. Этого можно достичь лишь путем аккуратного выбора соответствующих абстракций и подходящей структуры, которая позволяет их комбинировать. Руководство по языку должно быть весьма коротким и избегать пояснения частных случаев, проистекающих из общих правил. Мощь формализма не должна измеряться длиной описания. Более того, чересчур пространное описание - это характерный симптом двояких толкований. В этом плане целью должна быть не сложность, а простота.
Несмотря на краткость, описание системы должно быть законченным. Полнота должна достигаться в рамках выбранных абстракций. Ограничения, накладываемые конкретными реализациями, не относятся собственно к описанию языка. Примерами таких ограничений являются: максимальные значения чисел, арифметические ошибки округления и усечения, действия, предпринимаемые в тех случаях, когда программа нарушает установленные правила. Не должна появляться потребность в таком дополнении к описанию языка, когда толстенные описания стандартов покрывают непредвиденные ситуации.
В то же время, язык не должен быть одной лишь математической теорией. Он должен быть практическим инструментом. Это подразумевает определенные ограничения, накладываемые на краткость формализма. Несколько языковых средств Оберона, с чисто теоретической точки зрения, являются излишними. И, тем не менее, они присутствуют в языке из сугубо практических соображений, то ли для удобства самого программиста, то ли для достижения эффективной кодогенерации без использования в компиляторах сложных оптимизирующих алгоритмов сопоставления шаблонов. Примерами таких языковых средств является наличие нескольких форм оператора цикла, а также наличие стандартных процедур, таких как INC, DEC и ODD. Они не усложняют ни язык, ни компилятор.
Все эти аргументы нужно иметь в виду, когда производится сравнение Оберона с иными языками. Ни язык, ни описывающий его документ не достигают идеала, но Оберон приближается к этой цели гораздо лучше своих предшественников.
Компилятор Оберона был реализован для процессоров семейства NS32000 и был встроен в операционную среду Оберон. Этот компилятор требует 50 Кбайт памяти, состоит из 6 модулей, общим размером около 4000 строк исходного текста и сам себя компилирует примерно за 15 секунд на рабочей станции с 25 МГц процессором типа NS32532. »
Все это писано для Оберона в 1990 и сохранило свою актуальность и для Оберона-2 и, соответственно, для Компонентного Паскаля.
Какой же можно сделать вывод. При небольшом напряжении ума, можно понять, что языки линии Паскаля, основанные на абстрактном вычислительном механизме, обладают большей платформенной переносимостью (см. выделенный текст). То, что называется переносимостью Си(Си++) на деле - реализация вычислительной модели PDP-11 на других архитектурах (через пыхтение компилятора).
То есть, даже на самом низком уровне в Паскале (если понятие низкого уровня вообще применимо к виртовской группе языков :-)) уже заложена возможность настройки и оптимизации кодогенерирующих блоков компилятора под конкретный набор инструкций процессора.
Тут необходимо упомянуть еще один очень тонкий момент, который очень часто программисты (особенно начинающие) или не усматривают или же о нем умалчивается.
Дело в следующем: Да я согласен - в Си++ введены более строгие правила совместимости типов (по сравнению с Си), да у него очень мощная объектная модель, да и др.....
Но! Но ведь одним из основных требований к Си++ является обратная совместимость с Си. К чему это я? Да к тому, что в самой глубине, на самом нижнем уровне реализация всех управляющих конструкций, структур данных (управление ими) - это по сути дела тот же самый Си. Вспомните, например, как реализован и поддерживается тип XXXXXString в любой из реализаций Си++. Ведь в этом классе обязательно есть поле char* - а это уже источник потенциальных ошибок! Нет, как раз со стрингами может и нет никаких проблем. Здесь проблема общего плана. Это, часто превозносимый подход, при котором смешиваются указатели и массивы. Сама возможность «гулять» по памяти с помощью операций арифметики над указателями не имеет никакого смысла в языке высокого уровня. «Память» и «адрес» - это не понятия языка, не опирающегося на конкретный вычислительный механизм. Более подходящим для такого рода языков является понятие ссылки на объект (не важно какой природы). Значением же такой ссылки является нечто (неконкретизируемое), что позволяет определить объект, на который у нас имеется ссылка или NIL - ссылка ни на что не ссылается. Из операторов, к ссылке применим только оператор присвоения. Из всех операций разрешена только операция сравнения (равен - не равен). Это помогает выявить пустую ссылку и проверить тождественность объектов для разных ссылок. В Компонентном Паскале вообще существует только два вида указателей: на массив и на запись. И, при здравом размышлении, становится понятно, что это является сильнейшим средством избежать многих проблем. Ну, в самом деле, что такое УКАЗАТЕЛЬ НА ЦЕЛОЕ? Для чего я его могу использовать в языке высокого уровня (по Вирту)? Выделить память и хранить одно целое? Смысл? Если это временная переменная... Вернее так: в процедуре, если мне нужна временная переменная, то я ее просто объявлю локальной и она благополучно помрет при выходе из процедуры. Глобальнае переменная (в данном случае - целая) по сути своей (по сроку существования) не может быть «временной». Хранить в указателе на целое адрес массива целых ( одно- или многомерного массива?????)? И потом вводить дополнительные переменные для количества измерений и величин размерностей массива? Ну хорошо, все это прячется в классы. Придумываются и пишутся перегруженные операторы присвоения, конструкторы копирования. Но ведь проблема никуда не делась, она лишь запрятана внутрь библиотек классов. Куда только хваленая эффективность девалась? А мы ее на разные проверки истратили. Там, внутри классов!
Я ни в коей мере не призываю забросить подальше ООП (как в одном письме мне пытались это приписать). Ни в коем случае! В настоящий момент это самая мощная реально работающая парадигма программирования. Я лишь хочу сказать, что если я знаю, что на высоком уровне язык выдает себя за представителя этой идеологии, а в «трюмах» работают старые средства реализации (надежность и безопасность которых спорна), то я буду чувствовать себя довольно неуютно, пользуясь библиотеками классов, «сработанными» на этом языке.
В BlackBox-е, в разделе Помощи представлена книга Куно Пфистера (за транскрипцию не уверен). Приведу из нее один отрывок. Это Глава 7. Раздел 7.1. Где-то в начале... Здесь перевод мой.
(Cuno Pfister. Component Software: A Case Study Using BlackBox Components)
| There are two major "philosophies" of program-ming language design. One of them is exemplified by the language C. C is a terse systems program-ming language which allows to easily and efficiently manipulate memory data structures. The other ap-proach is exemplified by Pascal. Pascal is a read-able application programming language which pro-vides a high degree of safety. |
Существует две основные «философии» разработки языков программирования. Одна из них представлена языком Си. Си - это краткий (сжатый, выразительный - это варианты из словаря) системный язык программирования, который позволяет легко и эффективно манипулировать структурами данных в памяти. Другой подход воплощен в Паскале. Паскаль - это удобочитаемый язык программирования приложений, обеспечивающий высокий уровень безопасности. |
| The C approach is particularly adequate for writing low-level code such as device drivers. When C was increasingly being used for applications as well, a zero errors ideology formed, which says that because programming errors must not occur, they will not occur. A "real programmer" doesn't make mistakes, and therefore doesn't need any kind of protection facilities forced upon him by the lan-guage. Safety features such as index overflow checks are for beginners only; for professionals they are merely a handicap |
Подход Си, частично годится для написания низкоуровневого кода, такого как драйверы устройств. Именно, в то время, когда Си стал использоваться для [разработки] приложений, сформировалась идеология безошибочности, которая утверждала, что ошибки не будут случаться потому, что они не должны случаться. «Настоящий программист» не делает ошибок, а по сему не нужно никаких средств защиты, навязанных ему языком. Средства безопасности, такие как проверки переполнения индекса, - только для начинающих, для профессионалов же - они просто помеха. |
| However, modern psychological research has clearly shown that humans make mistakes all the time, whether they write programs, develop mathe-matical proofs, fly airplanes, or perform operations on a patient. Mistakes are made whether or not they are admitted. The important insight is that most mistakes can be corrected easily if they are de-tected early on. Detection works best in an openly communicating team, where a team member is not afraid of others double-checking his or her work (and thereby exposing the mistakes). Good airlines let their pilots train such cooperative behavior under stress. Some very forward-thinking clinics use a similar training for surgeons and their aides. They have overcome the zero errors ideology in their fields. |
Однако, современные исследования психологов ясно показали, что люди постоянно ошибаются: пишут ли они программы, разрабатывают ли математические доказательства, управляют ли самолетом, оперируют ли больного. Ошибки делаются вне зависимости от того, допустимы ли они или нет. Важным пониманием является то, что чем раньше большая часть ошибок обнаружена, тем легче они могут быть исправлены. Этот процесс лучше всего работает в коллективах, где любой работник не боится многократной проверки своей работы со стороны остальных (и, таким образом, выявления ошибок). Хорошие авиакомпании позволяют своим пилотам тренировать такое поведение в стрессовых ситуациях. Некоторые клиники с передовым мышлением проводят подобные тренировки для хирургов и их помощников. Они преодолели идеологию безошибочности в своих сферах деятельности. |
| In the world of programming, a reverse trend has shaped the industry in the last ten years, by making C the language of choice for all kinds of programs. In terms of software engineering and safety con-sciousness, this was a huge step backwards behind the state-of-the-art. Large companies tried to limit the damage by imposing the use of tools that rein-troduce at least a modest level of safety - instead of solving the problems where it costs least, namely at the language level. |
Однако, в сфере программирования, за последние десять лет (за счет выбора языка Си как средства реализации всех видов программ) сформировались абсолютно противоположные тенденции. В смысле разработки программ и понятия безопасности, это был огромный шаг назад от тогдашнего состояния дел. Большие компании пытались ограничить ущерб путем навязывания использования средств, которые обеспечивали хотя бы благопристойный уровень безопасности - вместо того, чтобы решить проблемы там, где это стоило бы им меньше всего , а именно - на уровне языка. |
| But while it is difficult for a programmer to admit that he makes mistakes, it is much easier for him to acknowledge that other programmers make mis-takes. This became relevant with the Internet. The Internet makes it easy and sometimes even auto-matic to download and execute small programs ("applets") from unknown sites. This code clearly cannot be trusted in general. For good reason, this has scared large corporations enough to look at safer languages again. In fact, safety concerns were the reason why the language Java was created in the first place. Superficially, Java looks similar to C++; but unlike C and C++, it is completely type-safe, like Component Pascal. |
В то время, как любому программисту трудно согласиться, что он делает ошибки, - значительно легче ему признать, что остальные программисты их делают. Это стало актуальным с появлением Интернета. Интернет делает легким и, даже обыденным, загружать и выполнять маленькие программы («апплеты») из неизвестных мест. Такому коду, естественно, вообще нельзя доверять. Эта причина достаточно обеспокоила большие корпорации, чтобы присмотреться к языкам с лучшей безопасностью. Фактически, средства безопасности были именно той причиной, почему был создан язык Ява. Ява похожа на Си++, однако, в отличие от Си и Си++, она подобно Компонентному Паскалю, полностью «типобезопасна» (строгая типизация). |
|
В заключении хотел бы поблагодарить Елену Филиппову за предоставленную возможность изложить свою точку зрения. Конечно я уверен, что никто из тех моих оппонентов, которым я посоветовал дальше не читать, не дочитали это упражнение в полемике до конца (эк вывернул!). Я так думаю каждый остался при своем мнении. Ну что ж, тогда для единомышленников обещанные адреса. Сразу предупреждаю, что список, во-первых, не полный, а, во-вторых, что-нибудь напутано.
Сначала откуда есть КП пошел: www.oberon.ch
Это - вторая вотчина Вирта.
Посмотрите, там масса ссылок на статьи, ресурсы.
Поклонникам Явы будет интересно узнать о Виртовской (вернее компании esmertech) реализации системы РЕАЛЬНОГО времени Jbed (размер в минимальной конфигурации - 8(!) КИЛО, стандарт (со всеми наворотами) - 256 К). Кстати Вирт в последнее время значительный упор делает на встроенные системы. К чему бы это (J)...
Кроме того мною где-то «посеян» целый список форумов и дискуссионных сходок по вопросам работы с Черным Ящиком. Порыщите, народ! Мне тоже не параллельно! Я бы и сам смог, но сейчас у меня горячая пора! Работы выше крыши!
Все что было выше - англоязычное.
Поиски материалов на русском языке можно начать со страницы
Сергея Свердлова (Вологда, ВГПУ). Человек сделал компилятор из Оберона в байт-код JVM (по-моему называется JOB). Может делать приложения и апплеты. С его страницы много до чего добраться сможете.
Кроме того привожу ряд публикаций в журналах (то же некоторые через Интернет достать можно).
Ну вот пока и все!
С наилучшими пожеланиями! 73!
Владимир Лос, 27 декабря 1999г.
[TComponent] [Средства разработки. Языки программирования.] [Free Pascal, Oberon, BlackBox]
 Обсуждение материала [ 03-02-2009 11:57 ] 25 сообщений |
