Комментарии 40
Статья из серии «зачем просто, если можно сложно». Очень много всего навернуто. Лично мне в первую очередь восприятию мешают постоянное употребление Придуманных Терминов (ПТ).
Дальше имеется очень много сомнительных терминов, которые довольно поверхностно раскрываются.
Когда я это прочитал, струя известной жидкости тут же ударила мне в Ментальный Орган (МО).
Теперь серьезно, почему объясняя реактивное программирование не упомянуть реактивный манифест? Пытаясь писать о реактивном программировании абстрактно, вы все равно скатываетесь конкретно в rx, а ведь на нем свет клином не сошелся. Есть, к примеру, акторная модель, которая вполне себе реактивное программирование, при этом в ней нет явно выраженных потоков. Еще смущает противопоставление реактивного программирования ООП с чем я бы поспорил, но лень.
Если тут есть джаверы, то я бы им дал самое простую Ментальную Модель для потоков реактивного программирования: поток в rx это такой же stream только во времени. Из-за этого доступно множество новых средств его трансформации. Вот и все, понятно что есть нюансы, но это то самое, от чего бы я отталкивался.
Дальше имеется очень много сомнительных терминов, которые довольно поверхностно раскрываются.
Струя
Когда я это прочитал, струя известной жидкости тут же ударила мне в Ментальный Орган (МО).
Теперь серьезно, почему объясняя реактивное программирование не упомянуть реактивный манифест? Пытаясь писать о реактивном программировании абстрактно, вы все равно скатываетесь конкретно в rx, а ведь на нем свет клином не сошелся. Есть, к примеру, акторная модель, которая вполне себе реактивное программирование, при этом в ней нет явно выраженных потоков. Еще смущает противопоставление реактивного программирования ООП с чем я бы поспорил, но лень.
Если тут есть джаверы, то я бы им дал самое простую Ментальную Модель для потоков реактивного программирования: поток в rx это такой же stream только во времени. Из-за этого доступно множество новых средств его трансформации. Вот и все, понятно что есть нюансы, но это то самое, от чего бы я отталкивался.
Придуманных Терминов (ПТ).
В статье вводится только один термин — Ментальные Модели (ММ). Другие авторы, в том числе и на Хабре, используют этот термин.
Дальше имеется очень много сомнительных терминов, которые довольно поверхностно раскрываются.
Термины типа «Струя» не вводятся, а упоминаются. Идея состоит указать место РП в общем ландшафте Программирования. Для этого названы его соседи, без их детального описания.
Теперь серьезно, почему объясняя реактивное программирование не упомянуть реактивный манифест?
Я не ставил задачу объяснить РП. Задача состояла рассказать о полезных с практической точки зрения Ментальных Моделях РП.
Еще смущает противопоставление реактивного программирования ООП
Речь идёт о различие Ментальных Моделей полезных при программировании в рамках ООП и РП. Они действительно разные.
поток в rx это такой же stream только во времени
Нет. Rx**, по крайней мере RxJS елементарно намного больше. В статье я упоминаю про радикально другой способ обработки ошибок, большое количество способов комбинирования струй. Детали в книге по RxJS. Вы действительно хорошо знаете оба инструмента, чтобы так судить?
Мне кажется, вы невнимательно прочитали статью, упустив шанс взять из неё кое-что полезное для себя.
В статье вводится только один термин — Ментальные Модели (ММ)
Задача состояла рассказать о полезных с практической точки зрения Ментальных Моделях РП
Речь идёт о различие Ментальных Моделей полезных при программировании в рамках ООП и РП
Ментальные модели, ментальные модели, ментальные модели… Объясните что это такое. Объяснение из статьи, мягко говоря, философско-сумбурное:
в голове заказчика или самого исполнителя появляются смутные идеи или представления о бушующем продукте или изменении существующего. Будем называть их Ментальными Моделями (ММ)
После этого вы все сводите к этому определению, очень удобно.
в общем ландшафте Программирования
Что такое ландшафт программирования? Что в нем овраги, а что возвышенности?
Rx**, по крайней мере RxJS елементарно намного больше.
Чего больше? Я же рассказываю про Ментальную Модель.
Мне кажется, вы невнимательно прочитали статью
Нет уж, спасибо, в третий раз не буду.
Ментальные модели, ментальные модели, ментальные модели… Объясните что это такое. Объяснение из статьи, мягко говоря, философско-сумбурное:
В моей статье, на которую я ссылаюсь как литературная ссылка N1, я привел размышления на эту тему. И там признаётся, что точного определения этому термину нет. Мы можем наличие ММ регистрировать (знаю или не знаю, как пользоваться RxJS, утюгом или самолётом?). Но мы не можем их измерять приборами. Пока.
Это интересно. Это важно. Но ученые занимаются теми вопросами, где можно защитить диссертацию или опубликовать рейтинговую статью, получить грант.
Так что строго определения ММ я не знаю, и боюсь, его пока нет вообще.
Что такое ландшафт программирования? Что в нем овраги, а что возвышенности?
Термин взят из «кровавого энтерпрайза», где любят говорить о ландшафте ИТ систем. Я нахожу эту метафору очень удачной. И как я указываю, таблица инспирирована таблицей из книги о RxJS. Эту книгу очень советую почитать.
Чего больше
Список функций RxJS значительно больше, чем список методов класса Stream в Java. Но это не только количественное различие, но и качественное. В RxJS используется много понятий, которых мне лично недостаёт в Java Stream. И это — не пустые фантазии или теоретизирование, а потребности практики.
Так что строго определения ММ я не знаю, и боюсь, его пока нет вообще.
Прекрасно
Список функций RxJS значительно больше, чем список методов класса Stream в Java. Но это не только количественное различие, но и качественное.
Так я и не спорил:
поток в rx это такой же stream только во времени. Из-за этого доступно множество новых средств его трансформации
И эти новые средства (методы) они в основном про то, что данные не есть сразу, а приходят во времени. Примерно это же и в спринговом reactor.
поток в rx это такой же stream только во времени. Из-за этого доступно множество новых средств его трансформации
Давайте в этом месте зафиксируем разницу мнений. С моей точки зрения, различия между Java Stream и RxJS качественное. Первое не просто небольшое подмножество второго. В RxJS присутствуют качественно новые по сравнению с Java Stream понятия, такие как «трехфазность» и многочисленные методы комбинирования потоков. Но это — моё мнение.
Как раз переходящим от Java Streams к Rx** полезно вначале узнать о важных отличиях типа «трехфазности», многообразии комбинирования потоков и так далее, а уж потом углубляться в эксперименты или детальное изучение отдельных методов.
Похоже на программный текст новой религии.
Что-то у меня этот код не запустился.
Автор, вы вообще свой пост читали?
кавычки на обычные и после .replace надо (
Но почему бы сразу не использовать dog?
Но почему бы сразу не использовать dog?
Вы правы, в первоначальном варианте не хватало скобки после replace. Похоже её «скушал» редактор. Спасибо. Изменил.
В первоначальном варианте действительно не хватало кавычки после replace. И кавычки Редактор Хабра меняет. Надо использовать обычные. Спасибо за замечание. Исправлено.
Ну а вопрос о том читает ли автор текст, отношу на плохое настроение в понедельник утром.
Ну а вопрос о том читает ли автор текст, отношу на плохое настроение в понедельник утром.
Глаза режет, когда пишут Все Подряд С Заглавных Букв.
Интересная концепция. Особенно порадовало наличие RxLua.
Похоже на программный текст новой религии.
Действительно, и, кстати, независимо, напомнило «Хорошую религию придумали индусы...»
Реактивное, событийное, акторы, корутины, горутины (думал, опечатка, оказалось нет), потоки такие, потоки сякие, асинхронное и синхронное программирование и т.д. и т.д. и т.д. Голова (пардон, Ментальный Орган) идет кругом… Может, пора остановиться и от религиозного перейти к научному познанию мира программирования.
Новое надо вводить, только доказав, что без него никуда. С точки зрения науки все просто: есть потоки информации, представимые символами, и есть преобразователи этой информации (дискретные преобразователи (ДП)). Все. Куда проще. Азы [дискретной] кибернетики (см. академика Глушкова В.М.). Любую информацию можно свести к символьной, а моделью ДП может быть машина Поста (МП), машина Тьюринга (МТ). Все эти машины как раз и перелопачивают эту самую символьную информацию. МТ — модель обычного программирования. Все — достаточно. С моделями мира программирования покончили…
Думаем, чем они нас не устраивают? Зачем нужен новый «реакционный» (опять, пардон, — реактивный) механизм? И нужен ли, если все делается в рамках «научной религии». Иначе — бардак.
Например. Понятен последовательный (опять же — курсорный, видимо) результат:
2 3 5
4 3 5
Но с какой «бухты-барахты» должно быть:
2 3 5
4 3 7
Если может быть и так:
4 3 5
2 3 7
?
А все потому, что операторы 1 и 5 элементарно по науке противоречивы. В науке не может быть одновременно X1 = 2 и X1 = 4. В религии, похоже, — без проблем. Ну уж тут надо как-то выбирать — знать или верить. Программирование, которое должно быть однозначным и предсказуемым, должно выбирать «знать». В РП, как мне представляется, остановились на «верить». А после этого уже началось какое-то «камлание». Ну, это на мой «научный взгляд» на проблему «реакционного» и «реагирного» программирования. Опять же «реактивное», думаю, больше отражает предполагаемую суть РП, если оно конечно про мгновенную, реактивную, так сказать, реакцию на возникшее событие.
Зря Вы так. Поищите рейтинги популярных Web-frameworks. Их много, но думаю в большинстве в лидерах значатся React и Angular. Трудно предположить, что сотни тысяч разработчиков тратят время на их изучение и применения исключительно по религиозным соображениям. А чтобы их правильно применять, необходимы базовые понятия (Ментальные Модели) Реактивного Программирования. Вот я и пытаюсь помочь таким коллегам.
Поверьте, их очень много среди читателей Хабра.
Возможно, когда-нибудь эти знания пригодятся и Вам.
Поверьте, их очень много среди читателей Хабра.
Возможно, когда-нибудь эти знания пригодятся и Вам.
Тут важно не количество использующих что-то, а качество того, что они используют…
Мне РП, надеюсь, уже понадобится, т.к. использую другую модель. И меня она устраивает на все 100.
Тем не менее, Ваша статья своим подходом к подаче материала понравилась. «Зажигалка» этакая :)
Но Вы не ответили по поводу замеченной мною противоречивости. Как с этим быть?
Мне РП, надеюсь, уже понадобится, т.к. использую другую модель. И меня она устраивает на все 100.
Тем не менее, Ваша статья своим подходом к подаче материала понравилась. «Зажигалка» этакая :)
Но Вы не ответили по поводу замеченной мною противоречивости. Как с этим быть?
Любую информацию можно свести к символьной, а моделью ДП может быть машина Поста (МП), машина Тьюринга (МТ). Все эти машины как раз и перелопачивают эту самую символьную информацию. МТ — модель обычного программирования. Все — достаточно. С моделями мира программирования покончили…
Увы, на МТ никто не программирует. Используют другие парадигмы, которые теоретически сводятся к МТ с помощью большого количества промежуточных слоёв.
Я не отношу себя к фанатам РП. Для меня это данность. В нескольких последних проектах приходилось с этим сталкиваться всё больше и всё ближе. Поэтому и появилась идея написать статью, чтобы поуменьшить боль другим.
На своём опыте могу подтвердить, что при решении многих задач взаимодействия UI с пользователем РП существенно элегантнее, чем традиционный подход (ООП).
РП это сложный инструмент для решения достаточно широкого круга задач. Эти решения весьма гармонично можно сочетать на практике с ООП решениями, поскольку речь не идёт (по крайней мере в моей статье) о новых языках программирования, а об расширении существующих.
Противоречия я не вижу.
Если я не понял Ваш вопрос, уточните.
Увы, на МТ никто не программирует.
У меня опечатка: МП — модель обычного программирования. Конечно, на МТ не программируют, но автоматы — это вполне аналог МТ. Так вот я на этом — автоматах.
Но вернемся к РП.
Повторю свой вопрос.
Что делать с замеченной неопределенностью, когда операторы 1 и 5 Вашего кода одновременно изменяют переменную X1 (см. также мой пост выше). Такого не может быть. Т.е. быть может, как в Вашем случае, но не должно быть. Иначе не ясно, каким будет значение X1 — 2 или 4. Или Вы допустили случайную ошибку? Или это «норма» для РП? Вот что меня очень интересует. А Вы как-то не замечаете вопроса… ;)
1. Х1 = 2
2. Х2 = 3
3. Х3 = Х1 + Х2
4. Напечатать Х1, Х2, Х3
5. Х1 = 4
6. Напечатать Х1, Х2, Х3
В тексте нет упоминания одновременности применительно к этому примеру.
Предположим переменная X1 связана с текущим курсом некоторой акции, а X2 — стоимость операции покупки (стабильна). Операция «+» означает, что вычисляется и выводится на экран стоимость возможной покупки. Меняется стоимость акции, меняется стоимость покупки.
Как это работает?
Прорабатывают строчки 1-4 мы получаем первую напечатанную строчку.
Проходит время. Запрашивается текущая стоимость акции. Она 4. Меняется и общая стоимость.
Почитайте, как это обьясняет Википедия: https://ru.m.wikipedia.org/wiki/Реактивное_программирование
Уф! Кажется понял. Точнее, догадался ;) Сейчас расскажу, как это работает. Ну, типа, как я это понял…
Есть два оператора — "+" и «Напечатать».
У первого два входа — X1, X2 и один выход — X3. На входах данные, на выходе — результат операции.
У второго — три входа — X1, X2, X3. На входе данные — печатает их значения.
1) Поступают данные — 2, 3. Вычисляем, Получаем печать — 2, 3, 5.
2) X1 меняется. Поступают данные — 4, 3. Вычисляем, Получаем печать — 4, 3, 7.
Есть вопросы по поводу синхронизации данных с работой операторов, но пока не будем «придираться».
Нет, ну, как? Как об этом можно узнать, догадаться (?), глядя на код примера?
Это, конечно, если я еще правильно интерпретировал работу кода. Но, честное слово, и здесь меня еще одолевают сомнения…
Моя Ментальность Программиста (МП) что-то бастует и не хочет воспринимать подобный код. Код, о работе которого нужно «догадываться» :)… Неужели это и есть РП? Я себе это представлял по-другому.
Есть два оператора — "+" и «Напечатать».
У первого два входа — X1, X2 и один выход — X3. На входах данные, на выходе — результат операции.
У второго — три входа — X1, X2, X3. На входе данные — печатает их значения.
1) Поступают данные — 2, 3. Вычисляем, Получаем печать — 2, 3, 5.
2) X1 меняется. Поступают данные — 4, 3. Вычисляем, Получаем печать — 4, 3, 7.
Есть вопросы по поводу синхронизации данных с работой операторов, но пока не будем «придираться».
Нет, ну, как? Как об этом можно узнать, догадаться (?), глядя на код примера?
Это, конечно, если я еще правильно интерпретировал работу кода. Но, честное слово, и здесь меня еще одолевают сомнения…
Моя Ментальность Программиста (МП) что-то бастует и не хочет воспринимать подобный код. Код, о работе которого нужно «догадываться» :)… Неужели это и есть РП? Я себе это представлял по-другому.
Ну вот, дискуссия становится интереснее.
Видите, у Вас была какая-то ментальная модель. Она оказалось неприменимой.
Напомню, что пример находится в параграфе под названием:
«Неожиданности-опасности, или что в РП не так, как мы все привыкли«.
Теперь вы помните, что имея дело с РП, надо помнить, что там не курсор, а вычислительный граф.
Случай из практики. Представьте себе, у Вас есть формуляр с паром десятков полей ввода. В каждое поле можно ввести значение, но система в зависимости от ввода в одном поле может подправить поля в других. Таких правил много. Также много правил валидации. Как одиночных полей, так и зависимых групп значений (типа x < y <z). Получается два вычислительных графа: вычисления значений и валидации. Первый запускается, если пользователь меняет значение в любом из полей. Второй запускается, если прокачан первый.
Впрочем, самый распространённый пример вычислительного графа — Excel, где значения в одних клетках вычисляются в зависимости от значений в других сразу же после окончания ввода.
Люди, как герой Бомарше, не знавший, что говорил всю жизнь прозой, не знают, что занимаются Реактивным Программированием.
Я себе это представлял по-другому.
Видите, у Вас была какая-то ментальная модель. Она оказалось неприменимой.
Напомню, что пример находится в параграфе под названием:
«Неожиданности-опасности, или что в РП не так, как мы все привыкли«.
Теперь вы помните, что имея дело с РП, надо помнить, что там не курсор, а вычислительный граф.
Случай из практики. Представьте себе, у Вас есть формуляр с паром десятков полей ввода. В каждое поле можно ввести значение, но система в зависимости от ввода в одном поле может подправить поля в других. Таких правил много. Также много правил валидации. Как одиночных полей, так и зависимых групп значений (типа x < y <z). Получается два вычислительных графа: вычисления значений и валидации. Первый запускается, если пользователь меняет значение в любом из полей. Второй запускается, если прокачан первый.
Впрочем, самый распространённый пример вычислительного графа — Excel, где значения в одних клетках вычисляются в зависимости от значений в других сразу же после окончания ввода.
Люди, как герой Бомарше, не знавший, что говорил всю жизнь прозой, не знают, что занимаются Реактивным Программированием.
Видите, у Вас была какая-то ментальная модель. Она оказалось неприменимой.
Конечно, есть и применима.
Вот структурные модели двух вариантов моего «ментального решения»:
Структурные модели
А вот это их алгоритмические модели:
Алгоритмические автоматные модели
Пояснять их пока не буду, т.к. это, пожалуй, тянет почти на статью, но уже по поводу моего ментального мышления. Но структурные, надеюсь, достаточно очевидны.
Даже не буду утверждать, что нет ошибок. Надеюсь, что нет.
Респект, как говорят немцы в таких случаях.
Если не ошибаюсь, Ваши алгоритмические модели — это варианты Конечных Автоматов.
Думаю, вы согласитесь, что запись для такой простой задачи громоздкая.
Хотя Конечные Автоматы как вид Ментальных Моделей для определённых случаев очень хорошо подходит.
За конечными автоматами стоит мощная математическая теория. А вот для потоков я такой теории, признаться, не знаю. И мои знакомые математики не знают. Хотелось бы найти для описания потоков не абстрактные механизмы, что-то по конкретности похожее на графы, матрицы или интегралы. Но пока формализация сводится к словесным описаниям, Марбл-диаграмам и примерам. Но может, плохо ищу.
Кстати, когда я собирался отвечать на ваш пост, он уже получил -1. Я его «выровнял». Интересно было бы понять мотивацию минусовальщика (или миносовальщицы) именно такого поста.
А как вы относитесь к описанию семантики с помощью UML?
Если не ошибаюсь, Ваши алгоритмические модели — это варианты Конечных Автоматов.
Думаю, вы согласитесь, что запись для такой простой задачи громоздкая.
Хотя Конечные Автоматы как вид Ментальных Моделей для определённых случаев очень хорошо подходит.
За конечными автоматами стоит мощная математическая теория. А вот для потоков я такой теории, признаться, не знаю. И мои знакомые математики не знают. Хотелось бы найти для описания потоков не абстрактные механизмы, что-то по конкретности похожее на графы, матрицы или интегралы. Но пока формализация сводится к словесным описаниям, Марбл-диаграмам и примерам. Но может, плохо ищу.
Кстати, когда я собирался отвечать на ваш пост, он уже получил -1. Я его «выровнял». Интересно было бы понять мотивацию минусовальщика (или миносовальщицы) именно такого поста.
А как вы относитесь к описанию семантики с помощью UML?
Если не ошибаюсь, Ваши алгоритмические модели — это варианты Конечных Автоматов.
Ошибаетесь только в одном — это и есть автоматы. Вот UML — это варианты, которые я, что там лукавить, отрицаю. Просто потому, что эти «варианты» от автоматов оставили только одно — название «автоматы». В остальном UML я даже уважаю. За фундаментальность и технологичность.
Думаю, вы согласитесь, что запись для такой простой задачи громоздкаяНе соглашусь. Может Вы не заметили, но я дал два решения — сложное 4 кубика (см. структурные модели) и простое — 1 кубик (см. имя Pr и два входа). Соответственно — сеть автоматов и один автомат.
Хотя Конечные Автоматы как вид Ментальных Моделей для определённых случаев очень хорошо подходит.Автоматы — универсальная модель, которая подходит для всех случаев. Отражая те или иные нюансы она может выглядеть громоздкой, но она делает очевидным то, что скрывает более «компактная» модель типа РП. Вот РП — «для определенных случаев». Что делает функция в РП, когда данные для нее не готовы? Насколько я понимаю — ничего. Но в жизни это обычная ситуация (частичная готовность данных). Для автоматов — это тоже не проблема. И приведенный «простенький автомат» это демонстрирует: жесткость модели РП и гибкость автоматов (хотите сложно и в деталях — пожалуйста, хотите просто — без проблем).
Но может, плохо ищу.И книги есть и есть даже теории. Но все достаточно специфично и не годится для создания универсальной теории (или может я тоже не знаю такой).
Интересно было бы понять мотивацию минусовальщикаНекоторые чувствуют себя плохо, когда другим хорошо. Я это тоже заметил и даже задавал вопрос — за что. Молчат и мелко так «гадят». Поэтому на подобные «минусовки» я просто не реагирую. Мне и так хорошо. А Вам «алаверды» за попытку восстановить справедливость :)
А как вы относитесь к описанию семантики с помощью UML?Семантика, как и сама модель Харелла, — мощнейшие (сколько же труда было в вложено в эту разработку!) и я ими только восхищаюсь. Но содержание, смысл «автоматов UML», как говорил один персонаж Райкина, — жутчайшие.Я бы назвал это «автоматной ересью». Почему этого не видят другие — для меня необъяснимо.
Возможно, в этом месте дискуссии полезно вернуться к теме и посмотреть на обсуждаемые темы сверху.
Итак, я рассматриваю процесс создание или модификации software (ПО) как материализацию идей.
Он начинается с зарождения Ментальных Моделей и заканчивается созданием программного кода (этапы тестирования и ввода в эксплуатацию я для упрощения опускаю).
Между ММ и кодом могут лежать полезные или отвлекающие промежуточные модели. От ММ и кода нам никуда не уйти, а вот нужны ли промежуточные модели и если да, то какие — вопрос пока открытый. Промежуточные модели — это артефакты, а не ментальные образы. Они могут быть неформальные или формальные. UML и различные модели автоматов — формальные модели.
Достоинство ММ РП в том, что они могут быть обращены в код без привлечения промежуточных моделей.
Но не стоит преувеличивать сферу их применимости. Там, где они неприменимы, почти всегда целесообразно вначале применить промежуточные модели, и только потом начинать кодировать. Поэтому и UML и модели автоматов надо изучать и «подтягивать» их в мир своих ментальных моделей.
Что вы скажете на это?
Итак, я рассматриваю процесс создание или модификации software (ПО) как материализацию идей.
Он начинается с зарождения Ментальных Моделей и заканчивается созданием программного кода (этапы тестирования и ввода в эксплуатацию я для упрощения опускаю).
Между ММ и кодом могут лежать полезные или отвлекающие промежуточные модели. От ММ и кода нам никуда не уйти, а вот нужны ли промежуточные модели и если да, то какие — вопрос пока открытый. Промежуточные модели — это артефакты, а не ментальные образы. Они могут быть неформальные или формальные. UML и различные модели автоматов — формальные модели.
Достоинство ММ РП в том, что они могут быть обращены в код без привлечения промежуточных моделей.
Но не стоит преувеличивать сферу их применимости. Там, где они неприменимы, почти всегда целесообразно вначале применить промежуточные модели, и только потом начинать кодировать. Поэтому и UML и модели автоматов надо изучать и «подтягивать» их в мир своих ментальных моделей.
Что вы скажете на это?
А смотрю на процесс классически — как нас учили. Материализация идеи не может пропустить ни один этап своей разработки — структурный, алгоритмический, кодирование. По сути Вы говорите о кодировании. О первых — как артефактах. Я считаю кодирование самым элементарным в этой цепочки, а первые — самые главные. Даже если первых двух нет в явном виде они есть в неявном. Т.е. их всегда можно представить «начальнику», если он этого потребует. Все это входит в этапы документирования процесса проектирования. Программисты часто представляют только код и им кажется или создается впечатления, что другого «артефакта» и быть не может. Программистам «сломали мозги», когда разрешили не рисовать блок-схемы. А это важно. Код может быть разным, модель в его основе — одна. Это и есть теория. Или, скажем так, с этого она начинается — нарисовать блок-схему, структурную модель и т.д. и т.д. Вот этим, кстати, мне и нравится UML. «Артефакты» (а я скажу — [формальные] модели) первичны, код — вторичен.
И моя позиция строго следующая: нужно мир своих ментальных моделей облекать в форму формальных моделей. Без этого ментальные модели превращаются в некое подобие «веры», а формальные — в «знание». Этим, как говорил Жорес Алферов, и отличается религия от науки.
Кстати, возник совсем «свежий» вопрос — а чем отличается наука от производства? В производстве, думаю, главное стандарты. Когда-то я заикнулся, что мы создали стандарт предприятия на автоматы. Буквально на днях его у меня попросили. Потому, что возник бардак: автоматы-то были созданы, но каждый [программист] их представлял по-своему. Возник «затык». Производство не может быть эффективным без науки. Речь не о «ментальном» — кустарном (в хорошем смысле, конечно). Что интересно (на мой взгляд), [формальная] наука может существовать и без производства, но только полезная наука находит рано или поздно свое воплощение в производстве, скажем так.
Вот такая у меня «философия». Конечно, не моя — меня ей обучили, а где-то ей я научился сам (по книжкам). Нынешняя «философия программирования» во многом, если говорить Вашей классификацией, ментальная. Потому-то когда я на хабре попросил объяснить, чем же отличаются «корутины» от известного уже лет так 60-т понятия сопрограммы меня, похоже, совсем не поняли. И объяснить отличие не смогли. Мол все очевидно, а вот как сказать по-русски не знаем.
И еще добавлю. Ментальное (мне больше нравится слово — образное) представление, как и кустарное производство весьма важны. С них все начинается. И удача, если первое становится наукой, а второе — из кустарного становится промышленным.
И моя позиция строго следующая: нужно мир своих ментальных моделей облекать в форму формальных моделей. Без этого ментальные модели превращаются в некое подобие «веры», а формальные — в «знание». Этим, как говорил Жорес Алферов, и отличается религия от науки.
Кстати, возник совсем «свежий» вопрос — а чем отличается наука от производства? В производстве, думаю, главное стандарты. Когда-то я заикнулся, что мы создали стандарт предприятия на автоматы. Буквально на днях его у меня попросили. Потому, что возник бардак: автоматы-то были созданы, но каждый [программист] их представлял по-своему. Возник «затык». Производство не может быть эффективным без науки. Речь не о «ментальном» — кустарном (в хорошем смысле, конечно). Что интересно (на мой взгляд), [формальная] наука может существовать и без производства, но только полезная наука находит рано или поздно свое воплощение в производстве, скажем так.
Вот такая у меня «философия». Конечно, не моя — меня ей обучили, а где-то ей я научился сам (по книжкам). Нынешняя «философия программирования» во многом, если говорить Вашей классификацией, ментальная. Потому-то когда я на хабре попросил объяснить, чем же отличаются «корутины» от известного уже лет так 60-т понятия сопрограммы меня, похоже, совсем не поняли. И объяснить отличие не смогли. Мол все очевидно, а вот как сказать по-русски не знаем.
И еще добавлю. Ментальное (мне больше нравится слово — образное) представление, как и кустарное производство весьма важны. С них все начинается. И удача, если первое становится наукой, а второе — из кустарного становится промышленным.
Материализация идеи не может пропустить ни один этап своей разработки — структурный, алгоритмический, кодирование.
Эти фазы три остались в прошлом, как мне кажется, поскольку абсолютное большинство программистов занимается исправлением ошибок, миграцией на новые платформы, улучшениями характеристик, впиливанием мелких деталий.
При этом перед ними нет формальных моделей и некогда их составлять.
Часто и кода, как такового, нет. В «кровавом энтерпрайзе», системы разрабатываются с помощью инструментов от IBM, SAP и других монстров на три буквы и больше. И в этих инструментах большие системы делаются с помощью заполнения формуляров, а не написания кода на языке программирования.
Т.е: промежуточных формальных моделей нет, кода нет. В этой ситуации я призываю иметь развитую систему Ментальных Моделей, включая ММ РП.
Ментальное (мне больше нравится слово — образное)
Слово «образное» ассоциируется с визуальными образами. Но многие люди мыслят «невизуально».
второе — из кустарного становится промышленным.
В Программировании, как а Датском Королевстве что-то прогнило. Как саранча налетели агильные менаджеры и сожрали ростки модельного подхода.
Дом за сто тысяч долларов строят по чертежам, а систему той же стоимости (и существенно более дорогие!) строят агильно, решая на собраниях, что бы нам взять из бэг-лога да привинтить.
Но увы, это реальность сегодняшнего дня во всём мире.
промежуточных формальных моделей нет, кода нет.
К счастью, пока еще «в резервациях» есть и другое программирование. Иначе бы не появлялись системы визуального программирования типа Stateflow в MATLAB. За подобным подходом, на мой конечно взгляд, будущее.
Как саранча налетели агильные менаджеры и сожрали ростки модельного подхода.
Не все им по зубам. Я занимаюсь системами управления в жестком реальном времени. Тут они просто не выживают :)
Другое дело, что подобного программирования у нас все меньше и меньше. Оно исчезает вместе с производством. Но это у нас. Мы можем сотворить Kotlin и переизобрести корутины в нем, но программирование типа MATLABа — это не про нас. И это тоже реалии. Раньше самолеты делали с лог.линейкой и кульманом чуть ли не за год, а сейчас «агильные менеджеры» даже один самолет никак не могут осилить.
И кто же это так Вас не любит и столь реактивно минусует ваши посты?
«в асинхронно-реактивном мире следующая операция не ждёт окончания предыдущей, если она предыдущая) асинхронная»
Не совсем так. Если вы выполняете операцию reduce над элементами потока, например, для получения суммы элементов, по следующая операция сложения ждет окончания предыдущей. В модели акторов такое ожидание встроено по умолчанию, а в реактивном программировании с этим туго. Хорошо, если найдется подходящий уже реализованный паттерн, например, reduce, а построить самому обработчик, эквивалентный по поведению актору, на базе фрейморков реактивного программирования затруднительно.
Не совсем так. Если вы выполняете операцию reduce над элементами потока, например, для получения суммы элементов, по следующая операция сложения ждет окончания предыдущей. В модели акторов такое ожидание встроено по умолчанию, а в реактивном программировании с этим туго. Хорошо, если найдется подходящий уже реализованный паттерн, например, reduce, а построить самому обработчик, эквивалентный по поведению актору, на базе фрейморков реактивного программирования затруднительно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ментальные Модели Реактивного Программирования для начальников