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

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

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

Жанр:

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

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

неизвестно

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

неизвестно

Год издания:

-

ISBN:

неизвестно

Отзывы:

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

Рейтинг:

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

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

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

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


Читаем онлайн "Языки, которые мы потеряли". Главная страница.

Крис Касперски ЯЗЫКИ, КОТОРЫЕ МЫ ПОТЕРЯЛИ

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

Язык определяет мышление, а мышление формирует язык, в результате чего язык начинает стремительно развиваться, приобретая новые, ранее не свойственные ему черты, не только позволяющие программисту выражать инженерную мысль во всей ее полноте, но и порождающие совершенно новые мысли, вытекающие из свойств языка.

Появление абстрактных типов переменных (не имеющих прямого машинного воплощения) — довольно наглядный тому пример. Программисты каменной эры, высекающие программы долотом (долотом в прямом смысле — на перфокартах), мыслили в конкретной плоскости — включить мотор дисковода, прочитать сектор, положить данные в ячейку размеров в N-слов, расположенную в памяти по адресу Р… Современные языки отошли от железа и мыслят категориями абстрактных концепций, позволяя сравнивать переменные А и В, одна из которых представляет файл на диске, а другая — сетевой локатор. Хорошо это или плохо?! Все намного хуже, чем вы предполагаете. Абстрактное мышление смертоносно, ибо провоцирует программиста на решение задачи в общем виде на сто тысяч строк исходного кода, в то время как частное решение (отвечающее ТЗ) уложилось бы и в десяток. Но это еще не самое страшное, истина в том, что…

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

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

И ведь никто не виноват!!! Программист, реализующий шаблон, тут, естественно, не причем, ведь он написал, что-то вроде: IF (a>b) THEN RETURN A; ELSE RETURN В, переложив реализацию процедуры сравнения на разработчиков классов, которым, возможно, и в голову не могло прийти, что их классы кому-то понадобится сравнивать. Взять хотя бы класс shape, реализующий различные геометрические фигуры: отрезки, круги. треугольники… Можно ли сравнивать два экземпляра класса shape друг с другом? А почему бы и нет! Это может соответствовать длинам отрезков и площадям фигур. Но ведь… может и не соответствовать!!! Проблема объектного- и метапрограммирования в том, что абстрагируясь от «ненужных» технических подробностей, они скрывают информацию о своем поведении от программиста. Программист каменной эры, глядя на запись А=А+В, мог однозначно сказать, что она выдаст при любых значениях А и В (даже с учетом переполнения переменных). А сейчас? Возьмем две переменные типа «символ» и попытаемся их сложить. Вопрос: как поведет себя реализующий их класс? Будет ли он добавлять код одного символа к другому, оперируя с ними как с целочисленными

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


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