Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>В идеале функция в ФП не имеет внутреннего изменяемого состояния, не влияет на состояние других функций и пр. А это опять же означает, что все результаты ее жизнедеятельности мы получим сразу после вызова. В итоге функция возвращает и принимает некое состояние, не хранит его. S>Угу. ВВ>>Что в ООП? Да, действительно у нас нет такого требования, чтобы класс, извините, объект "инкапсулировал побочные эффекты". S>Требования — нету. Возможность - есть. ВВ>>Но давай посмотрим в глаза реальности — как в действительности будет выглядеть ОО-приложение. В действительности во всех ОО программах, которые я видел, писал, переписывал и пр. у объектов есть внутренее *изменяемое* состояние. Причем поведение методов объекта будет зависеть от этого состояния. Все, бац, — у нас больше нет детерминированных функций. S>А разве у нас не может быть объектов с состоянием, которые пользуются детерминированными функциями?
Может быть, конечно. Тут вопрос немножко по-другому стоит. Как только у нас появляется это самое изменяемое состояние у объектов ведь кто-то же начинает им пользоваться, правильно? Например, функция Drive начинает "пользоваться" состоянием, выраженным через Gas.
ВВ>>Вот возникает такое серьезное подозрение — чего-то во всем этом не хватает. Мы же не просто контейнер для функций создали, у нас как бы класс, некоторая сущность, являющаяся проекцией объекта реального мира и т.д. и т.п. А помимо собственно действий, есть еще и такие штуки как характеристики. Ну вот например — у машины может быть такая отличная характеристика как количество бензина. S>Нет, никаких проекций объекта реального мира у нас нету. Открой рефлектором любую из сборок FCL и попробуй подсчитать проекции объектов реального мира.
"Объект реального мира" — это то, что рождается в воспаленном мозгу программиста. Сокеты, файлы, паки, сервисы. А ты думал, это кошки с собаками?
Но кроме шуток, вернемся к нашим баранам. Добавили мы св-во Gas к классу Car. Функция Drive теперь зависит (и изменяет) от этого свойства. Но вот с т.з. ОО-дизайна мне это свойство кажется очень уместным и удобным. Я могу его использовать, когда буду строить отчеты об имеющихся у меня в гараже машинах. Я могу использовать его при выборке автомобиля по критерию "какой доедет". И таки-да — у меня есть машина, у машины же не только мотор, но и бензобак имеется. В общем мне это свойство нравится, оно уместно.
А когда я начинаю думать, почему такого свойства мне не хочется в ФП, то и прихожу как раз к выводу, который до этого неудачно описывал как "ООП соединяет данные и функции в единое целое". Не данные и функции. Не совсем так.
Когда в рамках ООП я думаю об *экземпляре* класса Car, то я думаю о нем, как о конкретной машине. Ну т.е. вот есть у меня Москвич 2140 желтого цвета с вмятиной на крыле, бензина в баке — 20 литров, резина — лысая, а радио ловит только четные станции. Для меня экземпляр Car — это такой сложный уникальный механизм, у которого есть внутренние взаимосвязи, вернее скажем — который *детерминирован* своими характеристиками. И функция Drive в этом плане не просто какая-то там функция — я именно в этот Москвич сел, завел его и поехал.
В ФП я совсем иначе смотрю на вещи. У меня есть одна обобщенная функция Drive. Я пишу ее так, чтобы результат работы функции зависел только от ее параметров. Я могу эту функцию каррировать хоть до опупения, передавая таким образом кол-во бензина и проч., но все равно она не превратится в мой старенький Москвич 2140. Не будет той взаимосвязи, взаимной детерминированности, которая "наполняла жизнью" мой Москвич в ООП. Будет просто специализация функции Drive для некоторого — всегда константного — значения бензина.
Ну вот как-то так.
По этим причинам мне кажется, что с точки зрения моделирования ООП и ФП не очень совместимы.
Здравствуйте, Sinclair, Вы писали:
ВВ>>Эту — никак. Только делать замыкание "вручную" — через структуру, которая функтором, конечно же, не является. Но это ты о чем-то другом совсем, не об ФВП. В Си нету композиции ф-ций, каррирования и замыканий. Но ФВП в общем случае будет и такая функция: Sort(array, f), где f — это функция-компаратор. S>Всё как раз наоборот: в частном случае будет твоя Sort. А в общем случае будет в том числе и такая, как у меня.
Обе функции есть частный случай ФВП. Такая формулировка устроит? Sort, конечно же, не более общий случай, что-то я заговариваюсь последнее время.
Тут в общем-то все просто. Замыкания в языке не нужны, чтобы писать ФВП. Да, их отсутствие ограничивает. Точно так же, впрочем, как и отсутствие композиции как first class citizen в компиляторе, которую также хотелось бы видеть в "тру" ФЯ. Тот же STL написал во вполне функциональном стиле, но вот замыканий я там что-то не видел.
ДжаваСкрипт, кстати, весьма интересный пример. Я знаю, что считают его создатели, но вот положа руку на сердце — настоящий ли это функциональный язык? С одной стороны там есть минимальный джентльменский набор — честные первоклассные функции и замыкания. С другой — функциональный код на этом языке писать не очень-то удобно. ФП есть все же вид декларативного программирования и вот с этим в ДжаваСкрипте тухло как-то. С т.з. выразительности и удобства написания функционального кода этот язык сосет по сравнению с каким-нибудь OCaml. И несмотря на то, что базовые механизмы есть, когда пишешь на ДжаваСкрипте функциональную программу не покидает чувство, что занимаешься по-прежнему имитацией настоящего ФЯ.
Твой пример с композицией — типичной операцией над функциональном типе в ФЯ — очень характерен (кстати, зачем там "new"? ). Попробуй изобразить композицию для трех функций, для четырех. Как все это будет выглядеть? Не очень-то декларативно. А еще и про каррирование не стоит забывать.
Поэтому мое личное ИМХО — джаваскрипт НЕ функциональный язык. Вроде и замыкания есть, но все равно чего-то не хватает. Все равно имитация. В этом смысле аналогичная имитация на Си будет ну просто несколько более уродлива, чем на ДжаваСкрипт и все. Но при этом будет такой же имитацией.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Не делать утверждения — это какая-то неинтересная позиция я бы сказал. У тебя нет мнения по этому вопросу?
Не переводи стрелки. Речь о твоих утверждениях, а не о моих.
AVK>>А я ее и не сравниваю. На прямое опровержение твоим словам, что данные и функции в ФП связать нельзя.
ВВ>Я не говорил, что нельзя.
Сущностей, т.е. таких странных зверей, которые объединяют в себе как данные, так и функции, в ФП нет. Есть данные — отдельно. Есть операции — отдельно.
ВВ> Вообще само утверждение "в ФП нельзя то-то" какое-то неправильное. Что такое "в ФП нельзя"?
Ясно, пошла голимая софистика. Адьос.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Обе функции есть частный случай ФВП. Такая формулировка устроит? Sort, конечно же, не более общий случай, что-то я заговариваюсь последнее время.
Вполне устроит. Осталось показать, как реализовать второй частный случай в С.
ВВ>Тут в общем-то все просто. Замыкания в языке не нужны, чтобы писать ФВП. Да, их отсутствие ограничивает. Точно так же, впрочем, как и отсутствие композиции как first class citizen в компиляторе, которую также хотелось бы видеть в "тру" ФЯ. Тот же STL написал во вполне функциональном стиле, но вот замыканий я там что-то не видел.
Дело не в композиции. Дело в семантике.
ВВ>ДжаваСкрипт, кстати, весьма интересный пример. Я знаю, что считают его создатели, но вот положа руку на сердце — настоящий ли это функциональный язык? С одной стороны там есть минимальный джентльменский набор — честные первоклассные функции и замыкания. С другой — функциональный код на этом языке писать не очень-то удобно.
Удобство — вопрос, в некотором смысле, второстепенный. Если есть подходящая семантика, то этого, в принципе, достаточно. Если нет — то придётся извращаться с эмуляцией.
ВВ>Твой пример с композицией — типичной операцией над функциональном типе в ФЯ — очень характерен (кстати, зачем там "new"? ). Попробуй изобразить композицию для трех функций, для четырех. Как все это будет выглядеть? Не очень-то декларативно. А еще и про каррирование не стоит забывать.
При чём тут "декларативность"? Композиция есть композиция.
ВВ>Поэтому мое личное ИМХО — джаваскрипт НЕ функциональный язык. Вроде и замыкания есть, но все равно чего-то не хватает.
А чего именно? Мы же не мону лизу обсуждаем, а язык программирования. ВВ>Все равно имитация. В этом смысле аналогичная имитация на Си будет ну просто несколько более уродлива, чем на ДжаваСкрипт и все. Но при этом будет такой же имитацией.
Ну, если разницы между С и JavaScript в плане ФП не видно, то не вижу смысла обсуждать столь тонкие материи, как сочетание ООП и ФП.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, FR, Вы писали:
КЛ>>ИМХО, провалились OOA & OOD (как подходы к проектированию). Сами классы, наследование, полиморфизм — удобные инструменты, если ими пользоваться правильно.
FR>По моему скорее наоборот.
Что ты имеешь сказать, ООА и ООД круто, но классы, наследование, полиморфизм — гнусь ?
Материал из Википедии — свободной энциклопедии, -_*
Какой, к чертям, провал ? За последние 10 лет количество девелоперов выросло примерно в 100 раз. Если раньше это были высокоуровневые профессионалы, то сейчас девелоперы это школота которая нахваталась технологий. В среднем конечно же. Технологии вроде .Net, Java несут программирование в массы, которые необученые, неграмотные, неинтересующиеся, немотивированые.
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Эту — никак. Только делать замыкание "вручную" — через структуру, которая функтором, конечно же, не является. Но это ты о чем-то другом совсем, не об ФВП. В Си нету композиции ф-ций, каррирования и замыканий.
А что по твоему first class sitizen ? Если "никак", то очевидно и ФП нет.
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Тут в общем-то все просто. Замыкания в языке не нужны, чтобы писать ФВП. Да, их отсутствие ограничивает.
Замыкания — обязательное условие. "их отсутствие ограничивает". Сравни first class sitizen по аналогии с ООП, сразу станет ясно.
>Точно так же, впрочем, как и отсутствие композиции как first class citizen в компиляторе, которую также хотелось бы видеть в "тру" ФЯ. Тот же STL написал во вполне функциональном стиле, но вот замыканий я там что-то не видел.
СТЛ это только стиль, не более того.
ВВ>ДжаваСкрипт, кстати, весьма интересный пример. Я знаю, что считают его создатели, но вот положа руку на сердце — настоящий ли это функциональный язык? С одной стороны там есть минимальный джентльменский набор — честные первоклассные функции и замыкания. С другой — функциональный код на этом языке писать не очень-то удобно. ФП есть все же вид декларативного программирования и вот с этим в ДжаваСкрипте тухло как-то. С т.з. выразительности и удобства написания функционального кода этот язык сосет по сравнению с каким-нибудь OCaml. И несмотря на то, что базовые механизмы есть, когда пишешь на ДжаваСкрипте функциональную программу не покидает чувство, что занимаешься по-прежнему имитацией настоящего ФЯ.
Сосёт. Имитация.
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, -_*, Вы писали:
КЛ>>>ИМХО, провалились OOA & OOD (как подходы к проектированию). Сами классы, наследование, полиморфизм — удобные инструменты, если ими пользоваться правильно.
FR>>По моему скорее наоборот.
-_*>Что ты имеешь сказать, ООА и ООД круто, но классы, наследование, полиморфизм — гнусь ?
Нет, не так категорично.
ОО проектирование не доведенное до маразма вполне рулит. А вот механизмы конструирования разработанные в ОО подходе в виде
классов, объектов и соответственно использование для реализации наследования полиморфизма и т. п. сильно уступает по
выразительности средствам появившимся в функциональных языках (алгебраические типы и связанный с ними паттерн матчинг,
вывод типов, ФВП и комбинаторы, монады).
Исключение Smalltalk и ему подобные, но там выразительность достигается за счет динамики и метапрограммирования
ортогональных ООП.
Здравствуйте, IT, Вы писали:
IT>Если рассматривать ООП как моделирование объектов реального мира, то на самом деле он в таком виде толком и не родился. В остальном противопоставлять ООП и ФП просто глупо. Эти вещи мало в чём пересекаются и великолепно дополняют друг друга.
Дык в таком виде ООП существует только в нескольких маргинальных языках (Скала, Немерле, Питон, Руби). В остальных доминирует та или иная парадигма. Достаточно взглянуть на С++ или Яву (в меньшей мере Шарп). Там явно доминирует ООП. В Лиспе (который я сначала вписал в списко гибридов) все же доминирует ФП и МП. ООП там есть, но он там настолько своеобразный, что используется не часто.
А доклад, между прочем, делался 10 лет назад. В это время даже Руби с Питоном не были популярны. А уж Немерла и Скалы вообще не было.
Так что в принципе если судить по мэйнстриму, то ФП и ООП — это два разных мира.
Плюс если смотреть на программирование как на набор полезных практик, то преимущества ООП несомненно доступны и в процедурных языках. Чтобы далеко не ходить вспомним Win API. Это же принципы ООП реализованные в процедурном языке (Си).
А так, да ООП, ФП и даже МП отлично уживаются в одном языке. И мы все знаем как он называется.
Хотя причем тут...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Есть-то есть, но если подходить к этому с т.з. дизайна, то ООП по сути это один большой побочный эффект. Монады, всяческие корутины и проч. все же на несколько других правах.
Это огромное заблуждение. Одним большим побочным эффектом является не ООП, а программирование в целом. А ООП, ФП и даже МП — это средства завернуть игру с состояниями в понятную для человека абстрактную форму.
Скажем любую задачу что можно решить, можно решить написав конечный автомат на свитчах. Но это очень сложно и неудобно.
ООП инкапсуляция состояние в объектах, ФП в замыканиях. МП инкапсуляция все под личиной некоего языка.
В итоге мы работаем на более высоком уровне, а значит можем решать более сложные задачи.
ВВ>По факту там, где в ООП будет скрытое от пользователя состояние, в ФП будет открытое состояние и чистые функции. И как это полноценно сочетать?
Так и сочетать. Функции могут оперировать объектами, объекты есть ни что иное как набор функций соединенный с некоторыми данными.
Вот и выходит, что один стиль позволяет упростить реализацию другого.
Методы объектов отлично реализуются в функциональном стиле. А ООП — это отличный клей.
Можно рассматривать гибридный язык как ФЯ с отличной модульной системой. Или наоборот, ООЯ поддерживающий ФП можно рассматривать как ООЯ в который добавлено много приятных фишек позволяющих сократить и упростить кодирование методов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Побочный эффект не есть негативная характеристика чего-либо — так просто называется изменения состояние в результате выполнения каких-либо инструкций, в данном случае — скрытно от пользователя. Хорошо это или плохо — речи нет. Но здесь есть, как мне кажется, некоторое идеологическое противоречие ФП.
Дык, сформулируй нам в чем это противоречие?
Начать можно с объяснения того как писать программы без состояния. Мне это очень интересно, так как я пока этого делать не умею.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ВВ>>Побочный эффект не есть негативная характеристика чего-либо — так просто называется изменения состояние в результате выполнения каких-либо инструкций, в данном случае — скрытно от пользователя. Хорошо это или плохо — речи нет. Но здесь есть, как мне кажется, некоторое идеологическое противоречие ФП. VD>Дык, сформулируй нам в чем это противоречие?
То, что мог я сформулировал в ответах Синклеру. Если вкратце, то обсуждаемую тему можно свести к следующему: каковы отличия ООП и ФП при *моделировании* и, в частности, в чем кардинальное отличие между функцией в ФП и классом в ООП. Моя мысль, что классы в ООП by design инкапсулируют изменяемое состояние. Функции в ФП — by design стараются этого избежать.
Если вкратце — то на основе чего в ООП программе мы решаем, что должно быть включено в класс? Собственно, класс есть некая единая сущность, не просто же определенный набор атрибутов и функций. Очевидно, что предполагается определенная связь между членами класса. Но какая? Представим, что мы сотворили такое:
class Math {
int Sum();
int FirstOperand;
int SecondOperand;
}
Связь вроде присутствует, т.е. очевидно, что Sum зависит от полей FirstOperand и SecondOperand — абсолютно так же, как и функция sum(x, y) зависит от своих операндов. Но на класс это не тянет, тянет на бред.
А чего не хватает?
Ни FirstOperand, ни SecondOperand не являются тем, что мы привыкли называть "состоянием класса". Эти поля используются лишь в момент работы функции Sum — в этом плане их перенос в поля абсолютно бессмысленен. Результаты работы Sum также никак не влияет на эти поля.
Не хватает, как мне кажется, *взаимо*связи между полями и функциями класса, их как бы взаимной детерминированности. Сравни с этим:
class Car {
int Drive();
int Gas;
}
Вот это уже больше похоже на класс. Drive зависит от поля Gas (на пустом баке далеко не уедешь), но и Gas зависит от Drive (бензин-то кончается). И вот пожалуйста — получаем изменяемое состояние, которое несет в себе класс.
В ФП безусловно есть такие же шутки, но обычно ФП пытается такого программирования избежать. Т.е. в ФП бы я создал скорее универсальную функцию Drive принимающую кол-во бензина и возвращающую расстроение, которое мы проехали и кол-во оставшегося бензина. В ООП же у меня получается так, что каждый экземпляр класса Car есть как бы конкретный автомобиль со своими индивидуальными, так сказать, характеристиками.
Можешь почитать ответы Синклеру, я там объясняю более подробно.
Ну вот и получается, что у нас просто-напросто разное моделирование в ООП и ФП.
VD>Начать можно с объяснения того как писать программы без состояния. Мне это очень интересно, так как я пока этого делать не умею.
Об этом речи нет, как-то ты утрируешь. Речь о том, что последовательный дизайн приложения в ООП-стиле и дизайн в ФП-стиле идут разными путями.
Здравствуйте, VladD2, Вы писали:
VD>Скажем любую задачу что можно решить, можно решить написав конечный автомат на свитчах. Но это очень сложно и неудобно.
Не любую
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, Воронков Василий, Вы писали:
ВВ>То, что мог я сформулировал в ответах Синклеру. Если вкратце, то обсуждаемую тему можно свести к следующему: каковы отличия ООП и ФП при *моделировании* и, в частности, в чем кардинальное отличие между функцией в ФП и классом в ООП. Моя мысль, что классы в ООП by design инкапсулируют изменяемое состояние. Функции в ФП — by design стараются этого избежать.
Даже если мыслить так (хотя это не так на 100%), то чем эти идеи противоречат и почему нельзя их эффективно использовать совместно?
ВВ>Если вкратце — то на основе чего в ООП программе мы решаем, что должно быть включено в класс? Собственно, класс есть некая единая сущность, не просто же определенный набор атрибутов и функций. Очевидно, что предполагается определенная связь между членами класса. Но какая?
Общая задача. Функции работы с окнами логично поместить в класс "Окно", а функции работы с файлами в класс "Файл". Все же просто и очевидно. Это если не умничать и не идеологизировать ООП.
ВВ>Представим, что мы сотворили такое:
ВВ>
ВВ>class Math {
ВВ> int Sum();
ВВ> int FirstOperand;
ВВ> int SecondOperand;
ВВ>}
ВВ>
Даже страшно такое представлять .
Конечно и такое бывает, но это ведь не лучший образчик ОО-ситиля, правда?
ВВ>Связь вроде присутствует, т.е. очевидно, что Sum зависит от полей FirstOperand и SecondOperand — абсолютно так же, как и функция sum(x, y) зависит от своих операндов. Но на класс это не тянет, тянет на бред. ВВ>А чего не хватает?
ВВ>Ни FirstOperand, ни SecondOperand не являются тем, что мы привыкли называть "состоянием класса". Эти поля используются лишь в момент работы функции Sum — в этом плане их перенос в поля абсолютно бессмысленен. Результаты работы Sum также никак не влияет на эти поля.
ВВ>Не хватает, как мне кажется, *взаимо*связи между полями и функциями класса, их как бы взаимной детерминированности. Сравни с этим:
ВВ>
ВВ>class Car {
ВВ> int Drive();
ВВ> int Gas;
ВВ>}
ВВ>
Опять какая-то херня из бредовых учебников.
Давай ближе к делу. Вот у нас есть файл. Он по определению есть состояние. В ОС вроде Винды он описывается хэндлом. Хэнд — это, можно сказать, материализация того что мы называем объектом.
Вот для него имеет смысл ввести класс (объект) и объединить его все функции в нем.
ВВ>Вот это уже больше похоже на класс. Drive зависит от поля Gas (на пустом баке далеко не уедешь), но и Gas зависит от Drive (бензин-то кончается). И вот пожалуйста — получаем изменяемое состояние, которое несет в себе класс.
ВВ>В ФП безусловно есть такие же шутки, но обычно ФП пытается такого программирования избежать. Т.е. в ФП бы я создал скорее универсальную функцию Drive принимающую кол-во бензина и возвращающую расстроение, которое мы проехали и кол-во оставшегося бензина. В ООП же у меня получается так, что каждый экземпляр класса Car есть как бы конкретный автомобиль со своими индивидуальными, так сказать, характеристиками. ВВ>Можешь почитать ответы Синклеру, я там объясняю более подробно.
Да ладно фантазировать про гипотетические кары и драйвы.
Давай лучше опиши как бы ты выразил работу с файлами в функциональном мире.
Что снова изобретем хэндл? О боги! Да это же старое доброе процедурное программирование!
А где же та замечательная завеса таинства что так привлекала многих в ФП?
Вот классы надо расстраивать как средство борьбы с хэндлами. Инкапсуляция — это оно и есть.
ВВ>Ну вот и получается, что у нас просто-напросто разное моделирование в ООП и ФП.
У нас? Не... это у вас дохтор картиночки такие. А у нас все ОК. Мы и в ФП и в ООП моделируем все совершенно одинаково.
В объекты мы превращаем то что обладает состоянием. Причем объекты не обязаны быть изменяемыми. Я создаю неизменяемые объекты куда чаще чем изменяемые.
Мы просто не приемлем хэндлы и другие виды эмуляции ООП в не объектно-ориентированных языках.
VD>>Начать можно с объяснения того как писать программы без состояния. Мне это очень интересно, так как я пока этого делать не умею.
ВВ>Об этом речи нет, как-то ты утрируешь. Речь о том, что последовательный дизайн приложения в ООП-стиле и дизайн в ФП-стиле идут разными путями.
Я утрирую потому что свихнутые на ФП доходят и до такого бреда, что в их программах нет состояния. Надо же уточнить позицию?
Так вот я для себя сделал открытия. Не бывает ОО-дизайн или ФП-дизайн. А бывает хороший (красивый, удобный и т.п.) дизайн, и притянутый за уши. Когда преобразование А в Б пытаются оформить классом — это кривой дизайн, но все эти хэндлы — это точно такой же кривой дизайн.
Состояние есть, его не может не быть! Это объективная реальность. Состояние опасно! Точнее опасно не оно, а то что человеческий мозг не может представить состояние во времени и то, что мы не имеем возможности взглянуть в прошлое.
ФП просто протаскивает состояние через стек. И это во многом удобно. Но и тут его удобнее таскать в виде объекта, а не в виде открой структуры с тучей полей или в виде хэндла.
В чистом ФП-стиле можно писать только конвертеры. Любая интерактивная программа или даже просто большая требует ОО-подхода. И самое лучшее что можно придумать — это сочетать ФП и ООП в одной программе, делая в ФП-стиле все что можно сделать с его помощью не доводя решение до идиотизма. А ООП использовать в тех случаях когда у нас появляется состояние которое нужно абстрагировать и превратить в черный ящик.
Вот как-то так. И что характерно я уже три года пишу код только так и не понимаю как можно писать по другому.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, -_*, Вы писали:
VD>>Скажем любую задачу что можно решить, можно решить написав конечный автомат на свитчах. Но это очень сложно и неудобно.
-_*>Не любую
Например?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>>>Скажем любую задачу что можно решить, можно решить написав конечный автомат на свитчах. Но это очень сложно и неудобно.
VD>-_*>Не любую
VD>Например?
Например язык вида 0000011111 не распознается КА, т.к. КА не обладает полнотой по Тюрингу.
Материал из Википедии — свободной энциклопедии, -_*
Сокеты, файлы, паки, сервисы. А ты думал, это кошки с собаками?
). Попробуй изобразить композицию для трех функций, для четырех. Как все это будет выглядеть? Не очень-то декларативно. А еще и про каррирование не стоит забывать.
