Языки, которые мы потеряли

Крис Касперски
100
10
(1 голос)
0 0

Аннотация: Позади нас осталось целое кладбище языков, не прижившихся парадигм, вымерших концепций, идей, опередивших свое время. Для будущего не осталось ничего. Все, что только было можно придумать,— уже придумано, реализовано, опробовано и… Выброшено на свалку за ненадобностью. Эпоха великих открытий давно прошла, и нам осталось лишь обезьянничать, двигаясь от золотого века в деградирующую тьму чудовищных лингвистических решений. Назад возврата нет. А все потому, что…Читать книгу Языки, которые мы потеряли онлайн от автора Крис Касперски можно на нашем сайте.

Книга добавлена:
20-11-2022, 09:39
0
275
6
Языки, которые мы потеряли

Читать книгу "Языки, которые мы потеряли"



Явление Си++ народу

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

И ведь никто не виноват!!! Программист, реализующий шаблон, тут, естественно, не причем, ведь он написал, что-то вроде: IF (a>b) THEN RETURN A; ELSE RETURN В, переложив реализацию процедуры сравнения на разработчиков классов, которым, возможно, и в голову не могло прийти, что их классы кому-то понадобится сравнивать. Взять хотя бы класс shape, реализующий различные геометрические фигуры: отрезки, круги. треугольники… Можно ли сравнивать два экземпляра класса shape друг с другом? А почему бы и нет! Это может соответствовать длинам отрезков и площадям фигур. Но ведь… может и не соответствовать!!! Проблема объектного- и метапрограммирования в том, что абстрагируясь от «ненужных» технических подробностей, они скрывают информацию о своем поведении от программиста. Программист каменной эры, глядя на запись А=А+В, мог однозначно сказать, что она выдаст при любых значениях А и В (даже с учетом переполнения переменных). А сейчас? Возьмем две переменные типа «символ» и попытаемся их сложить. Вопрос: как поведет себя реализующий их класс? Будет ли он добавлять код одного символа к другому, оперируя с ними как с целочисленными переменными (поведение по умолчанию), или скомбинирует их в двухсимвольную строку? А если взять экземпляры класса share, то это вообще конец определенности. Математически можно складывать только отрезки (да и то с той лишь оговоркой, что задано их направление, т. е. мы оперируем с отрезком, как с вектором), но сложение квадрата с треугольником— бессмысленно. Зато в графическом аспекте сложение может быть уподоблено наложению, что, кстати говоря, тут же нарушит коммутативное свойство, т. е. А+В совсем не то же самое, что В+А! Вот и попробуй после этого вносить в программу изменения… У программистов каменной эпохи подобных проблем просто не возникало, поскольку язык не давал возможности оперировать абстрактными концепциями и в каждой точке программы приходилось выражать законченную техническую мысль. Конечно, это приводило к дублированию кода, снижало наглядность листинга, но зато исключало неоднозначности его интерпретации. Абстрагируясь от базовых концепций, мы усиливаем лексическую мощь языка (там где раньше приходилось писать тысячу команд, сейчас достаточно одной), но вместе с нею увеличиваем количество взаимодействий между различными компонентами, которые как-то нужно учитывать… В результате за кажущуюся легкость программирования приходится расплачиваться многократно возросшей сложностью проектирования. Язык невозможно осваивать последовательно, шаг за шагом, как это было раньше. Если на Бейсике первая программа состояла всего из одной строки «PRINT 'hello'», то теперь даже минимально работающая программа (с шаблонами, естественно) этих строк насчитывает десятки! Создавая новый экземпляр класса, мы должны обработать ситуацию с нехваткой памяти, установить обработчики исключений (ну или хотя бы «заглушки») и заблаговременно предусмотреть реакцию программы на ситуации, которые в рамках древнего процедурного программирования просто не возникали. Кстати, тот, кто считает, метапрограммирование достижением последних десятилетий, — жестоко ошибается. Да, в языке Си++ оно появилось совсем недавно и в полном объеме (описанном в последних редакциях Стандарта) не реализовано ни в одном реально существующем компиляторе, a Nemerle и R# (языки программирования для платформы. Net со встроенной поддержкой метапрограммирования) — вообще младенцы, но на самом деле концепция метапрограммирования возникла еще во времена палеолита. Lisp, появившийся в далеком 1958 г., — хороший пример языка, естественным образом поддерживающий метапрограммирование, одной из задач которого является создание программы, выводящей точную копию своего собственного исходного текста — так называемый куин (англ, quine). На Lisp'e он записывается так:

(funcall (lambda (x)

(append x (list (list 'quote x))))

'(funcall (lambda (x)

(append x (list (list 'quote x))))))

На Си так:

#include<stdio.h>

char*i="\tinclude<stdio.h>",n=' n',q="",*p=

«%s%cchar*i=%c%c%s%c,n='%cn',q='%c',*p= %c%c%s%c,*m=%c%c%s%c%c;%s%c",*m=

«int main () {returnIprintf (p,i+l,n,q,*i,i,q,*i,q,n,q,p,q,n,q,m,q,n,m,n);}"

;int main(){return!printf(p,i+l,n,q,*i,i,q,*i,q,n,q,p,q,n,q,m,q,n,m,n);}

А теперь попробуйте реализовать тоже самое на Си++ с использованием шаблонов и посмотрите, насколько сильно они вам «помогут». Парадигма метапрограммирования, красиво реализованная в Lisp'e, была заброшена на полвека именно из-за потери управляемости языком, но затем восстала из пепла в ужасной реинкарнации, уходящей своими корнями в директивы препроцессора языка Си… Но это уже совсем другая история.

Язык Си++ оказал огромное влияние как на мышление программистов, так и на развитие всех последующих языков, став стандартом де-факто. Никто, естественно, не говорит, что ООП- и метапрограммирование— это плохо. Почему обязательно плохо?! Очень даже хорошо! Местами. Но вот мысль о том, что ООП — единственно правильный подход — ужасна. Самолеты и космические корабли мирно сосуществуют с велосипедами и автомобилями. Никому ведь и в голову не придет летать за сигаретами на ракете, особенно если сигареты продаются в киоске на соседнем углу.

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

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


Скачать книгу "Языки, которые мы потеряли" - Крис Касперски бесплатно


100
10
Оцени книгу:
0 0
Комментарии
Минимальная длина комментария - 7 знаков.
Книжка.орг » Образование » Языки, которые мы потеряли
Внимание