Схожесть в подходе: берем реляционный движок и прикручивем к нему сверху новый слой абстракций, позволяющий разрабатывать в удобной авторам парадигме (ООП в нашем случае, «фукциональщина» в вашем)
Тот же эллипсоид, вид сбоку: "Реализация сервера объектного представления средствами реляционной СУБД"
20 лет назад мы обертывали РСУБД слоем реализации ООП (не путать с ORM), сегодня вы снова оборачиваете движок Кодда в функциональную абстракцию.
Вывод: выбор в пользу реляционой модели в 1970-х был обоснованным :)
Из реальной жизни:
Рекрутер (технарь): «Вам знаком термин „длинный метод“? Что это такое?»
Я: «Да, знаком, этот метод не помещается на мой экран целиком, приходится прокручивать»
…
Р: «Наш метод близок к экстремальному программированию»
Я: «Это плохие новости, я не отношу себя к экстремистам»
В MDD упор на моделирование, но на выдающее на выходе работающий код (рутинный, прежде всего) и побочные продукты вроде документации). Сгенерированный код руками не меняется, только через модель, что обеспечивает постоянную актуальность. Более тонкую доработку каркаса можно программиривать руками в расширениях типа partial class или в обработчиках.
Есть также инструменты two-way, например ModelMaker: интегрирован в IDE, UML постоянно синхронизирован с кодом, менять программу можно с обоих сторон.
Архитектура приложения: микросервисная или монолитная?
Имеет ли смысл вот так сразу обнаруживать знание всего двух архитектур по их маркетинговым названиям? Все ли монолит, что не микросервисы? Может, начать издалека, посчитать звенья, например?
Действительно, сам по себе UML — просто картинки, быстро теряющие актуальность по мере разработки. Более общий подход называется model driven devemopment и software factory, причем UML необязателен в качестве входного языка.
Пример реализации: GenieLamp
Часто сталкиваюсь с подобным на практике консультанта, поэтому небольшой перевод.
"продукт работает в сложных рыночных условиях" — зачем изучать рынок и потребности клиентов, давайте просто начнем, авось да небось получится
"все понимают, что четкое ТЗ на продукт не сформировать" — и нечеткое тоже, потому что это требует ответственности и компетентности
"очень важно, чтобы бизнес был вовлечен" — только тогда бизнес будет оплачивать карусель из спринтов
Добавлю, что аджайл неплохо работает для сопровождения уже существующего продукта, когда имеется стабильный входящий поток багов и небольших изменений.
Интеллект — это способность к абстрактному мышлению. В принципе, и покер-систему можно научить читать лица игроков, но суть не изменится. Нужны, как минимум 2 качества:
— осознать, что есть такая сущность и такой процесс — «игра», что в покере, что в шахматах, что в домино
— на основе этого осознания уметь самостоятельно обучаться другим играм, используя прежний опыт
По-моему, у нынешней (третьей?) волны строителей ИИ нет понимания этих пунктов.
Что может быть лучше фуллстека на небольших (порядка 10-100К строк) проектах? Да и дальше специализация происходит плавно, а не скачком.
Длинный список технологий тоже необязателен, например C++ или C# и SQL — это уже минимальный стек, достаточный для построения многозвенных систем.
В книге С.Свердлова «Языки программирования и методы трансляции» (2007) транслятор учебного языка реализован на нескольких языках: Паскале, Си, Обероне, Яве и Сишарпе. Это не только иллюстрирует принципы кросс-трансляции, но и позволяет получить множество сравнительных характеристик. На стр.400 эти характеристики сведены в таблицу. Рецензия на книгу по ссылке.
ML — молоток полезный, поэтому есть опасность уверовать, что все задачи вокруг суть гвозди :)
Основное отличие классического программирования в детерминированности: отлаженная программа дает 100% результат на исходных тестах. В ML всегда будет присутствовать вероятность ошибки (10% в вашем примере).
Если не брать вероятностных по своей сути задачи, то выбор идет между ценой ошибки и сложностью программирования.
Притягательность нейросетей в ощущении «магии», хотя бы и зная, что внутри нее неонка все та же неявно сформированная очень сложная статистическая функция(и), пробразующая входы в выходы.
Подправлять правила несложно, есть же параметризация программ. Вопрос в их количестве. И поскольку я тоже, правда очень давно, решал аналогичую задачу (обрезанный по правому краю текст -> HTML), то не могу назвать несколько десятков правил (при практическом отсутствии вероятностых) стимулом перехода к стат.методам (или к деревьям, раз уж упомянули).
В задаче определения кодировки вероятности следования одних букв и знаков за другими зависимы от группы языков, описывать это правилами, а не матрицей просто неудобно. Ну а лобовой метод «чтения со словарем» хоть и обходится фактически без обучения, требует наличия этих самых словарей.
К чему я все это написал? Мне кажется, что задачка детектирования кодировки или даже языка выглядела бы гораздо нагляднее для демонстрации пользы от применения ML.
Т.е. если предложение тянется до правой границы, то переноса абзаца не будет? Есть ли в таком случае смысл переходить от логики к статистике?
Вот в другой встречающейся задаче по определению кодировки текста без статистики тяжело.
Речь не про технический долг, а про функциональный (надеюсь, вы не будете отрицать, что техническая и функциональная архитектуры суть разные вещи). Чтобы распутать кашу функциональных зависимостей нужно заняться проектированием этой самой архитектуры. «Чистый» код в общем случае инвариантен «грязной» прикладной логике. Более того, «чистая» функциональность сэкономит вам тонны часов на технический рефакторинг.
При восходящей разработке (аджайлы — это bottom-up), функции добавляются инкрементально. После десятков итераций получается каша из взаимозависимостей, по-хорошему требующая работы предметных аналитиков по реструктуризации. Хотя, конечно, всегда есть опция «оставить как есть и жить с этим».
Т.е. по сути у вас 10-звенная система. Неужели нигде «не жмёт туфля» в плане производительности?
Обычные сервисы реализуют не строго одну «автономную» функцию (см.выше про кашу), а несколько тесно связанных (интегрированных), тем самым избавляя их от необходимости медленно взаимодействовать по сети.
Как решается вопрос функциональных зависимостей?
Сколько слоев из (микро)сервисов получется на данный момент?
Какова стоимость развертывания и управления зависимостями по сравнению с обычными сервисами?
Во «Многоруком боге далайна» финал, когда весь далайн трансформирован, похож на описанное превращение аналитика в overqualified «шамана». Перейдет ли он в итоге на «темную» сторону заказчика?
АЛМО все же не язык высокого уровня, а ассемблер для абстрактной машины. У американцев аналогичный проект Unicol в 1960-х не пошел, зато сейчас все это работает под брендом .NET в виде языка IL.
20 лет назад мы обертывали РСУБД слоем реализации ООП (не путать с ORM), сегодня вы снова оборачиваете движок Кодда в функциональную абстракцию.
Вывод: выбор в пользу реляционой модели в 1970-х был обоснованным :)
Рекрутер (технарь): «Вам знаком термин „длинный метод“? Что это такое?»
Я: «Да, знаком, этот метод не помещается на мой экран целиком, приходится прокручивать»
…
Р: «Наш метод близок к экстремальному программированию»
Я: «Это плохие новости, я не отношу себя к экстремистам»
Распрощались, конечно.
Есть также инструменты two-way, например ModelMaker: интегрирован в IDE, UML постоянно синхронизирован с кодом, менять программу можно с обоих сторон.
Имеет ли смысл вот так сразу обнаруживать знание всего двух архитектур по их маркетинговым названиям? Все ли монолит, что не микросервисы? Может, начать издалека, посчитать звенья, например?
Пример реализации: GenieLamp
"продукт работает в сложных рыночных условиях" — зачем изучать рынок и потребности клиентов, давайте просто начнем, авось да небось получится
"все понимают, что четкое ТЗ на продукт не сформировать" — и нечеткое тоже, потому что это требует ответственности и компетентности
"очень важно, чтобы бизнес был вовлечен" — только тогда бизнес будет оплачивать карусель из спринтов
Добавлю, что аджайл неплохо работает для сопровождения уже существующего продукта, когда имеется стабильный входящий поток багов и небольших изменений.
— осознать, что есть такая сущность и такой процесс — «игра», что в покере, что в шахматах, что в домино
— на основе этого осознания уметь самостоятельно обучаться другим играм, используя прежний опыт
По-моему, у нынешней (третьей?) волны строителей ИИ нет понимания этих пунктов.
Длинный список технологий тоже необязателен, например C++ или C# и SQL — это уже минимальный стек, достаточный для построения многозвенных систем.
Рецензия на книгу по ссылке.
Основное отличие классического программирования в детерминированности: отлаженная программа дает 100% результат на исходных тестах. В ML всегда будет присутствовать вероятность ошибки (10% в вашем примере).
Если не брать вероятностных по своей сути задачи, то выбор идет между ценой ошибки и сложностью программирования.
Притягательность нейросетей в ощущении «магии», хотя бы и зная, что внутри нее
неонкавсе та же неявно сформированная очень сложная статистическая функция(и), пробразующая входы в выходы.В задаче определения кодировки вероятности следования одних букв и знаков за другими зависимы от группы языков, описывать это правилами, а не матрицей просто неудобно. Ну а лобовой метод «чтения со словарем» хоть и обходится фактически без обучения, требует наличия этих самых словарей.
К чему я все это написал? Мне кажется, что задачка детектирования кодировки или даже языка выглядела бы гораздо нагляднее для демонстрации пользы от применения ML.
Вот в другой встречающейся задаче по определению кодировки текста без статистики тяжело.
На основании чего здесь делается вывод о конце абзаца (между предложениями)?
Т.е. по сути у вас 10-звенная система. Неужели нигде «не жмёт туфля» в плане производительности?
Обычные сервисы реализуют не строго одну «автономную» функцию (см.выше про кашу), а несколько тесно связанных (интегрированных), тем самым избавляя их от необходимости медленно взаимодействовать по сети.
Сколько слоев из (микро)сервисов получется на данный момент?
Какова стоимость развертывания и управления зависимостями по сравнению с обычными сервисами?