Библиотека knigago >> Компьютеры: Языки и системы программирования >> Другие языки и системы программирования >> Языки, которые мы потеряли

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

Языки, которые мы потеряли
Книга - Языки, которые мы потеряли.  Крис Касперски  - прочитать полностью в библиотеке КнигаГо
Название:
Языки, которые мы потеряли
Крис Касперски

Жанр:

Другие языки и системы программирования, Статьи и рефераты, Самиздат, сетевая литература, Литература ХXI века (эпоха Глобализации экономики), Программирование: прочее, C, C++, C#, Forth, Lisp, Scheme

Изадано в серии:

неизвестно

Издательство:

неизвестно

Год издания:

-

ISBN:

неизвестно

Отзывы:

Комментировать

Рейтинг:

Поделись книгой с друзьями!

Помощь сайту: донат на оплату сервера

Краткое содержание книги "Языки, которые мы потеряли"

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

Читаем онлайн "Языки, которые мы потеряли". [Страница - 2]

переменными (поведение по умолчанию), или скомбинирует их в двухсимвольную строку? А если взять экземпляры класса 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, была заброшена на полвека именно из-за потери управляемости языком, но затем восстала из пепла в ужасной реинкарнации, уходящей своими корнями в директивы препроцессора языка Си… Но это уже совсем другая история.

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

Но ведь это же неправильно! Появление ракет должно перевернуть наше мышление! Поэтому — строим киоск за орбитой Плутона и каждому даем по ракете, чтобы туда летать, а горючее покупаем за деньги, вырученные от строительства космодромов и продаж ракет. Кто не может строить ракеты — пусть учит других, как на них летать. Сколько создается новых рабочих мест и главное, что все в бизнесе. Вот тут уж действительно, возврата в прошлое нет… Сигареты стоят миллиарды долларов, и

Оставить комментарий:


Ваш e-mail является приватным и не будет опубликован в комментарии.