Haskell

[levgem]

Предварительные выводы про хаскель, сделанные по микро-опыту, по возможности очищенные от эмоций:

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

Comments

[_pacak_]

Монады это не this, монада может быть чем угодно. Поизучай например монады Maybe и List.

Жесткость к типам при прототипировании помогает - если грамотно систему типов использовать - он фактически проверит что ты в своих выкладках нигде не накосячил.

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

[ext_714455]

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

P. S. "быдлоокамл" это такая местная шутка?

[levgem]

1) «все идеи как правило начинаются с сигнатуры» - я не знаю на чём основан ваш опыт, но весь мой опыт говорит об обратном. Есть внешний источник данных (будь то видео или биржевые котировки) и надо их как-то обрабатывать. Причём, проектирование программы заранее абсолютно лишено всякого смысла, потому что по ходу всплывают бизнес-ньюансы, которые полностью ставят крест на всей архитектуре и надо заново.

2) насчёт окамла - да, шутка. Просто считается, что он попроще хаскеля и вообще более пролетарский.

[ext_714455]

1) я имел ввид прототипирование на хаскелле, а не прототипирование вообще
2) мнение довольно спорное, хотя порог вхождения безусловно отличается в пользу камла

[levgem]

1) не понял этого. Есть задача, сформулированная устно. Надо её решить. Садимся и начинаем итеративно строить программу, это прототипирование, которое потом превращается в production код.

При чём тут хаскель или не хаскель?

2) Мне тут нечего сказать, потому что я ещё ни строчки не написал на окамле. Это, надеюсь, впереди.

[palm_mute]

>Пример: ... alignAt, как и функции выше на самом деле по сути представляет из себя мутабельное изменение состояния

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

[levgem]

Наверное мне было бы немного понятнее, если бы явно был выделен в виде какой-то синтаксической ссылки тот this, который меняется такой функцией.

Впрочем, на плюсах же пишут и ничего, получается.

[palm_mute]

так нет никакого this в общем случае, монады одной State не исчерпываются.

[levgem]

Вот вы все заладили с общим случаем и прочим буквоедством.

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

[max630]

мешает несовпадение типов между разными библиотеками, всякие Int/Integer, Double/Float, String/Text/Bytestring. A внутри своего кода нормально. Наоборот - когда нет типов, как-то стрёмно.