Что делать с жунами , Что делать с жунами

[Qraizer]

Цитата applegame @ 23.04.21, 15:01

Возможно ошибаюсь, но вроде именно он зарубил нормальный static if.

А чем if constexpr не устраивает? Я, кстати, пока ни разу не пользовался, так что моё мнение может быть необъективным, но-таки заявлю, что коли зарубил, значит были причины. Концепты, вон, тоже зарубили в своё время, зато сейчас они выглядят логичнее и понятнее. Та и std::filesystem нонешный мне нравится куда как сильнее по сравнению с начальной редакцией, слизанной с буста. Зато спешка с принятием std::wstring_convert и std::wbuffer_convert сказалась весьма неприятно. Я поначалу вслед за Wound тоже был разочарован отказом от него, но проведя собственное "расследование", склоняюсь к тому, что буду скорее на стороне отмены.

Добавлено 28.04.21, 12:38

Цитата applegame @ 24.04.21, 18:01

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

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

Добавлено 28.04.21, 12:45

Цитата applegame @ 24.04.21, 18:01

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

Точно? Я бы определил императивность как метод, описывающий однозначную последовательность инструкций по получению результатов из входных данных. В отличие от декларативности, наиболее простым примером чего можно привести язык скриптов make. Одним из синонимом императивности является категоричность. По этому критерию ФП не ортогонально ИП, а является его более частным случаем, с дополнительными ограничительными методиками.

Добавлено 28.04.21, 12:49

Цитата sergioK @ 25.04.21, 21:02

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

Предлагаю перейти к решению квадратных уравнений.

Добавлено 28.04.21, 12:53

Цитата scrambrella @ 26.04.21, 07:41

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

Ну вот, а вы на sergioK-а наезжаете. sergioK нормальный парень.

Цитата scrambrella @ 26.04.21, 07:41

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

Ужос, правда?

Добавлено 28.04.21, 12:56

Цитата D_KEY @ 26.04.21, 16:02

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

Только его рассматривают не как декларацию иммутабельности, а как утверждение контракта. Как бы есть разница между гарантией и обещанием.

Добавлено 28.04.21, 13:03

Цитата applegame @ 27.04.21, 09:59

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

В догонку себе. Это следствие тех дополнительных качеств ФП, а не собственно базовое его отличие от ИП. Оно там просто всегда применимо. Я могу себе представить и в ИП то же самое, но конечно далеко не всегда, а в весьма частных случаях. Хотя тут от компилятора зависит, Intel C++, например, умеет раздербанивать всю программу целиком, и неважно, из скольких единиц трансляции она состоит. Запастись памятью и временем надо лишь.

[Pavia]

Цитата Qraizer @ 28.04.21, 12:34

Ну вот, а вы на sergioK-а наезжаете. sergioK нормальный парень.
Цитата scrambrella @ 26 апреля, 10:41
Программа должна работать на компьютере, который не умеет считать?
Ужос, правда?

На работающем не могут правильно сделать расчёты.
Плохой софт отправил работников почты за решетку
https://habr.com/ru/company/itsoft/blog/554404/
Джанет Скиннер рассказывает, что её разлучили с двумя детьми на девять месяцев, в течение которых она находилась в тюрьме, после того, как Horizon показал недостачу в £59,000. Она также сообщает, что потеряла предложение о работе из-за своей судимости. Время, проведенное ею и другими в тюрьме, невозможно вернуть, и это произошло, потому что программе доверяли на слово.

[OpenGL]

Цитата Qraizer @ 28.04.21, 12:34

Припоминаю спор о видах полиморфизма.

Ссылка есть?

Добавлено 28.04.21, 14:02

Цитата applegame @ 28.04.21, 09:40

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

Да, Cell, RefCell и остальное юзают внутри unsafe.

[Qraizer]

Цитата sergioK @ 22.04.21, 22:48

Что за ролик то про столицу IT ?

IT-Столица России. Таганрог

[Qraizer]

Цитата OpenGL @ 28.04.21, 13:57

Ссылка есть?

Та где-то тут в Холиварах. Поди найди, при неработающем поиске-то.

[applegame]

Цитата D_KEY @ 28.04.21, 11:18

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

Так это будут уже детали реализации. А нам важен код, а не реализация исполнителя этого кода.

Цитата D_KEY @ 28.04.21, 11:18

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

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

Цитата

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

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

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

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

Цитата

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

В императивном коде такой фокус не прокатит.
В D в принципе возможно писать в аналогичном ФП-стиле при помощи лямбд:

alias z = () => y() + 2;
alias y = () => x() + 1;
alias x = () => 3;

Забавно, но в C/C++ это можно это сделать, используя макросы. Вот такое ФП (причем полиморфное, все по-взрослому ):

#define z (y + 2)
#define y (x + 1)
#define x 3

C++ - лучший ФП-язык.

Цитата D_KEY @ 28.04.21, 11:18

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

Не совсем понимаю, что значит "убираем изменение состояния на уровне семантики языка". Пример можно? В ИП промежуточные результяты создаются явно в коде, в виде переменных, в том числе иммутабельных. Если в коде явно не создавать промежуточных результатов, то наверное получится ФП.

Цитата korvin @ 28.04.21, 12:04

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

Польза большая: нам не нужно знать чистые эти функции или нет, просто считаем, что инструкции выполняются друг за другом.
Например в том же Erlang/Elixir вообще нет понятия чистоты функций. Они могут быть чистыми или грязными - пофиг. То же самое и в do-нотации Haskell.

[korvin]

Цитата applegame @ 29.04.21, 09:31

Польза большая: нам не нужно знать чистые эти функции или нет

Мы знаем, что они чистые.

Цитата applegame @ 29.04.21, 09:31

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

В Хаскелле все функции чистые и do-нотация, как и монады, не имеют отношения к чистоте.

[Qraizer]

А если так?

auto x = []{ return 3; };
auto y = []{ return x() + 1; };
auto z = []{ return y() + 2; };

[applegame]

Цитата korvin @ 29.04.21, 10:06

Мы знаем, что они чистые.

Если знаем, то ИП можно не применять. ИП полезно тем, что не нужно знать. Ты можешь знать если хочется, но тебе это не нужно, пусть об этом знает компилятор.
От твоего знания чистые это функции или нет ИП не превращается в ФП и наоброт. Парадигма кода зависит от семантики языка, и собственно самого кода. От твоего знания что функции bar и foo чистые, ИП код

Цитата

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

не станет внезапно ФП.

Цитата korvin @ 29.04.21, 10:06

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

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

Цитата korvin @ 29.04.21, 10:06

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

Да, монады упрощают построение цепочек вызовов функций со скрытым внутренним состоянием.
do-нотация имеет отношение к последовательности инструкций. Об этои говорит название нотации (do) и название её элементов (statements).
Некоторые авторы пытаются зачем-то откреститься от этого. Например в пресловутой статье: https://wiki.haskell.org/Do_notation_considered_harmful написано:

Цитата

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

Что в общем случае является ложью. В качестве примера там берутся чистые функции. Но ведь если бы там были IO-функции с побочными эффектами, То the order of statements очень даже был бы the criterion for the evaluation order, при том что никаких явных data dependencies может вообще не быть.

Добавлено 29.04.21, 14:25

Цитата Qraizer @ 29.04.21, 12:52

А если так?

auto x = []{ return 3; };
auto y = []{ return x() + 1; };
auto z = []{ return y() + 2; };

Так не нужно. Вот если бы можно было так:

auto z = []{ return y() + 2; };
auto y = []{ return x() + 1; };
auto x = []{ return 3; };

то было бы нунифигасебе.

[korvin]

Цитата applegame @ 29.04.21, 14:19

не станет внезапно ФП.

Почему это?

Вот этот код тоже императивный:

foo() +
bar() +
gee() +
qux()

?

А этот:

foo() >>
bar() >>
gee() >>
qux()

?

Может, этот:

foo() ;
bar() ;
gee() ;
qux()

?

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

Цитата applegame @ 29.04.21, 14:19

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

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

Цитата applegame @ 29.04.21, 14:19

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

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

Цитата applegame @ 29.04.21, 14:19

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

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

Цитата applegame @ 29.04.21, 14:19

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

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

Цитата applegame @ 29.04.21, 14:19

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

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

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

Добавлено 29.04.21, 19:12

Цитата applegame @ 29.04.21, 14:19

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

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

Сообщение отредактировано: korvin - 29.04.21, 19:13

[D_KEY]

Цитата applegame @ 29.04.21, 09:31

Цитата D_KEY @ 28.04.21, 11:18

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

Так это будут уже детали реализации. А нам важен код, а не реализация исполнителя этого кода.

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

Добавлено 29.04.21, 19:38

Цитата applegame @ 29.04.21, 09:31

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

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

Цитата

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

Да почему это важно, если видимый результат никак от этого не зависит?

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

Добавлено 29.04.21, 19:45

Цитата applegame @ 29.04.21, 09:31

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

Аналогом того кода на haskell в С++ будет:

int x()
{
    return 3;
}
 
int y()
{
    return x() + 1
}
 
int z()
{
    return y() + 2;
}

Для перестановки достаточно заранее объявить функции:

int x();
int y();
int z();

И инструкции тут ни при чем, это особенности областей видимости имен.

Сообщение отредактировано: D_KEY - 29.04.21, 19:45

[applegame]

Цитата korvin @ 29.04.21, 19:11

Почему это?

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

Цитата korvin @ 29.04.21, 19:11

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

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

Цитата korvin @ 29.04.21, 19:11

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

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

Цитата korvin @ 29.04.21, 19:11

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

Пример чего?

Цитата korvin @ 29.04.21, 19:11

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

Опять апеллирование к авторитету.

Цитата korvin @ 29.04.21, 19:11

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

Понеслась волшебная аргументация. Я не знаю как тебе уже объяснять. Если по-твоему вот тут результат не зависит от порядка стейтментов, то я хз кто тут больше похож на Сирожу

main = do
  putStrLn "str1"
  putStrLn "str2"

Цитата korvin @ 29.04.21, 19:11

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

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

Цитата korvin @ 29.04.21, 19:11

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

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

Цитата korvin @ 29.04.21, 19:11

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

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

Ладно, походу этот холивор порвался.
Лично мне надоело.

Сообщение отредактировано: applegame - 29.04.21, 19:56

[scrambrella]

Функциональное и логическое программирование - единственно верные стили. ООП и ИП в топку. На С/С++ легко писать функционально.

[applegame]

Цитата D_KEY @ 29.04.21, 19:26

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

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

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

То мне не о чем больше с вами спорить.
Делаем функции foo и bar чистыми, и опаньки - это ФП код, делаем с побочными эффектами и снова ИП
Ну ок, оставайтесь при своем мнении.

Сообщение отредактировано: applegame - 29.04.21, 19:53

[D_KEY]

Цитата applegame @ 29.04.21, 19:46

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

main = do
  putStrLn "str1"
  putStrLn "str2"

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