Все-таки вариант с веб- компонентом кажется самым дешевым. Если лень в каждом обработчике обновлять состояние, можно использовать наследование. И вся эта императивщина инкапсулирована внутри компонента, там не может быть много обработчиков, так что и проблемы нет.
Вариант elm / flutter это теоретически интересно, но практически похоже дорого в реализации, по сути нужен толстый рантайм, интенсивная сборка мусора, и проч.
Так CTE оно для рекурсии придумано, произвольно обновить часть записей именованного курсора вы все равно не сможете. У меня давно еще была задача расчета плановой себестоимости по дереву BOM с учетом потерь и отходов на чистом SQL. Никакие синтаксические изыски этого тьюринг-полного языка не позволили избежать временных таблиц. Возможно лично я и ошибаюсь, но не от хорошей жизни процедурные расширения добвили во все СУБД.
Точно. Но в этом случае мы приходим к классической технологии, по которой тесты пишут не сами разработчики, а специально обученные люди в тесном взаимодействии с аналитиками / заказчиками. У меня очень успешный опыт именно такого разделения — разработчик думает о будущих фичах, тестировщик о качестве существующих фич, и оба получают з/п. Ну и старое правило — одна голова хорошо, а две лучше.
Если проверка делается в компайл-тайме, то тесты ненужны, а если в рантайме — привет TDD. Компилятор + статический анализатор (в некоторых языках это два в одном) — это бесплатный и очень быстрый инструмент поиска ошибок (в том числе и логических), и грех таким дешевым инструментом не воспользоваться. Тесты — это дорогой инструмент, требующий соизмеримых с разработкой трудозатрат, поэтому я выбираю компилятор. Возможно, кто-то выберет динамизм + тесты, не знаю.
Я согласен, но в вашем случае проверка, чтобы на покраску попадали только грунтованные кузова — делается в рантайме, а в моем случае — на стадии компиляции.
Cогласен, как раз сейчас пишу сложный прототип, и раз в неделю вынужден серьезно переделывать внутреннее API. Поэтому тесты — только интеграционные, в пограничных точках, иначе разработка вместо месяца займет год. А вот когда приходилось вносить точечные изменения в чужой коммерческий продукт — здесь да, и подробное ТЗ, и автотесты, и т.д.
типами можно заменить самые примитивные тесты — тесты функций никаких других функций не вызывающих и на одних и тех же данных возвращающих одно и то же значение.
Смотря как вы применяете типизацию. Если у вас например цикл производства какого-то агрегата, и операции объединены в цепочку / граф — нужно из каждой операции возвращать свой тип, например «кузов», «кузов грунтованый», «кузов покрашеный», а не просто «полуфабрикат». С такой системой типов можно частично отследить и ошибки композиции функций / операций.
или какие синхронизированные методы используются только из одного потока, что-бы «выключить» синхронизацию.
Пожалуй, раст такое сможет в компайлтайме. Интересна не битва «GC против не-GC», а JIT против AOT. Собственно, зачем этот высокоуровневый байт-код, который нужно джитить, если есть низкоуровневый байт-код (WASM) или вообще натив? Мне кажется что идея виртуальных машин устаревает, и Java и .Net скоро сольют тому же WASI, потому что в нем нет предустановленного GC, система команд, как я понял, довольно близка нативу, а значит компиляторы могут малыми усилиями добавить себе еще один target.
PS
Например, TypeScript, компилируемый в WASM, красота жеж, жаль что нету.
На самом деле меня во многом Java не устраивает, но это не относится к vm, gc, производительности и возможностям отладки.
Вообще интересно, когда я делаю бенчи на коленке — C# core оказывается быстрее чем Java, смотришь techempower — а в нем C# вообще довольно низко, и это странно.
PS
Я так понимаю, оба формата байт-кода не позволяют проводить глубокую оптимизацию, может поэтому и пилят альтернативу в виде WASI, где в компайл-тайм возможны чудеса.
Ну не знаю. Бывает, что сама задача хорошо ложится на ФП, но чаще нужно специальным образом писать чтобы «переиспользовать ссылки на объекты не боясь что их кто-то изменит». В реальной жизни все хуже, я вот недавно делал бенчмарк, на котором Scala умерла, а комментаторы указали, что я выбрал неправильный алгоритм. То есть ФП работает только на правильных алгоритмах :) Я сколько не пробовал — суровая императивщина с указателями на кучу и циклами получалась быстрее всяких итераторов. А вот применительно к БД — подход уже интереснее, потому что в БД накладные расходы на изменение старой записи соизмеримы с накладными расходами на добавление новой. Другими словами, функциональщина в БД обходится дешевле чем в ОС.
Остаток как сущность — для меня самого это странно, но в любое странное место нужно хоть раз сходить. У меня предчуствие, что это даст упрощение алгоритмов MRP, ведь и резерв и непокрытую потребность можно представить как разные типы остатков, сейчас как раз пытаюсь что-то подобное смоделировать.
Функциональная функция (простите за тафталогизм) всегда возврщает новые данные, поэтому ФП так критикуем и непопулярен, ведь аллокации памяти это дорого. А если фунция ничего не возвращает, и не меняет старых данных, то это не функция вообще, а черная дыра :)
По сути вы просто создаете транзакционный лог. Я бы на вашем месте это скорее блокчейн СУБД, а не функциональной СУБД называл бы. Ведь именно блокчейн это про аудируемость и т.п.
Именно! Вы совершенно верно схватили суть! На такую схему навернуть блокчейн — пять минут программирования, просто вычислить хэш и положить в дерево Меркла. А вот если у нас есть мутабельный регистр «Остатки», то как его надежно защитить от подделок и ошибок? Никак.
1) Теоретически можно менять и в закрытом, но это перезапись большого куска базы, долго и блокирующе. Издержи подхода.
2) Только практика ответит на этот вопрос, нужен пилотный проект и пилотный заказчик :) В свою защиту могу сказать, что 1С намного легче сломать или хакнуть, чем предлагаемую. В моей системе достаточно удалить все промежуточные данные (кэш), и истина будет восстановлена из первичных документов. Большие аудиторы, кстати, так и делают, и налоговая тоже.
3) Если аналгогичный запрос движений по гравицапе уже был — запись будет в кэше, и ее достаточно актуализировать на новых документах. Если нас интересует нестандартная свертка (какой еще не запрашивали), но без сальдо и по конкретному периоду (например обороты за прошлый год) — индексировать плоский файл по timestamp — плевое дело. Если фильтр не по времени — тогда извините, фуллскан.
PS
В целом я не против ни СУБД ни индексов, для прототипа выбрал файл только пожалев свое время, но все же хочется минимизировать мутабельность, то есть неконтролируемая правка любых записей в любой момент. В западных ERP к этому прикладывают специальные усилия, но их недостаточно.
NitroJunkie, по поводу вычисления остатков — отвечу развернуто. В ERP нам нужен граф сопоставлений — и для себестоимости, и для планирования. Есть 2 способа организации сопоставлений:
1) проводка-проводка
2) проводка-остаток
Если мы выбираем первый случай, тогда мы можем расчет остатка оформить вычисляемой кэшируемой сверткой, в чисто-функциональном ключе. Я сознательно выбрал второй вариант «проводка — остаток», таким образом остаток нам нужен в системе как самостоятельная сущность, с уникальным ID. Какая может быть функциональщина при организации связей между сущностями?
Любая функция (даже чистая) возвращает какие-то данные, в моем случае — новый документ типа «баланс», тогда как императивный подход подразумевает изменение старой записи регистра «баланс». Чувствуете разницу? Таким образом моя система намного ближе к принципам ФП, чем упомянутая 1С. Про вашу систему пока ничего определенного сказать не могу, решение с материализацией на лету — довольно сильное, но подходы к хранению данных принципиально другие, значит и никакого спора быть не может.
ФП на уровне документов и бизнес-агрегатов, а в реализации конечно императивка. Если вы пишете например на Scala, у вас функция внешне чистая, но внутри нее вполне допустимы и мутабельные переменные, и циклы, мы же не параноики. В целом согласен, и заголовок и некоторые тезисы статьи немного провокационны, но не более чем у других :)
В иммутабельной части невозможно, а в мутабельной — при вставке задним числом — блокируется база, и последовательность документов пересоздается в памяти (удаляются старые баланcы начиная с точки изменения, новые пересоздаются по цепочке). Это если реальная правка задним числом (сторно). Если накладные расходы пришли в середине месяца — они просто дооценят текущие балансы, а старые останутся неизменными. То есть блокировка базы нужна будет далеко не всегда. На моем ноуте обработка миллиона документов в памяти — 0.6 секунды, на сервере время блокировки будет сотые. Конечно, если в вашей ERP открытый период — год, то моя схема вряд-ли подойдет :)
Все императивно в триггере. Генерация нового баланса — Приход, Расход, Перемещение. Конечно, в проде нужно писать удобное API, но в прототипе, для целей демонстрации — самое то.
Так и есть, потому что у меня балансы создаются каждый раз заново, и материализовывать просто нечего. Это не бага, а фича — история остатков / резервов / потребностей (это все разновидности балансов), прибитая гвоздями иммутабельности, весьма полезна в планировании покрытий и разруливании конфликтов.
Мой проект на Deno, и тоже ничего )
Все-таки вариант с веб- компонентом кажется самым дешевым. Если лень в каждом обработчике обновлять состояние, можно использовать наследование. И вся эта императивщина инкапсулирована внутри компонента, там не может быть много обработчиков, так что и проблемы нет.
Вариант elm / flutter это теоретически интересно, но практически похоже дорого в реализации, по сути нужен толстый рантайм, интенсивная сборка мусора, и проч.
PS
Как правильно расшифровывается аббревиатура TDD :)
PS
Например, TypeScript, компилируемый в WASM, красота жеж, жаль что нету.
PS
Я так понимаю, оба формата байт-кода не позволяют проводить глубокую оптимизацию, может поэтому и пилят альтернативу в виде WASI, где в компайл-тайм возможны чудеса.
Функциональная функция (простите за тафталогизм) всегда возврщает новые данные, поэтому ФП так критикуем и непопулярен, ведь аллокации памяти это дорого. А если фунция ничего не возвращает, и не меняет старых данных, то это не функция вообще, а черная дыра :)
Именно! Вы совершенно верно схватили суть! На такую схему навернуть блокчейн — пять минут программирования, просто вычислить хэш и положить в дерево Меркла. А вот если у нас есть мутабельный регистр «Остатки», то как его надежно защитить от подделок и ошибок? Никак.
2) Только практика ответит на этот вопрос, нужен пилотный проект и пилотный заказчик :) В свою защиту могу сказать, что 1С намного легче сломать или хакнуть, чем предлагаемую. В моей системе достаточно удалить все промежуточные данные (кэш), и истина будет восстановлена из первичных документов. Большие аудиторы, кстати, так и делают, и налоговая тоже.
3) Если аналгогичный запрос движений по гравицапе уже был — запись будет в кэше, и ее достаточно актуализировать на новых документах. Если нас интересует нестандартная свертка (какой еще не запрашивали), но без сальдо и по конкретному периоду (например обороты за прошлый год) — индексировать плоский файл по timestamp — плевое дело. Если фильтр не по времени — тогда извините, фуллскан.
PS
В целом я не против ни СУБД ни индексов, для прототипа выбрал файл только пожалев свое время, но все же хочется минимизировать мутабельность, то есть неконтролируемая правка любых записей в любой момент. В западных ERP к этому прикладывают специальные усилия, но их недостаточно.
1) проводка-проводка
2) проводка-остаток
Если мы выбираем первый случай, тогда мы можем расчет остатка оформить вычисляемой кэшируемой сверткой, в чисто-функциональном ключе. Я сознательно выбрал второй вариант «проводка — остаток», таким образом остаток нам нужен в системе как самостоятельная сущность, с уникальным ID. Какая может быть функциональщина при организации связей между сущностями?
Любая функция (даже чистая) возвращает какие-то данные, в моем случае — новый документ типа «баланс», тогда как императивный подход подразумевает изменение старой записи регистра «баланс». Чувствуете разницу? Таким образом моя система намного ближе к принципам ФП, чем упомянутая 1С. Про вашу систему пока ничего определенного сказать не могу, решение с материализацией на лету — довольно сильное, но подходы к хранению данных принципиально другие, значит и никакого спора быть не может.