Они верят. И вы к этому должны быть готовы. Ведь вы же сами себя предупредили!
Кроме того — в вашей вселенной нет выхода. Это бьёт по голове каждому читателю. А ведь они так хотят видеть выход! Сладкий, мягкий, удобный, подъехавший прямо к их креслу. Но выхода-то статья и не предлагает! Тем более, подъехавшего к дивану.
Но на самом деле вы всё написали достаточно правильно, кроме отсутствующего указания на выход, разумеется. По мелочи придраться можно, но сути это не меняет — люди рабы системы и это данность, система не для них и вариантов нет, кроме… А что кроме? А там тот самый выход.
Описать алгоритм — это меньшая из проблем. Настоящая проблема — понять, почему именно такой алгоритм является хотя бы просто достаточным для современных реалий. Ну и было бы чудесно, если изложение строилось примерно так — данная часть алгоритма выполняет такое-то действие, потому что это действие необходимо для… и далее — зачем это действие, почему без него нельзя (или хуже).
По простому — зачем в алгоритме 3 шага? Почему недостаточно одного xor-а? Что даёт последующее нелинейное преобразование? Что даёт наложение линейного преобразования?
Возможно, проблема в размере ключа, а всё остальное каким-то образом повышает сложность вскрытия ключа небольшой длины. Но почему бы об этом не написать?
В прологе есть механизм унификации, то есть по другому — сопоставление шаблонов. Например — есть сущность — человек(зовут(«Вася»), живёт(«под мостом»)), а мы хотим найти экземпляр данной сущности, про который известно, что его(её) зовут Нина, тогда пишем — человек(зовут(«Нина»), пофигГдеЖивёт) — и получаем ответ — нет в БД таких сущностей. Здесь дерево вида человек(поддеревья) сопоставляется с имеющимися шаблонами и первое поддерево (которое про Нину) отсекает все имеющиеся в базе варианты. А вот если бы мы спросили так — человек(пофигКакЗовут, пофигГдеЖивёт), то мы обязательно нашли бы Васю. Это аналог SQL — select * from person. Но механизм унификации (шаблонов) позволяет сопоставлять целые деревья, а не одну гладкую строку. Это в SQL тоже достижимо, но для этого нужно строить декартово произведение всех ветвлений дерева, что может быть неэффективно при плохо спроектированной схеме данных, ну а для пролога это не всегда существенно, поскольку обход дерева можно сократить перенеся в начало обход наиболее мощного варианта (в БД же это не всегда правильно пытается делать оптимизатор, хотя и пролог тоже оптимизируют).
>> Пролог критикуется, в первую очередь, за неполную декларативную природу
Не совсем так. Природа-то полная, но что бы ей соответствовать, нужны бесконечные вычислительные ресурсы либо очень умный оптимизатор (на уровне человека). Только в вашем языке внутри вряд ли ИИ сидит, а потому и он грешен не меньше пролога.
>> на нем невозможно построить прикладных программ.
Построено много таких программ, но они нишевые. Например — управление посадкой Бурана (аналог Шаттла) частично написано на прологе, но очевидно, что сама задача далеко не массовая, а потому многим кажется, что пролог вообще никто и никак не использует. В плане же бизнес-логики in-memory database, которую как раз удобно писать на прологе, вполне применима для разного рода свойств и поиска по ним с некоторым логическим выводом. Но сложность бизнес-приложений обычно невысокая, а потому такие задачи быстрее решить на том, что знаешь, а не изучать пролог и способы его прикручивания в проект. Хотя вот GUI или тот же построитель запросов (близко к OLAP) уже предполагают как раз прологовский подход, что и я бывало использовал.
>> Давайте все-таки примеры парадигм с реально работающими реализациями и практическим применением
Вообще это интеллектуальные задачи, которые не могут быть массовыми. Пролог, дополненный работой с ограничениями, примерно в таких областях и используется. Хотя в этой части сильна конкуренция со стороны функциональных языков. Каких-то выстреливших массовых технологий не вспоминается, но массовость же достигается именно благодаря простоте задач, иначе сложно найти необходимое количество разработчиков. Так что и пролог и функциональное программирование в массах не особо распространены. Хотя функциональный подход постепенно внедряется в императивные языки и уже довольно популярен. Может и ваш инструмент поможет введению декларативной логической части в массовые языки.
>> Другим часто подвергаемым критике свойством языка является отсутствие типизации
Типизация там тоже есть, но не в стандартном виде проверки аргументов на этапе компиляции. В принципе IDE могли бы ещё до компиляции проверять наличие подходящих правил и как-то выделять в программе места, которые не унифицируются ни с одним правилом. Это примерно как проблема JavaScript — там тоже есть типы, но они скрыты внутри движка, да ещё на это накладываются неявные преобразования, позволяющие иногда передавать в функции неподходящие типы или получать undefined для, например, математических операций с объектами (то есть результат «ошибка» заменяется менее явным результатом). Но если в JavaScript это всё сделано в угоду упрощенчеству, то в прологе это сама суть языка — он проверяет, подходит ли аргумент под имеющиеся факты/правила или нет, и если не подходит — это законная возможность, не являющаяся ошибкой. В SQL аналог такой — в части WHERE задаётся шаблон, которому должны соответствовать данные в БД, соответственно, данные могут быть найдены или могут быть не найдены и оба результата — правильные, это не ошибка. То есть «отсутствие типизации» в прологе такое же, как и в SQL.
>> То есть нашел нужный функционал, написал REQUIRE
Вот как это выглядит в Eclipse — я нажимаю ctrl+shift+o и мне предлагается список одинаковых названий классов из разных пакетов. Я выбираю — и всё, ничего искать не надо, тем более что-то писать. А если имя класса уникально — даже выбирать не надо.
В целом по модульности понятно — как у всех. То есть просто куча файлов, с которым (уж как умеет) разбирается IDE.
>> Вообще ООП, а точнее полиморфизм / наследование плюс событийное программирование очень сильно недооценивают в разработке бизнес-приложений
Это просто структурирование задачи. И естественно, этим многие и активно занимаются. Другое дело, что в мире гораздо больше даунов, которые… Ну в общем они могут много чего недооценить.
>> очень часто переделывают то что есть, потому что клиенты постоянно экспериментируют
Мне вспоминается обычное недовольство типа «вот здесь нет поля ХХХ» или «вот это система должна сама!». И выливается это всё в довольно простые действия по добавлению поля или выполнению простого расчёта с выводом результата. Большего от учётных систем редко требуют. Поэтому здесь скорее речь об организации процессов в разработке, в смысле производительность у вас, конечно, как у всех, и не зависит от инструмента (или слабо зависит), а доработки требуют 10 человек именно из-за неидеальности процессов. Хотя соглашусь — в больших конторах процессы ещё более страшные и там легко могут и 100 человек на ваши задачи посадить.
>> сейчас ERP состоит из приблизительно 1100 модулей
Масштаб понятен. А теперь ещё интереснее — как вы во всей этой тысяче ещё не запутались?
>> Поддерживает и дорабатывает около 10 человек
Вообще получается 10 человеко-месяцев каждый месяц убивается на обслуживание изменений. За 10 человеко-месяцев упоминавшуюся систему на 25к строк можно написать (ну почти, то есть без тестирования и прочего отягощающего, плюс эффективно разработку организовать). В итоге получаем, что месяца за два-три-ну-пусть-четыре доработки становятся равны по сложности разработке с нуля. И теперь вопрос — а где выигрыш? Новый язык и многия обещания предполагают огромное сокращение затрат, ведь так? Но тем не менее по трудозатратам систему переписывают полностью раз в несколько месяцев, при чём не реализуют все процессы заказчика с нуля, а лишь слегка подправляют. И вот это «слегка подправляют» равно переписыванию с нуля по затратам. Так в чём выигрыш? Где гигантские сокращения времени разработки, количества ошибок, жалоб пользователей и т.д.?
Выше уже показали сходство с Прологом, поэтому остаётся лишь подчеркнуть — авторы изобрели способ декларации декартова произведения, аналогичный давно известному способу, используемому в прологе. Ну и понятно, для этого нужны новые инструменты, например точно такие же, как в Прологе. Но названы эти инструменты «функциями». В принципе термы Пролога можно интерпретировать как функции, но общепринятые функции не умеют возвращать все значения для всех аргументов, а термы (с соответствующим движком) умеют. То есть умеет движок, конечно, но это применимо вообще ко всему и уводит от полезных абстракций.
>> Вы вообще в курсе, что там под штук 40 разных типов узлов плана?
Ну не надо так страшно пугать. Если встретились с незнакомым алгоритмом джойна — читаем доку и через пол-часика оптимизируем без проблем. Главное — общее понимание процесса.
>> Я сравнивал, когда пытался людям из не IT…
Ну вам всегда нужны уточнения типа «берём выборку из всё-таки хоть как-то причастных людей»?
По модульности что-нибудь скажете? Как много зависимостей между модулями? Сколько лет приходится тратить на поддержку изменений в бизнес-процессах заказчика? Сколько человек поддерживают те 25к строк кода, которые работают на каком-то предприятии?
Про работу SQL знают все, а про работу вашей платформы — ну человек 10 знают. Поэтому вы всё прячете, а SQL ничего не прячет. Просто сравните количество людей, сходу понимающих суть SQL и вашего языка.
>> Мне например Haskell мозг взрывает, ну и все эти |>
Скорее это проблема преподавателя. Точнее — автора той книги, по которой вы пытались учить Хаскель.
Основа там тривиальная. Ну а всякие палочки и прочие значки — вы к ним просто не привыкли, а как привыкнете — они станут очень даже к месту, будут выглядеть логично, выполняя именно ту функция, на которую похожи.
Доказать сможете? Если доказательством опять будет ссылка на реализованный проект на вашем языке, то подскажу — вы встроили в платформу те встретившиеся алгоритмы, которые как раз и выходят за пределы базового набора примитивных действий, обычно идентифицируемого аббревиатурой CRUD. То есть «подшаманили» ради нужных расширений, а теперь некорректно заявляете об охвате 98% алгоритмов. В следующий раз (у следующего заказчика) вам придётся снова подшаманить, потом ещё и ещё. И окажется, то 98% — было явной натяжкой.
>> это скорее комбинаторное, реактивное, логическое и событийное программирование
А теперь было бы неплохо расшифровать приведённые термины. Мною использованы стандартные термины, вы же придумали свои, поэтому расшифровка необходима.
Хотя да, такой подход «сверху», пусть даже через доморощенные термины, я поддерживаю.
>> Декларативный стиль — это метрика того насколько язык высокоуровневый
Процедура «всё прекрасно» может быть написана почти на любом языке. Обратите внимание на силу декларативной метрики в данном примере.
Ну почему же? Вы как раз наглядно показали корни вашей системы. Всё началось с активной работы с БД, далее вам захотелось «расширить и углубить (с)», ну и вы начали сочинять навороты вокруг стандартной реляционной модели, использующей под капотом довольно сложные алгоритмы для выполнения запросов и эффективного хранения данных на диске. В итоге получилась надстройка над SQL, которая в SQL же и конвертируется (как я понял). Отсюда все эти абстрактные заявления про «множество объектов» по которым что-то «пробегает». На самом же деле речь идёт о банальном выполнении селектов по таблицам, возможно in memory tables, но суть-то не меняется.
Вот начали бы вы описание языка именно с такой подачи — это простая настройка над БД, транслирующая наш псевдо-код в SQL выражения и работающая с данными из БД неявным образом. Далее же надо показать — зачем вы прячете от разработчика всё то, что получается в результате трансляции в селекты. Этим вы убиваете понимание происходящего, но что вы при этом добавляете? Мне это совершенно непонятно. Минус (огромный) вижу. Плюсы — сомнительны.
>> небольшой объект с данными или функционалом, который в любое время можно добавить в список объекта-контейнера
В куче языков именно так можно работать с простыми классами или структурами. Просто кидаем их в список и получаем то, что вы называете «компонентный подход». Но это всего лишь один из способов использования классов/структур.
Повторюсь — в абстрактной системе, где непонятна роль платформы и целый алгоритм можно выразить используя длинные строки, просто нет критериев для оценки.
Трансляция в SQL, конечно, местами сокращает код, но это работает лишь до момента, когда потребуются усложнения в алгоритмах. Поэтому вторая часть «25к строк» — предметная область и её сложность. Они опять не заданы. Хотя есть намёк на тип «учётная система», для которой (особенно ради выигрыша в неких абстрактных соревнованиях, а не для реального предприятия) можно наваять ТЗ, предполагающее лишь примитивные селекты да апдейты, что наверняка хорошо ложится в ваш язык. Но если, внезапно, заказчику нужна сложная логика?
>> Фактически мы строили самолет в воздухе вместе с пассажирами
Это не самый удачный подход. Надо хотя бы иногда сажать самолёт и тщательно рассматривать все его составляющие. Ну и улучшать, включая крупные изменения, типа замены крыла на вертолётный винт. Заказчик будет против? Ну ладно, только тогда не стоит говорить о качестве.
>> Выполнять это императивно очень неэффективно
Императив максимально близок к железу, то есть как раз в этом случае трансляция эффективного алгоритма пройдёт наиболее эффективным способом. Поэтому неэффективность возможна лишь в следствии применения изначально кривого алгоритма.
>> Собственно и в статье есть про теоретический базис
Я тоже когда-то не знал, что такое функциональное программирование. Ну и много чего ещё не знал. Поэтому, немного познакомившись и с функциональным и с логическим, и тем более, с процедурным подходом, очень рекомендую вам заняться самообразованием. Ну и после завершения вам станет ясно, почему в статье нет теоретического базиса.
Есть три подхода — императив, функциональный и логический. Про императив вы знаете, а вот про два оставшихся — надо выучить. Почитайте про Хаскель, сделайте на нём что-то не самое простое, можно без IO, монад и уж тем более — без теории категорий (которая там, кстати, крайне слабо присутствует, если не выискивать связь странных названий с математикой). Так же почитайте про Пролог, без углубления в новомодные расширения. Было бы неплохо далее немного глянуть в сторону математики, но опять без фанатизма — общее представление об опробованных вами в Хаскеле и Прогологе концепциях, это даст некоторое обобщение над вашим опытом. Ну и потом уже можно будет попытаться взглянуть на свой собственный язык.
Да, кстати, декларативный стиль — это именно стиль. Декларативно можно писать в том числе на процедурном языке. Хотя да, поддержка на уровне синтаксиса будет не лишней. А вот подход к программированию бывает либо императивный, либо функциональный, либо логический.
Кроме того — в вашей вселенной нет выхода. Это бьёт по голове каждому читателю. А ведь они так хотят видеть выход! Сладкий, мягкий, удобный, подъехавший прямо к их креслу. Но выхода-то статья и не предлагает! Тем более, подъехавшего к дивану.
Но на самом деле вы всё написали достаточно правильно, кроме отсутствующего указания на выход, разумеется. По мелочи придраться можно, но сути это не меняет — люди рабы системы и это данность, система не для них и вариантов нет, кроме… А что кроме? А там тот самый выход.
По простому — зачем в алгоритме 3 шага? Почему недостаточно одного xor-а? Что даёт последующее нелинейное преобразование? Что даёт наложение линейного преобразования?
Возможно, проблема в размере ключа, а всё остальное каким-то образом повышает сложность вскрытия ключа небольшой длины. Но почему бы об этом не написать?
В прологе есть механизм унификации, то есть по другому — сопоставление шаблонов. Например — есть сущность — человек(зовут(«Вася»), живёт(«под мостом»)), а мы хотим найти экземпляр данной сущности, про который известно, что его(её) зовут Нина, тогда пишем — человек(зовут(«Нина»), пофигГдеЖивёт) — и получаем ответ — нет в БД таких сущностей. Здесь дерево вида человек(поддеревья) сопоставляется с имеющимися шаблонами и первое поддерево (которое про Нину) отсекает все имеющиеся в базе варианты. А вот если бы мы спросили так — человек(пофигКакЗовут, пофигГдеЖивёт), то мы обязательно нашли бы Васю. Это аналог SQL — select * from person. Но механизм унификации (шаблонов) позволяет сопоставлять целые деревья, а не одну гладкую строку. Это в SQL тоже достижимо, но для этого нужно строить декартово произведение всех ветвлений дерева, что может быть неэффективно при плохо спроектированной схеме данных, ну а для пролога это не всегда существенно, поскольку обход дерева можно сократить перенеся в начало обход наиболее мощного варианта (в БД же это не всегда правильно пытается делать оптимизатор, хотя и пролог тоже оптимизируют).
Не совсем так. Природа-то полная, но что бы ей соответствовать, нужны бесконечные вычислительные ресурсы либо очень умный оптимизатор (на уровне человека). Только в вашем языке внутри вряд ли ИИ сидит, а потому и он грешен не меньше пролога.
>> на нем невозможно построить прикладных программ.
Построено много таких программ, но они нишевые. Например — управление посадкой Бурана (аналог Шаттла) частично написано на прологе, но очевидно, что сама задача далеко не массовая, а потому многим кажется, что пролог вообще никто и никак не использует. В плане же бизнес-логики in-memory database, которую как раз удобно писать на прологе, вполне применима для разного рода свойств и поиска по ним с некоторым логическим выводом. Но сложность бизнес-приложений обычно невысокая, а потому такие задачи быстрее решить на том, что знаешь, а не изучать пролог и способы его прикручивания в проект. Хотя вот GUI или тот же построитель запросов (близко к OLAP) уже предполагают как раз прологовский подход, что и я бывало использовал.
>> Давайте все-таки примеры парадигм с реально работающими реализациями и практическим применением
Вообще это интеллектуальные задачи, которые не могут быть массовыми. Пролог, дополненный работой с ограничениями, примерно в таких областях и используется. Хотя в этой части сильна конкуренция со стороны функциональных языков. Каких-то выстреливших массовых технологий не вспоминается, но массовость же достигается именно благодаря простоте задач, иначе сложно найти необходимое количество разработчиков. Так что и пролог и функциональное программирование в массах не особо распространены. Хотя функциональный подход постепенно внедряется в императивные языки и уже довольно популярен. Может и ваш инструмент поможет введению декларативной логической части в массовые языки.
>> Другим часто подвергаемым критике свойством языка является отсутствие типизации
Типизация там тоже есть, но не в стандартном виде проверки аргументов на этапе компиляции. В принципе IDE могли бы ещё до компиляции проверять наличие подходящих правил и как-то выделять в программе места, которые не унифицируются ни с одним правилом. Это примерно как проблема JavaScript — там тоже есть типы, но они скрыты внутри движка, да ещё на это накладываются неявные преобразования, позволяющие иногда передавать в функции неподходящие типы или получать undefined для, например, математических операций с объектами (то есть результат «ошибка» заменяется менее явным результатом). Но если в JavaScript это всё сделано в угоду упрощенчеству, то в прологе это сама суть языка — он проверяет, подходит ли аргумент под имеющиеся факты/правила или нет, и если не подходит — это законная возможность, не являющаяся ошибкой. В SQL аналог такой — в части WHERE задаётся шаблон, которому должны соответствовать данные в БД, соответственно, данные могут быть найдены или могут быть не найдены и оба результата — правильные, это не ошибка. То есть «отсутствие типизации» в прологе такое же, как и в SQL.
Этот способ разработчики пролога показали лет 50 назад.
>> можете показать СУБД, которая построена по подобному принципу?
Ну написано же — пролог. И вам выше даже пример решения на нём приводили. Он тоже получился очень коротким.
Вот как это выглядит в Eclipse — я нажимаю ctrl+shift+o и мне предлагается список одинаковых названий классов из разных пакетов. Я выбираю — и всё, ничего искать не надо, тем более что-то писать. А если имя класса уникально — даже выбирать не надо.
В целом по модульности понятно — как у всех. То есть просто куча файлов, с которым (уж как умеет) разбирается IDE.
>> Вообще ООП, а точнее полиморфизм / наследование плюс событийное программирование очень сильно недооценивают в разработке бизнес-приложений
Это просто структурирование задачи. И естественно, этим многие и активно занимаются. Другое дело, что в мире гораздо больше даунов, которые… Ну в общем они могут много чего недооценить.
>> очень часто переделывают то что есть, потому что клиенты постоянно экспериментируют
Мне вспоминается обычное недовольство типа «вот здесь нет поля ХХХ» или «вот это система должна сама!». И выливается это всё в довольно простые действия по добавлению поля или выполнению простого расчёта с выводом результата. Большего от учётных систем редко требуют. Поэтому здесь скорее речь об организации процессов в разработке, в смысле производительность у вас, конечно, как у всех, и не зависит от инструмента (или слабо зависит), а доработки требуют 10 человек именно из-за неидеальности процессов. Хотя соглашусь — в больших конторах процессы ещё более страшные и там легко могут и 100 человек на ваши задачи посадить.
Масштаб понятен. А теперь ещё интереснее — как вы во всей этой тысяче ещё не запутались?
>> Поддерживает и дорабатывает около 10 человек
Вообще получается 10 человеко-месяцев каждый месяц убивается на обслуживание изменений. За 10 человеко-месяцев упоминавшуюся систему на 25к строк можно написать (ну почти, то есть без тестирования и прочего отягощающего, плюс эффективно разработку организовать). В итоге получаем, что месяца за два-три-ну-пусть-четыре доработки становятся равны по сложности разработке с нуля. И теперь вопрос — а где выигрыш? Новый язык и многия обещания предполагают огромное сокращение затрат, ведь так? Но тем не менее по трудозатратам систему переписывают полностью раз в несколько месяцев, при чём не реализуют все процессы заказчика с нуля, а лишь слегка подправляют. И вот это «слегка подправляют» равно переписыванию с нуля по затратам. Так в чём выигрыш? Где гигантские сокращения времени разработки, количества ошибок, жалоб пользователей и т.д.?
Ну не надо так страшно пугать. Если встретились с незнакомым алгоритмом джойна — читаем доку и через пол-часика оптимизируем без проблем. Главное — общее понимание процесса.
>> Я сравнивал, когда пытался людям из не IT…
Ну вам всегда нужны уточнения типа «берём выборку из всё-таки хоть как-то причастных людей»?
>> Домашняя команда — атрибут матча
Скорее атрибут места проведения матча. Закрыли стадион — и «атрибут матча» придётся поменять.
По модульности что-нибудь скажете? Как много зависимостей между модулями? Сколько лет приходится тратить на поддержку изменений в бизнес-процессах заказчика? Сколько человек поддерживают те 25к строк кода, которые работают на каком-то предприятии?
Скорее это проблема преподавателя. Точнее — автора той книги, по которой вы пытались учить Хаскель.
Основа там тривиальная. Ну а всякие палочки и прочие значки — вы к ним просто не привыкли, а как привыкнете — они станут очень даже к месту, будут выглядеть логично, выполняя именно ту функция, на которую похожи.
Доказать сможете? Если доказательством опять будет ссылка на реализованный проект на вашем языке, то подскажу — вы встроили в платформу те встретившиеся алгоритмы, которые как раз и выходят за пределы базового набора примитивных действий, обычно идентифицируемого аббревиатурой CRUD. То есть «подшаманили» ради нужных расширений, а теперь некорректно заявляете об охвате 98% алгоритмов. В следующий раз (у следующего заказчика) вам придётся снова подшаманить, потом ещё и ещё. И окажется, то 98% — было явной натяжкой.
>> это скорее комбинаторное, реактивное, логическое и событийное программирование
А теперь было бы неплохо расшифровать приведённые термины. Мною использованы стандартные термины, вы же придумали свои, поэтому расшифровка необходима.
Хотя да, такой подход «сверху», пусть даже через доморощенные термины, я поддерживаю.
>> Декларативный стиль — это метрика того насколько язык высокоуровневый
Процедура «всё прекрасно» может быть написана почти на любом языке. Обратите внимание на силу декларативной метрики в данном примере.
Ну почему же? Вы как раз наглядно показали корни вашей системы. Всё началось с активной работы с БД, далее вам захотелось «расширить и углубить (с)», ну и вы начали сочинять навороты вокруг стандартной реляционной модели, использующей под капотом довольно сложные алгоритмы для выполнения запросов и эффективного хранения данных на диске. В итоге получилась надстройка над SQL, которая в SQL же и конвертируется (как я понял). Отсюда все эти абстрактные заявления про «множество объектов» по которым что-то «пробегает». На самом же деле речь идёт о банальном выполнении селектов по таблицам, возможно in memory tables, но суть-то не меняется.
Вот начали бы вы описание языка именно с такой подачи — это простая настройка над БД, транслирующая наш псевдо-код в SQL выражения и работающая с данными из БД неявным образом. Далее же надо показать — зачем вы прячете от разработчика всё то, что получается в результате трансляции в селекты. Этим вы убиваете понимание происходящего, но что вы при этом добавляете? Мне это совершенно непонятно. Минус (огромный) вижу. Плюсы — сомнительны.
В куче языков именно так можно работать с простыми классами или структурами. Просто кидаем их в список и получаем то, что вы называете «компонентный подход». Но это всего лишь один из способов использования классов/структур.
Повторюсь — в абстрактной системе, где непонятна роль платформы и целый алгоритм можно выразить используя длинные строки, просто нет критериев для оценки.
Трансляция в SQL, конечно, местами сокращает код, но это работает лишь до момента, когда потребуются усложнения в алгоритмах. Поэтому вторая часть «25к строк» — предметная область и её сложность. Они опять не заданы. Хотя есть намёк на тип «учётная система», для которой (особенно ради выигрыша в неких абстрактных соревнованиях, а не для реального предприятия) можно наваять ТЗ, предполагающее лишь примитивные селекты да апдейты, что наверняка хорошо ложится в ваш язык. Но если, внезапно, заказчику нужна сложная логика?
>> Фактически мы строили самолет в воздухе вместе с пассажирами
Это не самый удачный подход. Надо хотя бы иногда сажать самолёт и тщательно рассматривать все его составляющие. Ну и улучшать, включая крупные изменения, типа замены крыла на вертолётный винт. Заказчик будет против? Ну ладно, только тогда не стоит говорить о качестве.
>> Выполнять это императивно очень неэффективно
Императив максимально близок к железу, то есть как раз в этом случае трансляция эффективного алгоритма пройдёт наиболее эффективным способом. Поэтому неэффективность возможна лишь в следствии применения изначально кривого алгоритма.
>> Собственно и в статье есть про теоретический базис
Я тоже когда-то не знал, что такое функциональное программирование. Ну и много чего ещё не знал. Поэтому, немного познакомившись и с функциональным и с логическим, и тем более, с процедурным подходом, очень рекомендую вам заняться самообразованием. Ну и после завершения вам станет ясно, почему в статье нет теоретического базиса.
Есть три подхода — императив, функциональный и логический. Про императив вы знаете, а вот про два оставшихся — надо выучить. Почитайте про Хаскель, сделайте на нём что-то не самое простое, можно без IO, монад и уж тем более — без теории категорий (которая там, кстати, крайне слабо присутствует, если не выискивать связь странных названий с математикой). Так же почитайте про Пролог, без углубления в новомодные расширения. Было бы неплохо далее немного глянуть в сторону математики, но опять без фанатизма — общее представление об опробованных вами в Хаскеле и Прогологе концепциях, это даст некоторое обобщение над вашим опытом. Ну и потом уже можно будет попытаться взглянуть на свой собственный язык.
Да, кстати, декларативный стиль — это именно стиль. Декларативно можно писать в том числе на процедурном языке. Хотя да, поддержка на уровне синтаксиса будет не лишней. А вот подход к программированию бывает либо императивный, либо функциональный, либо логический.
Не могли бы вы представить примеры?
На мой взгляд репутации сегодня нет ни у кого. Хотя здесь можно поговорить о моём максимализме :)
В плане «не одновременно» я согласен с комментарием выше — только до появления некоторого важного расширения, для которого вполне есть место.