AI
короче надо ДРАКОН допиливать, на самом деле
Size: a a a
2021 January 06
AB
короче надо ДРАКОН допиливать, на самом деле
Нинада
AI
чому, солидные же идеи
AI
мне кажется, надо когда-то переставать делать вид, что мы программируем на телетайпах
AB
Ок, ладно, можно - но для каких задач?
LL
скоро мы всё же выясним, что такое ооп
Надеюсь
AB
Вот те же самые бизнес-процессы - они ведь в первую очередь про обработку данных, получение и создание производных.
AI
прямо как будто программирование - это про потоки данных
V
прямо как будто программирование - это про потоки данных
ну а про что ещё?
AB
Вот те же самые бизнес-процессы - они ведь в первую очередь про обработку данных, получение и создание производных.
А это, мне кажется, уже естественнее описывается в терминах артефактов.
Опять же, если строить процесс от артефактов, у тебя нет намертво зафиксированной последовательности выполнения действий, легко получается параллелизм работ.
Опять же, если строить процесс от артефактов, у тебя нет намертво зафиксированной последовательности выполнения действий, легко получается параллелизм работ.
AB
Переход от bpmn к artifact-centric это переход от императивного к декларативному описанию, не меньше.
AI
в бпмн тулы для описания датафлоу несколько рудиментарные, соглашусь
AB
Не буду скрывать, в загнивании того проекта сыграли свою роль и джава с джавистами, и человеческий фактор, и бардак вокруг.
Но именно в плане кода fsm и проектирование от последовательности действий(vs данных) тоже внесло свою долю тягот и лишений
Но именно в плане кода fsm и проектирование от последовательности действий(vs данных) тоже внесло свою долю тягот и лишений
БЁ
Есть три концепции, данные, время и логика. В классических ооп языка это все намешено на уровне одного класса. В эрланге/эликсире разделено. Данные в иммутабельных структурах, логика в модулях, а временные концепции через акторы. Вот в этом важное отличие, отделяем мухи от котлет, получаем более понятные код. В принципе никто не мешает на той же джаве так писать, но никто так делать не будет, потому-что базовые библиотеки делают по другому, ну и люди не привыкли. А в эликсире тупо это сложно сделать, потому-что уже все заточено под раздельный подход. Но тут на помощь могут прийти макросы и "класссическое" ООП можно затащить в элексир через них.
Откуда информация, что никто так делать не будет и к чему там привыкли? Данные в датаклассы или кейсклассы лет 10 кладут
Логику в классы, которые имплементируют интерфейсы кладут
Логику в классы, которые имплементируют интерфейсы кладут
БЁ
Это очень странная манипуляция типа вон там говнокодеры, а у нас нормально и по полочкам
нихрена не так, аргумент уровня `В классических ооп языка это все намешено на уровне одного класса.`— слабый
нихрена не так, аргумент уровня `В классических ооп языка это все намешено на уровне одного класса.`— слабый
БЁ
Я напомню, что в эликсире структура декларируется в модуле(defstruct)
Структура это данные, верно? Туда даже кладётся какая-то базовая логика(кастомные конструкторы, кодеки) Верно?
Структура это данные, верно? Туда даже кладётся какая-то базовая логика(кастомные конструкторы, кодеки) Верно?
БЁ
Получается в эликсире тоже данные с логикой в одном месте лежат? И здесь тоже говно?
И я плохо понимаю, чем это лучше/хуже/отличается от скалового кейскласса, который иммутабелен и в нём хранят данные
И я плохо понимаю, чем это лучше/хуже/отличается от скалового кейскласса, который иммутабелен и в нём хранят данные
Aß
скорее наоборот, модуль объявляется структурой
БЁ
сути не меняет
V
Может быть стоит сперва разобраться в эликсире, и лишь потом делать выводы?