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

Эммм, я думал тут всем очевидно, что чистота, иммутабельность и т.п. ортогональны функциональности языка. Да, приходим к основному вопросу философии - что есть ФП?

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

О, знаток CS пожаловал со своим взрослым определением :) А что бета-редукция лямбда-термов может выполняться по нормальной/аппликативной/смешанной/прочими стратегиями мы скромно умалчиваем? Но ведь именно в этом и состоят различия ленивых и строгих ФЯ, колл бай нид/бай валью/бай нэйм и «прочая ахинея» (С). Так что, каковы бы ни были альтернативные больные фантазии и детские понты критиков, но возможность генерировать лямбда-термы для последующей редукции вполне себе имеет право быть критерием функциональности языка.

возможность генерировать новые значения этого типа в качестве возвращаемого значения функций

Это автоматически подразумевает карринг.

(define (bind1st f x)
    (lambda args (apply f (cons x args))))

Где мне тут понадобился карринг?

с приходом лямбд по моему определению становится функциональным

На самом деле, смысл не в лямбдах как таковых, а в том, что функции — первоклассные объекты, они не обязаны быть безымянными, это на семантику вообще не влияет. Хотя, как я уже ранее отметил, это не имеет отношения к «ФПшности» языка. Да и само по себе определение первоклассности объектов, имеет смысл рассматривать только с точки зрения конкретного языка, потому что можно пойти дальше и сказать, например, что в лиспе функции не являются первоклассными объектами с точки зрения понятия «объект» в ООП, есть языки, где лямбды помимо того, что могут быть аргументами, присваиваться, добавляться в структуры данных и тп, являются еще и частным случаем(подтипом или сабклассом) настоящих объектов, имеют поля/слоты, индивидуальное поведение, наследуются, принимают и отсылают сообщения и тп.

utf8nowhere, я подозреваю, что оратор хотел сказать «имея такую функциональность, можно реализовать карринг», что очевидно. Более того, карринг по любому порядку аргументов, а не как известно где.

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

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

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

Есть различные стратегии вычисления в рамках ФП, но не понимаю, каким образом это должно отменять тот факт, что ФП — подстановочная модель.

Ты правильно понял.

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

Так я и не посягаю на отмену этого факта. Но лямбда исчисление тьюринг-полно, а значит на нем можно нарисовать все привычные абстракции, с высоты которых будет не видна та подстановочная модель, а будет видно мутабельное состояние, например. Тут к другому придирались - к критерию «функциональности» конкретного языка. Такому, чтобы можно было вот так взять конкретный язык и проверить. И несмотря на то, что по предложенному критерию однозначно и бесспорно отпал С и припал Питон, все равно он не устроил критиков :)

Да, согласен

Если рассматривать настоящее ООП

Разговоры на уровне «чья религия более правильная».

Но лямбда исчисление тьюринг-полно, а значит на нем можно нарисовать все привычные абстракции,

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

Это так, к сведению

В рамках этих моделей честный рандом конечно не выразить. Модель замкнута в себе и не имеет внешний мир в своем составе. А язык может запросто иметь команду запросить температуру процессора, откуда из последнего 20-го знака его и получать. Тут еще мне кажется интересным другой вопрос. В обоих моделях можно нарисовать новые абстракции и создать новые языки с новой семантикой. Я вот накостылил схемоподобный язык (функциональный, но с мутабельным окружением) и на хаскеле (функциональном чистом иммутабельном) и на джаве (императивном мутабельном). Но тут имхо нельзя говорить о расширении языка и семантики - а только о создании нового другого языка с другой семантикой. Тот же хаскель сначала в С транслировался да и вообще все языки в ассемблерные команды. Но тогда и надо говорить об абстрактной семантике выбранного языка, а не о том, каких расширений можно добиться за счет библиотек.

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

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

Есть мнение, что IO не противоречит чистоте и иммутабельности.

Это странное мнение

Почему же?

потому что если ты можешь куда то писать, и оттуда же читать, ты де-факто уже имеешь изменяемое состояние.

Твоей функции суют под нос список символов. Она достаёт оттуда один символ и возвращает пару (символ, хвост списка).

Это что, не чистая функция?

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

де-факто уже имеешь изменяемое состояние

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

Вы же знаток CS. Любая хаскельная функция возвращает одинаковый выход на одинаковом входе. Вопрос что считать входом.

эта может быть и чистой, тут это не при чем.

Как не при чём, если я практически описал getChar? Как видишь, он вполне себе чист.

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

Эта демагогия позволила написать хаскель как таковой, оставив его чистым ФЯ даже с учетом ИО. И то что для человеческого сознания демагогия, для компилятора вполне себе модель работы.

И если «она принимает и возвращает» - то она чистая. И это не демагогия и работает в любых парадигмах как чистая функция.

с этой точки зрения, любой ООП язык является столь же чистым как и хаскель, на считая некоторых конвенций и сахара. По-сути, так оно и есть, собственно

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

Для компилятора — бесспорно, но мы говорим о сементике

любой ООП язык является столь же чистым как и хаскель

Если все изменения объектов протаскивать через входящие параметры и выходные значения функций - то да, так оно и есть. Один эпатирующий неподготовленную публику джавист в своем блоге http://www.yegor256.com/ проповедует именно этот подход и тезис :)

Даже безо всяких если, просто это, почему то, с трудом воспринимается. Если говорить о чистом ООП, где все есть объект, то любое значение есть такой же контейнер как и монада. Например, какой нибудь 1 у тебя на самом деле {type: Number, value: 1}, и ты меняешь лишь value, а объект у тебя тот же самый, проблема в примитивных типах данных, они всю картинку портят и вводят в заблуждение.

тот же самый, только с измененным содержимым.

Так «тот же самый», или «с изменённым содержимым»? Лол.

Это демагогия, не более того.

Нет, это чистый IO.

Тот же самый, с измененным содержимым. В чем вопрос?

В чем вопрос?

У тебя шиза?

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

с этой точки зрения, любой ООП язык является столь же чистым как и хаскель

ВНЕЗАПНО! Это то, о чём нам тезис Чёрча-Тьюринга говорит.

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

Хорошо, хорошо. Тот же самый, с изменённым содержимым. Чёрный — это белый, с изменённым содержанием чёрности.

Ты, главное, не нервничай.

Чёрный — это белый, с изменённым содержанием чёрности.

скорей, черный — это всегда черный с изменяемым содержимым черно-белости

Приведи реальный пример, когда это не так.

Т.е. обоснований нет?

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

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

Касательно монад. Они достаточно хорошо оптимизируются. То, что на Scala или Java было бы действительно тормозом и создавало бы до фига объектов в куче, в случае компилятора хаскеля благодаря ссылочной прозрачности может быть достаточно хорошо оптимизировано, включая монады. Даже трансформеры хорошо оптимизируется, если для них используются прагмы инлайнинга.

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

Многие люди находят код с лямбдами более читабельным.

Оно как-то эффективнее работает, чем лупы, или что?

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

Ну может это я тупой. Мне никак не влазит в голову все эти неизменяемые переменные и прочие быстрые сотрировки в одну строку. Все равно все скатываю к аккумулятором и буду писать на хацкеле в императивном стиле :D

т.к. в отдельных случаях

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

Представь себе обновление участков кода без остановки его функционирования. Может ли такое java?

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

По работе пишу на Scala. Девелоперскую тулзу как-то сделал на Haskell.

У тебя проблемы с логикой, дорогой анонимус.

в C++ нет паттерн-матчинга

https://github.com/solodon4/Mach7

https://github.com/jbandela/simple_match