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

деньги в индустрию вращаются просто огромные. Кто же захочет от них отказываться?! Напротив, ракеты будут стремительно «совершенствоваться», чтобы за сигаретами можно было летать даже на Альфу Центавра. Говорите, что это нелогично и невозможно? Но ведь именно такая ситуация сложилась с Си++. Судите сами — реализация компиляторов языка Си++ очень сложная и дорогостоящая задача, а сам язык настолько обширен и объемен, что его изучение требует невероятных усилий. Чтобы окупить средства, вложенные в разработку компиляторов, фирмы вынуждены «подсаживать» на него миллионы программистов, которые, пройдя длительный (и ужасно мучительный) путь обучения Си++, просто не могут признаться себе в том, что напрасно убили десять лет своей жизни (данной человеку лишь однажды!) и что стоящие передними задачи с ничуть не меньшей эффективностью реализуются на чистом Си и других процедурных языках, легко осваиваемых на ходу без отрыва от производства. Вот они и начинают убеждать остальных, что процедурные языки давно мертвы. Сложность ради сложности.

Впрочем, среди этого мрака есть и светлые пятна. При приеме в нормальную фирму за попытку решить задачу с применением шаблонов, там, где они не требуются, по головке не погладят и программу скорее всего не зачтут. Один из известных «подколов» — написать программу, выводящую сумму первых 100 натуральных чисел на экран, int а, Ь=0; for(a=1;a<101;a++) b+=a; printf(«%d\n», b);— незачет, printf(«5050\n») — зачет. Ключевое слово здесь — «выводящую», а не «вычисляющую». Чуть более жестокий вариант— вывод первой сотни простых чисел. Разумеется, сумму членов арифметической прогрессии можно вычислить и в уме, а найти простые числа без компьютера не то, чтобы нереально, просто… зачем мучаться, когда компьютер под рукой? Однако, программист — это прежде всего инженер, а инженер должен не только внимательно читать ТЗ, но и выбирать адекватные средства для решения задачи. В данном случае — написать программу, генерирующую программу, выводящую простые числа на экран, т. е. что-то вроде: рг::: 1,5,7…\n»), после чего первую программу можно смело стереть. Действительно, какой смысл обсчитывать одни и те же данные при каждом запуске программы, когда это достаточно сделать всего один раз?! Важно понять, что язык — это всего лишь средство выражения мыслей. Не стоит фетишизировать его. Умные мысли можно выразить и в машинном коде (там, где это оправданно), если же мыслей нет — не поможет никакой язык. Проблема, однако, в том, что программирование машины (т. е. задание последовательности операций, которая она должна выполнять) все больше превращается в диалог с ней. Программисты перестали обдумывать решения поставленных задач вдали от машины. Компьютер превратился в калькулятор, а программы — в «записки охотника». Именно поэтому, когда современный программист слышит «сумма ряда», он рефлекторно представляет себе цикл и машинально тянется к клавиатуре… Он утратил понимание того, что язык (машинный) тут и рядом не валялся. Это чисто математическая задача, а от машины требуются лишь средства ввода/ вывода для печати результата.

ООП в ретроспективе

Многие языки, возникшие задолго до появления термина ООП (например, уже упомянутый Лисп), вполне отвечают его критериям, возможно, даже в большей степени, чем «чистокровные» представители ООП, такие как Си++ или его прямые предшественники Симула (Simula) и Смолток (Smalltalk), созданные в 1967 и 1980 году соответственно. Кстати, о предшественниках. Язык Си++ часто критикуют за то, что обращение к методу класса в нем реализовано как вызов функции, в то время как Симула и Смолток позволяли объектам обмениваться сообщениями. Сторонники Си++ утверждают, что конкретный способ вызова метода класса — внутренняя кухня языка, скрытая от программиста и что посылка сообщения является частным случаем вызова функции, только прямой вызов намного более эффективен в плане накладных расходов и машинных затрат на такты и оперативную память.

Все это так, но… Симула и Смолток естественным образом поддерживают многозадачность, многопоточность и распараллеливают вычисления на уровне языка. Посылка сообщений может быть как синхронной (объект посылает сообщение и ждет результата), так и асинхронной (объект посылает сообщение и продолжает заниматься своими делами). Это позволяет транслятору в кооперации с операционной системой равномерно раскидать объекты по процессорам или даже по --">