K
Size: a a a
2020 August 15
АГ
Вообще, многое в Хаскеле исторически делалось не чтобы научить, а чтобы впечатлить. В последние годы, к счастью, стали массово появляться и простые рабоче-крестьянские материалы, а вот лет за пять до того были статьи и пейперы в стиле "Смотри, какую крутую штуку я изучил! Щаз я тебе покажу, насколько я умный!"
AP
Все пошутили и я пошутил!
А если серьезно, у меня было два примера, какой из них лучше рассмотреть?
Давайте я возьму работу Build Systems à la Carte А. Мохова и др.
Первая ее часть очень хороша. Это осмысление принципов работы систем автоматизации сборки, попытка выделить в них наиболее существенные элементы.
Здесь еще нет никакого Haskell. Однако, давайте вспомним недавно прозвучавшую в чате фразу "они как от огня бегут ото всего мейнстримного". И действительно, в теоретической части наблюдаются странности в выборе систем автоматизации сборки для анализа: из популярных систем упоминается лишь make и ни о каких Gradle и проч. даже слова не говорится, как будто их не существует. Зато авторы много пишут об Excel.
Далее авторы приводят на Haskell модели систем сборки и описывают детали их реализации. Предполагается, судя по всему, что реализация на Haskell это своеобразная "математическая модель", анализ которой поможет многое узнать о прообразе. Но авторы лишь пробуют разные комбинации того, что было выявлено в теоретической части, и выводом статьи оказывается "a simple recombination leads to a design for a monadic suspending cloud build system".
А если серьезно, у меня было два примера, какой из них лучше рассмотреть?
Давайте я возьму работу Build Systems à la Carte А. Мохова и др.
Первая ее часть очень хороша. Это осмысление принципов работы систем автоматизации сборки, попытка выделить в них наиболее существенные элементы.
Здесь еще нет никакого Haskell. Однако, давайте вспомним недавно прозвучавшую в чате фразу "они как от огня бегут ото всего мейнстримного". И действительно, в теоретической части наблюдаются странности в выборе систем автоматизации сборки для анализа: из популярных систем упоминается лишь make и ни о каких Gradle и проч. даже слова не говорится, как будто их не существует. Зато авторы много пишут об Excel.
Далее авторы приводят на Haskell модели систем сборки и описывают детали их реализации. Предполагается, судя по всему, что реализация на Haskell это своеобразная "математическая модель", анализ которой поможет многое узнать о прообразе. Но авторы лишь пробуют разные комбинации того, что было выявлено в теоретической части, и выводом статьи оказывается "a simple recombination leads to a design for a monadic suspending cloud build system".
Доклад на хаскелистов ориантирован, вот моноиды и использовали в качестве концепций
PS
Если гит не занимается и не решает проблемы, которые они подымут, то да, на него ссылаться не за чем
Возможно. Но я, как разработчик, из прочтения статьи не получаю понимания, какое место в картине мира авторов статьи занимают реально применяемые системы. Собственно, как и Вы спрашиваете, мол, "если в gradle уже действительно придумали...". А как об этом узнать, если в статье нет ничего на эту тему? :)
AP
Просто как общий вокабулярий
АГ
Доклад на хаскелистов ориантирован, вот моноиды и использовали в качестве концепций
Это ничуть не более продвинуто, чем, например, использование паттерна Builder из GoF. Просто еще одна форма построения языка. Мне не очень понятно, почему люди так носятся с этим, будто это просветление
K
Возможно. Но я, как разработчик, из прочтения статьи не получаю понимания, какое место в картине мира авторов статьи занимают реально применяемые системы. Собственно, как и Вы спрашиваете, мол, "если в gradle уже действительно придумали...". А как об этом узнать, если в статье нет ничего на эту тему? :)
Это значит, что Introduction & Evaluation написаны недостаточно хорошо для вас
АГ
У нас, вообще говоря, нарастает кризис науки, заключающийся в подмене науки наукообразностью. Если принять эту реальность, то в любом мало-мальски сложном программном проекте есть куча вещей, которые можно было бы наукообразно описать и получить свои PhD. В этом смысле академики зря надувают щеки, инженеры ничуть не хуже, просто у них нет задачи впечатлить коллег и нацеплять лычек (точнее, есть, но это другие лычки)
AP
Всем весело!
AP
Возможно. Но я, как разработчик, из прочтения статьи не получаю понимания, какое место в картине мира авторов статьи занимают реально применяемые системы. Собственно, как и Вы спрашиваете, мол, "если в gradle уже действительно придумали...". А как об этом узнать, если в статье нет ничего на эту тему? :)
Статья не о том, какие есть реальные системы сборки. Статья о том, на основе каких принципов можно оные строить и какие можно получить свойства, если выбрать ту или иную модель.
Реальные системы — наборы костылей, от которых подозрительно пахнет не только клеем.
Реальные системы — наборы костылей, от которых подозрительно пахнет не только клеем.
AP
Сравнительных статеек вроде "Базель против Никса" достаточно. Все сравнивают фичи, а не основу
AP
В кои то веки кто-то пофантазировал на тему, но нет, нужно более скучно, чтобы с примерами и практичненько
AP
"Ох уж эти теоретики! Обмазались моноидами и рассуждают о том, в чём не разбираются! Где примеры, где Гредл?"
AP
Да вот за моноидами и идут в хаскель! Потому что надоели гредлы с вебпаками!
AP
Тут хоть какая-то, пусть призрачная, уверенность есть в том, что некто подумал о логичности архитектуры, а не просто фигачил очередной NIH с кештированием и воспроизводимостью.
YS
Так, кому тут скучно? А не хотите попереписывать фронт с тс на котлин?
А шо, на нем и фронт пишут?
AP
Пишут и давно
AP
(отщепенцы)