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

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

AA>>

S>Половина две трети статьи — вода.

>> Когда вы знаете 95% Lisp, вы знаете 90% Clojure. Этот простой скобочный синтаксис и есть вся фишка синтаксиса в данных языках. Они абсурдно просты.

S>Мне нравится как слово "примитивный" пытаются подменить "простым".

Я не практикую кложу( в основном C# и F#). Но познакомившись с lisp и clojure уже не смог спать спокойно. Опять же интересовался D2(Ди dlang.org),
но увидев концепцию Nemerle, понял что ди это еще один клон C.
Нет предела совершенству.
Вот например в кложе есть такая функция get. Одна!

(get [1 2 3] 0) =>; 1
(get {:name "Alice"} :name) =>; "Alice"
(get [1 2 3] 10) =>; nil
(get [1 2 3] 10 9) =>; 9

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

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

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

AA>>>>2. Объектно-ориентированное программирование накладывает ограничение на косвенную передачу управления.

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

AA>>и нарушаешь инкапсляцию?

I>Инкапсуляция решает вполне конкретные задачи. Нет таких задач — не надо за неё и держаться. Самое главное в ООП это структуризация решения сложной задачи, и, как следствие, организация взаимодействия.

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

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

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

AA>>>>идут по пути все большего ограничения возможностей (из книги "Чистая архитектура" Р.М.):
AA>>>>1. Структурное программирование накладывает ограничение на прямую передачу управления.
AA>>>>2. Объектно-ориентированное программирование накладывает ограничение на косвенную передачу управления.

AA>>Как-то так. Нет?

S>Как-то сложно сформулировано.

AA>>1. оператор goto — усложняет понимание логики.

S>Усложняет понимание и накладывает ограничение ни одно и тоже. А вызво ф-ии по адресу (делегат) разве запрещен? Тоже ведь косвенная передача управления.

AA>>2. запрет на прямой изменение памяти — путем перемещения стека функции в кучу, т.е. создание объекта, который через вызовы функций по указателю(методы объекта) изменяет значения переменных связанных с этим объектом(его поля).

S>Я бы не назвал косвенную передачу управления нарушением инкапсуляции. Опять же какие-то путанные определения. Не косвенная передача управления, а неявное изменение состояния, наверное, так?



Думаю, стоит поискать ответы в книге "Чистая архитектура" Р.М.

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

AA>Вот например в кложе есть такая функция get. Одна!
AA>Одна функция вытаскивает данные из любой структуры в кложе.

Это потому, что там и есть всего одна структура — список.

Кстати, а как будет работать эта суперфункция, если надо вытащить n-й символ из строки в формате unicode (под «символом» понимаем extended grapheme cluster, а не просто байт)?

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

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

Противопоставлять ООП и ФП крайне неграмотно. Это разные парадигмы, одна про вычисления, другая про структурирование и взаимодействие.

Одна из математики, другая из головы человека. Компьютеру не надо структурировать, но это надо человеку — у него окно внимания короткое, около 5-7 обьектов. Без структурирования человек не может решить вообще ничего. И в основе ООП именно это — ментальная модель мышления человека.

Отсюда понятно, что полно языков, где есть и то, и другое.
Например Окамl.

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

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

Кстати, про поведение — от программы требуется именно это. И не надо удивдяться, что в ФП есть средства для моделирования поведения — те самые монады например.

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

AA>Думаю, стоит поискать ответы в книге "Чистая архитектура" Р.М.

Увы, это не ответ. Сложилось впечатление, что Вы не совсем понимаете о чем говорите.

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

I>>Инкапсуляция решает вполне конкретные задачи. Нет таких задач — не надо за неё и держаться. Самое главное в ООП это структуризация решения сложной задачи, и, как следствие, организация взаимодействия.

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

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

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

AA> 1. оператор goto — усложняет понимание логики.

Смотря как его применять.

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

PJ>>Общая скорость определяется самым медленным элементом. Иногда это память, иногда процессор, но в 99% это IO. Именно оно и определяет в большей степени.

_>Ага, ага. ))) И именно поэтому современные серверы представляют из себя сотни ядер процессора и сотни гигабайт оперативки, имея при этом точной такой же IO (грубо говоря гигабитную сетевую карту), как и дохлый ноут.

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

Теперь посчитай, сколько сетевых гнезд у ноутбука. Гы-гы.

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

Что касается сотен гигабайт оперативы — такое ставится далеко не везде. Обычные приложухи уткнутся в сетевую производительность. Если канал гигабитный, а каждая из приложух хочет загрузить его по максимуму, очевидно, ничего не выйдет. Смысл в сотнях гигабайт?

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

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

_>Ага, ага. ))) И именно поэтому современные серверы представляют из себя сотни ядер процессора и сотни гигабайт оперативки, имея при этом точной такой же IO (грубо говоря гигабитную сетевую карту), как и дохлый ноут.

Я боюсь себе даже представлять, в какой это дикой глуши вы такие сервера находите.
Потому что у нормальных сбалансированных реализаций сейчас там не один гигабит в интерфейсе, а 10. На гигабите сейчас только домашнюю нагрузку пускать. А то и 40 (причём, вероятно, InfiniBand, а не Ethernet). И не один такой интерфейс, а два или четыре.
Встречались и больше, но это уже под спецзадачи (и спецадаптеры, которые сами некоторые виды потока разбирают).

В целмо согласен с остальными тезисами письма, но именно эта часть у вас откровенно неадекватна. Вообще же проблема в IO не ширина полосы, на которую вы накой-то свернули разговор, а задержки. Даже на InfiniBand гарантии RTT целевого обмена с соседом — дают что-то вроде 2-3 мкс в лучшем случае, при отсутствии задержек на очередь. Это уже на порядок медленнее даже тупого RAM.

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

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

I>>>Инкапсуляция решает вполне конкретные задачи. Нет таких задач — не надо за неё и держаться. Самое главное в ООП это структуризация решения сложной задачи, и, как следствие, организация взаимодействия.

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

ltc>И доколе человек будет ломать мозг, чтобы писать на языке, более близком и понятном компьютеру, а не наоборот?

Да что там ломать? У меня есть опыт использования F# и Nemerle в учебных целях. Скажу так, ФП по синтаксису намного проще ООП.
Возьмем конкретный пример — наследование. И для простоты Nemerle (как более близкий по синтаксису с C#).

public abstract class LogEntry {}

public sealed class Info :LogEntry  
{
    public Info (string message){}
}
public sealed class Err : LogEntry  
{
     public Err (string message){}
}

Теперь тоже самое в функциональном стиле:

variant LogEntry {
    | Info { message : string }
    | Err { message : string }
}

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

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

AA>Теперь тоже самое в функциональном стиле:

Это не наследование, а алгебраический тип данных. Что совершенно другое — наследование открыто для расширения, алгебраические типы — закрыты.

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

Шо?

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

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

AA>>Теперь тоже самое в функциональном стиле:

ARK>Это не наследование, а алгебраический тип данных. Что совершенно другое — наследование открыто для расширения, алгебраические типы — закрыты.

Я про естественность реализации наследования для типизации данных — подтип четко связан с базовым(находится в одном модуле). В C# требуется вынести подтипы в отдельный модуль(файл) и уже теряется читабельность.
Хотел показать, что в основе реализации механизма АТД лежит наследование от абстрактного класса, но удобство разное именно из-за идеологии.

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

ARK>Шо?

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

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

ARK>>Это не наследование, а алгебраический тип данных. Что совершенно другое — наследование открыто для расширения, алгебраические типы — закрыты.

AA>Я про естественность реализации наследования для типизации данных — подтип четко связан с базовым(находится в одном модуле). В C# требуется вынести подтипы в отдельный модуль(файл) и уже теряется читабельность.

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

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

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

Нет никаких преимуществ в том, что АлгТД весь в одном файле. Его преимущество — исчерпывающий match. И вытекающий отсюда же недостаток — нерасширяемость при необходимости. Всё это известно под названием expression problem.

ФП или ООП — вообще ортогонально данному вопросу.

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

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

ARK>>>Это не наследование, а алгебраический тип данных. Что совершенно другое — наследование открыто для расширения, алгебраические типы — закрыты.

AA>>Я про естественность реализации наследования для типизации данных — подтип четко связан с базовым(находится в одном модуле). В C# требуется вынести подтипы в отдельный модуль(файл) и уже теряется читабельность.

ARK>Идеологически алгебраический тип данных — это один тип, никаких подтипов в нем нет (хотя внутри можно реализовывать и классами, разумеется). Это "расширенный енум". И его конструкторы — это аналог членов енума, а не типов.
Enum в C# это алиас целочисленных типов, не более. Какие там члены?

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

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

Сразу вспоминаю доклад Рича Хикки "Когда от кодиннга лопаются мозоли на пальцах рук".

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

ARK>>Идеологически алгебраический тип данных — это один тип, никаких подтипов в нем нет (хотя внутри можно реализовывать и классами, разумеется). Это "расширенный енум". И его конструкторы — это аналог членов енума, а не типов.
AA>Enum в C# это алиас целочисленных типов, не более. Какие там члены?

Я сказал — _расширенный_ енум. Идеологически АлгТД — это енум, а не тип с наследниками.

И что, других языков нет, кроме C#?
Вот енум в rust: https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html

ARK>>Мне нет разницы, потому что вручную мотать файл в поисках нужного метода все равно геморройно. Обычно используют поиск или вообще IDE сразу позволяет сделать переход к нужной декларации, где бы она ни находилась.
AA>Сразу вспоминаю доклад Рича Хикки "Когда от кодиннга лопаются мозоли на пальцах рук".

Не знаю, кто такой Рич Хикки, но вряд ли стоит прислушиваться к его словам, если у него от кодинга на руках мозоли, да еще и лопнутые. Вероятно, говнокодер, у которого оплата за количество строк кода.

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

AA>Да что там ломать? У меня есть опыт использования F# и Nemerle в учебных целях. Скажу так, ФП по синтаксису намного проще ООП.

А тебя не смущает, что оба языка этих поддерживают ОО ?

AA>Возьмем конкретный пример — наследование. И для простоты Nemerle (как более близкий по синтаксису с C#).

AA>

AA>public abstract class LogEntry {}

AA>public sealed class Info :LogEntry  
AA>{
AA>    public Info (string message){}
AA>}
AA>public sealed class Err : LogEntry  
AA>{
AA>     public Err (string message){}
AA>}
AA>

Типичный приём от тех, кто противопоставляет ООП и ФП — ни слова о задаче, только фрагменты решения. Для начала нужно озвучить задачу. К слову, пока что здесь наследование не нужно, от слова 'вообще'.

Представь себе такую задачу — есть сервер, который умеет работать с несколькими протоколами. Для конкретного соединения нужно выбрать тот или иной протокол. Каждый из протоколов имеет кое какие общие черты. В силу требований реализация протокола должна подключаться через плагины и управляться через общий конфиг.

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


S>Ну, я пока не видел учётных систем, построенных на ФП. Но, по идее, в отличие от императивы, мы можем формально проверить, что все пререквизиты есть — и действие "отгрузка" просто не выполнится, пока нет оплаты, даже если программист это руками не проверил.
Учетная система всё никогда не будет на ФП, так как всегда будет бизнес логика задачей которой является изменения состояния базы, создание новых счетов, изменения состояния счетов, вот это всё.
На ФП возможно только часть учетной системы — отчетность, и прочее когда не надо изменять состояние, а по существующему нужно получить что-то.
И вот для этой части, ФП вполне себе хорошо.

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

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

ARK>>>Это не наследование, а алгебраический тип данных. Что совершенно другое — наследование открыто для расширения, алгебраические типы — закрыты.

AA>>Я про естественность реализации наследования для типизации данных — подтип четко связан с базовым(находится в одном модуле). В C# требуется вынести подтипы в отдельный модуль(файл) и уже теряется читабельность.

ARK>Идеологически алгебраический тип данных — это один тип, никаких подтипов в нем нет (хотя внутри можно реализовывать и классами, разумеется). Это "расширенный енум". И его конструкторы — это аналог членов енума, а не типов.

enum X {
 A
}
void Method(X x)
{
}
Method((X)10);

Спокойно скомпилится. Попробуй тоже самое с АТД и скажи что это одно и тоже.

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

I>Типичный приём от тех, кто противопоставляет ООП и ФП — ни слова о задаче, только фрагменты решения. Для начала нужно озвучить задачу. К слову, пока что здесь наследование не нужно, от слова 'вообще'.

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

Это ТЗ? вы хотите чтобы я закодил задачу?
ХМ, Если вас не тронула чистота ФП-кода, значит вам это не подходит. Что ж, рано или поздно все придут к ФП.
Наверно также со скрипом заходило ООП когда-то.