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

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

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


O>>>>Представим нам нужна функция которая будет описывать объект в строковом виде, ну т.е ToString().
S>>>Объект?!?!?! В процедурном программировании? Интересно.

O>>А что тут не понятного , тут единственный вариант функции string ToString( MyType type)
S>Вопрос не про вариант, а про объект в процедурном программировании. Что это такое?
Ну очевидно же сложный тип с полями.

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


O>>Функции разбросать по файлам еще не достаточно будет, нужно еще контролировать API чтобы не дай бог кто-то не назвал и не опечатался вместо H_String не напечатал N_Stling как минимум, в ООП это уже рестрикшен из коробки. Второе это то что не всегда нужно делать новую функцию, также как ToString() в шарпе реализует вывод названия типа. Как это будет в процедурном ? A_String, B_String, Other_String ? сидищь ищещь среди 1000 функций нет ли той которая тебе нужна и не опечатались ли в ее названии.
S>Перегрузку процедур и функций в процедурном тоже не запретили. Работает же перегрузка операторов! Чем процедуры хуже?

Так я тебе написал только что — неумышленная очепятка и все ищи свищи функцию , кто будет контролировать это. В ООП контролируется на уровне компиляции, уже удобнее. Ты знаешь что ToString() везде будет ToString() а не иначе.

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

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

O>Так я тебе написал только что — неумышленная очепятка и все ищи свищи функцию , кто будет контролировать это. В ООП контролируется на уровне компиляции, уже удобнее. Ты знаешь что ToString() везде будет ToString() а не иначе.

В общем случае в ООП ничего не конролируется при компиляции. В C# есть override, в Java и C++ — нет. Там ровно так же можно неумышленно ошибиться.

O>Чем процедуры хуже ? Тоже же написал , про базовую реализацию, как ты будешь искать функцию которая работает для нужного тебе типа.

С помощью IDE — она покажет функцию с наиболее точным типом.

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

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

S>Вот это новость! Прямо-таки в принципе невозможно?

Ну а как? Буфер с данными — это явное хранение состояния программы, которое функциональное программирование не предполагает.

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

BFE>Ну а как? Буфер с данными — это явное хранение состояния программы, которое функциональное программирование не предполагает.

Неверняка монада для ентих целей существует -- что-нибудь типа IO.

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

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

S>>Вопрос не про вариант, а про объект в процедурном программировании. Что это такое?
O>Ну очевидно же сложный тип с полями.
Для процедурного программирования это не очевидно. Если подразумевается структура, то ей, внезапно, не передать сообщение.

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

O>>>Функции разбросать по файлам еще не достаточно будет, нужно еще контролировать API чтобы не дай бог кто-то не назвал и не опечатался вместо H_String не напечатал N_Stling как минимум, в ООП это уже рестрикшен из коробки. Второе это то что не всегда нужно делать новую функцию, также как ToString() в шарпе реализует вывод названия типа. Как это будет в процедурном ? A_String, B_String, Other_String ? сидищь ищещь среди 1000 функций нет ли той которая тебе нужна и не опечатались ли в ее названии.
S>>Перегрузку процедур и функций в процедурном тоже не запретили. Работает же перегрузка операторов! Чем процедуры хуже?

O>Так я тебе написал только что — неумышленная очепятка и все ищи свищи функцию , кто будет контролировать это. В ООП контролируется на уровне компиляции, уже удобнее. Ты знаешь что ToString() везде будет ToString() а не иначе.
Неумышленная опечатка в ООП и ищи ToStrinG()

O>Чем процедуры хуже ? Тоже же написал , про базовую реализацию, как ты будешь искать функцию которая работает для нужного тебе типа.
Компилятор/IDE будет искать. Мне зачем ее искать? Ну а даже если — не найду что ли поиском?

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

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

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

O>>Так я тебе написал только что — неумышленная очепятка и все ищи свищи функцию , кто будет контролировать это. В ООП контролируется на уровне компиляции, уже удобнее. Ты знаешь что ToString() везде будет ToString() а не иначе.
S>Неумышленная опечатка в ООП и ищи ToStrinG()
Ну это уже не опечатка, а случай когда человек не понимает что он делает, а именно поддерживает новую реализацию для типа,
т.е. явно не указал слово override. Дальше уже опечатки исключаются.
Т.е. в итоге ООП снижает множество ошибочных ситуаций.

O>>Чем процедуры хуже ? Тоже же написал , про базовую реализацию, как ты будешь искать функцию которая работает для нужного тебе типа.
S>Компилятор/IDE будет искать. Мне зачем ее искать? Ну а даже если — не найду что ли поиском?
Ну найти можно и без поиска тогда уж, только придется потом еще разбираться G_Strink() это была очепятка предыдущим автором он хотел именно переопределить функцию ToString или хотел сделать новую функцию.

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

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

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

S>>Вот это новость! Прямо-таки в принципе невозможно?

BFE>Ну а как? Буфер с данными — это явное хранение состояния программы, которое функциональное программирование не предполагает.

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

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

BFE>>Ну а как? Буфер с данными — это явное хранение состояния программы, которое функциональное программирование не предполагает.
S>Неверняка монада для ентих целей существует -- что-нибудь типа IO.

Наверняка существует и имплементирована на императивном языке.

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

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

S>>Неумышленная опечатка в ООП и ищи ToStrinG()
O>Ну это уже не опечатка, а случай когда человек не понимает что он делает, а именно поддерживает новую реализацию для типа,
O>т.е. явно не указал слово override. Дальше уже опечатки исключаются.
override не является необходимым ключевым словом в некоторых языках, претендующих на ООП.
O>Т.е. в итоге ООП снижает множество ошибочных ситуаций.
А в Smalltalk, например, вообще нет override. Каким образом ООП в лице Smalltalk снижает ошибочные ситуации такого рода?

S>>Компилятор/IDE будет искать. Мне зачем ее искать? Ну а даже если — не найду что ли поиском?
O>Ну найти можно и без поиска тогда уж, только придется потом еще разбираться G_Strink() это была очепятка предыдущим автором он хотел именно переопределить функцию ToString или хотел сделать новую функцию.
Разбираться придется и в случае ООП тоже, что там за G_Strink.

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

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

S>>Неверняка монада для ентих целей существует -- что-нибудь типа IO.

BFE>Наверняка существует и имплементирована на императивном языке.

https://wiki.haskell.org/IO_inside#Welcome_to_the_machine:_the_actual_GHC_implementation

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

BFE>>Ну а как? Буфер с данными — это явное хранение состояния программы, которое функциональное программирование не предполагает.

S>Как не предполагает?
Так написано в википедии:

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

здесь и насколько я знаю, так оно и есть.

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

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

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

S>>>Неверняка монада для ентих целей существует -- что-нибудь типа IO.
BFE>>Наверняка существует и имплементирована на императивном языке.
S>https://wiki.haskell.org/IO_inside#Welcome_to_the_machine:_the_actual_GHC_implementation

newtype IO a = IO (State# RealWorld -> (# State# RealWorld, a #))

Ну и? Где имплементация RealWorld?

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

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

BFE>>>Ну а как? Буфер с данными — это явное хранение состояния программы, которое функциональное программирование не предполагает.

S>>Как не предполагает?
BFE>Так написано в википедии:
BFE>

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

BFE>здесь и насколько я знаю, так оно и есть.
А взять буфер, положить его в очередь буферов (получив, при этом новую очередь буферов) — тут что, какие-то проблемы?

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

BFE>Насколько я знаю, "полнота по Тьюрингу" означает, что задачу, которая решается на данном языке можно решить на машине Тьюринга.
Я придумал язык, который умеет складывать любое число с 0-ем, и больше ничего не умеет. Он полный по Тьюрингу согласно определению выше, т.к. на машине Тьюринга эту задачу можно решить, полагаю. В чем же смысл такого тупого определения?

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

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

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

S>>>>Неверняка монада для ентих целей существует -- что-нибудь типа IO.
BFE>>>Наверняка существует и имплементирована на императивном языке.
S>>https://wiki.haskell.org/IO_inside#Welcome_to_the_machine:_the_actual_GHC_implementation

BFE>

BFE>newtype IO a = IO (State# RealWorld -> (# State# RealWorld, a #))
BFE>

BFE>Ну и? Где имплементация RealWorld?
Это фиктивный тип. IO монада — просто чейнинг. Организация порядка вычислений. Ничего более.

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

O>т.е. явно не указал слово override. Дальше уже опечатки исключаются.

Ты путаешь ООП как концепцию и конкретные реализации в конкретных языках. В C# и Java есть ООП и есть override, в JavaScript нет override, а ООП — есть (при желании).

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

BFE>Насколько я знаю, "полнота по Тьюрингу" означает, что задачу, которая решается на данном языке можно решить на машине Тьюринга.

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

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

Угу. Когда пишешь на 1С, сразу вспоминаешь 1С только хорошими словами.
В итоге там пошли по пути утиной типизации и кучей if оф где утиная типизация не проходит

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

BFE>>Насколько я знаю, "полнота по Тьюрингу" означает, что задачу, которая решается на данном языке можно решить на машине Тьюринга.
F>Наоборот. Язык полон по Тьюрингу, если на нем можно реализовать любые вычисления, которые можно реализовать на машине Тьюринга.

Да, конечно. В данном конкретном случае это что-то меняет?

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

S>А взять буфер, положить его в очередь буферов (получив, при этом новую очередь буферов) — тут что, какие-то проблемы?
Для функционального программирования это, конечно, проблема. Если вы взяли буфер, то у вас появился объект со своим состоянием и программирование перестало быть функциональным.

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

BFE>>Насколько я знаю, "полнота по Тьюрингу" означает, что задачу, которая решается на данном языке можно решить на машине Тьюринга.
S>Я придумал язык, который умеет складывать любое число с 0-ем, и больше ничего не умеет. Он полный по Тьюрингу согласно определению выше, т.к. на машине Тьюринга эту задачу можно решить, полагаю. В чем же смысл такого тупого определения?

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

BFE>>Из этого никак не следует, что данный язык использует внутри себя машину Тьюринга или её аналог. Поэтому здесь нет противоречия.
S>Из этого не следует. Может, взять нормальное определение полноты?
Возьмите другое определение. Что это изменит?

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

BFE>>Ну и? Где имплементация RealWorld?
S>Это фиктивный тип. IO монада — просто чейнинг. Организация порядка вычислений. Ничего более.

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