Веб-сервер на Haskell

ты гарантируешь что только ты будешь поддерживать?

Веб-сервер на Haskell
Испытываю дефицит времени

то есть года у тебя нет? зачем тогда Haskell ? :D

Для дела

Ты гонишь. Если бы было для дела, ты бы не спрашивал за цену хостинга, а купил VPS. Тема твоя — для понтов на лоре.

Могут ли сами подниматься?

Ясен пень, что если стоит отдельная хрень, которая следит за сервером, всегда может его перезапустить. Только, ведь, часто бывает нужно не это, а то, чтобы твой сервак не падал на каждый чих, умел обрабатывать ошибки, игнорировать их, продолжая работу. Сомнительно, что хаскель хорошо справляется с подобными вещами.

Я это всё делал на happstack. Haskell тут практически ничем не отличается от всяких дурацких языков.

Я знаком с haskell, вебом, и, в частности, с одним современным фреймворком для php, но душа резко против php. Сайт буду поддерживать сам.

на самом деле если нет нетривиальных задач нет смысла брать хаскелл, для такой задачи думаю вообще без разницы что за язык (ну если конечно не пхп-жс)

Ооочень странные вопросы. Вокруг yesod есть keter, который должен перезагружать при обновлении и т.п.. Просто при падениях или неправильной работе должны перезагружать супервизоры или мониторы (systemd, s6, supervisors, monitord).

Виджеты это css и твой layout, ну в есоде опять же встречались для pagination например, но это опять же совсем не дело.

Хостинг в смысле хостинг, его просто нету, нужно VPS или т.п. где можешь свои программы пускать, там разницы нету смотри ресурсы

Сомнительно только то, что человек может давать серьёзные оценки технологиям с которыми он не знаком.

на самом деле если нет нетривиальных задач нет смысла брать хаскелл, для такой задачи думаю вообще без разницы что за язык (ну если конечно не пхп-жс)

Это что за задачи такие, для которых подходит хаскель но не подходят другие языки? Факториал посчитать?

Вокруг yesod есть keter, который должен перезагружать при обновлении и т.п.. Просто при падениях или неправильной работе должны перезагружать супервизоры или мониторы (systemd, s6, supervisors, monitord).

Уже ближе к делу. Как понимаю, апач настраивать не надо. Он сам себя прописывает в скрипты ini. Вот, хорошо бы что-то такое и для yesod. Минимум ручного вмешательства. Неохота мне еще и самому скрипты такие писать.

Чем хорош php здесь. Он - скриптовый. Восстановится апач после перезагрузки, и ладно.

Виджеты это css и твой layout, ну в есоде опять же встречались для pagination например, но это опять же совсем не дело.

А для создания меню по навигации по сайту есть виджеты?

Хостинг в смысле хостинг, его просто нету, нужно VPS или т.п. где можешь свои программы пускать, там разницы нету смотри ресурсы

Значит, VPS. Уже понятнее.

Неохота мне еще и самому скрипты такие писать.

это очень сложный скрипт для хаскеллиста?

Это что за задачи такие, для которых подходит хаскель но не подходят другие языки?

Разумеется, для этих задач не только хаскелл подходит. Не подходят динамические языки т.к. много логики(которая меняется), разрабатывают несколько(много) человек, нужна надёжность. Динамический язык - бомба замедленного действия, точка Ж* наступает намного раньше.

-----
Точка Ж - момент, когда единственное решение — переписать с нуля т.к. ничего не понятно.

Как понимаю, апач настраивать не надо

LOL, причем тут апач?, ты ж на хаскеле собрался писать? Или уже передумал? Измени название темы на «хаскель-клоунады тред»

Динамический язык - бомба замедленного действия, точка Ж* наступает намного раньше.

Это только когда программист безмозглый.

А вообще, для сложной логики как-раз ничего кроме динамики не подходит. Smalltalk не для факториалов создавался, да.

т.к. много логики(которая меняется)

Да, с присваиваниями и прочими изменениями в хаскеле все особенно хорошо, не поспоришь.

Это только когда программист безмозглый.

Да. Проблема в том, что безмозглы абсолютно все. Человек впринципе не может одновременно держать в голове слишком много информации о типах переменных во всех нужных контекстах.

для сложной логики как-раз ничего кроме динамики не подходит.

Это не так, статика(нормальная) никак не ограничивает программиста, только заставляет его убедить компилятор что ошибок нет. Нет задачи, которую решает динамика и не может решить статика.

с присваиваниями и прочими изменениями

Я не про иммутабельность, а про изменение логики.

Elm на фронтенд не забудь, камрад.

держать в голове слишком много информации о типах переменных во всех нужных контекстах.

Для того чтобы не держать в голове много информации, люди придумали средства абстрагирования

никак не ограничивает программиста

LOL

а про изменение логики.

Это взаимосвязанные вещи

Для того чтобы не держать в голове много информации, люди придумали средства абстрагирования

Не всегда решает эту проблему

LOL

Докажи обратное или иди на хуй

Это взаимосвязанные вещи

Нет. Логику меняет заказчик. Мутабельность — изменения данных в памяти.

насколько дороже хостинг

Никто уже не пользуется хостингами. Сервера копейки давно стоят.

А что тут доказывать? Достаточно просто перечислить ограничения

* нет первоклассных типов

* нет полноценного наследования

* нет семантики сообщений

* нет синтаксической абстракции

* нет интроспекции

* нет рефлексии

* нет метаобъектов

* нет абстракции состояния (она костылится)

* нет возможности изменить типы/классы в рантайме

* нет возможности создать иерархию типов/классов

* нет возможности адекватного контроля за расходом памяти

* нет возможности рантайм-оптимизации

* нет кодогенерации

Это не полный список, конечно, просто надоело. Единственное, что получаем взамен — отлов ошибок типов(и только их) в компилтайме.

Логику меняет заказчик.

логику меняет кто угодно, жалко только, что реализует измененения программист

Достаточно просто перечислить ограничения

Я про реальные возможности. То, что ты перечислил — или вообще не нужно т.к. СТ предоставляет аналогичные решения, либо пиздёж

Никто уже не пользуется хостингами. Сервера копейки давно стоят.

Ну, я и правда сильно отстал от этой темы. Лет на десять. Поэтому и спрашиваю.

У тебя хорошая новость.

Клоун пока здесь ты. Мне нужно сделать сайт. Тема, которой не занимался лет десять. Поэтому решил прозондировать почву здесь.

почву здесь.

У нас тут python + flask. Всё сходу легко понимается. Рекомендую посмотреть доку и и захотеть делать не нём

Слабоватое оправдание.

Уже ближе к делу. Как понимаю, апач настраивать не надо. Он сам себя прописывает в скрипты ini. Вот, хорошо бы что-то такое и для yesod. Минимум ручного вмешательства. Неохота мне еще и самому скрипты такие писать.

попроси кого-нибудь :] апачу же меинтейнеры написали. В целом [keter](https://github.com/snoyberg/keter) для этого проектировался, почитай доку, может подойдет.

Чем хорош php здесь. Он - скриптовый. Восстановится апач после перезагрузки, и ладно.

ну тут вместо апача твой исполнимый файл запускаться будет. Может всякие nginx умеют это и в конфиге, не знаю, честно.

А для создания меню по навигации по сайту есть виджеты?

не видел. не дело это сервера, и вопрос дело ли фреймворка типа yesod.

anonimous уйди пожалуйста из ВСЕХ хацкель тредов, за исключением тех, что ты создал, НАВСЕГДА, пожалуйста.

Уговорил. Разрешаю тебе остаться наедине со своей анальной болью

не дело это сервера

канешн, клиент сам создаст себе меню, он нынче умный пошел.

т.к. много логики(которая меняется)

кстати, по этому поводу хорошая цитата

Immutability Considered Harmful

A simple example: Apple's FoundationKit has a NSURLRequest object which can only be initialized with an initialized NSURL instance. NSURL can only be initialized with a URL string. The URL string in the NSURL cannot be changed after initialization and the NSURL cannot be changed after the NSURLRequest.

Now this is ok if you can assume you'll never need to change the URL after it's instantiated or change a NSURLRequest's url after it's instantiated. Unfortunately, these assumptions are wrong.

Consider an Amazon S3 request. Setting up the URL scheme, domain, path and parameters can involve logic specific to the S3 request. Naturally, we'd like something like an S3Request subclass of NSURLRequest that would contain this logic. But as our constructor effectively makes these things immutable by the instance, we can't.

So now we've got all this logic and data which should be handled by the request but can't be. So we can either do the wrong thing by creating giant constructor methods that try to pass in everything, and which invariably make their own false assumptions (e.g. that you'll never need to switch the url scheme from https to http for testing) or we can do the ugly thing by creating a new class that holds all the data which NSURLRequest does but is used to create a NSURLRequest request instance after all it's data is set.

The design decision to use constructors in these frameworks classes has the unseen consequence of limiting our design decisions to a choice between the wrong way or the ugly way and this isn't an isolated case. I've seen many other examples of this problem in the Java and C++ world but I suspect they are particularly common among FP languages which seem to actively encourage this pattern of design.

Final notes: It's not the use of a convenience constructor that is the problem, but that such uses are typically associated with the use of immutable instance state. Some might propose returning a new instance for each mutation as a solution, but this creates even worse code when you consider it potentially has to follow the entire immutable state chain and the consequences for multiple references.

http://www.dekorte.com/blog/2012

хорошая — потому что правильная.

Haskell тут практически ничем не отличается от всяких других дурацких языков.

Могут ли сами подниматься?

Это не от них зависит, а от тебя.
Ставишь какой-нибудь supervisor или пилишь скрипт на баше и кидаешь в крон.

Никто уже не пользуется хостингами.

Похапешники пользуются.

Этих уже ничего не спасёт)

например

на первых порах можно ограничиться одной статикой

И при этом нужен haskell? :) А что хоть за задачи у тебя - хоумпейдж, интернет-магазин, соцсеть? Почему haskell, а не RoR тот же?

Если ты такие вопросы задаешь, что хаскель тебе не нужен.

рор ради статических страничек? Ради такого синатры будет на 100% достаточно.

RoR

Человек не хочет шквариться о раби-экосистему, и его можно понять.

Спасибо! Примерно это мне и нужно было. Я уже нашел сегодня, когда узнал здесь про Keter.

Сайт начинающего шароварщика + информация о моих открытых проектах. Продуктовая линейка и открытые проекты из одной области. Хочу все вместе разместить.

А haskell при том, что технически и идеологически самая сильная часть в виде одной из открытых библиотек написана мною на haskell. Подумал, было бы неплохо и сайт на этом языке написать :)

Как хаскеллист могу сказать, что для многих из нас RoR в принципе не входит в множество фреймворков, у которых есть юзкейсы, в силу поносности языка, библиотек, тулзов и комьюнити.

для многих из нас RoR в принципе не входит в множество фреймворков, у которых есть юзкейсы

Объективно RoR чуть ли не самая развитая из инфраструктур для веба. Из альтернатив по сути только python и clojure (но из-за jvm это далеко не для всех задач приемлемое решение).

в силу поносности языка, библиотек, тулзов и комьюнити.

Язык явно будет получше пхп, батареек не меньше чем в yii, да и выглядит стройнее. Не на java же ты предлагаешь веб писать, правильно?

рор ради статических страничек? Ради такого синатры будет на 100% достаточно.

Зачем учить несколько фреймворков, если и один неплохо справляется?

Человек не хочет шквариться о раби-экосистему, и его можно понять.

А вас что не устраивает в «раби-экосистеме», можно поинтересоваться?

Жырнота, разноцветные DSL и цирк с версиями.

Ok, принято. А что лучше есть? Так, чтобы самому не писать либы на каждый чих?

g: no silver bullet