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

GZ> С# — хороший язык. Там можно писать в любом стиле. А после введения нормального синтаксиса кортежей, стало совсем хорошо.

Использовать c# для type drive development наверно можно, но читать это будет невозможно совершенно. А что может быть хорошего в кортежах вида (int, int) вообще непонятно.

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

PJ>Я лишь вернул тебе твои же аргументы в другой форме.

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

ARK>>Ты привел в цитате ту же фразу, по поводу которой сам же и спрашивал. Ты там чтоль зациклился рекурсивно?
PJ>Так это ты сослался на начало темы.

Да, но это не начало темы.

PJ>>>Так это, прости, чушь. Кто определяет уродство синтаксиса? Мне, лично, уродским кажется синтаксис си, это бесконечные скобки, которые по сути мусор.

PJ>Уродство синтаксиса живет только в твоем воображении. Оно вообще никак на рынок не влияет.

Верь в это и дальше. Терпение и крепкая вера тебе будут нужны в ожидании пришествия царства хардкорного ФП.

А я больше, чем на ИМХО, и не претендую, о чем написал изначально.

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

ARK>Если пушки сразу стали популярными, значит, никакой аналогии с нишевым ФП быть не может.
Сразу? Дислексия что ли? Нет пушки стали не сразу, но стали. Смысл аналогии в том, что натягивание прошлого на будущее не всегда работает.

ARK>Да, но это не начало темы.
Тогда зачем ты на него сослался?

ARK>Верь в это и дальше. Терпение и крепкая вера тебе будут нужны в ожидании пришествия царства хардкорного ФП.
Это ты во что-то веришь. Я просто использую. Мне не требуется ждать сферического будущего.

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

кт>Перевод статьи «Object-Oriented Programming — The Trillion Dollar Disaster»
кт>Рассказывает Илья Суздальницкий, senior full-stack-разработчик

Чувак, пишущий на JS, ругает другие языки и ООП? Серьезно?

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

ARK>>Если пушки сразу стали популярными, значит, никакой аналогии с нишевым ФП быть не может.
PJ>Сразу? Дислексия что ли? Нет пушки стали не сразу, но стали. Смысл аналогии в том, что натягивание прошлого на будущее не всегда работает.

Вот и не натягивай. Это ты тут натягиваешь пушки с машинами. ФП — маргинальная ниша и это не меняется с момента его появления. Можешь веровать в его пришествие послезавтра, я не против.

ARK>>Да, но это не начало темы.
PJ>Тогда зачем ты на него сослался?

Я на него не ссылался, я сослался на начало темы.

ARK>>Верь в это и дальше. Терпение и крепкая вера тебе будут нужны в ожидании пришествия царства хардкорного ФП.
PJ>Это ты во что-то веришь. Я просто использую. Мне не требуется ждать сферического будущего.

Держи в курсе!

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

S>Объект с состоянием и объект с изменяемым состоянием — не одно и то же. Изменяемое состояние для ФП нетипично. Но с хранением неизменяемого состояния никаких проблем в ФП вообще нет. Умеет же ФП работать со строками/списками. В чем проблема взять неизменяемый кусок памяти?

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

BFE>>Это что-то говорит о внутреннем устройстве вычислений? Нет, не говорит. В частности, не обязывает устройство вычислений хранить данные.

S>Как это не обязывает? А что делать с вычислениями, для выполнения которых нужно хранить данные?
В функциональном программировании не нужно хранить данные.

S>Как же на таком языке реализовать машину Тьюринга, собственно, которая хранит данные в ленте?
Никак.

S>Без реализации такой машины доказательство полноты языка становится затруднительным, не находите?
Не уверен, что в доказательстве используется факт хранения.

S>В нормальном определении полнота по Тьюрингу означает возможность реализации машины Тьюринга.
S>

S>In computability theory, a system of data-manipulation rules (such as a computer's instruction set, a programming language, or a cellular automaton) is said to be Turing complete or computationally universal if it can be used to simulate any Turing machine.

simulate != реализовать

S>А машина Тьюринга позволяет хранить данные на ленте.
Но симулятор не обязан хранить данные.

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

ARK>ФП — маргинальная ниша и это не меняется с момента его появления.

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

ARK>Я на него не ссылался, я сослался на начало темы.
Ты сослался на себя в начале тебе и стал удивляться цитате оттуда. С тобой все хорошо?

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

S>Ну... Да, меняет как бы ровно всё. Если ФП-язык Turing-complete, то на нём можно смоделировать Машину Тьюринга.
Смоделировать — это не значит сделать один в один. Это значит, что тот же самый результат можно получить с помощью выполнения функциональной программы и с помощью Машины Тьюринга, если взять те же исходные данные.

S>Берём программу на вашем любимом ОО-языке, сводим её к Машине Тьюринга (а это возможно в силу Тезиса Чёрча), и запускаем на нашей модели МТ, построенной на ФП-языке.

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

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

S>Машина Тьюринга позволяет буферизовать ввод-вывод данных?

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

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

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

S>>Объект с состоянием и объект с изменяемым состоянием — не одно и то же. Изменяемое состояние для ФП нетипично. Но с хранением неизменяемого состояния никаких проблем в ФП вообще нет. Умеет же ФП работать со строками/списками. В чем проблема взять неизменяемый кусок памяти?

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

S>>Как это не обязывает? А что делать с вычислениями, для выполнения которых нужно хранить данные?
BFE>В функциональном программировании не нужно хранить данные.

S>>Как же на таком языке реализовать машину Тьюринга, собственно, которая хранит данные в ленте?
BFE>Никак.
Это опровержение полноты по Тьюрингу всех функциональных языков. Поздравляю с Нобелевкой!

S>>Без реализации такой машины доказательство полноты языка становится затруднительным, не находите?
BFE>Не уверен, что в доказательстве используется факт хранения.
Не уверен, что факт хранения используется и в определении полноты.

S>>В нормальном определении полнота по Тьюрингу означает возможность реализации машины Тьюринга.
S>>

S>>In computability theory, a system of data-manipulation rules (such as a computer's instruction set, a programming language, or a cellular automaton) is said to be Turing complete or computationally universal if it can be used to simulate any Turing machine.

BFE>simulate != реализовать
По буквам — нет. Но в чем отличие?

S>>А машина Тьюринга позволяет хранить данные на ленте.
BFE>Но симулятор не обязан хранить данные.
Кто же обязан, если симулятор не обязан? Каким же образом тогда симулятор симулирует машину Т?

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

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

S>>Машина Тьюринга позволяет буферизовать ввод-вывод данных?

BFE>На Машине Тьюринга можно реализовать буферизацию ввода-вывода данных.
Отлично

BFE>Программа написанная на функциональном языке тоже может реализовать буферизацию ввода-вывода данных
О, уже прогресс наметился. Отталкивались мы от принципиальной невозможности реализовать буферизацию в ФП.

BFE>но для этого потребуется специальное устройство для хранения промежуточных данных. Таким образом композит 'функциональная программа'+'устройство для хранения промежуточных данных' превращается в императивную программу.
И что за загадочное такое устройство нужно для хранения промежуточных данных? Почему же функциональные языки полны без ссылки на специальное устройство для хранения промежуточных данных??

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

ARK>>ФП — маргинальная ниша и это не меняется с момента его появления.
PJ>Судя по всем у некоторых денайл это форма религии.

Где же оно, великое хардкорное ФП? В ядрах операционных систем? В самолетах и марсоходах? В играх? В бизнес-приложениях? В движках гугла и яндекса, быть может? В веб-сайтах? Где? Какая доля от миллиардов программных проектов написана на Haskell/Lisp/ML? Какой процент вакансий на этих языках? Вопросы риторические.

ARK>>Я на него не ссылался, я сослался на начало темы.
PJ>Ты сослался на себя в начале тебе и стал удивляться цитате оттуда. С тобой все хорошо?

Я не "ссылался на себя в начале тебе", что бы эта странная фраза ни значила. Я сослался на начало темы: http://rsdn.org/forum/philosophy/7540923.1

Автор: AlexRK
Дата: 12.09.19

Диалог:

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

Ты испытываешь сложности с интерпретацией смысла этого диалога? Или с пониманием фразы "об этом я уже писал в начале этой темы"?

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

Здравствуйте, B0FEE664, Вы писали:
S>>Ну... Да, меняет как бы ровно всё. Если ФП-язык Turing-complete, то на нём можно смоделировать Машину Тьюринга.
BFE>Смоделировать — это не значит сделать один в один. Это значит, что тот же самый результат можно получить с помощью выполнения функциональной программы и с помощью Машины Тьюринга, если взять те же исходные данные.
Совершенно верно. Вот ровно всё-всё, что делает Машина Тьюринга с некоторыми исходными данными, можно получить с помощью выполнения некоторой функциональной программы.
Включая те моменты, когда МТ выполняет запись на ленту. Иначе бы мы получили МТ, которую невозможно изобразить при помощи ФП, а это противоречило бы тьюринг-полноте ФП.

S>>Берём программу на вашем любимом ОО-языке, сводим её к Машине Тьюринга (а это возможно в силу Тезиса Чёрча), и запускаем на нашей модели МТ, построенной на ФП-языке.

BFE>Так вы сэмулировали функциональный язык на Машине Тьюринга, а надо наоборот, машину Тьюринга сэмулировать на функциональном языке.
Нет. Так я сэмулировал ОО на МТ, а МТ на ФП — получив, таким образом, исполнение ОО-программы на ФП-вычислителе.

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

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

O>>И где тут простота процедурного программирования будет ? Легко будет разбираться в таком коде где будет либо 1000 функций A_ToString() B_ToString() или одна функция с большими ветвлениями.
S>Надо сказать, что в ООП все именно так и устроено. 1000 функций A_ToString() B_ToString(), но перегруженных по типу аргумента неявно. ToString(A), ToString(B). А то, что функции лежат в файле A.cs, B.cs — так никто так же не запрещает и в процедурном программировании писать.

Куда деть полиморфизм ? Вот есть у меня переменная некоего неуточненного типа, как мне узнать, в каком из 1000 модулей лежит нужный toString ?

Для работы с полиморфмными переменными на ходу изобретаются правила, а следовательно — изобретение ООП.

Как только таких переменных становится больше одной, появляются структуры-записи с которыми выполняем строго определенные операции, то есть, мы изобрели типы и нужны правила работы с ними. Опаньки — изобретаем ООП!

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

Теперь от интерфейсов до контрактов осталось совсем немного — закрепить ожидания вызывающего кода. Принцип замещения Лисков он не с потолка взялся.

Теперь у нас, внимание, есть АТД.

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

В итоге изобретаем всё, что давно есть в ООП искаропки.

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

PJ>>>Она очень точно отражает твою уверенность в провале фп.

ARK>>Машины заменили лошадей за 15 лет. ФП не смогло заменить ИП за 70 лет и не видно никаких признаков, чтобы это произошло в обозримом будущем.
PJ>Первый автомобиль с двс появился в 1886 году, лошади как средство передвижения, практически полностью вышли из употребления к середине 20го века. 15 лет чо.

Лошади-мулы-итд, как средство передвижения, используются по сей день. Например, в горах, где для авто и дороги никакой нет. Например, в деревнях. Например у целой кучи народов, которые живут далеко от основной цивилизации. Далее, есть ряд профессии, которые предполагают передвижение на лошади. Например — пастух или лесник.

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

BFE>>Неизменяемый кусок памяти — это константный объект, с ними никаких проблем, только это не буфер, т.к. в буфер можно записывать данные.
S>Да, а неизменяемый список — это не список. Неизменяемое дерево — не дерево, т.к. в список и дерево можно записывать данные, а в неизменяемые — нет. Так, получается?

Что получается?

S>>>Как же на таком языке реализовать машину Тьюринга, собственно, которая хранит данные в ленте?
BFE>>Никак.
S>Это опровержение полноты по Тьюрингу всех функциональных языков. Поздравляю с Нобелевкой!
Здесь нет опровержения. Небелевку не дают за математику

S>>>Без реализации такой машины доказательство полноты языка становится затруднительным, не находите?
BFE>>Не уверен, что в доказательстве используется факт хранения.
S>Не уверен, что факт хранения используется и в определении полноты.
Вот именно.

BFE>>simulate != реализовать
S>По буквам — нет. Но в чем отличие?
Отличие в том, что эмуляция может работать как ей угодно, лишь бы результат совпадал.

S>>>А машина Тьюринга позволяет хранить данные на ленте.
BFE>>Но симулятор не обязан хранить данные.
S>Кто же обязан, если симулятор не обязан? Каким же образом тогда симулятор симулирует машину Т?
Получает тот же результат.

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

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

S>>Надо сказать, что в ООП все именно так и устроено. 1000 функций A_ToString() B_ToString(), но перегруженных по типу аргумента неявно. ToString(A), ToString(B). А то, что функции лежат в файле A.cs, B.cs — так никто так же не запрещает и в процедурном программировании писать.

I>Куда деть полиморфизм ? Вот есть у меня переменная некоего неуточненного типа, как мне узнать, в каком из 1000 модулей лежит нужный toString ?
Что за неуточненный тип в процедурном программировании? Полиморфизм функций там есть, а полиморфизма типов — нет.

I>Для работы с полиморфмными переменными на ходу изобретаются правила, а следовательно — изобретение ООП.
Полиморфные переменные в ПП? Это шутка?

Далее ответы в том же духе.

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


BFE>>но для этого потребуется специальное устройство для хранения промежуточных данных. Таким образом композит 'функциональная программа'+'устройство для хранения промежуточных данных' превращается в императивную программу.
S>И что за загадочное такое устройство нужно для хранения промежуточных данных?
Буфер.

S>Почему же функциональные языки полны без ссылки на специальное устройство для хранения промежуточных данных??
Да потому, что полноты хранение промежуточных данных не требуется.

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

кт>Перевод статьи «Object-Oriented Programming — The Trillion Dollar Disaster»
кт>Рассказывает Илья Суздальницкий, senior full-stack-разработчик

кт>По мнению многих, ООП является жемчужиной информатики. Идеальное решение для организации кода. Конец всем проблемам. Единственный верный способ написания программ. Дарован нам самим истинным Богом программирования.
кт>Но это не так. Люди начинают уступать под тяжестью абстракций и сложного графа беспорядочно разделяемых изменяемых объектов.

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

Вообще, не совсем ясно, почему функциональное противопоставляется ООП.

Каждый взрослый язык общего назначения имеет слоёную архитектуру.

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

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

На верху, соответсвенно, или модульное программирование, или его развитие, ООП.

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

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

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

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

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

S>>Объект с состоянием и объект с изменяемым состоянием — не одно и то же. Изменяемое состояние для ФП нетипично. Но с хранением неизменяемого состояния никаких проблем в ФП вообще нет. Умеет же ФП работать со строками/списками. В чем проблема взять неизменяемый кусок памяти?

BFE>Неизменяемый кусок памяти — это константный объект, с ними никаких проблем, только это не буфер, т.к. в буфер можно записывать данные.

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

Вот возьмем C#

string s = "";
for( int i =0; i < 100; ++i ){
  s += ReadDataPart();
}
s = s.Substring( s.length / 2 );

Логически — тут постоянно меняется содержимое в строке s. А технически — нет, не меняется, строки неизменяемы в C#.

А если взять код

string s = GetHalf( FillString( "", 100 ) );

//...

string GetHalf( string s ){
   return s.Substring( s.length / 2 );
}

string FillString( string s, int count ){
  if( count == 0 ){
    return s;
  }
  return FillString( s + ReadDataPart(), count - 1 );
}

То мы избавимся еще и от изменяемых переменных. А суть кода осталась та же — накопить длинную строку и отрезать от нее половину.