Интуиция тут ни при чём. Просто проще строить системы такие, какие ты видишь IRL.

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

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

Объекты, обменивающиеся сообщениями, - это явно гуманитарии придумали.

цепь - функция, представляющая собой композицию отдельных блоков (функций)

Почему это она функция, а не объект? Цепь состоит из блоков-объектов, которые получают некоторые данные, по команде запускают некий метод и меняют своё состояние. Более того, они имеют поля-состояния и когда питания нет.

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

Нет, ты их не видел IRL, иначе не порол бы такую чушь. Электрические цепи — это целиком и полностью состояния, и только они. ФП тут сосет настолько глубоко, что любая глубокая глотка могла бы позавидовать.

Цепь состоит из блоков-объектов, которые получают некоторые данные, по команде запускают некий метод и меняют своё состояние.

Ну тут явные лишние сущности.

Более того, они имеют поля-состояния и когда питания нет.

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

И не нужны там никакие поля, сообщения и т д.

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

Садись, 2. Открывой учебник Баскакова, да прочитай главу про математические модели цепей, умника не корчи.

Ну тут явные лишние сущности.

Где?

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

А есть триггеры, ПЗУ и прочие штуки, которые хранят состояние и не могут быть функциями ни в каком виде.

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

Даже в sicp в третьей главе про объекты и состояния есть пример про электрические цепи.

и не могут быть функциями ни в каком виде.

Вообще-то могут. Есть функция задержки, например)

Описывают же как-то рекурсивные ЦФ.

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

И не нужны там никакие поля, сообщения и т д.

Вот тебе простейшая электрическая цепь:

to source______/ ____rele____lamp___ to source
to source_____________/ _____lamp2__ to source

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

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

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

просто поля и вся фигня тут - лишние сущности, достаточно просто функций и данных.

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

Данные у тебя одни, входные, которые преобразуются в выходные.

Данные у тебя одни, входные, которые преобразуются в выходные.

Состояния каких нибудь озу ты где хранишь?

Состояния каких нибудь озу ты где хранишь?

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

У чувака либо адовая каша в голове, либо, скорее всего, он троллит. После той ссылке «о вреде ООП» я бы вообще не связывался. Хотя, смеха ради, попроси его ссылку на его репозитории с кодом.

У тебя входные данные это замкнут или разомкнут ключ?

Так элементарно описывается, не?

Вот тебе на хаскиле, который я не знаю:

rele :: Int -> (Int, Int)
rele x = case x of
  1 -> (1, 0)
  0 -> (0, 1)

Ты толи совсем дурачек, то ли притворяешься. Нужно не описать, а реализовать — то-есть модулировать работу. А то что ты кукарекаешь, действительно, сродни математической демагогии. У меня есть яблоко, надо его разделить надвое. Ответ ФП-дегенерата: 1/2. Только от этого яблоко не разделится на две части. Нужны средства для этого.

переменные могут существовать

И где существует переменная, которая хранит состояние триггера? В какой функции, если каждая функция живёт только в момент прохождения сигнала через узел?

Объекты, обменивающиеся сообщениями, - это явно гуманитарии придумали.

Когда в детстве пытался осознать эту фразу, никак не мог понять механизм «обмена сообщениями», пока, наконец, не дочитал, что «сообщение» — это просто вызов метода объекта.

модулировать

Что делать?

сродни математической демагогии

Ну а как же ты без математики это все моделировать собрался?

Ты сначала с первым вопросом разберись. Реализуй эту парашу хоть как нибудь хоть с математикой хоть без нее. А то что ты написалэто ысе равно, что я русским языком написал бы

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

Такая «реализация» под силу младенцу или секретутке. В каком месте ты инженер тогда?

И где существует переменная, которая хранит состояние триггера? В какой функции, если каждая функция живёт только в момент прохождения сигнала через узел?

Нигде. Тебе нужна функция задержки, я же сказал.

если каждая функция живёт только в момент прохождения сигнала через узел?

Нет конечно, что за бред, у тебя функция от времени.

функция задержки

Какая нах*й задержка, если в ФП нет времени?

Такая «реализация» под силу младенцу или секретутке. В каком месте ты инженер тогда?

Каков вопрос, таков ответ. Ты запили нормальную схемку для начала со всеми данными, сопротивлениями проводников, паразитными емкостями, индуктивностями и т д, тогда это можно моделировать.

А когда начнешь моделировать, ты в любом случае элементы будешь как функции представлять, как ты их по-другому сможешь описать?

Тебе нужна функция задержки, я же сказал.

А поподробнее? Я как человек от ООП понимаю так, что нечто запускает «функцию цепи», которая запускает функции над каждым элементом. Так где хранится текущее состояние элементов?

Функции - тоже объекты. Тут нет противоречия.

если в ФП нет времени

Ну приехали, в фп состояний нет, функцию от времени тебе кто запрещает запилить?

Так где хранится текущее состояние элементов?

Нигде. Когда ты моделируешь сигнал, ты же даешь не мгновенные значения на вход, а сигнал на определенном временном отрезке. Некая входная S(t), цепь описывается переходной функцией h(t), на выходе получишь свертку.

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

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

Там безо всякой схемы все любому дебилу понятно по описанию.

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

Ты что же маленький, даже не понял, что делает эта цепь?

Ты что же маленький, даже не понял, что делает эта цепь?

Ты мне лучше модель этой цепи покажи. Мне интересно, как ты ее смоделируешь.

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

Ну а как же ты, малыш представляешь себе проектирование без моделирования? Типо, декларативно описал, КАК ДОЛЖНА работать схема, а реализацией пусть занимаются инженера? Это типа как принцесса на горошине, сказала, я хочу чтобы у меня было авто, чтоб ездило со скоростью такой-то такой-то, была полулимузином, полукабриолетом, покрашена была бы в серебристый металлик, и чтобы музыка вней была — это она спроектировала автомобиль, по-твоему? Хватит уже, у меня легкие уже от смеха отваливаются, иди лучше в ученики к Петросяну.

не могу

Ясно, слив засчитан.

Что не могу? Это ты тут распинался, что на чистом ФП можно проектировать схемы, а то что в ООП это можно делать и так никто не сомневается, открой хоть 3-ю главу SICP и посмотри как это делается с полусумматором, не позорься.

Ну почитай про моделирование рекурсивных цепей.

Ссылку можно?

что на чистом ФП можно проектировать схемы

Цитату, пожалуйста.

открой хоть 3-ю главу SICP и посмотри как это делается с полусумматором

Ну так вот тебе и модель твоей релешки, на вход единица или ноль, на выход - кортеж.

По-другому ты ее не смоделируешь, не имея данных об импедансах.

http://btdigg.org/search?info_hash=&q=цепи и сигналы

Можно.

Цитату, пожалуйста.

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

По-другому ты ее не смоделируешь

Так что ж ты тогда весь тред голову людям морочишь, что ее можно спроектировать в ФП?

Я уже понял, что чукча не читатель, либо никогда не проектировалцепи.

Так что ж ты тогда весь тред голову людям морочишь, что ее можно спроектировать в ФП?

Спроектировать что-либо нельзя в языке.

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

Вот для моделирования используются именно декларативные языки, да

https://ru.wikipedia.org/wiki/Язык_описания_аппаратуры

Всегда узнаешь что-то новое, да?))

И чем тебе моя модель релешки не понравилась, я так и не понял.

Ты и что такое модель не знаешь, да?

короче, я понял, ты нулевой. знал бы сразу, не ввязался бы.

Как аргументированно ты меня слил, красавчик.

строить системы такие, какие ты видишь IRL.

на виденье_восприятие влияет предистория смотрящего ,

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

агрегирование.

это вредители стали абстрагировать вызов в сообщение.

по чистому

сообщение это набор бит приходящий актору. актор диспатчит сообщение , меняет(возможно) своё состояние и также делает 0 и более сообщений.

на виденье_восприятие влияет предистория смотрящего ,

Если видишь функции, то наверное ФП для тебя будет привычнее. Но к доктору всё же обратись :3

жООПщикам надо к дохтуру обращаться.

И всяким идиотам, которые исповедуют С♯, жабку, пхытон и прочую порнуху.

Кстати, SystemVerilog вполне настоящий ООП язык.

нет именно инкапсуляцию, агрегирование это совсем другое.

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

При таком подходе, о котором ты говоришь, от «функционального» подхода, там остается только название.

Когда в детстве пытался осознать эту фразу, никак не мог понять механизм «обмена сообщениями», пока, наконец, не дочитал, что «сообщение» — это просто вызов метода объекта.

«сообщение» — это просто вызов метода объекта.

И неправильно понял. Так только в популярных ООП ЯП.

ох жеж.

в С плохо(не вполне всем удобно через static всем рулить) с модульностью было ( до пространств_имён С++) поэтому сокрытие прикрутили через доступ к полям тем более атд были модны.

в рантайм-языках объект по сути сам решает какой у него интерфейс сей момент т.е. есть не столько сокрытие сколько лицемерие.

сообщение это набор бит приходящий актору. актор диспатчит сообщение , меняет(возможно) своё состояние и также делает 0 и более сообщений.

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

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

на виденье_восприятие влияет предистория смотрящего

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

Причем тут фп вообще? В любой парадигме все то же самое. Ты говоришь про слои абстракции.

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

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

:

A Plea for Lean Software