LINUX.ORG.RU

Haskell, Yesod vs. Go, Revel

 , , ,


1

2

Что использовать для хобби проекта? Важна статическая типизация (деньги считать, чтобы без косяков) и скорость разработки. О производительности думать рано, но оба кандидата на отсутствие оной, вроде, не жалуются, аналогично с качеством сторонних библиотек. Для второго, полагаю, проще будет, в случае необходимости, найти команду девелоперов.
Холиварный срач о преимуществах/убогости языков - приветствуется.



Последнее исправление: CYB3R (всего исправлений: 1)

Python во все поля.

деньги считать, чтобы без косяков

+

скорость разработки

+

статическая типизация (деньги считать, чтобы без косяков)

Не думаю, что в случае с Python возникнут проблемы.

Deleted
()
Ответ на: комментарий от yoghurt

В йесоде тоже роуты типизированны, и урлы в темплейтах проверяются.

provaton ★★★★★
()

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

qnikst ★★★★★
()

Haskell, конечно же. По поводу фреймворка не знаю, для REST API я бы брал Scotty, для классического веба брал бы Yesod.

kost-bebix ★★
()

Go

Лалы, смотри, тебе сейчас понарассказывают о своих локальных свершениях.

Никто. Никогда. Не использует. Хаскелл.
(одна простая истина)

Выбирай Go и Goря не знай.

anonymous
()

Считать деньги? Хорошее хобби.

outtaspace ★★★
()

На Haskell ничего не делал, не знаю, но в плане проектов для веба Go довольно хорош. Revel приличный фреймворк хоть и для определенных задач. В общем не зная типа проекта сложно предложить адекватный инстьрумент. В общем случае если интересует скорость разработки, то можно взять Python/Django(Flask, Tornado). Батареек вагон.

northicewind
()
Ответ на: комментарий от exabikakad

зная сам язык и понимая монадические трансформеры, разобраться в хаппстаке - дело пары вечеров, Crash Course в помощь

yoghurt ★★★★★
()

Важна статическая типизация (деньги считать, чтобы без косяков)

Не уловил взаимосвязи. Это не очень влияет. (хоть и сам сторонник статической типизации). Просто не вздумайте числа с плавающей точкой использовать. С фиксированной (если ЯП поддерживает, в python есть это), либо вообще только целыми все деньги считать.

А вообще haskell во все поля, ага.

BattleCoder ★★★★★
()
  • Скорость разработки: ROR. В раби для этого есть скафолдинг, продуманный ActiveRecord и все такое. Очень много готового, хорошо продумано, как это готовое встраивать в приложение.
  • Haskell + Yesod: скомпилировалось - значит работает. Никаких ошибок типов, значительно меньше требуется тестов (тесты вьюх не нужны инфа 100% например). Хотя если деньги считаешь, то тесты логики нужны по любому, и тут тебе на выручку приходит охрененный QuickCheck. Сложноват, с места в карьер не получится.
  • Python + Django: все вручную, как в Yesod, только никаких типов, проверок, куча тестов, уныние.
s9gf4ult ★★
()

Пиши на Java и не парься.

kovrik ★★★★★
()
Ответ на: комментарий от Miguel

прочитал ещё два раза, и теперь явно прошу пояснить, в чем по твоему мнению:

a). написанность Yesod на 'Template Haskell'?

б). чем код на TH отличается от обычного кода?

Пока высказанное выглядит или неточностью или неверной формулировкой.

qnikst ★★★★★
()
Ответ на: комментарий от s9gf4ult

В раби для этого есть скафолдинг

Если ОП умеет бутстрап, например, то это перестаёт быть таким уж преимуществом. Ну и ты забыл упомянуть, что в рельсах тоже без тестов никуда (во всяком случае, если есть планы развивать проект).

Apple-ch ★★
()
Ответ на: комментарий от qnikst

в чем по твоему мнению: a). написанность Yesod на 'Template Haskell'?

Им невозможно пользоваться из чистого Haskell, без TH. То есть, теоретически такая возможность, конечно, есть. Практически это выльется в безумные неподдерживаемые коровники.

б). чем код на TH отличается от обычного кода?

Под «обычным», видимо, понимается всё-таки код на Haskell (не Template)?

Отличие в том, что код на Haskell имеет определённую семантику, формулируемую в терминах предметной области и не зависящую от скрытых деталей (таких как, например, сгенерированный ассемблерный код). Код на Template Haskell тоже имеет вполне определённую семантику, но она формулируется только в терминах кода на Haskell, который в результате генерируется. В итоге программист изолируется от предметной области, что полная суксь.

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

Им невозможно пользоваться из чистого Haskell, без TH. То есть, теоретически такая возможность, конечно, есть. Практически это выльется в безумные неподдерживаемые коровники.

TH там исключительно в boilerplate коде, вся логика и предметные области пишутся без него.

Отличие в том, что код на Haskell имеет определённую семантику, формулируемую в терминах предметной области и не зависящую от скрытых деталей (таких как, например, сгенерированный ассемблерный код). Код на Template Haskell тоже имеет вполне определённую семантику, но она формулируется только в терминах кода на Haskell, который в результате генерируется. В итоге программист изолируется от предметной области, что полная суксь.

Абстрактненько как-то звучит, такое ощущение, что ты поглядел на Yesod увидел зависимость от TH и забил..

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

такое ощущение, что ты поглядел на Yesod увидел зависимость от TH и забил

Это не совсем так. Я действительно ни разу не писал на Yesod, но только потому, что вовремя нашёл Happstack. В своё время я довольно много времени потратил на то, чтобы выбрать между Yesod, Happstack, Snap и чем-то ещё.

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

в общем не всё так плохо в Yesod, во всяком случае в этом отношении, хотя для следующего проекта (домашнего) я буду брать happstack.

qnikst ★★★★★
()
Ответ на: комментарий от provaton

Пожалуй, тем, что в нем нет лишней магии, код на обычном хаскеле (ЕМНИП на это в туторе делали ударение)

yoghurt ★★★★★
()
Ответ на: комментарий от yoghurt

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

provaton ★★★★★
()
Ответ на: комментарий от provaton

Я разбирался и с тем и другим по оффициальным мануалам.

С yesod мне потребовалось инициализировать проект какими-то базовыми файлами. Как новичок я не сильно разбирался в их содержимом. Я не люблю, когда у меня в проекте код, который я не понимаю. Некоторые мои хотелки плохо реализовывались (когда я вместо sqlite хотел подключить mongo, например, пришлось повозиться).

С happstack я начинал писать с нуля, по-необходимости добавляя новые компоненты. По отдельности все выглядело простым, кажется что здесь больше развита модульность. Плюс еще есть happstack-lite для начала

Правда с yesod я возился год назад, и тогда хуже понимал haskell

tri10bit
()
Ответ на: комментарий от Nagwal

Java же восьмая. Или скала. Изживай из себя борщевика по капле ;)

Боюсь интерпрайза же. Эти ваши Джавы для меня сродни тарабарщине. То ли дело Golang: Revel - первый фреймворк, устройство которого я знаю от и до, понимаю каждую строчку в его исходниках. Такой уровень понимания был только в случае с Erlang и используемыми в нем библиотеками (но там, кажись, это было свзяано с отсутствием документации, из-за чего по каждому чиху приходилось смотреть в исходники, хотя он очень понятный, да). Haskell же просто последкрайний язык, который использовал. Его философии пока не разделяю, ибо не вник и не проникся, но, полагаю, дипломка на Haskell даёт +5 к длине члена (т.е. движет простое ЧСВ).

exabikakad
() автор топика
Ответ на: комментарий от exabikakad

Вот и используй Go.

Зачем вообще haskell от которого со временем так или иначе придётся уйти? Go действительно милое, очень мощное продакшн решение, с фокусом на перспективу в многопроцессорном будущем; haskell — для товарищей домоседов и клинических девственников, странная каста людей, поистине странная.

anonymous
()

Выбор очевиден :)

Go не нужен и мёртв. А haskell - один из лучших языков.

anonymous
()
Ответ на: комментарий от anonymous

Уйти со временем придётся от Go, когда все окончательно смиряться с тем, что он не взлетел и кто-нибудь выпустить новую игрушку для илитки. А Haskell ещё и тебя переживёт.

anonymous
()
Ответ на: комментарий от anonymous

А Haskell ещё и тебя переживёт.

Да разве это жизнь :) Жизнь овоща?

anonymous
()
Ответ на: Выбор очевиден :) от anonymous

Диванный теоретик. :) И где же применяется твой haskell, где все ваши успехи?

«Go не нужен и мёртв» — это так вас в ненужных конторках осведомляют? Ну-ну, смешные.

anonymous
()
Ответ на: комментарий от anonymous

В каких ненужных конторках? В которых тебе сказали, что go круче, чем haskell? Я мнениями ненужных конторок не интересуюсь.

Посмотри, к примеру вот это, если действительно интересно:

http://www.haskell.org/haskellwiki/Applications_and_libraries

http://www.haskell.org/haskellwiki/Haskell_in_industry

anonymous
()
Ответ на: комментарий от anonymous

Да, в частности, в моей конторке так и сказали. Я думаю, моя конторка тебе очень хорошо известна, она вообще всем известна.

Насчёт гугловской инфраструктуры, источник уже врёт, перетерпела она хорошую модернизацию — хаскелл с некоторых пор там не числится, т.е. вообще.

anonymous
()
Ответ на: комментарий от Apple-ch

Бутстрап не вместо тестов, а вместо скафолдинга :)

Я это и имел в виду [facepalm]. Про тесты - это ответ на второе предложение.

s9gf4ult ★★
()
Ответ на: комментарий от anonymous

Я думаю, моя конторка тебе очень хорошо известна, она вообще всем известна.

Мейлру что ли?

anonymous
()
Ответ на: комментарий от s9gf4ult

Взять лучшее от всех миров

Фронтенд - ребе, логика - хашкель, скрепты - педон.

Ребе Хашкель Педон

Этого-то хоть можно (в отличие от Столлмана) по настоящему имени называть =)

stevejobs ★★★★☆
()
Ответ на: комментарий от exabikakad

только в случае с Erlang

playframework - там Скала, совместима с поеданием борща. (хоть и не православный лишп, но тут шашечки или ехать). Плюс Акка, близкая милому тебе Эрлангу (но в отличие от него, с этой дрянью можно разобраться за ночь, плюс документация фанатически подробная).

stevejobs ★★★★☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.