46078 (762211), страница 2
Текст из файла (страница 2)
Исходные коды «hello, world» программ на 190 языках программирования: http://en.wikibooks.Org/wiki/Transwiki:List of hello world programs
Эволюция программистов и языков программирования (шутка) www.ariel.com.au/iokes/The Evolution of a Programmer.html
Самомодификация в законе
В Лиспе (Lisp) и Форте (Forth), созданных в 1958 и 1970 годах соответственно, самомодификация была вынесена на уровне языка, что позволяло реализовывать высокоэффективные программы, построенные на динамических алгоритмах. Уникальнейшей особенностью Форта (не реализованная ни в каком другом языке) была и остается возможность «честной», модификации Форт-машины, то есть непосредственно самого транслятора, который при желании со стороны программиста можно вообще полностью переписать штатными средствами самого языка!
В Фортране, Алголе, Паскале, Си/Си++ и прочих «хороших и разных», клонах (включая Бейсик) самомодификация возможна лишь теоретически - путем варварской правки машинного кода в оперативной памяти. Почему «варварской».? Да потому, что язык к этому не имеет никакого отношения, более того, самомодификация опирается на недокументированные возможности языка, закладываясь на логику конкретных трансляторов, что чревато развалом программы при переходе на другой компилятор, не говоря уже о том, что машинный код - штука понятная лишь небольшому кругу избранных, но даже Великий Гуру не сможет написать самомодифицирующуюся программу, работающую более чем на одном процессоре. В конечном счете, самомодификация попала в черный список дурных приемов программирования, а сами программы «распались», на код и данные, обрабатываемые этим кодом, инвариантным по отношению к самим данным. Другими словами - один и тот же код обрабатывает разные данные, что не есть правильно. Машина Тьюринга вообще не имела таких понятий. В ней код был неотделим от обрабатываемых им данных. Вернее, поступающие данные задавали методы их обработки (естественно, в рамках заложенных в машину алгоритмов).
К счастью, в последнее время предпринято несколько попыток реабилитации самомодификации. Во-первых, это Java со своей виртуальной машиной, байт-код которой не меняется от процессора к процессору, а, значит, самомодификация не ухудшает переносимость программы (правда, если быть честным, Java не предоставляет для самомодификации никаких языковых средств и программисту приходится работать с низкоуровневыми командами чтения/записи памяти). Во-вторых, Си++, Nemerle и RW поддерживают (и активно продвигают) парадигму метапрограммирования, позволяя писать программы, создающие другие программы, которые в свою очередь создают третьи... Это, конечно, не совсем самомодификация, но нечто на нее похожее. Однако, реализация метапрограммирования крайне тяжеловесна, логика и синтаксис - запутаны, сложны для понимания и абсолютно непрозрачны, а возможности существенно уступают Форту и Лиспу. В общем, муть и мрак.
Вавилонское столпотворение
Всякий раз, когда появляется очередной новый язык, о котором говорят, как об «окончательном и безальтернативном», предрекая скорую смерть всех остальных, мне становится смешно.
Сам по себе язык в отрыве от среды программирования —малоинтересен, да и все языки крутятся вокруг одного и того же набора концепций и парадигм, просто разные языки смешивают этот коктейль в различных комбинациях. Популярность Си++ отчасти вызвана тем, что он вобрал в себя все существующие парадигмы, допускающие эффективную реализацию. Остальные языки либо неэффективны, либо представляют собой подмножество Си++. Да, есть совершенно иные классы языков, в частности логические языки (ярким примером которых является Prolog), основанные на выводе новых фактов из заложенных в них данных согласно установленной системе логических правил, работающей в замкнутом мире фактов. Другими словами, если определить объекты «вода», «чайник», «газ», «огонь», то Prolog'y достаточно дать задание «вскипятить воду», чтобы он поставил чайник на огонь. Но... насколько же медленно он это сделает! И сколько времени уйдет на формирование «базы знаний» об объектах окружающего мира. В отличие от Си++, придерживающегося парадигм декларативного программирования, описывающих процесс вычисления в виде инструкций, изменяющих состояние программы, функциональные языки (самый популярный из которых Haskell) не представляют собой последовательность инструкций и не имеют глобального состояния, вместо этого они определяют, что нужно вычислять, а как это делать—забота транслятора. Вот только эффективных трансляторов декларативных языков упорно не наблюдается. Увы, машина не может мыслить, а ответ на вопрос «как это сделать?» предполагает активную творческую деятельность. Таким образом, благополучию Си++ ничего не угрожает. Сколько бы языков ни создавалось и какие бы усилия ни предпринимались для продвижения их на рынок, мы получим либо урезанный вариант Си++, либо страшный тормоз. Ни то, ни другое программистам даром не нужно. Разумеется, это не означает, что Си++— венец эволюции. Скорее, это свалка всех идей, демонстрирующих хорошую эрудицию его создателей, но нарушающих целостность языка, из-за чего, собственно, с завидной регулярностью появляются «претенденты на престол», пытающиеся отобрать лучшие из конструкций Си++, скомпоновав их в гармоничный «букет», но... новые языки приходят и уходят, а Си++ вбирает в себя все удачные решения своих конкурентов, становясь целым миром. И навряд ли найдется хоть один вменяемый программист, который осмелится утверждать, что он владеет этим миром во всей его полноте. Максимум на что он может претендовать — на ту малую часть, которую вмещает ум отдельно взятого индивидуума.
***
Заключение или есть ли свет в конце тоннеля?
Первые языки программирования были крайне простыми, изучались они быстро и легко, а потому при обучении основное внимание уделялось концептуальным понятиям — архитектуре, алгоритмам и т. д., однако языковые средства того времени были недостаточно выразительными для записи мыслей в наглядной удобочитаемой форме и код быстро превращался в «спагетти», которое было невозможно ни отлаживать, ни сопровождать, ни развивать. При достижении определенных размеров программы буквально «рушились» под собственной тяжестью и проще было переписать их заново, чем добавить пару строк в уже существующий код, что, естественно, не устраивало ни пользователей, ни программистов. Языки последующих поколений совершили качественный рывок вперед, избавившись от множества недостатков своих предшественников, но... при этом они так усложнились, что язык из инструмента для решения проблем сам по себе превратился в проблему, образовав предметную область шириной во всю жизнь. Алгоритмы оттеснились на задний план, и вузы стали выпускать молодых людей с кашей в голове и программирующих на Си++ еще хуже, чем на Бейсике—с кучей глобальных переменных и десятками классов, там где и трех функций хватило бы с избытком. .. Программирование усложнилось так, что стало уделом избранных. Появились консультанты по языку (не умеющие программировать вообще, но знающие Стандарт как отче наш, это что-то вроде искусствоведов, не нарисовавших ни одной картины, но с умным видом рассуждающих о правилах композиции, восходящих и нисходящих мажорных и минорных линиях и т. д.) При этом ни Си++, ни его последователи не решили поставленных перед ними проблем. Напротив, они открыли множество новых возможностей испортить дизайн программы так, что потом его никакими средствами уже не исправить. Если программу, написанную на процедурном языке, можно переписывать по частям, исправляя ее структуру путем декомпозиции, то с Си++ этот номер так просто не пройдет. Иерархия классов жестко задается на этапе проектирования и закладывается в программу точно железобетонный каркас, расширяемый только в одном направлении — в направлении наслаивания нового кода. В результате нас окружают программы-монстры, а программисты утрачивают возможность понимать друг друга. Изобилие языковых средств приводит к тому, что использование всех конструкций языка одновременно становится затруднительно и неоправданно. Даешь каждому программисту по парадигме! Ну и что с того, что остальные ни строчки не понимают! Никто же ведь и не обещал, что программировать—легко! А почему, собственно, программировать должно быть тяжело?! Почему мы ссылаемся на авторитеты всякий раз, когда чувствуем себя недостаточно компетентными?! Откуда вообще взялась слепая вера в то, что профессиональный программист обязан идти в ногу с прогрессом, осваивая новые библиотеки, языки и т. д.? И уже совсем не понятно, почему программирование превращается в соревнование, кто напишет самую непонятную программу с использованием новейших языковых средств. Программирование идет по пути непрерывного наращивания сложности, и эта гонка «вооружений» ничего хорошего в себе не несет. В мире есть только одна причина, способная поддерживать движение этой машины —деньги. Программное обеспечение невероятно дорого, и разработчикам хочется, чтобы оно было еще дороже. Программировать быстро, красиво и эффективно становится просто невыгодно, вот индустрия и движется к собственному краху огромными прыжками.
Остановить этот суицид очень просто—достаточно на законодательном уровне потребовать от производителей отвечать за свой продукт, выплачивая неустойку за каждую критическую ошибку. Программисты мгновенно одумаются и выкинут из программы все лишние узлы, а оставшиеся перепишут с использованием «легких» языковых средств, выбросив «заумные» и «тяжелые» в топку.
Впрочем, процесс упрощения языков пошел уже и без того. При всей моей нелюбви к С#, я все-таки вынужден признать, что это большой шаг вперед, поскольку из него выкинули кучу конструкций Си++, которые были слишком сложны для рядовых программистов. В результате на С# намного меньше шансов написать уродливую программу, и это вселяет надежду, что свет в конце тоннеля все-таки есть. Или это всего лишь встречный? Вопрос риторический, а значит, безответный.
Список литературы
IT спец № 07 ИЮЛЬ 2007
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
