Как это реализовано на нижнем уровне это — детали реализации, могут меняться от версии к версии компилятора, быть разным для разных монад и вообще ничего не объяснят в принципе.
Ну казалось бы, почему бы по ссылке не вести на страницу с формой (с одной кнопкой),
там показывать (ну или не показывать) капчу на первый заход, затем сажать куку и выдавать данные только по POST-запросу
Заказная разработка, демон для управления специфическим железом + месседжинг по сети. Ну как успехи? Планомерно делается, сделается — сдастся. В принципе, проект будет довольно заметный, закроем проект — расскажу. Никаких проблем от хаскелла нет.
У нас сейчас проект на хаскелле, который разрабатывают двое. Никакой специфики по сравнию с другими языками я не вижу. Код легче ревьювить, потому что его мало и есть типы.
Код верхнего уровня понимают даже не разработчики, т.е. можно интуитивно догадаться, что он делает, т.к. фактически это DSL на предметной области
Если в рамках задачи нет различий между кругом и эллипсом (и, кстати, пока задача не сформулирована — все эти архитектурные терки впустую вообще) — то вообще не доказано, что это разные объекты. Ergo, никакой фабрики пока что не надо
Архитектура — это способ реализации задачи. Что эти круг и эллипс вообще должны делать? В чем их поведение одинаково, в чем различается?
Как только это выяснится, сразу и выяснится, кто от кого наследует.
Скорее всего (круг и эллипс — мы что, графический редактор проектируем?) это вообще одна и та-же сущность в рамках задачи. Если вы в графическом редакторе растянете круг в эллипс, что, произойдет уничтожение круга и создание эллипса? Бред ведь.
Бессмысленно рассуждать об архитектуре приложения, не сформулировав задачу и не описав предметную область.
В Си современные компиляторы умеют оптимизировать хвостовую рекурсию.
В JVM ее оптимизировать практически невозможно, следовательно и оптимизировать нечего. Так что никак не лучше.
Ну надо учитывать теоретическую вероятность такого попадоса, но она мала и легко купируется подписанием какой-нибудь бумажки или акцептованием какой-нибудь оферты на вебе. Теоретически сюда попадает вообще большая часть удалённой-полуофициальной работы, однако о подобных разборках что-то пока не слышно. Т.е что бы кого-то так поиметь, надо 1) найти подобный заход 2) нанять кого-то, что бы сделал задание, причем большое и много — если будет мало, к суду весь чужой код выкинут и доказывай потом, что там был твой код 3) если контора станет настолько толстой, что ее будет иметь смысл доить, то, вероятно, она придет к традиционным формам найма с HR и т.п. В общем, конечно можно попытаться кого-то таким образом посудить… Ну успехов, что.
там показывать (ну или не показывать) капчу на первый заход, затем сажать куку и выдавать данные только по POST-запросу
Очевидно, что вам захочется в какой-то момент иметь вложенные контексты — например, программа должна уметь делать ввод-вывод и обладать состоянием.
А матан можно оставить для любителей — для того, что бы писать на haskell, он необязателен.
Control.Monad — это штука, сделанная для нашего с вами удобства, как ее не использовать?
Это мой второй и его первый коммерческий проект на haskell
Код верхнего уровня понимают даже не разработчики, т.е. можно интуитивно догадаться, что он делает, т.к. фактически это DSL на предметной области
Как только это выяснится, сразу и выяснится, кто от кого наследует.
Скорее всего (круг и эллипс — мы что, графический редактор проектируем?) это вообще одна и та-же сущность в рамках задачи. Если вы в графическом редакторе растянете круг в эллипс, что, произойдет уничтожение круга и создание эллипса? Бред ведь.
Бессмысленно рассуждать об архитектуре приложения, не сформулировав задачу и не описав предметную область.
В JVM ее оптимизировать практически невозможно, следовательно и оптимизировать нечего. Так что никак не лучше.
Haskell — там похожий import и можно при желании отступами код группировать
Думаю, можно и в два уложиться. Это говорит о том, что надо выбирать инструменты под задачу, а не пытаться забить все гвозди мира отверткой.