Фатальные дефекты

        У всех наверное технологий есть свои обусловленные историческим развитием "особенности", которые могут как минимум не соответствовать теоретическим парадигмам инженерии программного обеспечения и служат предметом постоянного слома копий между их противниками и адвокатами. Чаще всего устранить или исправить их сложно или почти невозможно, или как-будто нецелесообразно т.к. уже много кода создано с учетом этих проблем и исправление приведет к его устареванию, неработоспособности и затратам на управление. Платформы которые имеют серьезную культуру проектирования и разработки обычно обычно характеризуются не столь вопиющими фатальным проблемами, а вот любительские инструменты созданные сообществами и одиночками очень часто содержат множество совсем несуразных проблем. Так в языке программирования питон напримерн необходимо всегда явно передавать ссылку на экземпляр класса (self) в сигнатуре каждого метода, чего нет пожалуй ни в одном другом языке, по крайней мере из тех, что создавались в эру ооп. Большое число таких проблем ведет сначала к массовой ненависти по отношению к технологии, что одновременно видимо и популяризирует ее за счет эффекта скандальной славы, но затем неизбежно эту технологию хоронит в пользу других. Так выразительный язык Perl не имел классов в обычном понимании ооп, в 6ой версии разработчики попытались создать универсальную виртуальную машину и новый стандарт языка, однако за время пока они ее делали язык успел растерять большинство сторонников и спциалистов и фактически умер, уступив место не менее богатым на проблемы PHP и Python, кое какой ооп у которых все же имелся. В это время по отрасли шагал паттерн разработки модель-вид-представление (MVC), в котором без ооп как-то не просто. Была замечательная технология Flash, которая позволяла очень удобно и быстро создавать анимацию, игры, и даже веб-приложения в том числе с использованием возможностей не доступных остальному клиентсайдовому вебу, однако ее фатальный недостаток оказался в обособленности от этого самого веба следовательно некоторый замкнутости в развитии и проблемам в использовании. Кроме того флеш был в некоторой части динамически типизированным, что в то время давало некоторые преимущества в продуктивности разработчиков и более низком пороге вхождения, а следовательно и стоимости над существовавшими серьезными технологиями программирования. За время развития, прежде всего серьезных технологий и появления новых промежуточных видов преимущество динамически типизированных стало их фатальным недостатком, т.к. оно дает существенно больший процент пропускаемых ошибок, а следовательно перерасходы по оценкам коммерческой разработки, худшую практику использования, затрудненный поиск ошибок и рефакторинг. Масштабный проект на динамически типизированной технологии чреззвычайно сложен в поддержке и сколь либо серьезном развитии. Даже с такими простыми потребностями как автодополнение кода в средах разработки у них всегда было гораздо больше проблем.

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

        Сам по себе синтаксис динамических языков часто содержит лишние символы навроде доллара $ или собачки @, что было внедрено очевидно для более простого разбора в том числе малофункциональными текстовыми редакторами, что в принципе неплохо для задач создания скриптов, однако совершенно излишне при работе с ощутимыми по обьему кода и логических единиц приложениями. Наличие таких символов создает визуально грязный и трудно читаемый код, т.е. разбирать его сложно не только парсерам инструментов разработки, но и инженерам.

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

 

Среднее (0 Голоса)
Средний рейтинг 0.0 звезд из 5.


Пока нет комментариев. Будь первым.