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

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

G>>Да. Парадоксально, но дешевле всего для решения задачи именно сгенерировать параллельные вселенные, чем обеспечить симуляцию вариантов на архитектуре фон неймана в одной вселенной. Генерация мульти-вселенных — это самый дешёвый и даже "обыденный" процесс. Каждая мини-радуга на стене от солнечного окна — это на самом деле ансамбль мульти-вселенных, взаимодействующих друг с другом через механизм интерференции, и это всё истинно параллельно. А для построения симуляции фон неймана нужно описать императив, прогнать его последовательно (или параллельно, но с издержками синхронизации).
G>>Вопрос лишь за тем, чтобы дождаться удешевления квантового компьютинга и развития соотв. методик и языков.

D>У тебя получилась очень точная метафора, но я могу судить об этом только умозрительно на основании прочитанных мною книг и статей, потому что у меня самого с мновариантностью туговато

Я сам пришёл в эту тему с изучения проблематики синхронности в типовой архитектуре фон неймана (книги по java concurrency), и потом по книге "квантовые вычисления для айтишников" и по книге "структура реальности" дойча (одного из отцов квантового компьютинга), которую мне подсказали на этом форуме несколько лет назад.

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

Я не имею ничего против функциональщины как очередного около-академического загона, тем более на нём построен реактивный стэк, но только к месту (например, как higload/gateway микросервис). На мой взгляд, основная проблема как раз в том, что типовые корпоративные приложения, где я в основном работаю, нет смысла делать на таком сложном стэке, т.к. этот стэк контринтуитивен (по опыту, вижу как разрабы, даже опытные, пытаются его освоить и применять), и если одна успешная команда "академиков" напишет тебе истинно функциональный код, но потом на поддержку придут джуны/мидлы, которые не сильно шарят в этой теме, то они начнут дописывать такой код уже в "псевдо-функциональном" стиле и сидеть над элементарным багфиксом месяцами, тупо из-за того, что функциональный код "не понятен".
Чтобы функциональщина стала полезной, нужно, чтобы типовой разработчик с рынка этими методами владел, а это пока далеко не так.
А писать в функциональном стиле сложную бизнес-логику типового enterprise-приложения, при том, что разрабы сменяют друг друга каждые полгода — это антиутопия.
Функциональщина больше годится в сфере научного труда, как и прочие методики, типа DSL (например, IntelliJ MPS, которые прекрасны в теории, но ужасны на практике). Ну может немного на фронте, т.к. фронт по своей природе реактивен.

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

G>Я не имею ничего против функциональщины как очередного около-академического загона, тем более на нём построен реактивный стэк, но только к месту (например, как higload/gateway микросервис). На мой взгляд, основная проблема как раз в том, что типовые корпоративные приложения, где я в основном работаю, нет смысла делать на таком сложном стэке, т.к. этот стэк контринтуитивен (по опыту, вижу как разрабы, даже опытные, пытаются его освоить и применять), и если одна успешная команда "академиков" напишет тебе истинно функциональный код, но потом на поддержку придут джуны/мидлы, которые не сильно шарят в этой теме, то они начнут дописывать такой код уже в "псевдо-функциональном" стиле и сидеть над элементарным багфиксом месяцами, тупо из-за того, что функциональный код "не понятен".
G>Чтобы функциональщина стала полезной, нужно, чтобы типовой разработчик с рынка этими методами владел, а это пока далеко не так.
G>А писать в функциональном стиле сложную бизнес-логику типового enterprise-приложения, при том, что разрабы сменяют друг друга каждые полгода — это антиутопия.
G>Функциональщина больше годится в сфере научного труда, как и прочие методики, типа DSL (например, IntelliJ MPS, которые прекрасны в теории, но ужасны на практике). Ну может немного на фронте, т.к. фронт по своей природе реактивен.

Если ты джавист, то функциональщиной можно назвать Stream API. Я перестал использовать джаву до того, как там появилось это API. Но поиск в яндексе показывает, что это оно.

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

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

И заметь одну важную вещь. Почти нигде в документации в подобных случаях не указывают на прямую связь ФП. Если тебе напишут, что Java Stream — это моноид, то тебе такое понравится? А ведь самый настоящий моноид, как ни посмотри

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

S>По моему мнению, например, в современном мире лишним является сам Си. И чем меньше софта будет писаться на Си (с переходом на C++ и/или Rust), тем лучше. Но это мое личное заблуждение мнение.

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

Rust выглядит прикольным, но на мой взгяд, слишком уж переусложнён. И от восклицательных знаков в глазах рябит. Напоминает чем-то конфиг sendmail-а.

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

S>Кто-то будет писать ; а кто-то скажет что это лишнее. Начнется новый холивар, еще похлеще пробелы vs табы, возможно дойдет до кровопролития в отдельных случаях.

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

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

D>И заметь одну важную вещь. Почти нигде в документации в подобных случаях не указывают на прямую связь ФП. Если тебе напишут, что Java Stream — это моноид, то тебе такое понравится?

А как ответить на такой вопрос: если из этого моноида вызвать транзакционный jpa-код, к какому треду и связанному с каким тредом и tx-менеджером его соотнесет EE-фреймворк, от этого ведь будет зависеть логика коммита/отката? И вообще, этот моноид исполняется на треде реквеста или на вторичном треде из некоего пула? А этот пул какой вместимости? Не станет ли он узким местом? А с секьюрностью что будет, если секьюрити контекст с авторизацией привязан к треду реквеста, он што, потеряется и тред моноида будет выполняться анонимно? Значит, код моноида подвержен атакам? Секьюрность контекста у моноида вообще можно обеспечить гарантией java sdk, как у классического threadlocal, или это обеспечивается лишь псевдо-гарантией на уровне самописных реактивных библиотек? А шо там у моноидов с OneToMany/ManyToMany? Не поддерживается, и нужно вручную реализовывать? Надо же, какая досада, но зато функционально! А шо там у них с пробросом эксепшнов? А стектрейс человеческий (кто это когда и с чем по цепочке вызвал) можно посмотреть без установки в ide спец-приблуд? Нельзя, но зато функционально!
Столько вопросов, столько рисков, это же не просто голые computation, может надёжнее не открывать эту кротовую нору и писать enterprise-код в общепринятом процедурном стиле с анемичной моделью?

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

S>Это чисто фишка C — строго ; и строгость в больших/маленьких буквах.

А почему везде ; надо, а после закрывающей фигурной скобки не надо?

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

D>Кстати, таким людям обычно нравится функциональное программирование. Их вдохновляет сама красота математических абстракций, а в абстракциях они разбираются просто превосходно. Это так, к слову. Ты попробуй! Может быть, и тебе тоже понравится?

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

Когда я вижу слишком абстрактную абстракцию, меня всё время не покидает чувство, что где-то на каком-то уровне меня обязательно на@&ут, и из красивой математической абстракции вылезет какая-нибудь неучтённая деталь реализации, которую я знать вроде как не должен, но которая обязательно подкрадётся и укусит исподтишка, когда не ждёшь.

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

S>>По моему мнению, например, в современном мире лишним является сам Си. И чем меньше софта будет писаться на Си (с переходом на C++ и/или Rust), тем лучше. Но это мое личное заблуждение мнение.

Pzz>OK. Я в этом вопросе предпочитаю заблуждаться вслед за Дейкстрой, который считал, что язык для писания сложных программ должен быть понятным и простым.

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

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

Pzz>Мне очень неуютно и трудно программировать, если я не могу разобрать красоту математической абстракции до самых её корней

А у функциональщины ещё и практически нет нормального стектрейса на брейкпоинте или в логе, чтобы эту муть разобрать. Но это должно тебе понравится (если ты мазохист).

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

Pzz>Когда я вижу слишком абстрактную абстракцию, меня всё время не покидает чувство, что где-то на каком-то уровне меня обязательно на@&ут, и из красивой математической абстракции вылезет какая-нибудь неучтённая деталь реализации, которую я знать вроде как не должен, но которая обязательно подкрадётся и укусит исподтишка, когда не ждёшь.

То ли дело чистая императивщина на теплой ламповой Сишечке:

    if (finding->name != NULL) {
        device->mdns_name = str_dup(finding->name);
    }

Вот прямо очевидно, что str_dup, если повезет, приведет к логированию и вызову abort.

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

SP>наверное вы
SP>

SP>• запоминаете номер текущего гвоздя
SP>• проверяете, что этот номер не больше -дцати
SP>• отсчитываете нужный гвоздь (причём считаете и уже забитые гвозди!)
SP>• после приколачивания прибавляете к номеру гвоздя единицу
SP>

SP>Думаю, всё таки нет. Вы берёте пачку гвоздей. Если пачка пуста, процесс завершаете. Иначе берёте первый гвоздь, приколачиваете и с оставшимися возвращаетесь в начало (рекурсия!).
SP>Всё дело в привычке. Вы уже подсознательно воспринимаете for(int i = 0...) за прохождение по всем элементам. И не обращаете внимания сколько фигни с точки зрения человека происходит.

Не хочу вклиниваться в спор (лично мне фунциональная парадигма ближе, чем императивная), но всё же замечу, что номера гвоздей здесь несколько притянуты, ведь императивный цикл можно записать и без этих номеров:

void sign(const auto& docs) {
    for(const auto& doc : docs) {
        sign(doc);
    }
}

Тогда приведённый выше список упрощается:

• Забить каждый гвоздь

И это всё ещё императивный стиль!

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

S>То ли дело чистая императивщина на теплой ламповой Сишечке:
S>

S>    if (finding->name != NULL) {
S>        device->mdns_name = str_dup(finding->name);
S>    }
S>

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

А что еще можно сделать? Собственно, даже и этого можно не делать по большому счёту. malloc не вернёт NULL. Он выделит какое-то место в адресном пространстве и вернёт его адрес, а при первом обращении система не найдёт свободной странички и пришлёт SIGSEGV или SIGBUS (если OOM Killer не пришлёт раньше SIGKILL).

Ну уж я и не говорю о том, что соответствующее поведение документированно в комментарии к mem_resize.

P.S. Этот код, кстати, внимательно просматривали специально обученные люди из RedHat, Canonical и Google. Все возникающие вопросы мы с ними обсудили и пришли к консенсусу. Не говоря уж о нескольких десятках контрибьютеров.

Так что неудачный заход, увы.

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

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

Pzz>Так что неудачный заход, увы.

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

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

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

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

D>>И заметь одну важную вещь. Почти нигде в документации в подобных случаях не указывают на прямую связь ФП. Если тебе напишут, что Java Stream — это моноид, то тебе такое понравится?

G>А как ответить на такой вопрос: если из этого моноида вызвать транзакционный jpa-код, к какому треду и связанному с каким тредом и tx-менеджером его соотнесет EE-фреймворк, от этого ведь будет зависеть логика коммита/отката? И вообще, этот моноид исполняется на треде реквеста или на вторичном треде из некоего пула? А этот пул какой вместимости? Не станет ли он узким местом? А с секьюрностью что будет, если секьюрити контекст с авторизацией привязан к треду реквеста, он што, потеряется и тред моноида будет выполняться анонимно? Значит, код моноида подвержен атакам? Секьюрность контекста у моноида вообще можно обеспечить гарантией java sdk, как у классического threadlocal, или это обеспечивается лишь псевдо-гарантией на уровне самописных реактивных библиотек? А шо там у моноидов с OneToMany/ManyToMany? Не поддерживается, и нужно вручную реализовывать? Надо же, какая досада, но зато функционально! А шо там у них с пробросом эксепшнов? А стектрейс человеческий (кто это когда и с чем по цепочке вызвал) можно посмотреть без установки в ide спец-приблуд? Нельзя, но зато функционально!
G>Столько вопросов, столько рисков, это же не просто голые computation, может надёжнее не открывать эту кротовую нору и писать enterprise-код в общепринятом процедурном стиле с анемичной моделью?

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

В программировании часто нет такого водораздела, что здесь, мол, функциональное программирование, а вот здесь идет уже императивное.

Ты летал на самолете на высоте 10 километров при смене дня и ночи? Там будет такое явление, как "терминатор", когда день и ночь поделили ровно словно масло ножом. Но на самой земле свет рассеивается, и такой жесткой границы нет. Так и нет жесткой границы между функциональным стилем и императивным. Более того, их по-моему даже часто неправильно противопоставлять друг другу. Это как есть профиль и анфас лица человека. Лицо человека — это как задача программирования, а смотрим мы на нее сбоку или прямо — саму задачу не особо-то и меняет. Просто могут быть разные пути решения для достижения одной цели. Так, и функциональное программирование и императивное — это иногда разные пути достижения одной цели. Часто они даже работают в тандеме.

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

Ты так не дели мир на черное и белое! Все куда сложнее и проще одновременно

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

D>... И там тоже есть место всем этим транзакциям, исключениям, потокам исполнения и тому подобному.

Есть-то есть, но через одно место. Например, в реактивном стэке Spring Reactor/Webflux стримы выполняются на небольшом кол-ве системных тредов, т.е. сами реактивные стримы не многопоточны, поэтому если разработчик выполняет любую блокирующую операцию на стриме неправильно ("неправильно" — это обычным вызовом блокируюшей операции), то он блочит весь стрим, т.е. блочит все сотни других и превращает высоконагруженный скоростной стрим в узкое место.
А блокирующие операции — это чуть ли не 90% всех БД и интеграционных операций — вызовы REST API, вызовы к файловой системе, работа с БД, даже просто поставить паузу через Thread.sleep. И поэтому реактивщина тянет за собой целый ворох специфики — чтобы работать с БД в неблокирующем стиле, нужен реактивный jdbc-драйвер, чтобы работать в неблокирующем стиле с REST API, нужен особый неблокирующий REST API-клиент, чтобы работать в неблокирующем стиле с входящими веб-запросами, нужен особый неблокирующей веб-сервер. В общем, это полностью новый мир со своими правилами, и многие из этих библиотек ещё сырые (например, в реактивном JPA, насколько знаю, до сих пор не реализованы OneToMany/ManyToMany), реактивный сервер netty имеет баги и утечки (сам лично находил), т.е. я бы сказал, что для корпоративной разработки функциональщина и реактивщина ещё не "дозрели" и остаются либо вотчиной "академиков", либо хайлоада, где имеет смысл жертвовать в угоду хайлоаду (типа простейших микросервисов гейтвеев), но желательно, чтобы бизнес-логики на функциональщине было написано минимум, потому что попытка писать на ней сложную бизнес логику приводит к миллиону не-императивных функциональных конструкций, в которых потом никто, даже сам автор, разобраться не в силах, и случайно посадить в этом нагромождении баг проще простого, например вставив куда-нибудь блокирующую операцию, что превращает всё это великолепное нагромождение функциональных операторов в тыкву.

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

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

D>>... И там тоже есть место всем этим транзакциям, исключениям, потокам исполнения и тому подобному.

G>Есть-то есть, но через одно место. Например, в реактивном стэке Spring Reactor/Webflux стримы выполняются на небольшом кол-ве системных тредов, т.е. сами реактивные стримы не многопоточны, поэтому если разработчик выполняет любую блокирующую операцию на стриме неправильно ("неправильно" — это обычным вызовом блокируюшей операции), то он блочит весь стрим, т.е. блочит все сотни других и превращает высоконагруженный скоростной стрим в узкое место.
G>А блокирующие операции — это чуть ли не 90% всех БД и интеграционных операций — вызовы REST API, вызовы к файловой системе, работа с БД, даже просто поставить паузу через Thread.sleep. И поэтому реактивщина тянет за собой целый ворох специфики — чтобы работать с БД в неблокирующем стиле, нужен реактивный jdbc-драйвер, чтобы работать в неблокирующем стиле с REST API, нужен особый неблокирующий REST API-клиент, чтобы работать в неблокирующем стиле с входящими веб-запросами, нужен особый неблокирующей веб-сервер. В общем, это полностью новый мир со своими правилами, и многие из этих библиотек ещё сырые (например, в реактивном JPA, насколько знаю, до сих пор не реализованы OneToMany/ManyToMany), реактивный сервер netty имеет баги и утечки (сам лично находил), т.е. я бы сказал, что для корпоративной разработки функциональщина и реактивщина ещё не "дозрели" и остаются либо вотчиной "академиков", либо хайлоада, где имеет смысл жертвовать в угоду хайлоаду (типа простейших микросервисов гейтвеев), но желательно, чтобы бизнес-логики на функциональщине было написано минимум, потому что попытка писать на ней сложную бизнес логику приводит к миллиону не-императивных функциональных конструкций, в которых потом никто, даже сам автор, разобраться не в силах, и случайно посадить в этом нагромождении баг проще простого, например вставив куда-нибудь блокирующую операцию, что превращает всё это великолепное нагромождение функциональных операторов в тыкву.

Если ты про async-await, то в языках типа C# и F# весь IO должен быть явно определен в терминах асинхронных вычислений. Это ограничение метода реализации.

С другой стороны, в том же Haskell все стандартные операции IO внутри рантайма являются неблокирующими (асинхронными) через select/poll/epoll. И это делается прозрачно для пользователя за счет зеленых потоков. Код пишется как обычно, то есть, якобы как синхронный, но на деле он — асинхронный. Я так понимаю, что в тех же Go и Erlang ситуация похожая (вот, не смог себя заставить до конца прочитать учебник по Go этим летом)

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

Pzz>Например, в Go очень популярная штука — слайс. Они там почти всегда используются вместо массивов. Как сишнику, мне это понятно и комфортно. Но вот питонист, боюсь, на этом свихнётся, если наткнётся.

Слайсы — совершенно очевидная вещь: https://habr.com/ru/articles/89456/

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

S>>Кто-то будет писать ;
GIV>Не будет. И холиваров нет.

Да помню споры с разработчиками на Scala:
— Это можно писать вот так.
— Одерски так не пишет!!!

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

S>Но в JS так же ; не обязательна. Пишут и так и эдак. В бейсике тоже не требовалась ;

Из за этого там есть грабли типа:

console.log((function () {
    return
        "Oops!";
})());

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

S>>Это чисто фишка C — строго ; и строгость в больших/маленьких буквах.
Pzz>А почему везде ; надо, а после закрывающей фигурной скобки не надо?

Символ } служит окончанием блока инструкций, это аналог символа ; в конце одной инструкции.