На С/С++ легко писать функционально.

Давай теперь программу, которая фигачит инструкции в рандомном порядке.

Нет, я же за Палестину.

applegame, ясно-понятно, ты таки достиг уровня Серёжи. Не планируешь в Израиль переехать?

Это доказывает, что ты
1) не читаешь, что тебе пишут
2) не пытаешься понять, что тебе пишут
3) не разбираешься в том, о чём пишешь
4) продолжаешь с завидным упорством игнорировать факты

Опровергайте.

Правда хз, что это докажет.

Давай, расскажи ещё про порядок в do-выражении.

Не коррелируют.

Кстати в Erlang/Elixir нет мутабельных переменных, но полно функций с побочными эффектами. Значит таки можно писать императивно (по вашему определению) без мутабельных переменных?

Значит таки можно писать императивно (по вашему определению) без мутабельных переменных?

Последний - ИП, первые два ФП.

Откуда такой вывод? Почему все, если я говорил о хаскельном IO, в том числе и о монаде IO?

Раз возможно IO, значит возможны функции с побочными эффектами.

Потому что парадигма не может измениться если не меняется код Очевидно же.

Пример чего?

В чистой ФП-композиции порядок может быть любым, уже обсуждали и ты вроде согласился. Опять по кругу?

Ага, а то что эти критерии коррелируют с порядком стейтментов в do-нотации - это просто совпадение?

Какой из этих примеров — чистая композиция функций (например, на Хаскелле), а какой — императивная последовательность statement'ов (например, на Паскале)?

IO не имеет отношения к языку. Они разделены.

Не имеет. Тебе уже пример приводили.

всего-то wiki на сайте языка, наполняемая и модерируемая сообществом хаскеллистов.
При этом и Haskell Report не пишет ни о какой «последовательности инструкций».

Э нет, это чистая правда и просто факт. Но ты скатился до уровня Серёжи, ему тоже тыкали фактами в нос, а он продолжал витать в своих фантазиях.

а все другие монады, прячущие свои внутренности тоже в каком-то сговоре?

Порядок «вызова» IO-функций задаётся обычной чистой функциональной композицией.

Нет. Критерием вычисления является конкретная монада, используемая в do-выражении.

Не исключаю, а делаю необязательным. Не надо искажать.

В чистом ФП (идеальном) в коде нет явных промежуточных результататов, даже иммутабельных

В императивном коде такой фокус не прокатит.

Не все. Иначе IO был бы просто невозможен.

do-нотация имеет отношение к последовательности инструкций. Об этои говорит название нотации (do) и название её элементов (statements).

Некоторые авторы пытаются зачем-то откреститься от этого. Например в пресловутой статье: https://wiki.haskell.org/Do_notation_considered_harmful написано:

Что в общем случае является ложью.

Каждая IO-функция получает в качастве параметра, условное состояние внешнего мира, полученное из предыдущей IO-функции, делает IO и возвращает измененное состояние. НО! Если, допустим, функции чтения символа с клавиатуры подсунуть несколько раз одно и то же состояние мира, то она запросто может вернуть разные значения. Чтобы такого не происходило, в Хаскеле IO-функции вместе с сотоянием мира плотно завернуты в монаду, и остальные функции не имеют доступа к этому состоянию и, соответственно, не могут заставить IO-функцию вызваться с одним и тем же состоянием.
Получается, что IO-функция как хитрожопый коррупционер: все знают что делишки грязные, но нет никакой возможности доказать это в рамках языка, формально все чисто. А все потому что все коррупционеры (IO-функции) в сговоре и никому, кроме как друг-другу, свои внутренние дела не раскрывают.
Но они все равно с побочными эффектами, иначе порядок их вызова был бы не важен. Тем они и отличаются от обычных функций.

Но ведь если бы там были IO-функции с побочными эффектами, То the order of statements очень даже был бы the criterion for the evaluation order

immutable a = foo(x)
if(a == 0) return 1;
immutable a1 = a + bar(a);
if(a1 == 1) return 2;
return 3;

В Хаскелле все функции чистые

и do-нотация, как и монады, не имеют отношения к чистоте.

The order of statements is also not the criterion for the evaluation order. Also here only the data dependencies count.

А если так?

То же самое и в do-нотации Haskell.

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

x = 3
y = x + 1
z = y + 2

z = y + 2
y = x + 1
x = 3

Если мы убираем побочные эффекты и изменение состояния (на уровне семантики языка), то это все становится лишь деталью реализации.

И какая нам польза в этом знании?

По поводу Rust. А вот этот вот Cell - это же не конструкция языка, а элемент стандратной библиотеки. Он внутри unsafe?

Можно, конечно скатываться в терминологическую демагогию, как это делаешь ты: ну типа раз в определении ИП написано "мутабельный", значит ответ очевиден: низзя. А на остальное насрать.

Отсюда делаю. вывод: "конвенционально принятое" определение ИП устарело. Ключевое - это последовательность инструкций

Не не понимаю, я ничего кроме hello world никогда не писал

Математически доказано, что невозможно проверить зависнет программа или нет. На этом можно остановиться.

Программа должна работать на компьютере, который не умеет считать?

За const парятся в обязательном порядке.

Поэтому в ИП последовательность инструкций важна, а в ФП нет.

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

даже если функции считать чистыми, все равно, в определенном смысле, имеет мутабельный стейт. Условно говоря - это контекст (в лице стека, например). В третьей строке в контексте появилась новая переменная a1 - считай мутировал стейт. Какая по сути разница: в коробке лежал синий кубик, мы вытащили его и положили вместо него красный кубик или лежал синий, а красный мы положили рядом? Один фиг содержимое коробки (стейт) изменилось.

Если нет побочных эффектов, то последовательность действий фактически важна лишь с точки зрения корректности вычислений. А тут нет никаких отличий от ФП.

Ты не объясняешь, а приводишь странные примеры, в основном Как и ниже, собственно.

Зависит от наличия побочных эффектов

Нет. А ты похоже из тех, кто думает что иммутабельность - это про языки.

Так если оно так и есть?

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

Теперь это функциональщина?

Опять начнешь растекаться мыслью по древу, что тут нельзя точно сказать, что это смесь разных парадигм и так далее? :lol:

Ты похоже один из тех, кто думает, что const в C/C++ - это и есть иммутабельность. :lol:

А ещё есть шутка, что Хаскелл --- это лучший императивный язык.
https://wiki.haskell.org/Do_notation_considered_harmful

А если б не было побочных эффектов?

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

Впрочем, давай рассмотрим твой кусок:

Так ты же выше отказался от общепринятого определения ИП, убрав оттуда изменение состояния. Откуда тогда побочные эффекты? До сих пор не понимаю, чем тебе не нравится "обычное" определение ИП.

Почему первое предложение про тебя, а второе про всех?
Вот ты и не парился, когда писал

За const парятся в обязательном порядке.

Да даже на системном уровне попадается что-то в духе RCU, например

Именно в таком виде нет, т.к. если бы было можно, то легко было бы нарушить правило BC "на объект есть только одна mut ссылка". Но тем не менее это не иммутабельность, т.к. ничто не мешает менять объект, на котором нет mut, посредством Cell:

Criticism
Haskell's do notation is popular and ubiquitous. However we shall not ignore that there are several problems. Here we like to shed some light on aspects you may not have thought about, so far.

Didactics
The do notation hides functional details. This is wanted in order to simplify writing imperative style code fragments. The downsides are that:

- Since do notation is used almost everywhere IO takes place, newcomers quickly believe that the do notation is necessary for doing IO,
- Newcomers might think that IO is somehow special and non-functional, in contrast to the advertisement for Haskell being purely functional,
- Newcomers might think that the order of statements determines the order of execution.

Я писал много и на Си и на C++. Никто на парится иммутабельностью вообще.

За счет побочных эффектов, очевидно.

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

Я писал много и на Си и на C++. Никто на парится иммутабельностью вообще.

"Не имеет значения" и "отсутствует" --- не одно и то же

Не обязательно. И do-нотация не завязана на монаду IO, она работает с любой монадой, например монадой списков:

За счёт чего же результат может измениться? )

А за счёт чего наблюдаемый результат может измениться?

Это в первом случае, где у функций разные типы. А во втором? Там всё прекрасно скомпилируется. А результат поменяется?

В GHC задан, в другом компиляторе может быть не задан. Ты же надеюсь понимаешь, что мы обсуждаем не конкретные реализации, а ФП в целом? Ты же сам признал, что порядок вычисления аргументов функции в ФП не имеет значения.

Как минимум она означает, что foo будет выполнена раньше чем bar. Вся эта ваша монада IO для этого и предназначена: дать возможность в Haskell выполнять код последовательно, потому что IO - это связь с внешним миром, который императивен.

Результат может измениться. А вот в чистом ФП (например Хаскеле) ничего измениться не может.

Ключевое тут "не изменяет наблюдаемый результат"

Если поменять местами строчки, оно просто не скомпилируется.

В чём тут трешевость и костыльность?

И что, что это деталь реализации? Порядок задан? Задан.

Нет, это то, чем она является.

Что, по-твоему, означает эта запись:

И что, что она выполнена до? Что будет, если поменять их местами? Чем по-твоему это отличается от Хаскелла, например? Чем это отличается от ФП, если реальное вычисление может быть выполнено в любом порядке?

Ответь лучше на вопрос: почему в ИП порядок имеет значение? Что будет, если в
поменять местами вызовы foo и bar:?

И ещё вопрос: для ФПшной композиции порядок важен?

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

Это же трешовый костыль

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

надо понимать, что это просто деталь реализации

Судя по тому, что я нашел в интернетах, Haskell не запрещает реализации вычисляющие операнды в любом порядке.

То что do-нотация является сахаром к монаде - это не семантика, это детали реализации

Семантика же заключается в последовательном выполнении

И do-нотация, кмк, отходит от ФП в сторону ИП.

Пример с Promise неудачен, функция foo-то все равно выполнена до начала выполнения функции bar.

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

В моём примере нет списка.

Странный вопрос. Для чистого ФП разницы нет (разве что одна из функций bar, baz значительно дольше вычисляется, чем другая).

И вот ты снова путаешь синтаксис и семантику.

foo вычислится гарантировано до вызова bar при аппликативном порядке вычислений (а это все неленивые ФП языки, F#, Ocaml, Clojure и т.д.)

может вычислиться в другом порядке при нормальном порядке вычислений или просто отложенных вычислениях, например, в Си/Паскале foo может вернуть какой-то объект Promise.

Вообще-то нет.

Этож одна из фишек этого вашего ФП, типа смотрите, компилятор может все нафиг распараллелить.

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

На первый взгляд кажется, что разницы нет, но на самом деле есть. В императивном варианте функция foo будет выполнена до начала выполнения функции bar. В функциональной же версии foo может быть выполнена уже после начала выполнения bar (например в середине или даже паралелльно), да и вообще пофиг когда она выполнится. Мысли абстрактней, в ФП композиция функций - это просто новая функция, а не последовательность вызовов функций.

Да не, там отличные, на мой взгляд, статейки. Там прекрасно описаны достоинства и недостатки связных списков в том числе по сравнению с массивам. И вообще, рассмотрена туева хуча всяких видов списков, включая xor и unrolled варианты, на доступном английском языке с картинками. Даже дебил осилит. Инфа представленная там никак не противоречит твоим бенчам, скорее наоборот, объясняет почему так может происходить.

Аргументации чего? Ты выкинул из конвенционально принятого определения ИП половину, а аргументы какие-то должен приводить я?

Смотри, это зависит от определения императивности. Ты же пытаешься наоборот , из примера вывести определение. Или я тебя не понимаю.

А если б у бабушки...

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

Есть и она точно такая же: очередной элемент будет проверен после предыдущего.

Присутствует: нельзя вычислить значение функции, не вычислив её аргумента.

А LinkedList нужен когда ды ты считываешь данные неопередельной длины, особенно большие обьемы,

хватит тут теории разводить,с умным видом

1) Ты сам реализуешь так как тебе нужно, теоретик млин

Это если не надо память реалацировать

и машина мощная ,

на размер обьекта + 24байта
изучай

Так что я бы на твоем месте перестал аппелировать к авторитетам, и к Страуструпу в частности.

Если забить на грязность main, то да: вполне себе ФП.

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

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

Порядок действий никак не прописан в этом примере и не имеет никакого значения.

В ФП порядок действий как таковой отсутствует.

Так что я бы на твоем месте перестал аппелировать к авторитетам, и к Страуструпу в частности.

а приступишь непосредственно к аргументации? :)

ФП тоже получается, по-твоему, бесполезно?

Это имеет значение для парадигмы

Может ты считаешь что мой пример на D и корвиновский на Haskell написаны в одной и той же парадигме (ФП или ИП)?

Что мой пример не императивен?

ты пытаешься смешать парадигмы, программы и исполнителей этих программ

Я же как раз таки пытаюсь абстрагироваться от всего, кроме непосредственно парадигмы.

Это имеет значение для парадигмы.

А в комитете выступает как тормоз прогресса, блокируя современные тенденции ЯП.

И что? Ты опять пытаешь языки и парадигмы?

Ну это ты молодец. Но это ничего не говорит о верности твоей демаркации.

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

Проблема в том, что это не имеет значения для данного кода.

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

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

Программа на C/С++/D это тоже просто функция. Она даже может быть чистой, просто возвращая int в качестве результата.

Я обычно пишу в гибридном стиле и избегаю ненужной мутабельности

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

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

— это композиция функций? ФП, значит?

Это общепринятое определение.

А почему? И какой толк от последовательности инструкций, если мы убираем изменение состояния?

Но это просто функция.

Программу-то полноценную если ты начнешь писать без мутабельности, то не скатишься ли ты к функциональному стилю, по сути?

applegame, чем это:


отличается от

?

А LinkedList умножает память на 3.

и сравни с вектором

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

queue когда в минуту приходит 15-20 тыс обьетов, массивом не сделаешь.