Позади нас осталось целое кладбище языков, не прижившихся парадигм, вымерших концепций, идей, опередивших свое время. Для будущего не осталось ничего. Все, что только было можно придумать, — уже придумано, реализовано, опробовано и… Выброшено на свалку за ненадобностью. Эпоха великих открытий давно прошла, и нам осталось лишь обезьянничать, двигаясь от золотого века в деградирующую тьму чудовищных лингвистических решений. Назад возврата нет. А все потому, что…
Язык определяет мышление, а мышление формирует язык, в результате чего язык начинает стремительно развиваться, приобретая новые, ранее не свойственные ему черты, не только позволяющие программисту выражать инженерную мысль во всей ее полноте, но и порождающие совершенно новые мысли, вытекающие из свойств языка.
Появление абстрактных типов переменных (не имеющих прямого машинного воплощения) — довольно наглядный тому пример. Программисты каменной эры, высекающие программы долотом (долотом в прямом смысле — на перфокартах), мыслили в конкретной плоскости — включить мотор дисковода, прочитать сектор, положить данные в ячейку размеров в N-слов, расположенную в памяти по адресу Р… Современные языки отошли от железа и мыслят категориями абстрактных концепций, позволяя сравнивать переменные А и В, одна из которых представляет файл на диске, а другая — сетевой локатор. Хорошо это или плохо?! Все намного хуже, чем вы предполагаете. Абстрактное мышление смертоносно, ибо провоцирует программиста на решение задачи в общем виде на сто тысяч строк исходного кода, в то время как частное решение (отвечающее ТЗ) уложилось бы и в десяток. Но это еще не самое страшное, истина в том, что…
Явление Си++ народу
Язык Си++ (а вместе с ним и его многочисленные «преемники») уже давно не является объектно-ориентированным языком и доэволюционировал до метапрограммирования, более известного как программирование с использованием шаблонов (хотя шаблоны — всего лишь одно из средств его реализации). Конечная цель метапрограммирования — создание программ, создающих другие программы как результат своей работы, т. е., другими словами, язык престает быть сущностью, полностью подчиненной авторскому замыслу, и приобретает определенную самостоятельность, значительно упрощающую решение поставленной задачи, но вместе с тем вносящую большую долю неопределенности и неуправляемости. Например, вместо того, чтобы писать десяток функций, сравнивающих переменные различных типов, достаточно запрограммировать один-единственный шаблон. Правда, тут же возникает вопрос: а как он себя поведет, если ему «скормить» нечисловые переменные? Ответ — шаблон вообще ничего не знает ни о типах, ни о размерностях. Он просто обращается к методам соответствующих классов, которые могут быть реализованы как угодно либо же не реализованы вовсе, и тогда программа даст сбой. До тех пор пока использовались только статические абстрактные типы, «перекладываемые» на машинное представление еще на стадии компиляции, транслятор легко отлавливал подобные ошибки, но с появлением динамических типов, обрабатываемых в реальном времени, язык стал вообще неконтролируемым и программы начали падать в случайное время.
И ведь никто не виноват!!! Программист, реализующий шаблон, тут, естественно, не причем, ведь он написал, что-то вроде: IF (a>b) THEN RETURN A; ELSE RETURN В, переложив реализацию процедуры сравнения на разработчиков классов, которым, возможно, и в голову не могло прийти, что их классы кому-то понадобится сравнивать. Взять хотя бы класс shape, реализующий различные геометрические фигуры: отрезки, круги. треугольники… Можно ли сравнивать два экземпляра класса shape друг с другом? А почему бы и нет! Это может соответствовать длинам отрезков и площадям фигур. Но ведь… может и не соответствовать!!! Проблема объектного- и метапрограммирования в том, что абстрагируясь от «ненужных» технических подробностей, они скрывают информацию о своем поведении от программиста. Программист каменной эры, глядя на запись А=А+В, мог однозначно сказать, что она выдаст при любых значениях А и В (даже с учетом переполнения переменных). А сейчас? Возьмем две переменные типа «символ» и попытаемся их сложить. Вопрос: как поведет себя реализующий их класс? Будет ли он добавлять код одного символа к другому, оперируя с ними как с целочисленными переменными (поведение по умолчанию), или скомбинирует их в двухсимвольную строку? А если взять экземпляры класса share, то это вообще конец определенности. Математически можно складывать только отрезки (да и то с той лишь оговоркой, что задано их направление, т. е. мы оперируем с отрезком, как с вектором), но сложение квадрата с треугольником— бессмысленно. Зато в графическом аспекте сложение может быть уподоблено наложению, что, кстати говоря, тут же нарушит коммутативное свойство, т. е. А+В совсем не то же самое, что В+А! Вот и попробуй
Последние комментарии
12 часов 48 минут назад
16 часов 56 минут назад
17 часов 13 минут назад
17 часов 34 минут назад
20 часов 16 минут назад
1 день 3 часов назад