Крис Касперски - Языки, которые мы потеряли

собственной тяжестью и проще было переписать их заново, чем добавить пару строк в уже существующий код, что, естественно, не устраивало ни пользователей, ни программистов. Языки последующих поколений совершили качественный рывок вперед, избавившись от множества недостатков своих предшественников, но… при этом они так усложнились, что язык из инструмента для решения проблем сам по себе превратился в проблему, образовав предметную область шириной во всю жизнь. Алгоритмы оттеснились на задний план, и вузы стали выпускать молодых людей с кашей в голове и программирующих на Си++ еще хуже, чем на Бейсике — с кучей глобальных переменных и десятками классов, там где и трех функций хватило бы с избытком… Программирование усложнилось так, что стало уделом избранных. Появились консультанты по языку (не умеющие программировать вообще, но знающие Стандарт как отче наш, это что-то вроде искусствоведов, не нарисовавших ни одной картины, но с умным видом рассуждающих о правилах композиции, восходящих и нисходящих мажорных и минорных линиях и т. д.) При этом ни Си++, ни его последователи не решили поставленных перед ними проблем. Напротив, они открыли множество новых возможностей испортить дизайн программы так, что потом его никакими средствами уже не исправить. Если программу, написанную на процедурном языке, можно переписывать по частям, исправляя ее структуру путем декомпозиции, то с Си++ этот номер так просто не пройдет. Иерархия классов жестко задается на этапе проектирования и закладывается в программу точно железобетонный каркас, расширяемый только в одном направлении — в направлении наслаивания нового кода. В результате нас окружают программы-монстры, а программисты утрачивают возможность понимать друг друга. Изобилие языковых средств приводит к тому, что использование всех конструкций языка одновременно становится затруднительно и неоправданно. Даешь каждому программисту по парадигме! Ну и что с того, что остальные ни строчки не понимают! Никто же ведь и не обещал, что программировать — легко! А почему, собственно, программировать должно быть тяжело?! Почему мы ссылаемся на авторитеты всякий раз, когда чувствуем себя недостаточно компетентными?! Откуда вообще взялась слепая вера в то, что профессиональный программист обязан идти в ногу с прогрессом, осваивая новые библиотеки, языки и т. д.? И уже совсем не понятно, почему программирование превращается в соревнование, кто напишет самую непонятную программу с использованием новейших языковых средств. Программирование идет по пути непрерывного наращивания сложности, и эта гонка «вооружений» ничего хорошего в себе не несет. В мире есть только одна причина, способная поддерживать движение этой машины — деньги. Программное обеспечение невероятно дорого, и разработчикам хочется, чтобы оно было еще дороже. Программировать быстро, красиво и эффективно становится просто невыгодно, вот индустрия и движется к собственному краху огромными прыжками.

Остановить этот суицид очень просто — достаточно на законодательном уровне потребовать от производителей отвечать за свой продукт, выплачивая неустойку за каждую критическую ошибку. Программисты мгновенно одумаются и выкинут из программы все лишние узлы, а оставшиеся перепишут с использованием «легких» языковых средств, выбросив «заумные» и «тяжелые» в топку.

Впрочем, процесс упрощения языков пошел уже и без того. При всей моей нелюбви к С#, я все-таки вынужден признать, что это большой шаг вперед, поскольку из него выкинули кучу конструкций Си++, которые были слишком сложны для рядовых программистов. В результате на С# намного меньше шансов написать уродливую программу, и это вселяет надежду, что свет в конце тоннеля все-таки есть. Или это всего лишь встречный? Вопрос риторический, а значит, безответный.

Список литературы

IT спец № 07 ИЮЛЬ 2007

--">