Здравствуйте, Ikemefula, Вы писали:

I>Теоретически. Надо учитывать, что язык нужен человеку, а не компьютеру. Если учеть, что особенности человеческого внимания сильно ограничены, все резко меняется.
I>Отсюда ясно, что уровень языка нужно определять через количеством умозаключений, которые надо нагородить, что бы решать задачи абстрагируюясь от аппаратных и прочих особенностей.

Сомнительно. Вот допустим мы возьмём некую узкую предметную область (и кстати совсем не завязанную на железо или быстродействие) и ассемблер. Напишем на нём мощный фреймворк (да, это будет нам дорого стоить) под нашу предметную область. А вот теперь посмотрим на работу пользователя нашего фреймворка! Думаю она будет очень высокоуровневая, хотя он и будет вроде как работать на ассемблере...

Здравствуйте, Ikemefula, Вы писали:

I>Это некорректное сравнение. Динамика означает, что всякие проверки переносятся на момент вызова или не выполняются вообще. Корректно ли будет ПО дело десятое. Где у нас вызов шаблонов С++ ? Правильно, при конкретном использовании.

Что значит "корректность ПО дело десятое", если вообще смысл всех этих типизаций как раз в гарантиях отсутствия определённого класса ошибок? ) Если нам наплевать на корректность, то вообще не нужна никакая типизация в языке.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>>Определение какое-то странное — о строительных блоках любого языка можно рассуждать как о математических объектах и извлекать из этого пользу.
I>>Теоретически.

EP>Я привёл конкретные примеры.

Если ты не заметил, я их и не оспариваю, более того, я с ними абсолютно согласен.

I>>Надо учитывать, что язык нужен человеку, а не компьютеру. Если учеть, что особенности человеческого внимания сильно ограничены, все резко меняется.

EP>Вот выше был пример Fibonacci numbers через fix — ты сможешь объяснить его ребёнку? Зато обычная итеративная версия и проще и быстрее.

Для кого проще ? Ты внятно ответь сначала и расскажи, что ты под простотой-сложностью понимаешь.

Если человек не знаком с программированием, то приседания с переприсваиванием ему чужды. А вот функциональная запись это именно то, чем он занимался в школе. Формулы он умеет писать с 4го класса, с 9го он знает что такое производная, с 10го — интеграл.
Вот на такой базе ему можно объяснить очень многое. А вот твои переприсваивания совершенно не ясно как объяснить, потому что это принципиально другая область — организация вычислений, а не сами вычисления. То есть, делегирование вычислений кому то другому, а не сами вычисления.

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

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

EP>Неверно. Из ассемблерных команд делают блоки побольше, которые собирают ещё более в крупные блоки и т.п.

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

Объяснение простое — нет в ассеблере возможности оперировать только высокоуровневыми блоками. Ассемблер тебя жостко ограничивает — придется продираться черз конструкции типа "локальная переменная", "параметр". В итоге внимание тупо распыляется.

Даже больше — любой язык не дает возможности использовать только высокоуровневые конструкции. Отсюда синтаксический шум/мусор и проблемы с читабельностью кода.

Собтсвенно возможности наименьших блоков уже неплохо характеризуют уровень языка.

EP>И это так везде, даже в ФП — из маленьких блоков собирают побольше и т.п.

1 Высота вот этой иерархии "блоков" на ассемблере несравнимо выше чем в любом высокоуровневом языки.
2 Количество такого мусора в реальной программе превосходит любые ожидания

В ФП тебе не надо конструировать блок "локальная переменная" или "передать параметр" или даже "функция"

I>>На С++ думать надо меньше, но все равно очень много относителя Хаскеля.
I>>А вот Хаскель будет лидер из трех этих примеров, без шансов. (Тут кто нибудь из плюсовиков почти наверняка не согласится)

EP>Конечно не согласится — то убожество которое гордо демонстрируют Хаскелисты это не Quick Sort.
EP>Адекватные Хаскилсты даже явно говорят, что это не Quick Sort Тони Хоара, например

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

I>>Т.е. высокоуровневый, это такой который легко позволяет оперировать абстракциями, а не конкретными особенностями аппаратной платформы.

EP>Конкретные модели абстракций на чём будешь реализовывать?

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

I>>Очевидно, из этого не следует, что Ассемблер или С++ иногда становятся высокоуровневыми языками.

EP>Очевидно, что из этого не следует и обратное. То есть не следует ни то, ни другое — к чему вообще тогда пример?

Еще раз — язык нужен для людей. Процессору он не нужен. Представь себе эдакого Всемогутора, который может любую задачу любой сложности решить за 0 времени.
Вопрос — на кой ляд ему какой то язык ? Он прямо в машинных кодах за 0 времени навернёт решение любой сложности.

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

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

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

В итоге ассемблер это вагон трудозатрат на ровно месте в ЯВУ это достается почти что даром.

I>>Пример — можно легко устранить лишние вызовы функций заменив их на переходы. Или инлайнить виртуальные вызовы, про которые ни у компилятора ни у линкера нет полноты сведений для принятия решения.

EP>Если во время написания кода ты знаешь что есть возможность инлайнинга, то ты сможешь заинлайнить даже на C# — для этого ассемблер не нужен.

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

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

Следовательно генереный код сливает рукописному.

Здравствуйте, alex_public, Вы писали:

I>>Это некорректное сравнение. Динамика означает, что всякие проверки переносятся на момент вызова или не выполняются вообще. Корректно ли будет ПО дело десятое. Где у нас вызов шаблонов С++ ? Правильно, при конкретном использовании.

_>Что значит "корректность ПО дело десятое", если вообще смысл всех этих типизаций как раз в гарантиях отсутствия определённого класса ошибок? ) Если нам наплевать на корректность, то вообще не нужна никакая типизация в языке.

Ну тогда тебе остаётся признать, что Джаваскрипт это статически типизированый язык

Здравствуйте, alex_public, Вы писали:

_>Сомнительно. Вот допустим мы возьмём некую узкую предметную область (и кстати совсем не завязанную на железо или быстродействие) и ассемблер. Напишем на нём мощный фреймворк (да, это будет нам дорого стоить) под нашу предметную область. А вот теперь посмотрим на работу пользователя нашего фреймворка! Думаю она будет очень высокоуровневая, хотя он и будет вроде как работать на ассемблере...

А что значит "мощный" ? Определи этот термин.

Чтобы доказать, что это не будет высокоуровневая работа, необходимо и достаточно показать, что
1 в таком фремворке есть нечто, от чего можно избавить без потери эффективности, продуктивности и тд и тд, это необходимо
2 отсутствует нечто, чего дает эффективность, продуктивность и тд и тд. — необходимо
3 показать, что существует нечто, что даст и эффективность и продуктивность при избавлении от п.1 — необходимо и достаточно

Итого

От примитивов типа "паттерн передать аргумент", "паттерн почистить стек" , "паттерн возвращаемое значение" ты никуда не уйдёшь.

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

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

Опаньки !
1 работа пользователя фремворка оказалась не такой уж высокоуровневой
2 есть инструмент который повыше уровнем

Как то так

P.S. Писать на ассемблере и не завязываться на железо это сильно. Регистры, стек, флаги, порты — куда это все девать ?

Здравствуйте, alex_public, Вы писали:

I>>То есть, в кратце, тебя смущают не страхи в Хаскеле, которых ты не смог показать, а всего-то
I>>1 если писать на XXX, как на YYY, то получается многословный код.

_>При такой логике и брейнфак легко становится идеальным языком... )

Нет, не становится.

I>>2 изменение состояния на функциональном языке дает многословный код

_>А вот и нет. Если мы глянем на тот же Ocaml и многие другие ФЯ, то там подобной ереси нет.

Конкретно такой может и нет, но есть другая. И вообще, все эти ФЯ по сравнению с Хаскелем сильно вряд ли ФЯ Так, гибриды.

I>>Хаскель не С++ — ужос !

_>Вообще то там было скорее показано, что "монадный хаскель" — это не хаскель. Хотя в сравнение "монадный хаскель" vs. C++ расклад оказался даже ещё хуже.

Если уж сравнивать монадный хаскель с С++, то надо обязательно посмотреть на ко-монады.

_>А вот против классического красивого Хаскеля никто ничего и не говорил. Ну за исключением того, что подобных Хаскель можно увидеть только в академических примерах, а во всех реальных приложениях почти весь код занимают гигантские монады.

Я полистал книгу по Yesod и с тобой не согласен.

Здравствуйте, Ikemefula, Вы писали:

I>>>Надо учитывать, что язык нужен человеку, а не компьютеру. Если учеть, что особенности человеческого внимания сильно ограничены, все резко меняется.
EP>>Вот выше был пример Fibonacci numbers через fix — ты сможешь объяснить его ребёнку? Зато обычная итеративная версия и проще и быстрее.
I>Для кого проще ? Ты внятно ответь сначала и расскажи, что ты под простотой-сложностью понимаешь.
I>Если человек не знаком с программированием, то приседания с переприсваиванием ему чужды. А вот функциональная запись это именно то, чем он занимался в школе. Формулы он умеет писать с 4го класса, с 9го он знает что такое производная, с 10го — интеграл.
I>Вот на такой базе ему можно объяснить очень многое. А вот твои переприсваивания совершенно не ясно как объяснить, потому что это принципиально другая область — организация вычислений, а не сами вычисления. То есть, делегирование вычислений кому то другому, а не сами вычисления.

Проще для всех — есть тысячи примеров императивщины, как в школе, так и в повседневной жизни:

Детский конструктор с пошаговой инструкцией как собрать конкретную модель. Да хоть то же оригами.

Карточные игры, или например пасьянсы — сплошное мутирование с императивщиной. Кстати, я когда в 12 лет изучал сортировку (императивную!) — для наглядности использовал карты.

Работа с бытовой техникой.

Кухонные рецепты.

Я помню как в первом классе мы рисовали различные фигуры: поставим точку в определённую точку, а дальше учитель говорит (императивно!) куда и сколько клеток прочертить.

Алгоритмы описанные в книге Liber Abaci Леонарда Пизанского (aka Фибоначчи) учат в первых классах: сложение, умножение и т.п.

Начала Евклида — книга по которой учат геометрию почти 2300 лет. В дословном переводе первые три постулата отличаются от того, как нас учат в школе "через две точки можно провести прямую ...". Например перевод Sir Thomas Heath:

Let the following be postulated:
1. To draw a straight line from any point to any point.
2. To produce a finite straight line continuously in a straight line.
3. To describe a circle with any centre and distance.

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

Proposition 1.
On a given finite straight line to construct an equilateral triangle.

Лабораторные работы по физике, химии и т.п.

Вот, кстати, наглядная сортировка с мутированием. Попробуй изобрази функциональный аналог с cons'ами.

I>А вот если минимально научить его программированию, то, внезапно, станет наоборот — проще понять итерационную версию, потому что он руками сможет проделать ту работу, которую делает процессор.

Люди с самого детства взаимодействуют с миром императивно, мутируя какие-либо состояния, выполняя последовательности действий — это более естественно чем ФП. Вот хотя бы попробуй описать рыбалку.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>Вот на такой базе ему можно объяснить очень многое. А вот твои переприсваивания совершенно не ясно как объяснить, потому что это принципиально другая область — организация вычислений, а не сами вычисления. То есть, делегирование вычислений кому то другому, а не сами вычисления.

EP>Проще для всех — есть тысячи примеров императивщины, как в школе, так и в повседневной жизни:

У меня ощущение, что ты читаешь мои сообщения пяти- или десятилетней давности и берешь идеи оттуда.

Вычисления и программирование оных это две большие разницы. Было бы по твоему, то без малого все бы умели программировать хоть чуть-чуть. А этого не происходит — смотри на ЗП разработчиков и их количество в общей массе.

Для того, что бы понять твою итерационную версию, надо освоить простейший вычислитель. У ребенка нет в голове модели этого вычислителя. Когда появится, вот тогда можно будет начать объяснять итерационную версию фибоначчи. А просто объяснить функцию Фибоначчи не нужны никакие вычислители, формулу нарисовал и всё.
Более того, этот человек сможет проверить её же в Экселе том же, на раз. К программированию это не приблизит, но фибоначчи объяснить вполне получится.

Здравствуйте, Ikemefula, Вы писали:

I>>>Вот на такой базе ему можно объяснить очень многое. А вот твои переприсваивания совершенно не ясно как объяснить, потому что это принципиально другая область — организация вычислений, а не сами вычисления. То есть, делегирование вычислений кому то другому, а не сами вычисления.
EP>>Проще для всех — есть тысячи примеров императивщины, как в школе, так и в повседневной жизни:
I>У меня ощущение, что ты читаешь мои сообщения пяти- или десятилетней давности и берешь идеи оттуда.

lolwut?

I>Вычисления и программирование оных это две большие разницы.

Я в первую очередь и говорю про понимание написанного.

I>Было бы по твоему, то без малого все бы умели программировать хоть чуть-чуть.

Тем не менее, непосредственно программирование тоже встречается в повседневной жизни — разве трудно составить рецепт, или например описание маршрута?

I>А этого не происходит — смотри на ЗП разработчиков и их количество в общей массе.

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

I>Для того, что бы понять твою итерационную версию, надо освоить простейший вычислитель. У ребенка нет в голове модели этого вычислителя. Когда появится, вот тогда можно будет начать объяснять итерационную версию фибоначчи.

Ему не нужна модель вычислителя — у него вычислитель уже есть в голове.
Итеративную версию чисел Фибоначчи можно элементарно объяснить ребёнку даже если он не умеет складывать числа — с помощью линейки и циркуля.

I>А просто объяснить функцию Фибоначчи не нужны никакие вычислители, формулу нарисовал и всё.
I>Более того, этот человек сможет проверить её же в Экселе том же, на раз. К программированию это не приблизит, но фибоначчи объяснить вполне получится.

Попробуй объяснить вот этот "идиоматичный ФП" код ребёнку:

fibs = fix $ (0:) . (1:) . (zipWith (+) <*> tail)
fibs !! 10

Или даже не ребёнку, а своему коллеге, который с ФП не сталкивался.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Попробуй объяснить вот этот "идиоматичный ФП" код ребёнку:
EP>

EP>fibs = fix $ (0:) . (1:) . (zipWith (+) <*> tail)
EP>fibs !! 10
EP>

Или даже не ребёнку, а своему коллеге, который с ФП не сталкивался.

OMFG

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

Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>Вычисления и программирование оных это две большие разницы.

EP>Я в первую очередь и говорю про понимание написанного.

Начинать объяснять любой итерационный алгоритм можно не раньше, чем человек поймет сам вычислитель.

I>>Было бы по твоему, то без малого все бы умели программировать хоть чуть-чуть.

EP>Тем не менее, непосредственно программирование тоже встречается в повседневной жизни — разве трудно составить рецепт, или например описание маршрута?

И где здесь вычислитель навроде машины тьюринга или регистровой машины ?

I>>А этого не происходит — смотри на ЗП разработчиков и их количество в общей массе.

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

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

EP>Во-вторых для программирования нужна тяга к машинам, и какая-никакая интровертность. То есть программистов мало не потому что трудно, а потому что далеко не всем интересно.

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

I>>Для того, что бы понять твою итерационную версию, надо освоить простейший вычислитель. У ребенка нет в голове модели этого вычислителя. Когда появится, вот тогда можно будет начать объяснять итерационную версию фибоначчи.

EP>Ему не нужна модель вычислителя — у него вычислитель уже есть в голове.

Машина тьюринга или регистровая машина ? Жжош !

EP>Итеративную версию чисел Фибоначчи можно элементарно объяснить ребёнку даже если он не умеет складывать числа — с помощью линейки и циркуля.

Для ребенка в этом возрасте это будут просто линии и квадраты, а не фибоначчи.

I>>А просто объяснить функцию Фибоначчи не нужны никакие вычислители, формулу нарисовал и всё.
I>>Более того, этот человек сможет проверить её же в Экселе том же, на раз. К программированию это не приблизит, но фибоначчи объяснить вполне получится.

EP>Попробуй объяснить вот этот "идиоматичный ФП" код ребёнку:
EP>

EP>fibs = fix $ (0:) . (1:) . (zipWith (+) <*> tail)
EP>fibs !! 10
EP>

Или даже не ребёнку, а своему коллеге, который с ФП не сталкивался.

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

Нужно объяснять вот такой или классический рекурсивный

def F(n):
    return ((1+sqrt(5))**n-(1-sqrt(5))**n)/(2**n*sqrt(5))

Теперь скажи, что здесь будет непонятно школьнику 10 класса который никогда не пробовал программировать ?

Всё что сложнее требует знакомства с вычислителем.

Здравствуйте, Ikemefula, Вы писали:

I>Ну тогда тебе остаётся признать, что Джаваскрипт это статически типизированый язык

С чего бы это? )

Здравствуйте, Ikemefula, Вы писали:

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

Здравствуйте, Ikemefula, Вы писали:

I>Конкретно такой может и нет, но есть другая. И вообще, все эти ФЯ по сравнению с Хаскелем сильно вряд ли ФЯ Так, гибриды.

Так есть. Но о том и речь, что чистые функциональные не нужны.

I>Если уж сравнивать монадный хаскель с С++, то надо обязательно посмотреть на ко-монады.

Вообще то у меня там претензии не к самим монадам (это же на самом деле достаточно удобный инструмент для определённых задач), а к реализации IO/ST в Хаскеле. Просто оно там и сделано через соответствующие монады, так что получается приходится их ругать. )))

Здравствуйте, alex_public, Вы писали:

I>>Конкретно такой может и нет, но есть другая. И вообще, все эти ФЯ по сравнению с Хаскелем сильно вряд ли ФЯ Так, гибриды.

_>Так есть. Но о том и речь, что чистые функциональные не нужны.

Тебе они не нужны, уже давно выяснили.

I>>Если уж сравнивать монадный хаскель с С++, то надо обязательно посмотреть на ко-монады.

_>Вообще то у меня там претензии не к самим монадам (это же на самом деле достаточно удобный инструмент для определённых задач), а к реализации IO/ST в Хаскеле. Просто оно там и сделано через соответствующие монады, так что получается приходится их ругать. )))

Я пока не увидел никаких обоснованых претензий

Здравствуйте, alex_public, Вы писали:

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

Мне кажется ты скипнул не читая.

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

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

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

То есть, чем ближе язык к железу, тем он более низкоуровневый. Чем ближе к математике — тем более высокоуровневый.

Ну и специализацию надо учитывать. Скажем, c т.з. Datalog языки C++, Haskell и ассемблер будут примерно одинаково низкоуровневыми

Здравствуйте, Ikemefula, Вы писали:

I>Тебе они не нужны, уже давно выяснили.

Тот же OCaml мне вполне нравится. )

I>Я пока не увидел никаких обоснованых претензий

Так, напишу здесь всё своё видение последний раз. Не для того чтобы тебя убедить (при твоей упёртости это мало реально ), а просто чтобы подвести некий итог и кидать сюда ссылки потом, если ещё возникнут вопросы. Писать в дальнейшем на эту тему уже не собираюсь.

И так, появилась идея создать чистый функциональный язык. Для этого надо как-то решить проблему не вписывающихся в эту концепцию обязательных нюансов программирования. Как минимум это "изменение состояния" и ввод/вывод (тоже в общем то состояние, только как бы внешнего мира). В Хаскеле эту проблему решили с помощью выделения всего кода ST/IO в некую специальную резервацию. Кстати, построение резервации выполнено с помощью монадных техник (далеко не единственный вариант) и как раз исключительно это и является причиной такого широкого использования монад в Хаскеле (с этого моего утверждения и началась вся эта дискуссия). Так вот, в результате мы получили внутри Хаскеля ещё один маленький встроенный язык, причём уже чётко императивный. Естественно он убогонький и неудобный, причём не только по сравнению с самим Хаскелем, но и в сравнение с классическими императивными языками (что не удивительно, т.к. у в них именно такая функциональность оттачивалась годами). Но видимо авторы языка посчитали это приемлемой ценой за возможность писать вне этого подъязыка строго чистый и ленивый код.

И для определённого вида приложений это действительно замечательно. Например, если мы возьмём приложение, которое считает что-то сложное и потом просто печатает это в консоль, то вся "нехорошая" часть приложения сведётся к виду "main=print $ pure_main", а вся остальная часть приложения будет представлять из себя красивый чистый и ленивый код. Красота!

Однако если мы вернёмся из академического мира в реальность, то там ситуация становится противоположной. При написание скажем какого-нибудь десктопного GUI, наибольший объём кода у нас становится не в области нормального Хаскеля, а в области того самого убогого императивного подъязыка. Со всеми вытекающими из этого последствиями. И в итоге весь смысл изначальной идей оказывается выкинутым в помойку.

Здравствуйте, Ikemefula, Вы писали:

I>То есть, чем ближе язык к железу, тем он более низкоуровневый. Чем ближе к математике — тем более высокоуровневый.

Не думаю) ФЯ — это совсем не признак высокоуровневости. Это скорее тоже низкий уровень, но совсем с другой стороны.

I>Ну и специализацию надо учитывать. Скажем, c т.з. Datalog языки C++, Haskell и ассемблер будут примерно одинаково низкоуровневыми

Воот, с этим уже согласен. Кстати, Пролог мне всегда очень нравился. )))

Здравствуйте, alex_public, Вы писали:

I>>То есть, чем ближе язык к железу, тем он более низкоуровневый. Чем ближе к математике — тем более высокоуровневый.

_>Не думаю) ФЯ — это совсем не признак высокоуровневости. Это скорее тоже низкий уровень, но совсем с другой стороны.

Любой ФЯ намного ближе к математике чем С++ а следовательно и уровнем выше.

В С++ такая вещь, как композиция функций, это много-много ручной работы, вагоны темплейтов распиханых по разным уголкам, а в ФЯ это все одной строчкой.

Здравствуйте, alex_public, Вы писали:

I>>Тебе они не нужны, уже давно выяснили.

_>Тот же OCaml мне вполне нравится. )

Ты на нем не пишешь в продакшн Судя по тем вещам, которые ты выдал в разговоре про монады, короутины и async/await ты яростно защищает императивные фичи.

_>И так, появилась идея создать чистый функциональный язык. Для этого надо как-то решить проблему не вписывающихся в эту концепцию обязательных нюансов программирования. Как минимум это "изменение состояния" и ввод/вывод (тоже в общем то состояние, только как бы внешнего мира). В Хаскеле эту проблему решили с помощью выделения всего кода ST/IO в некую специальную резервацию. Кстати, построение резервации выполнено с помощью монадных техник (далеко не единственный вариант) и как раз исключительно это и является причиной такого широкого использования монад в Хаскеле (с этого моего утверждения и началась вся эта дискуссия). Так вот, в результате мы получили внутри Хаскеля ещё один маленький встроенный язык, причём уже чётко императивный. Естественно он убогонький и неудобный, причём не только по сравнению с самим Хаскелем, но и в сравнение с классическими императивными языками

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

_>Однако если мы вернёмся из академического мира в реальность, то там ситуация становится противоположной. При написание скажем какого-нибудь десктопного GUI, наибольший объём кода у нас становится не в области нормального Хаскеля, а в области того самого убогого императивного подъязыка. Со всеми вытекающими из этого последствиями. И в итоге весь смысл изначальной идей оказывается выкинутым в помойку.

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

Что характерно, если поступать иначе, то в любом языке будет тупой низкоуровневый мусор ближе всего похожий на Си, только более глупый и многословный. Повторяю — в любом.