Функциональная парадигма

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

Я не знаю, что за херню ты там у себя имел в виду. Что должен делать код с «>>» вообще не понятно.

Я вроде внятно объяснил, нет?

лол, нет =)

Тот код, что ты привел, на хаскеле не пишется, потому что хаскелисты не пишут скобки, они пишут $

Сферические хаскелисты в вакууме из твоего воображения.

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

Один хер.

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

Парсить ничего не пришлось. Уязвимо разве что к ошибкам компиляции, а это хорошо.

В моем коде >> - это не бинд, я же указал специально. x >> f = f x, я просто хз как эта ф-я в хаскеле называется.

Что должен делать код с «>>» вообще не понятно.

Что там непонятного?

лол, нет =)

Видимо, ты туповат. Перечитай еще раз.

Сферические хаскелисты в вакууме из твоего воображения.

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

Один хер.

С каких пор впятеро большие временные затраты - это один хер?

Парсить ничего не пришлось.

Как не пришлось? А как ты определил порядок выполнения операций, не зная ассоциативности и приоритета?

В моем коде >> - это не бинд, я же указал специально. x >> f = f x, я просто хз как эта ф-я в хаскеле называется.

То есть единственная твоя проблема с хаскелем — это что тебя не устраивает вот это:

($) f x = f x

Тебе обязательно в обратном порядке писать?

x.cos().sqr() + y.sin().sqr() = 1

:D

Что там непонятного?

Ну, если, как ты там написал выше, x >> f = x f, то твой код не тайпчекается.

С каких пор впятеро большие временные затраты - это один хер?

Впятеро большие затраты там только в твоем воображении.

Видимо, ты туповат. Перечитай еще раз.

Если ты не в состоянии внятно изложить свою мысль, то это не мои проблемы.

Как не пришлось? А как ты определил порядок выполнения операций, не зная ассоциативности и приоритета?

Ровно настолько, насколько тебе пришлось думать об ассоциотивности оператора точки в твоем «сишкоязыке», как ты выразился.

& но не надо так, это ж нечитаемо.

То есть единственная твоя проблема с хаскелем — это что тебя не устраивает вот это:

Я понимаю, что у хаскелистов когнитивное расстройство, но для номральных людей записанный шиворот-навыворот код в стиле blah blah where blah-blah - вырвиглаз.

Ну и общая-то претензия в перегруженности синтаксиса

Ну, если, как ты там написал выше, x >> f = x f, то твой код не тайпчекается.

Конечно, тайпчекается. Точнее, это зависит от f.

Впятеро большие затраты там только в твоем воображении.

Это в моем оображении ты сумел выродить что-то хотя бы относительно удобо-варимое только с третьей попытки?

Если ты не в состоянии внятно изложить свою мысль, то это не мои проблемы.

Что невнятного в «приведи пример кода на хаскеле с let-блоком внутри if-блока, который сам находится внутри let-блока внутри if-блока»?

Ровно настолько, насколько тебе пришлось думать об ассоциотивности оператора точки в твоем «сишкоязыке», как ты выразился.

В сишкоязыке это единственный оператор подобного рода (ну ок, пусть у нас какойто воображаемый язык, в котором их будет целых 2-3), его синтаксис и семантика полностью описана в спецификации языка и общеизвестна. В хачкиле таких операторов десятки и какой-то строгой спецификации на них нет - т.к. по факту это просто ф-и. Их может навелосипедить любой кретин. И не просто может - а велосипедит, потому что язык этому потворствует (ведь функции на хаскеле должны быть однострочниками, помним?).

& но не надо так, это ж нечитаемо.

с &? Действительно нечитаемо. Только хаскелисты могли для обозначения конвеера выбрать &.

знаешь что я скажу про хацкель...

Ты казался умнее когда о «плюсохейтерах» ныл.

Я понимаю, что у хаскелистов когнитивное расстройство, но для номральных людей записанный шиворот-навыворот код в стиле blah blah where blah-blah - вырвиглаз.

Это очень наивно. [сарказм]Ведь, конечно же, x.sin() всегда удобнее sin(x).[/сарказм]

Ну и общая-то претензия в перегруженности синтаксиса

Если ты имеешь в виду язык в целом, то соглашусь. Но в этом есть и свои плюсы.

Конечно, тайпчекается. Точнее, это зависит от f.

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

Что невнятного в «приведи пример кода на хаскеле с let-блоком внутри if-блока, который сам находится внутри let-блока внутри if-блока»?

Я тебя просил сперва привести код на любом другом языке, где это по-твоему выглядит красиво. Надоело первым все писать.

А невнятно относится к тому, что у тебя там что-то на хаскеле не скейлится. Читай внимательно, пожалуйста.

Если я правильно понял, то на rust как-то так:

if let Some(x) = get_optional() {
    if let Point(x, y) = get_point() {
        // do_magic...
    }
}

вопрос в нужности конвеера остаётся открытым, имхо всякие |> читаются на порядок хуже.

разница точно не убедительна..

result <- liftA2 (,) get_optional get_point
case result of
  (Maybe x, (x', y)) -> do_magic

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

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

не работает и никому ненужно это ненужно.

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

Хм... POSIX и сишные имена функций? Вот уж где экономия на буквах во весь рост.

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

Ну а параметрам-типам много где принято однобуквенные названия давать.

Ну в том же C++ в более-менее сложном шаблонном коде имена параметров шаблонов быстро перестают быть однобуквенными.

Сюда же лайфтаймы из раста.

Как будто в этом есть что-то хорошее. У авторов Rust-а вообще чувство «прекрасного» явно имеет корни в области функционального хардкора :)

T — одна буква. Почему тогда тебя удивляет аналогичная ситуация в хаскеле?

Справедливости ради, у других параметров вполне нормальные имена: ForwardIt, а не I, UnaryPredicate, а не P и т.д. Если тип единственный, то да, будет T, тем более, зачастую, это будет «просто тип» - вполне нормально.

3. Людям плохо знающим язык компилятор позволит писать плохие названия

А какие языки защищают от неправильных названий? Кое-где имеется контроль именования, но всё ограничивается ерундой в духе «обязателен кемелкейс» и всё. Тут хаскель, возможно, даже гарантирует больше обычного - по крайней мере, (не)чистота функции снаружи видна.

Отсюда и переиспользование уже имевшегося в языке символа операции «дополнение до единицы».

Честно говоря, даже после объяснения логика мне кажется сомнительной. Почему дополнением служит деструктор, а не оператор присваивания, например?..

По моему, это случай когда проще запомнить.

Если я правильно понял, то на rust как-то так:

Кстати, раст-хейтеры любят подчёркивать его «далёкость» от С(++). (:

не работает и никому ненужно это ненужно.

Видать крепко тебе хаскель «обосрал шаровары».

P.S. На хаскеле не пишу и не собираюсь.

Как будто в этом есть что-то хорошее.

Учитывая, что оно встречается далеко не в одном языке, то, по всей видимости, кому-то нравится. Хотя я тоже предпочитаю давать более осмысленные названия.

А то, хаскелль то и то явно ближе по синтаксису.

А то, хаскелль то и то явно ближе по синтаксису.

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

Тут хаскель, возможно, даже гарантирует больше обычного - по крайней мере, (не)чистота функции снаружи видна.

А еще по названию никогда нельзя спутать тип с функцией =)

Простите, забыл тег [sarcasm]

Почему дополнением служит деструктор, а не оператор присваивания, например?..

«Дополнение до единицы» — это когда 0 меняется на 1, а 1 на 0. Конструктор переводит объект из состояние «не существует» (т.е. 0) в состояние «существует» (т.е. 1), а деструктор — напротив, из «существует» (т.е. 1) в «не существует» (т.е. 0).

Сложно судить, насколько это полезно для запоминания, но то, что это логичнее, чем «оператор присваивания», это уж точно.

(не)чистота функции снаружи видна

Но это может быть обман. Лучше бы язык ничего не гарантировал

Но это может быть обман. Лучше бы язык ничего не гарантировал

Обман возможен только если там какой-нибудь unsafePerformIO или FFI спрятан.

Лучше бы язык ничего не гарантировал

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

_ в имени функции обозначает, что функция

Обозначает что нам в том или ином виде пофиг на возвращаемое значение. Мы его не используем. Кроме forM_ и mapM_ можно увидеть, например, тут http://hackage.haskell.org/package/base/docs/Control-Exception-Base.html#v:br...

он выбран, потому что

в pattern-matching-е

_ is the pattern which matches anything without binding (wildcard, «don't care» pattern).

Обозначает что нам в том или ином виде пофиг на возвращаемое значение.

Не надо про нас, надо про функцию. Чем отличаются ф-и с _ от ф-й без _?

в pattern-matching-е

Не вижу связи, если честно.

В с++ этот значок у деструктора ставят потому, что так указано в спецификации языка. Которая одна для всех.

У Haskell тоже одна спецификация для всех.

https://www.haskell.org/onlinereport/haskell2010/haskellch13.html#x21-1960001...

Не надо про нас, надо про функцию.

Почему?

Не вижу

К окулисту.

Почему?

Вопрос был в том, чем функция отличается. Какое отношение это имеет к тому, чего мы хотим или нет? Каззалось бы, хаскелисты ведь разбираются в матемтаике? Значит, они без проблем должны быть способны дать нормальное определение. Но не дают :(

Где в этой «одной спецификации для всех» указаны назначения _ или '? И используют ли абсолютно все пользователи языка эти обозначения в указанном смысле?

И используют ли абсолютно все пользователи языка эти обозначения в указанном смысле?

А должны?