ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Подходы к построению архитектуры в функциональном программировании
207 сообщений из 207, показаны все 9 страниц
  все  
Подходы к построению архитектуры в функциональном программировании
    #39920433
redkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
redkij
Гость
Всем привет.
Для ООП есть ряд книг, которые признаны более или менее классическими и описывают подходы к процессу разработки и построению архитектуры крупного приложения. Шаблоны банды четырех, DDD Эрика Эванса, SOLID и Clean architecture Боба Мартина, Рефакторинг Фаулера, книги по TDD, труды Бертрана Мейера, Dependency Injection in .NET Марка Симана и тд
То есть книги описывают не только сам подход ООП, но и как на нем построить какое-то более-менее сложное приложение для реальных нужд. Своего рода best practices.
Есть ли что-то подобное для функционального программирования?
...
Рейтинг: 0 / 0
30.01.2020, 12:20
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920514
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Есть: Кнут (трёхтомник), Вирт (структуры + алгоритмы = программа).
...
Рейтинг: 0 / 0
30.01.2020, 14:45
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920522
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kealon(Ruslan)
Участник
redkij,

https://wiki.nsunc.com/haskell

http://anton-k.github.io/ru-haskell-book/files/ru-haskell-book.pdf
...
Рейтинг: 0 / 0
30.01.2020, 15:00
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920523
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
ФП книжки больше по языкам профилируются.

Из ФП подобной теории я не встречал. ФП пришло из математики поэтому ихние первоисточники
скорее всего читать будет невозможно для простого it-мозга. Функциональщики втаскивают в предмет
обсуждения монады, комбинаторы и формальные логические системы наподобие prolog, грамматики.
Для них - это легко. А для нежного мышления испорченного J2EE/Spring это будет смерти подобно.
Вы 90% ничего не поймете даже по мотивации к применению.

Из наиболее "теоретичного" я помню Романа Душкина с его Haskell. Книжка - негодная для изучения
практики Haskell. Ну по крайней мере она мне лично показалась в этом смысле бесполезной. Хотя
она касалась целей и назначений Хаскела. Там хотя-бы описываются цели и задачи.
И даётся кратая вводная по математике. Это какраз то про что на youtube вообще ничего не говорят.
Там - сразу идут - упражнение №1. Частично-вычислимые функции и так далее. Рекурсии. Бесконечные
списки.

Из теоретичного - есть SICP. Только (ахтунг!) там не чистый Common Lisp, а диалект наподобие FrancLisp или Scheme
я не помню точно. SICP считается must have для всех кто изучает правильное ФП программирование.
Но мне он тоже показался нудным. Не все главы я читал.

Из best-practices - нет почти ничего. Тоесть я не находил. Но есть неплохой журнал http://fprog.ru/
который заглох и в настоящее время не публикуется.
В нем есть различные статейки по проектам и есть даже сорцы.

Еще из практики - можно поискать проекты на github по стикерам Haskell но активности в них раз в 100
меньше чем в других проектах и авторы или умерли давно или не интересуются своим проектом.

Грубо говоря функциональщики считают что если ты просто сделал декомпозицию задачи на функции -
то это есть самый главный и осново-образующий паттерн. Это 80% успеха парень. А шаблоны типа
банды четырех в ФП найух не впились. Зачем в ФП синглтон? Там его нет - и нет проблемы.

Чуть позже я могу приаттачить библиографию своих книжек которые перечислил и еще кое-что добавлю если интересно.
Но это опять-же не про паттерн
...
Рейтинг: 0 / 0
30.01.2020, 15:00
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920577
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Мне кажется человек интересуется именно подходом к разработке в функциональном стиле применительно в архитектуре. Язык и технологии не особо важны. ФП-шные подходы к разработке можно (и нужно) успешно применять в Java, Python, C#, и практически в любом современном языке.

Нежели про глубокую лютую функциональщину, которую суровая реальность вертела на одном месте, вместе со всеми лиспами, хаскелями, оставляя им очень узкую нишу и дисциплину, где всё не-ФП считается святотатством и жестоко карается :)

По мне, уместная комбинация подходов порой приводит к удивительному профиту.
...
Рейтинг: 0 / 0
30.01.2020, 16:31
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920584
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Нет смысла этим интересоваться находясь исключительно в контексте Java/C#.
Всё про эти языки уже описано Фаулером, Мартином (другим мартином) и никаких
исключительных кивков в адрес ФП они не делают.

Тоесть автору надо определиться в какую сторону языковых наук он пойдет. Чистая теория ООП и ФП
расходится в разные стороны именно на языках.
...
Рейтинг: 0 / 0
30.01.2020, 16:44
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920616
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Может нужно отталкиваться от того, для каких бизнес-задач данный язык более-менее преднозначен

Знал в 90-ые людей пишуших на Прологе для фирмы-создателя Пролога... с каким же вожделением они смотрели на Borland C, Turbo C и Windows API, когда им нужно было на Прологе интерфейсы дли прикладной системы рисовать )))

Вроде, в результате, потом интерфейсы на C и стали рисовать.
...
Рейтинг: 0 / 0
30.01.2020, 17:53
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920639
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Назначение у Пролога было другое.
...
Рейтинг: 0 / 0
30.01.2020, 18:14
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920646
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kealon(Ruslan)
Участник
однако если вспомнить, то прообраз хаскеля - миранда, использовалась как раз для создания менеджера окон X Window System (xmonad)
...
Рейтинг: 0 / 0
30.01.2020, 18:23
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920650
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Никогда не видел на функциональных языках ничего UI-ного.
Я думаю что их сфера применения - это какой-то back-end.
Вроде как фейсбук использует Хаскель для умных спамо-фильтров.
Вот - применение.
...
Рейтинг: 0 / 0
30.01.2020, 18:32
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920663
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anatoly Moskovsky
Участник
Лучшее доказательство того что чисто функциональные языки не годятся для создания реальных сопровождаемых систем это размер доказательства теоремы Ферма в сравнении с решаемой проблемой.
...
Рейтинг: 0 / 0
30.01.2020, 19:00
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920670
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kealon(Ruslan)
Участник
Anatoly Moskovsky
Лучшее доказательство того что чисто функциональные языки не годятся для создания реальных сопровождаемых систем это размер доказательства теоремы Ферма в сравнении с решаемой проблемой.
вы не путаете функциональное и символьное?
...
Рейтинг: 0 / 0
30.01.2020, 19:04
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920676
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anatoly Moskovsky
Участник
kealon(Ruslan)
вы не путаете функциональное и символьное?

Это неважно в данном контексте.
Функциональное - в смысле разработанное на основе математики и математиками.
Судя по всему математиков не интересуют вопросы сопровождаемости их "кода".
...
Рейтинг: 0 / 0
30.01.2020, 19:15
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920680
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Anatoly Moskovsky
Лучшее доказательство того что чисто функциональные языки не годятся для создания реальных сопровождаемых систем это размер доказательства теоремы Ферма в сравнении с решаемой проблемой.

Большая?

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

Давайте хоть зайдем со стороны простых доказательств.
...
Рейтинг: 0 / 0
30.01.2020, 19:20
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920707
Фотография полудух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
полудух
Участник
Anatoly Moskovsky
Судя по всему математиков не интересуют вопросы сопровождаемости их "кода".

вброшу ещё раз, это всегда актуально :
авторВ сравнении с программистами, математики это "плохой (ужасный) код":
1. высшая степень абстракции (все операции в уме, а на выходе набор букв с цифрами);
2. "буквы" в прямом смысле - все переменные однобуквенные, нихрена непонятные;
3. им не хватает букв на все переменные, но математики продолжают жрать кактус;
4. никакого форматирования;
5. 0 (ноль) комментариев;
6. даже при наличии "готового кода", напиленного предыдущими математиками, они его постоянно дублируют;
7. часто (особенно в вышке) требуется визуализация (рисование графиков и функций), чтобы хоть понять, о чём речь вообще;
8. чтобы было чем заняться постоянно приходится выдумывать несуществующую ахинею, которой нет и быть не может: шестимерные пространства, семимерные фигуры;
...
Рейтинг: 0 / 0
30.01.2020, 20:04
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920710
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Кто может формально доказать что Jesus Christ является сыном Бога (The God) ?
...
Рейтинг: 0 / 0
30.01.2020, 20:08
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920711
Фотография полудух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
полудух
Участник
но причём тут математики? Человек же спрашивает про ООП и процедурное...
в кач-ве процедурного по-моему лучше C/C++ нету ничего
можно весь код разбросать по .h-файлам, при этом он аккуратно будут уложен в любые неймспейсы
потом просто дёргать:
db::func();
core::func();
легко сопровождать, легко работать
идеально!
...
Рейтинг: 0 / 0
30.01.2020, 20:09
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920718
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anatoly Moskovsky
Участник
полудух
но причём тут математики? Человек же спрашивает про ООП и процедурное...

Читайте еще раз тему топика )))
...
Рейтинг: 0 / 0
30.01.2020, 20:21
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920730
redkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
redkij
Гость
hVostt
Мне кажется человек интересуется именно подходом к разработке в функциональном стиле применительно в архитектуре.


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

А в случае с ФП я такого не наблюдаю. Будто подразумевается, что поняв теорию категорий, функторы, монады и тд, человек сразу готов писать в продакшн систему на миллионы строк, и никаких сложностей не будет.
Вот и хочется узнать - может какие-то гайды по архитектуре для ФП все-таки есть?
Или их реально нет, просто потому что мало кто пишет промышленные большие системы, используя ФП как единственный путь, а не фрагментарные вкрапления, и поэтому гайды особо некому писать, и спрос на них тоже не особый
...
Рейтинг: 0 / 0
30.01.2020, 20:36
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920734
redkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
redkij
Гость
mayton
Чуть позже я могу приаттачить библиографию своих книжек которые перечислил и еще кое-что добавлю если интересно.
Но это опять-же не про паттерн

Буду благодарен. SICP я осилил где-то 60%, но это все-таки не совсем то. Но интересно, что вообще есть.
...
Рейтинг: 0 / 0
30.01.2020, 20:41
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920735
redkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
redkij
Гость
kealon(Ruslan),

спасибо, увидел книжку
...
Рейтинг: 0 / 0
30.01.2020, 20:42
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920740
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Anatoly Moskovsky
полудух
но причём тут математики? Человек же спрашивает про ООП и процедурное...

Читайте еще раз тему топика )))

Давайте отвлечёмся.
Зачем математики делают те или иные гипотезы или открытия или теоремы?
А низачем? Вообще зачем - это какбы запрещённый вопрос. Многие великие
открытия в математике были сделаны безо всякой на то мотивации. Не было заказа
со стороны физиков или любых других учёных. Просто математик "играл разумом".
И его никому не нужные "игры в бирюльки". Вдруг! Внезапно! Через 100 с лишним лет
оказались НУЖНЫ квантовой физике. Просто потому что эти игры уже были исследованы.
И описаны.

Вот ФП - это игры разума. Да. Это программирование. Да. Оно позволяет решать задачи.
Обычно кратко. И оригинально. И когда классическое императивное программирование
устаёт само от себя - выдыхается. Оно обращает взор в ту сторону где есть большая
выразительность мысли. А ведь что такое программирование вообще. Это не писание
кода. Это выражение бизнес-правил на конкретном языке. Это по сути перевод
с естественного языка на технический. Разумеется язык бывает
разный. Бывает многсловный как Java. Это ее главный недостаток. Бывает опасный.
Это С++. Можно стрельнуть себе в ногу. Бывает узко специализированный (SQL).
Где только подмножетсво действий можно сделать. Бывает безтиповой типа JScript
где хер ево знает что в рантайме прилетит в аргумент. Бывает язык prolog где я
например доказал что Иисус является сыном божьим. Бывает scala где я писал CDC
просто по причине того что мне нравились multiline strings + interpolation
(честно-честно) другого мотиватора не было.

А бывают такие языки где ваш покорный слуга - замирает в восхищении. Он смотрит
разинув рот несколько минут и думает. Как это можно было МЫСЛЬ так красиво
описать.

Ведь описать красиво мысль - это же главная мечта любого разработчика. Это как
для писателя - найти красивую метафору. Эстетика.

И деньги тут непричём кстати.

P.S. И перформанс кстати тоже непричем. Когда ты красиво описал мысль - плевать
на перформанс. Эволюция компилляторов - заполирует. Главная цель - достигнута.

Ты. Красиво. Описал. Свою. Мысль.
...
Рейтинг: 0 / 0
30.01.2020, 20:45
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920742
redkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
redkij
Гость
Leonid Kudryavtsev
Может нужно отталкиваться от того, для каких бизнес-задач данный язык более-менее преднозначен

Да вот и непонятно, для чего языки, которые позиционируются как в первую очередь ФП-языки, предназначены. Может быть они не выйдут из своей узкой (академической?) ниши, и можно вообще не рассматривать их как то, что понадобится для мейнстримной разработки в ближайшие 20-30 лет)
...
Рейтинг: 0 / 0
30.01.2020, 20:46
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920750
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
mayton,

а платить за "папа может" будет пушкин
...
Рейтинг: 0 / 0
30.01.2020, 21:01
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920755
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
К чему банальности?
...
Рейтинг: 0 / 0
30.01.2020, 21:07
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920760
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
С моей скромной кочки зрения, все эти метания были изложены в приложении к "Мифическому человеко-месяцу": "Серебряной пули нет" (1975 год).
Краткое изложение "в перепеве Рабиновича".
Не надо думать, что только вы и только сейчас начали решать сложные задачи - их решали всегда .
Изобретение более-менее современных вычислительных машин со многими "современными" абстракциями типа виртуальной памяти, виртуальных устройств и систем, систем параллельной обработки с разделением времени - всё это существовало уже в шестидесятые годы двадцатого века.
В то же самое время были реализованы и основные концепции быстрой разработки. Как следствие, ещё одного кардинального (на порядок) прорыва не просматривается до сих пор.
...
Рейтинг: 0 / 0
30.01.2020, 21:16
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920773
Фотография полудух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
полудух
Участник
redkij
hVostt
Мне кажется человек интересуется именно подходом к разработке в функциональном стиле применительно в архитектуре.


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

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

 
Маргарет Гамильтон в 1969 году и код "Аполлона"

Модератор: Картинки надо убирать под спойлер


вряд ли есть что-то более "процедурное", чем это
и вот правила NASA, как сопровождать миллионы строк кода и не сойти с ума
...
Рейтинг: 0 / 0
30.01.2020, 21:41
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920781
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kealon(Ruslan)
Участник
Anatoly Moskovsky
kealon(Ruslan)
вы не путаете функциональное и символьное?

Это неважно в данном контексте.
Функциональное - в смысле разработанное на основе математики и математиками.
Судя по всему математиков не интересуют вопросы сопровождаемости их "кода".
ну загнул
ФП такое же математическое как и С++, просто альтернатива машине тьюринга

redkij,
кстати (спасибо mayton что напомнил), SQL тоже функциональный язык, и "бест-практики" по нему завались
...
Рейтинг: 0 / 0
30.01.2020, 21:50
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39920823
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anatoly Moskovsky
Участник
kealon(Ruslan)
SQL тоже функциональный язык, и "бест-практики" по нему завались

Лучшие из которых хинты оракла ))
...
Рейтинг: 0 / 0
30.01.2020, 23:19
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921024
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
mayton
Вот ФП - это игры разума. Да. Это программирование. Да. Оно позволяет решать задачи.
Обычно кратко. И оригинально. И когда классическое императивное программирование
устаёт само от себя - выдыхается.


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

Достаточно почитать книжку по ООП времён его популяризации. У опытного разработчика волосы зашевелятся, чё за бред эти люди несут?

В подобной теории есть польза только если правильно на это смотреть. Не в лоб.

У ФП подхода в программировании есть конкретные преимущества. Но есть и конкретные недостатки.

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

И не увидите той математической красоты и элегантности, которую некоторые вам впаривают :)
...
Рейтинг: 0 / 0
31.01.2020, 15:15
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921039
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
mayton
Назначение у Пролога было другое.

странно было бы учить "назначению Пролога" людей, которые его и придумали )))

https://www.pdc.com/
...
Рейтинг: 0 / 0
31.01.2020, 15:40
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921052
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Leonid Kudryavtsev
mayton
Назначение у Пролога было другое.

странно было бы учить "назначению Пролога" людей, которые его и придумали )))

https://www.pdc.com/

Я не понял ни ссылку ни комментарий.
...
Рейтинг: 0 / 0
31.01.2020, 15:58
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921055
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
hVostt

В подобной теории есть польза только если правильно на это смотреть. Не в лоб.

Вот это вопрос на мильен баксов. Давай поищем пользу. По целям и задачам я подниму старика Душкина.
...
Рейтинг: 0 / 0
31.01.2020, 16:03
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921062
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
PDC - Пролог Двелопер Центр
разработчик Visual & Borland Prolog'а (Borland у них просто в свое время лицензию купил и распространял под своим именем)

в 90-ые компилятор в том числе писался на улице Красной Связи. г. Санкт-Петербург
а какие-то части их поделки для авиакомпаний на углу ул Некрасова и Востания. GUI изначально писали на Prolog'е, потом, мучать программистов прекратили ))), стали на C переходить

p.s.
Это я к тому. что есть мазохисты добровольные ))), которые Subj в свои проекты по собственной инициативы тянут
и те, кто и рад бы без Subj'ей жить, но их жестоко принуждают обстоятельства
p.p.s.
Честно говоря, не отрицая общей академической ценности данных вещей, как-то практическая ценность в реальных проектах для меня сильно под сомнением
...
Рейтинг: 0 / 0
31.01.2020, 16:17
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921063
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Basil A. Sidorov

...всё это существовало уже в шестидесятые годы двадцатого века...
ещё одного кардинального (на порядок) прорыва не просматривается до сих пор.

+100500
...
Рейтинг: 0 / 0
31.01.2020, 16:18
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921067
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
И я бы сказал, просматривается регрес

По собственному опыту работы, могу сравнить СВМ (Система Виртуальных Машин) от IBM в 1990-91 г. и "изобретение"/развитие современного VMWare - за современные системы как-то больно становится.
...
Рейтинг: 0 / 0
31.01.2020, 16:25
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921070
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Leonid Kudryavtsev

Честно говоря, не отрицая общей академической ценности данных вещей, как-то практическая ценность в реальных проектах для меня сильно под сомнением

Год назад я пытался приспособить Пролог (swi-pl) для хранения онтологических знаний одной крупной системы
для бизнес-аналитики. Идея была - извлекать из Java-кода сведенья и формировать из них базу
фактов. Формально я базу фактов сделал. Но вот с рулами и запросами пока еще провис.
...
Рейтинг: 0 / 0
31.01.2020, 16:33
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921071
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingiz ✓Привилегированный пользователь
Участник
redkij
Всем привет.
Для ООП есть ряд книг, которые признаны более или менее классическими и описывают подходы к процессу разработки и построению архитектуры крупного приложения. Шаблоны банды четырех, DDD Эрика Эванса, SOLID и Clean architecture Боба Мартина, Рефакторинг Фаулера, книги по TDD, труды Бертрана Мейера, Dependency Injection in .NET Марка Симана и тд
То есть книги описывают не только сам подход ООП, но и как на нем построить какое-то более-менее сложное приложение для реальных нужд. Своего рода best practices.
Есть ли что-то подобное для функционального программирования?


Майерс надежность программного обеспечения pdf
шестая глава, как мне кажется
...
Рейтинг: 0 / 0
31.01.2020, 16:36
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921075
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
mayton
Я не понял ... ссылку...

IMHO На замом деле, хороший показать "значимости" продукта/направлений для современного IT рынка/конкретной_компании

https://www.pdc.com/
https://www.visual-prolog.com/

Вторая ссылка, самый старый продукт данной компании, давшая ей имя. На сайте компании, вроде только одна коротенькая страничка посвешенная данному продукту. а на заглавной странице - сами видели что
...
Рейтинг: 0 / 0
31.01.2020, 16:40
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921078
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kealon(Ruslan)
Участник
mayton,

как-то мы отклонились, пролог не относится к ФП
...
Рейтинг: 0 / 0
31.01.2020, 16:48
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921079
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
kealon(Ruslan)
mayton,

как-то мы отклонились, пролог не относится к ФП

Обычно Функциональное и Логическое произносят через запятую.

Кроме того... Ты видел когда-нибудь реализацию списков на Lisp, Haskell, Scala, Prolog?
...
Рейтинг: 0 / 0
31.01.2020, 16:52
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921095
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Честно говоря, я всего этого кипиша вообще не понимаю

когда изучал языки программирования в начале 90-х, слова типа APL, Lisp, Forth знал и даже работал (с Lisp сталкивался в Auto CAD)

но вот, что есть такое сокрашение ФП и есть какое-то "функционельное программирование" узнал толко несколько лет назад из данного форума

Подозреваю, что люди которые пользуются MathLab'ом тоже ни о каком функциональном программирование слыхом не слышали и за него не отвечают )))
...
Рейтинг: 0 / 0
31.01.2020, 17:31
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921099
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Leonid Kudryavtsev

Подозреваю, что люди которые пользуются MathLab'ом тоже ни о каком функциональном программирование слыхом не слышали и за него не отвечают )))

Мысль интересная. Пожалуй соглашусь.

Мне просто кажется что математики взирают на наши споры с удивлением. Скорее им вообще пофиг на наши проблемы.
...
Рейтинг: 0 / 0
31.01.2020, 17:43
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921125
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Проблемы просто нет.

Кто умеет - работает
Кто не умеет - учит (изобретает шаблоны, пишет книжки)
кто не может ни того, ни другого - руководит (агила/скрам?)

Вот, например, такой ФП как MathLab. Интересно, какой шаблон нужно было бы использовать в Java для таких задачь ( https://www.mathworks.com/help/matlab/math/basic-matrix-operations.html) ?

заготовка для ответа "для транспонирования матриц нужно использовать шаблон...", "для рисования графика нужно использовать шаблон ....". И к какому месту нужно прикладывать Dependency Injection в соответствие с best practics
...
Рейтинг: 0 / 0
31.01.2020, 18:49
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921127
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
Leonid Kudryavtsev
И я бы сказал, просматривается регрес

По собственному опыту работы, могу сравнить СВМ (Система Виртуальных Машин) от IBM в 1990-91 г. и "изобретение"/развитие современного VMWare - за современные системы как-то больно становится.

приходят тупые ребята с горящими глазами, изучать старое жопы не хватает и начинают выдумывать 100 раз одно и то же
все эти ооп, фп,... части одного и того же
как описать
как отобразить
как трансформировать
+ всякая сопровожденческая инфраструктура + интерфейс к устаревшим вещам (т.е. на все что имеется на сегодня)
сегодня последняя фигня обезумела и полностью вытеснила первые пункты, во всяком случае инет полон только этой фигней в виде всяких контейнеров, систем тестирования и деплоя, протоколов общения и т.д.
а основные пункты монополизировали несколько дебилов - паттернистов
одно только "строгая типизация" заставила часть население планеты заняться "программированием", появилась куча бездельников тестеров, которые "тестируют" тривиальные вещи не нуждающиеся в тестировании ( а то что надо тестить фиг кто может тестить)
всякая туфта MV* навязывается миллионам рожостроителям
мощные возможности ОС элиминируются сраными браузерами и детским протоколом
вощем бабло пилится будь здоров
...
Рейтинг: 0 / 0
31.01.2020, 18:51
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921137
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Leonid Kudryavtsev

заготовка для ответа "для транспонирования матриц нужно использовать шаблон...", "для рисования графика нужно использовать шаблон ....". И к какому месту нужно прикладывать Dependency Injection в соответствие с best practics

Если-бы я использовал матрицы в ООП - я-бы создал базовый тип - матрица. Или интерфейс.

Код: java
1.
2.
3.
IMatrix<T>{
    IMatrix transpose();
}



Почему интерфейс? Ну... у меня будет 2-3 реализации. Наверное (1) я возьму матрицу целых чисел. Int.
Потом вещесвтенных. Потом рациональных. Вида m/n где и числитель и знаменатель - целые.
И у меня будет еще куча мотиваций развивать мою парадигму. Ведь я могу брать разные системы
хранения. Например я могу использовать механику sparse-matrix для хранения толстых матриц
диагонального вида где значимые коэффициенты клубятся вокруг диагонали а все остальные - нули.
Я сыграю на этом. По сути это уже я решаню задачи перформанса. Вот такой вот я беспокойный
кабанчик. Когда пишу на ООП языке - заведомо думаю об оптимизациях.

Но первый поинт для haskell не нужен т.к. у него параметрический полиморфизм. Декларируем
функцию transpose которая принимает нечто и отдает нечто. Ну вот только одна функция и все.

Код: sql
1.
2.
transpose :: matrix -> matrix
transpose m = ....



Насчет сжатых матриц. Ну не знаю. Тоже самое. Создаю функцию которая возвращает тип сжатая матрица.

Далее - trust to compiller.
...
Рейтинг: 0 / 0
31.01.2020, 19:14
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921140
exp98
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
exp98
Участник
redkij
hVostt
Мне кажется человек интересуется именно подходом к разработке в функциональном стиле применительно в архитектуре.
Да. Это я и имел ввиду...
А мне кажется, автор в глубине души надеялся в итоге на существование системы в стиле быстрого прототипирования. Но на высшем уровне, типа меню с набором кнопок: "сделать хочу козу" "сделать хочу утюг" ...
Отдалённо похожее практивалось давно, в частности для т.н. вертикальных рынков. Продаём систему, а вы свои рабочие процессы перестраивайте под неё. И, мол, в ней есть весь нужный вам функционал, а мелочи сами допИлите. (К примеру 1С-предпр-е, Галлактика, Амдокс ...) Ну вот м.б. в своей области поискать описания таких систем.

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

Мои грошики в ттему.
...
Рейтинг: 0 / 0
31.01.2020, 19:25
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921144
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kealon(Ruslan)
Участник
mayton
kealon(Ruslan)
mayton,

как-то мы отклонились, пролог не относится к ФП

Обычно Функциональное и Логическое произносят через запятую.

Кроме того... Ты видел когда-нибудь реализацию списков на Lisp, Haskell, Scala, Prolog?
если делить только на императивное программирование и остальное, то конечно можно всё в кучу смешать и не делить, как нечто далёкое(правда забывают про SQL)

но ФП, логическое программирование, системы символьной алгебры - это всё очень разные вещи, из разряда: горькое, синее, больно
...
Рейтинг: 0 / 0
31.01.2020, 19:39
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921149
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
...
Рейтинг: 0 / 0
31.01.2020, 19:48
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921150
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
...
Рейтинг: 0 / 0
31.01.2020, 19:48
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921240
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kealon(Ruslan)
Участник
mayton,

Выкини этот вводный курс, не засоряй мозг. Если с основ исходить, то и Lisp-ом лучше не засорять на первых этапах.

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

Как полезное для практики оптимизации рантайма ФЯ (да и для общего развития тоже) стоит про персистентные структуры почитать.
...
Рейтинг: 0 / 0
01.02.2020, 00:18
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921275
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Да я его не читал. Это был просто комментарий на то что в 20м веке функциональное и логическое не разделяли.
...
Рейтинг: 0 / 0
01.02.2020, 11:00
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921286
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
ViPRos

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

Здесь я-бы с вами не согласился. Поскольку альтернатив на самом деле нет. Это человеческая минимизация рисков.

....А! Или есть еще одна альтернатива. Заняться "церебральным сортингом" людей (по Савельеву) чтобы
отобрать и вырастить гениев которые никогда не делают ошибок и не требуют тестирования. Но
я думаю что большая часть населения планеты с вами не будет согласна исключительно исходя
из гуманных или гуманитарных или толерантных соображений.
...
Рейтинг: 0 / 0
01.02.2020, 12:10
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921300
Фотография fixxer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fixxer
Участник
Возвращаясь к теме топика, мне понравилась книга Domain Design made Functional . Очень практическая книга. Примеры там на F#, я на нем не пишу, но все равно показалась очень полезной. Потом знаменитый red book и следом Functional And Reactive Domain Modelling . Тут фокус на скале, но описываемые принципы применимы не зависимо от языка.
...
Рейтинг: 0 / 0
01.02.2020, 13:20
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921307
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
mayton

Здесь я-бы с вами не согласился. Поскольку альтернатив на самом деле нет. Это человеческая минимизация рисков.

Ну вот напиши тест, который проверяет трансформацию матриц (ты че то про это тут говорил), или правильность топологической сортировки графа и т.д.
выложи сюда, как раз будет чем тебе заняться
...
Рейтинг: 0 / 0
01.02.2020, 13:52
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921309
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Зачем мне это? Это мне не интересно.
...
Рейтинг: 0 / 0
01.02.2020, 13:55
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921311
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
mayton
Зачем мне это? Это мне не интересно.

ну, я так и знал :)
...
Рейтинг: 0 / 0
01.02.2020, 14:24
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921358
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Извини.
...
Рейтинг: 0 / 0
01.02.2020, 19:56
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921386
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
mayton
hVostt

В подобной теории есть польза только если правильно на это смотреть. Не в лоб.

Вот это вопрос на мильен баксов. Давай поищем пользу. По целям и задачам я подниму старика Душкина.


Ох, ну подход, а давайте найдём в какой-то книжонке правильные ответы на все вопросы, лишил бы смысла такого понятия, как опыт. Поиск пользы -- это собственно задача разработчика. И эффективности. И компромиссов.
...
Рейтинг: 0 / 0
01.02.2020, 23:42
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921387
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
exp98
А мне кажется, автор в глубине души надеялся в итоге на существование системы в стиле быстрого прототипирования. Но на высшем уровне, типа меню с набором кнопок: "сделать хочу козу" "сделать хочу утюг" ...
Отдалённо похожее практивалось давно, в частности для т.н. вертикальных рынков. Продаём систему, а вы свои рабочие процессы перестраивайте под неё. И, мол, в ней есть весь нужный вам функционал, а мелочи сами допИлите. (К примеру 1С-предпр-е, Галлактика, Амдокс ...) Ну вот м.б. в своей области поискать описания таких систем.

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

Мои грошики в ттему.


Да, очень на это похоже. А потом на подходе очередное "изобретение", программирование мышкой, и прочие прелести долб-зма :)
...
Рейтинг: 0 / 0
01.02.2020, 23:44
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921388
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
hVostt
mayton
пропущено...

Вот это вопрос на мильен баксов. Давай поищем пользу. По целям и задачам я подниму старика Душкина.


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

Это был просто комментарий к фразе "правильно на это смотреть".

Кто знает как это делать?
...
Рейтинг: 0 / 0
01.02.2020, 23:45
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921399
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
mayton
Это был просто комментарий к фразе "правильно на это смотреть".

Кто знает как это делать?


Ну вот на примере. В книгах по ООП часто рассматриваются примеры типа иерархии фигур, животных и т.п. С абстрактными Figure, Animal и абстрактными методами, которые реализуются наследниками. Проводятся аналогии Объекта с объектами реального мира. Начинающий программист читает всё это и понимает буквально.

В реальных программах подобный подход моделирования реального мира почти всегда приводит к плачевным результатам. Новичкам сложно, они думают "либо я тупой, либо лыжи не едут..". Потом мы имеем удовольствие наблюдать жалобное нытьё на тему "ООП не работает/говно/бла-бла-бла", иногда даже оформленных в виде статей на профильных ресурсах.

Только опыт помогает научиться смотреть правильно. Не воспринимать всё буквально, а через призму проблем и задач, которые помогает решать та или иная методология.

В том же ФП декларируются профит в виде безопасного распараллеливания всего и вся, ведь у нас "нет мутируемого состояния", о чудо! Потом топаем на конференции и слушаем рассказы о том, что состояние всёже есть, но его просто нужно изолировать. И ворох заботливо предоставленных костыликов, к кристально чистому ФП.

В общем предметы глубоко дискуссионные, и одними книжечками тут не обойдёшься.
...
Рейтинг: 0 / 0
02.02.2020, 01:10
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921400
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
hVostt
mayton
Это был просто комментарий к фразе "правильно на это смотреть".

Кто знает как это делать?


Ну вот на примере. В книгах по ООП часто рассматриваются примеры типа иерархии фигур, животных и т.п. С абстрактными Figure, Animal и абстрактными методами, которые реализуются наследниками. Проводятся аналогии Объекта с объектами реального мира. Начинающий программист читает всё это и понимает буквально.

Я помнится писал где-то про аналогию с наследованием. Это грандиозная мистификация!
Нет никакого наследования (как в генетике например)!
Есть расширение класса. Оно так и называется - extend.
Код: java
1.
class Dog extends Wolf {


Собака расширяет волка. И всё. Не наследует. Не копирует. Не инкапсулирует. А просто расширяет.
Это буквальный английский перевод.
...
Рейтинг: 0 / 0
02.02.2020, 01:28
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921401
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
hVostt

В том же ФП декларируются профит в виде безопасного распараллеливания всего и вся, ведь у нас "нет мутируемого состояния", о чудо! Потом топаем на конференции и слушаем рассказы о том, что состояние всёже есть, но его просто нужно изолировать. И ворох заботливо предоставленных костыликов, к кристально чистому ФП.

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

Я надеюсь что в ближайшее время я доберусь до монад и у нас будет тема для спора о "состоянии".
Пока у меня еще мало понимания мотиваций к использованию тех или иных абстракций ФП.

А состояние - это тема важная. Без нее и БД не работает и файловая система выглядела бы странной
метафорой. Кому нужна файловая система без состояний? Мне - нет.
...
Рейтинг: 0 / 0
02.02.2020, 01:32
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921404
iOracleDev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iOracleDev
Участник
mayton
Собака расширяет волка.

Да да, прямо берет и надувает))

Термин наследование растет из деревянной иерархии parent-child, не вижу смысла придумывать свои термины и уж тем более приводить синтаксис java в качестве аргумента.

PS: объектно ориентированных программ на машинном уровне не существует вообще, процессор не понимает по объектно-ориентированному и память тоже, это чисто человеческая абстракция, чтобы человекам было проще писать программы и чтобы человеки меньше путались в коде. ФП тоже абстракция, просто немного другая.
...
Рейтинг: 0 / 0
02.02.2020, 01:46
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921406
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
iOracleDev

Термин наследование растет из деревянной иерархии parent-child, не вижу смысла придумывать свои термины и уж тем более приводить синтаксис java в качестве аргумента.

Прокомментируйте что здесь. О чем эти куски кода?
Где вообще впервые появляется наследование?

С++
Код: plaintext
1.
class Dog : Wolf {


Pascal
Код: pascal
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
type
  // Define a parent class, base on TObject by default
  TFruit = class
  public
    name   : string;
    Constructor Create; overload;   // This constructor uses defaults
    Constructor Create(name : string); overload;
  end;

  // Define a descendant types
  TApple = class(TFruit)
  public
    diameter : Integer;
  published
    Constructor Create(name : string; diameter : Integer);
  end;
...
Рейтинг: 0 / 0
02.02.2020, 01:53
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921407
iOracleDev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iOracleDev
Участник
mayton,

ГуглInheritance was invented in 1969 for Simula. An inherited class is called a subclass of its parent class or super class. ... Inheritance is contrasted with object composition, where one object contains another object (or objects of one class contain objects of another class); see composition over inheritance.
...
Рейтинг: 0 / 0
02.02.2020, 02:08
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921408
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
booby
Участник
hVostt
...
Ну вот на примере. В книгах по ООП часто рассматриваются примеры типа иерархии фигур, животных и т.п. С абстрактными Figure, Animal и абстрактными методами, которые реализуются наследниками. Проводятся аналогии Объекта с объектами реального мира. Начинающий программист читает всё это и понимает буквально.


Тут такое дело, имхо: там где ооп про "Figure, Animal и абстрактными методами" - это левое ооп, норвежского типа,
а там где ооп про "объектами реального мира" - это правое, калифорнийского посола.
Начинающий сено от соломы не отличает, как же у него ооп должно заработать?
И вот ещё, когда-то в наивные времена, считалось, что было бы замечательно,
если бы программа смогла не просто заработать, а нашлись бы способы правдоподобного формального суждения о том,
что программа работает правильно, в некотором строго указанном смысле.

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

У левого ооп с самого начала с вменяемой математикой такого рода серьёзные проблемы.
И почти все что в рамках левого ооп достигнуто, достигалось не контексте объектов,
а в процессе работы с автоматами или шаблонами/обобщениями.
К автоматам ооп как-то пристёгивается, хоть и не является обязательным,
а во втором случае ооп это просто антиконценпия, и выглядит, имхо, просто как
изуродованная модель работы с обобщениями.

Правое ооп, там где про "объекты реального мира" - не жилец без вменяемых математизированных моделей взаимодействия этих объектов - будь то модели акторов или Хоаровы модели взаимодействующих процессов.

То есть имхо, "само по себе" ооп ни быть понято, ни работать не может.
И нечего здесь на студентов пенять, бла-бла-бла.

hVostt

Только опыт помогает научиться смотреть правильно. Не воспринимать всё буквально, а через призму проблем и задач, которые помогает решать та или иная методология.

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

hVostt

В том же ФП декларируются профит в виде безопасного распараллеливания всего и вся, ведь у нас "нет мутируемого состояния", о чудо! Потом топаем на конференции и слушаем рассказы о том, что состояние всёже есть, но его просто нужно изолировать. И ворох заботливо предоставленных костыликов, к кристально чистому ФП.

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

Имхо, не совсем так.
В связи с тем, что "состояния нет" - прозрачно реализуется любая изобретённая и, вероятно,
любая будущая модель сети "взаимодействующих объектов".
По крайней мере до тех пор, пока игнорируется вопрос о том, а существует ли у самой сети состояние.
Но вот с самими "объектами" возникает маленькая проблема: как имитировать состояние средствами, не предполагающими оного.
Будучи ошеломительно эффективным в одном месте, ФП оказываются изумляюще затруднительным в другом.
Хотя Erlang-у с Elixir-ом это никак процветать не мешает.
...
Рейтинг: 0 / 0
02.02.2020, 02:34
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921432
Фотография полудух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
полудух
Участник
booby
Тут такое дело, имхо: там где ооп про "Figure, Animal и абстрактными методами" - это левое ооп, норвежского типа,
а там где ооп про "объектами реального мира" - это правое, калифорнийского посола.

а Figure, Animal, Dog, Wolf - это не из реального мира объекты?
я вообще хз, что там можно напутать в наследованиях и как там можно запутаться...
самое сложное в ООП это интерфейсы и разные типы иерархий
...
Рейтинг: 0 / 0
02.02.2020, 11:39
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921439
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
iOracleDev,

Мне очень приятно что вы напоминаете мне о существовании поисковиков.

Но было бы ещё приятнее слышать ваше мнение. И вашу речь.

Иначе яб не сидел в этом форуме.
...
Рейтинг: 0 / 0
02.02.2020, 12:45
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921456
iOracleDev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iOracleDev
Участник
mayton,

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

Кстати пример про волка и собаку абсурдный, как ты наверное помнишь, наследование можно применить
если между подклассом и суперклассом можно поставить слово "является". Является ли собака волком?
Конечно нет, собака самостоятельный объект в который волк не влезает никаким видом, наследовать
собаку от волка с точки зрения ООП нельзя.

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

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

В реальном мире как правило нет никакого наследования, каждый объект самостоятелен и не отнаследован
ни от какого другого, в информационном плане можно выделить группу общих свойств и поведения и
вынести их в абстрактного родителя, но этот абстрактный родитель не существует в реальности. То что
обозначается термином наследование в реальном мире, в мире ООП не годится для создания суперклассов,
наследование в реальном мире и в абстракции ООП роднит только то, что и то и другое можно представить
в виде направленного графа.
...
Рейтинг: 0 / 0
02.02.2020, 14:19
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921468
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
iOracleDev,

ооп сложнее, собака может запросто унаследовать только некоторые черты волка, добавить новые черты характера и одеться в новый прикид - а это все приводит к великому бардаку
должно было бы появиться понятие "аспектное подобие" и т.д., это все в обобщениях заглохло
а ФП - это мертворожденная фигня, саван (попытка формализации того что имеем)
...
Рейтинг: 0 / 0
02.02.2020, 15:30
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921488
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
booby
Участник
полудух,

полудух
...
а Figure, Animal, Dog, Wolf - это не из реального мира объекты?

Figure, Animal, Dog, Wolf - это вообще не объекты, а имена,
в терминах которых вы, как Адам, описываете окружающий мир и рассуждаете о нём.
Вообще, программирование, это техника/наука манипулирования именами, а не объектами.

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

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

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

Кто такие "интерфейсы"? Это "объекты" или нет?
Если да - зачем для некоторых объектов потребовалось специальное "системное" имя?
Если нет, то что они вообще делают в "ооп", где весь мир - "объекты"?
О чём весь этот, уже много лет как потерявший актуальность, хайп?

Предположим, что он о "многократном повторном использовании кода".
Тогда, применительно к норвежскому ооп, в изначальной формулировке,
тезис о пользе ооп будет звучать так:
а) постройте "удачную", "соответствующую задаче" систему классификации
б) поместите код, предполагаемый к повторному использование к корни построенных классификаций
в) многократно используйте этот код в наследниках.

Вернемся на время к Адаму.
Занимался ли он классификациями? Несомненно.
А должны ли мы помнить об этом? А вот это вряд ли.
Все имена птиц, животных и рыб остались и используются до сих пор,
а классификации - нет.

Классификации - это сложно - сложная и не сводимая к простой древовидности штука.
Фасетные классификации не кладутся в иерархии.
После Адама много достойнейших людей занимались классификациями, и мало какие из них
переживали своих создателей.
В классификациях Платона курица оказывалась неотличима от человека.
А таблицы Менделеева создаются вообще один раз за время жизни человечества.
Что вообще делать с "подходом к программированию", в котором до написания программы
ты должен создать классификацию задействованных в ней "объектов"...
Её вообщи нельзя использовать практически, потому что в ней нельзя начать писать.
А главный секрет программирования заключается в том, что никакую программу нельзя написать с "первого раза".
Заранее известно, что программу придется менять, пока она не приобретет свой финальный вид.
И, навязывая себе рабскую зависимость от выбранной (обязательно неудачно) системы классификации,
вы оказываетесь в ситуации, когда программу нужно не просто менять, а обязательно выкидывать
и переписывать заново целиком.
Тут уж не до "многократного использования кода" становится...

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

Обычно это выглядит как-то так:
Мне в программе понадобится:
а) умножать целые числа
б) возводить их в целочисленную степень
в) иногда вычислять n-ый член последовательности Фибоначчи
г) возводить матрицы в целочисленные степени
д) размножать строки
е) ...
Все это делается одним алгоритмом, я знаю его, и хотел бы написать функцию один раз,
так чтобы она оказалась пригодна к вызову для всех таких ситуаций "многократно".
В формальные параметры такой функции будут попадать различные фактические параметры, в зависимости
от существа выполняемой в конкретном месте операции -
возведения в степень целого или размножения указанной строки заданное колисчество раз.
И все, что требуется от входных параметров - предоставлять возможность выполнения
над экзеплярами параметров необходимых алгоритму действий.

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

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

ООП вообще не требуется и не подразумевается задачей повторного использования кода.
...
Рейтинг: 0 / 0
02.02.2020, 17:47
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921490
iOracleDev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iOracleDev
Участник
booby,

Каждая сущность имеет набор характеристик, характеристики могут быть комплексными, иметь глубокую вложенность,
если у тебя одна сущность, ты можешь все это дело пораспихать в переменные и раскрутить вложенность, после чего
помещать их в функции, но если сущность не одна, да они в придачу еще и разные попадаются, код программы превращается
в нечитаемую кашу, в которой невозможно разобраться. И в этот момент на помощь приходит инкапсуляция, все переменные
убираются в экземпляр объекта, который становится "черным ящиком", строительным блоком имеющим интерфейс для
взаимодействия, в итоге каждая часть программы становится понятной и легкочитаемой. Компилятор проделает обратную работу
по сваливанию всего этого добра в одну кучу, но поскольку процесс формализован, а компилятор машина, ему пофигу на
читаемость и человеческую возможность понять написанное, он не ошибается и не путается и память у него абсолютная.
...
Рейтинг: 0 / 0
02.02.2020, 18:05
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921494
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
booby
Участник
iOracleDev,
компилятор машина, доцент тупой, а людям вообще не следует заниматься программированием.
По крайней мере, большинству из них.

Стараниями писателей компиляторов профессия уже давно заметно выродилась,
и даже уже вот-вот люди заменятся на Алис, но инкапсуляция здесь ни при чём.
...
Рейтинг: 0 / 0
02.02.2020, 18:47
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921495
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
mayton
Я помнится писал где-то про аналогию с наследованием. Это грандиозная мистификация!
Нет никакого наследования (как в генетике например)!
Есть расширение класса. Оно так и называется - extend.


Почему нет? Есть. Но к реальному миру это не имеет отношения. Насчёт расширения, -- ну нет же. Для расширения есть множество различных паттернов и подходов. Тот же Мост, например. Для расширения как раз лучше используется аргрегация, чем наследование.

mayton
Код: java
1.
class Dog extends Wolf {



Собака расширяет волка. И всё. Не наследует. Не копирует. Не инкапсулирует. А просто расширяет.
Это буквальный английский перевод.


Ну вот он и плохой пример для ООП :)
Тут термин extends работает ещё хуже, так как конкретно запутывает, и откровенно нагло врёт разработчику.
...
Рейтинг: 0 / 0
02.02.2020, 18:51
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921497
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
mayton
Я надеюсь что в ближайшее время я доберусь до монад и у нас будет тема для спора о "состоянии".
Пока у меня еще мало понимания мотиваций к использованию тех или иных абстракций ФП.

А состояние - это тема важная. Без нее и БД не работает и файловая система выглядела бы странной
метафорой. Кому нужна файловая система без состояний? Мне - нет.


Надо было мне выделить слово _мутируемое_ :) В самом состоянии проблем никаких нет.
...
Рейтинг: 0 / 0
02.02.2020, 18:55
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921498
redkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
redkij
Гость
hVostt
exp98
А мне кажется, автор в глубине души надеялся в итоге на существование системы в стиле быстрого прототипирования. Но на высшем уровне, типа меню с набором кнопок: "сделать хочу козу" "сделать хочу утюг" ...

Да, очень на это похоже. А потом на подходе очередное "изобретение", программирование мышкой, и прочие прелести долб-зма :)

Если автор в смысле топикстартер, то нет, я о таком не думал)
...
Рейтинг: 0 / 0
02.02.2020, 19:09
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921499
redkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
redkij
Гость
fixxer,

Спасибо!
...
Рейтинг: 0 / 0
02.02.2020, 19:10
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921500
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
redkij
hVostt
пропущено...

Да, очень на это похоже. А потом на подходе очередное "изобретение", программирование мышкой, и прочие прелести долб-зма :)

Если автор в смысле топикстартер, то нет, я о таком не думал)


Слава те хоспади
...
Рейтинг: 0 / 0
02.02.2020, 19:12
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921543
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
iOracleDev

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

100% согласен. Более того. Наша наивная попытка построить онтологию или таксономию
биологического мира вызовет гомерический хохот у всех биологов и зоологов и генетиков.

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

Почему я так часто и так много делаю на этом акцент. Да потому что бизнес сущности - это не животные.
Это - другое. И изучать ООП для бизнеса надо на примере с вовлечением правильных сущностей.
Истина должна быть даже в мета-программировании. Нельзя ее игнорировать или быть поверхностными.

iOracleDevМы написали классы на каждое животное, стали писать функцию отвечающую за перемещение объекта
и выяснилось, они все о четырех конечностях и функция перемещения у них одинакова, что у нас получилось?
Мы написали одинаковый код много раз, а если еще и накосячили, придется исправлять в многих местах и тестировать
каждый объект по отдельности, это хорошо, нет это совсем не хорошо (даже принцип в программировании
на этот счет имеется - DRY). А давай ка мы возьмем и выделим четыре конечности и функцию перемещения
в самостоятельный класс, назовем его "животное бегающее на четырех ногах", являются ли все перечисленные
нами животные животными бегающими на четырех ногах? Да являются, замечательно получили суперкласс
в котором один раз описали количество конечностей и метод перемещения, бинго.

Это уже не зоопарк. Это сценарий комьютерной игры где мы решили схитрить и что-то соптимизировать.
Ну а по поводу животного с четырьмя ногами... Вы уж меня извените. Это какой-то "плантоновский" человек получается.
Никаких реальных биологических обобщений с 4 ногами мы не сделаем.

В игре - да. В зоопарке - нет. В зоопарке мы можем найти табличку с Properties - где написано имя зверя.
Вид. Подвид. Окрас. Наличие шкуры. Что он кушает. Где обитает. Вот это правда! Да. Вот это - вносите
в ваши классы. Это и будет биологической правдой. Можете его скелет описать. Но это скорее топология
или морфология. Графы. Но наследование здесь тоже не подходит.

А 4 ноги - это.. Вобщем это пахнет антропологией. Наукой которая построена на обмане и на политической
целесообразности.

Увольте. Не надо нам такой подход.

Если-бы вы меня попросили описать зоопарк - то я-бы взял для этого именно описательный инструмент.
Semantic Web. RDF. Графы со связями. Triplets. И SparQL как язык и платформа для сбора сведений и формирования
отчотов.

Я-бы не беспокоился о полиморфизме потому-то там нечего полиморфировать. Или нужно совершенно
другое задание. Как я уже говорил. Комьютерная игра например.

Вообще нужно быть аскетом в описательных задачах.

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

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

Почему формализм важен? Если вы хотите что-то доказать в математике - то вы втаскиваете систему
аксиом. Лемм. И теорем. И выдаете новую теорему. И все присутсвующие - соглашаются. После того
как заслушают ваше доказательсво.

Здесь есть некий слабый кивок в сторону ФП например где хотя-бы декларирована попытка внести
доказательную базу (Prolog/Lisp).

В ООП не так. Сколько в аудитории человек - столько и мнений по поводу декомпозиции задачи на ООП.
Это напоминает богословские споры средних веков. Священники любили спорить что такое ребро Адама
или сколько ангелов пляшут на кончике иголки.

Грубо говоря ООП математически недоказуемо. ООП - гуманитарно. ООП создано в угоду когнитивным
качествам разработчика как best practices, как вспомогательный описательный инструмент. Красота.
Наглядность и прочее и прочее что не из чего не вытекает и не доказывает.

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

Да. В реальном мире объекты - скорее клоны или прототипы. Здесь - самое реалистичное ООП - как ни странно
в JavaScript.
...
Рейтинг: 0 / 0
02.02.2020, 22:17
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921545
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
hVostt
mayton
Я помнится писал где-то про аналогию с наследованием. Это грандиозная мистификация!
Нет никакого наследования (как в генетике например)!
Есть расширение класса. Оно так и называется - extend.


Почему нет? Есть. Но к реальному миру это не имеет отношения. Насчёт расширения, -- ну нет же. Для расширения есть множество различных паттернов и подходов. Тот же Мост, например. Для расширения как раз лучше используется аргрегация, чем наследование.

Наверное имелось в виду не агрегация а композиция. Агрегация это КМК включение коллекции объектов.

А с композицией еще интереснее. Если-бы в биологии мы могли композировать... типа беременная курица
комозирует в себе яйцо...

Ну что-то в этом роде.

Я-бы ограничился просто "включением нужного функционала". И механик много. Модули. Зависимости. Шаблоны.
Например если мне надо создать мапу где код физлица отображается на его ФИО + дату рождения + признак
заблокирован или нет. То я сделаю нечто вроде.
Код: sql
1.
Map<String, Triple<String, Date, Boolean>> = ....


И какую механику я использовал? Кодогенерация? Метапрограммирование?

Да пофиг по большему счету. Компиллятор разрулит.

Ну а сишники в этом смысле еще дальше ушли. Что есть их шаблонный процессор? Куда его классифицировать
в этой схеме? Непонятно.
...
Рейтинг: 0 / 0
02.02.2020, 22:30
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921549
iOracleDev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iOracleDev
Участник
Процессор штука тупая, он может считать, может не считать и скормить мы ему можем только его же команды, но человек не может генерировать команды процессору, понадобились абстракции, начали с близкой к машинным, потом поднялись до уровня процедурных, ООП всего лишь следующий этаж над процедурным, абстракция позволяющая людям, не машине, лучше ориентироваться и поддерживать код. Чем ограничены все языки программирования? Они ограничены возможностью преобразовать хотелку в машинные команды процессора. Ничего общего с реальным миром компьютерные языковые абстракции не имеют.

С физическим лицом все несколько сложнее, у него нет ID, единственный ID это полная 100% расшифровка генетического кода, которая в настоящий момент с необходимой точностью недостижима, но и этот ID в случае клонов не даст уникальности.

С десяток лет назад многие пытались создать объектно-ориентированную СУБД, но сделать этого не смогли, потому что подходы несовместимы и сами абстракции тоже несовместимы. Программа на ООП языке компилируется в исполнимые модули, решающие какую то заданную задачу, СУБД является уже скомпилированной готовой программой, предоставляющей возможность обрабатывать множества с использованием декларативного языка запросов. Но несмотря на несовместимость подходов люди упорно продолжали пытаться впихнуть невпихуемое.

ООП для бизнеса на примере правильных сущностей? Давайте рассмотрим простой пример person, employee, department.
С точки зрения ООП employee является person и employee не является department, по идее мы должны отнаследоваться
от person, а department ввести композицией. Однако в СУБД совершенно спокойно обходятся композицией и ссылки на
person и department равноценны.
...
Рейтинг: 0 / 0
02.02.2020, 22:58
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921552
iOracleDev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iOracleDev
Участник
mayton
То я сделаю нечто вроде.
Код: sql
1.
Map<String, Triple<String, Date, Boolean>> = ....


Жава вообще штука неадекватная, scanner.nextInt(), scanner.hasNextInt(), она не может сделать банальную
вещь одной функцией и не упасть по эксцепшену.
...
Рейтинг: 0 / 0
02.02.2020, 23:12
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921553
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Не помню чтоб вообще пользовался Scanner.
По моему это редкая штука. Если нужен какой-то особый процессинг
текста - нам хватает CSV/JSON/Yaml парсеров. Если что-то сложное - то Antlr.

А сканнер - это какой-то уе6анский API.
...
Рейтинг: 0 / 0
02.02.2020, 23:21
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921555
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
iOracleDev

ООП для бизнеса на примере правильных сущностей? Давайте рассмотрим простой пример person, employee, department.
С точки зрения ООП employee является person и employee не является department, по идее мы должны отнаследоваться
от person, а department ввести композицией. Однако в СУБД совершенно спокойно обходятся композицией и ссылки на
person и department равноценны.

Если ты имеешь в виду MongoDb, Couch и прочие NoSQL и докумнетно-ориентированные - то у них есть своя
методология разработки. Она основана на поиске и вычленении т.н. агрегатов. Это по сути тоже что и 1 ко многим
только для документов.

Общая рекомендация была такова. Единого подхода нормализации для таких систем нет. Там по сути
есть несколько вариантов как реализовать одну и ту-же документную модель комбинируя по разному
агрегаты. Например персона - агрегирует кассовые чеки. Магазин агрегирует транзакции. Все это
говн0 запускается под нагрузкой - и смотрится - где упадёт или где плохо.

Если плохо - тогда делается попытка сделать агрегаты по другому.

Напоминает повторную сдачу карт в покере. Или еще один вариант решения транспортных задач.

Вобщем тут дело не в ООП а в практической нерешаемости декомпозиции предметной области
на агрегаты правильно.

Как ни бей - всё неправильно. И аномалий куча. Просто из всех неправильных надо выбрать хотя-бы подходящий
по перформансу.
...
Рейтинг: 0 / 0
02.02.2020, 23:28
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921558
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
mayton
Наверное имелось в виду не агрегация а композиция. Агрегация это КМК включение коллекции объектов.


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

mayton
А с композицией еще интереснее. Если-бы в биологии мы могли композировать... типа беременная курица
комозирует в себе яйцо...

Ну что-то в этом роде.


Ну вот. Если говорить строго, про курицу и яйцо, это именно самая настоящая агрегация :)
Хотя конечно как посмотреть, точнее в какой момент времени?

mayton
Я-бы ограничился просто "включением нужного функционала".


Зависит от архитектуры. И много от чего. Нужный функционал иногда можно добавить настройками, встраиваемыми скриптами, исключительно императивным путём.


mayton
Например если мне надо создать мапу где код физлица отображается на его ФИО + дату рождения + признак
заблокирован или нет. То я сделаю нечто вроде.
Код: sql
1.
Map<String, Triple<String, Date, Boolean>> = ....



Это решение в лоб. Вот совсем не интересно. Интересно, если вы выделили чистый домен. И смогли объяснить это на языке бизнеса, используя свой домен.

mayton
Компиллятор разрулит.


Ну тут абстракции довольно низкоуровневые. Про архитектуру говорить не приходится.


mayton
Ну а сишники в этом смысле еще дальше ушли. Что есть их шаблонный процессор? Куда его классифицировать
в этой схеме? Непонятно.


Обычное (сегодня) уже мета-программирование :)
Посмотрите в сторону Nemerle, например, там ещё интереснее.
...
Рейтинг: 0 / 0
02.02.2020, 23:41
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921559
Фотография полудух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
полудух
Участник
iOracleDev
ООП для бизнеса на примере правильных сущностей? Давайте рассмотрим простой пример person, employee, department.
С точки зрения ООП employee является person и employee не является department, по идее мы должны отнаследоваться от person, а department ввести композицией. Однако в СУБД совершенно спокойно обходятся композицией и ссылки на person и department равноценны.

чего вы всё усложняете то?
объекты это не серебрянная пуля, а способ избежать повторения кода + автоматизировать (на этапе конструктора, например)
а ещё можно создать вектор структур.
ну и прекрасно они справляются с этой задачей, какие вы там проблемы нашли?
зациклились на названиях зачем-то... надо задачу решать, а не огород городить.
...
Рейтинг: 0 / 0
02.02.2020, 23:46
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921564
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
booby
Участник
mayton

...
Если плохо - тогда делается попытка сделать агрегаты по другому.

Напоминает повторную сдачу карт в покере. Или еще один вариант решения транспортных задач.

Вобщем тут дело не в ООП а в практической нерешаемости декомпозиции предметной области
на агрегаты правильно.

Как ни бей - всё неправильно. И аномалий куча. Просто из всех неправильных надо выбрать хотя-бы подходящий
по перформансу.


Это интересный аспект, и на мой взгляд, в практической жизни он выглядит примерно так:
Нечего даже и пытаться "сделать правильно".
А идеальную программу надо делать так:
а) с ближайшей банды четырёх, или там какого местного Фаулера, немедленно стребовать образцов, шаблонов и прочих паттернов.
б) заказать в соседнем опенсорце библиотечную реализацию таких образцов, спрингов подходящей системы, бутов и прочего подспорья, зависимо от яп,
после чего умыть и отряхнуть руки.

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

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


И с этого момента программа работает не просто сама, а с каждом днём всё быстрее,
и требуя все меньше памяти.

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

Не знаю, подразумевалась ли бандой такого рода идея с самого начала, но на практике она работает безотказно.
...
Рейтинг: 0 / 0
03.02.2020, 00:09
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921569
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
booby
местного Фаулера


А сколько у вас Фаулеров в команде?
...
Рейтинг: 0 / 0
03.02.2020, 01:03
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921570
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
booby
Участник
hVostt
booby
местного Фаулера


А сколько у вас Фаулеров в команде?

дык, это ведь коммерческая тайна, чай.

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

В общем, хватает нам и Фаулеров и прочих замечательных людей.
...
Рейтинг: 0 / 0
03.02.2020, 01:12
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921602
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
mayton
Никаких реальных биологических обобщений с 4 ногами мы не сделаем.
Тетраподы - вполне реальные потомки вполне реальных кистепёрых рыб.
Просто, как вы уже неоднократно отмечали - требуется хорошо знать предметную область, чтобы делать корректные декомпозицию и иерархию классов. И, вероятно, в разных задачах одной и той же предметной области иерархия и декомпозиция будут разными.
...
Рейтинг: 0 / 0
03.02.2020, 06:39
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921648
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
booby,

Вопрос был риторический )
...
Рейтинг: 0 / 0
03.02.2020, 10:12
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921708
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
hVostt,

топик напомнил анекдот про философа и сантехника :)

По теме:
- Functional reactive programming
- Railway oriented programming
- Railway oriented programming C#
...
Рейтинг: 0 / 0
03.02.2020, 11:49
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921742
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
skyANA,

Гуд. Рельсы и FRP это намного ближе к вопросу топикастера, чем всё, что тут обсуждалось :)
...
Рейтинг: 0 / 0
03.02.2020, 12:41
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921751
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Basil A. Sidorov
mayton
Никаких реальных биологических обобщений с 4 ногами мы не сделаем.
Тетраподы - вполне реальные потомки вполне реальных кистепёрых рыб.
Просто, как вы уже неоднократно отмечали - требуется хорошо знать предметную область, чтобы делать корректные декомпозицию и иерархию классов. И, вероятно, в разных задачах одной и той же предметной области иерархия и декомпозиция будут разными.

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

Представте что вы обращаетесь к механике рефлексии класса и указываете
период (since, until) и рефлектор вам отвечает да дескыть 100 млн лет назад
бронтозавр действительно существовал и имплементировал интерфейс тетраподов.

Это еще раз подтверждает мои слова о том что поставленная задача вообще не соответствует
задачам ООП.

Историческая изменчивость объектов и классов или их lineage - это вообще сверх-постановка.
...
Рейтинг: 0 / 0
03.02.2020, 12:51
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921760
exp98
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
exp98
Участник
hVostt, автор...Вот совсем не интересно. Интересно, если вы выделили чистый домен. И смогли объяснить это на языке бизнеса, используя свой домен. Я и говорю, все хотят готовые кнопки. А лучше одну большую. Тогда вас всех сферический бизнесмэн посылает и жмёт всё сам, он ведь самый умный, либо нанимает обычного манагера. Сбылась мечта дурака бизнесмэна.
И booby туда же авторТак создаются самоулучшающиеся, без влияния прикладного программиста, программы.

А на практике ... в вакансиях пишут требования к сантехнику, совмещённые с требованиями к философу. Когда это повелось там, не знаю, а у нас сразу резко с 90-х.
...
Рейтинг: 0 / 0
03.02.2020, 13:00
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921761
Фотография полудух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
полудух
Участник
mayton
Это еще раз подтверждает мои слова о том что поставленная задача вообще не соответствует задачам ООП.

каким-таким "задачам ООП"? Кто их ставил?
Их ставили все кому не лень и там уже целый частокол, в котором чёрт ногу сломит.
В итоге тут уже 4я страница обсуждений этого барахла.
Решать надо свою задачу, и ООП даёт для этого кучу инструментов, которые прекрасно решат что угодно.
...
Рейтинг: 0 / 0
03.02.2020, 13:01
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921766
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
mayton
Мы еще дальше ушли от зоопарка.
Мы подошли к нему вплотную: млекопитающие - тоже тетраподы.
Просто, как уже отмечалось - требуется знать предметную область. Хотя бы на уровне дилетанта.
...
Рейтинг: 0 / 0
03.02.2020, 13:04
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921770
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
полудух
mayton
Это еще раз подтверждает мои слова о том что поставленная задача вообще не соответствует задачам ООП.

каким-таким "задачам ООП"? Кто их ставил?
Их ставили все кому не лень и там уже целый частокол, в котором чёрт ногу сломит.
В итоге тут уже 4я страница обсуждений этого барахла.
Решать надо свою задачу, и ООП даёт для этого кучу инструментов, которые прекрасно решат что угодно.

Выше по топику. Один господин задал задачу.

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

Вот и попробуй решить эту задачу. Я не знаю как ее решать.
Может я подхожу слишком фундаментально?
...
Рейтинг: 0 / 0
03.02.2020, 13:09
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921778
Фотография полудух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
полудух
Участник
mayton
Вот и попробуй решить эту задачу. Я не знаю как ее решать.
Может я подхожу слишком фундаментально?

я не вижу тут задачу, нет чёткого условия и цели, есть просто набор животных.
Но иерархия классов позволяет запихнуть и животный класс, и класс парнокопытных, и класс кошачьих
а может он хотел на клеточном уровне разделение провести?
...
Рейтинг: 0 / 0
03.02.2020, 13:26
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921812
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
полудух
mayton
Вот и попробуй решить эту задачу. Я не знаю как ее решать.
Может я подхожу слишком фундаментально?

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

Вот вот. Это само интересное.
...
Рейтинг: 0 / 0
03.02.2020, 14:00
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921823
iOracleDev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iOracleDev
Участник
mayton
Вот и попробуй решить эту задачу. Я не знаю как ее решать.
Может я подхожу слишком фундаментально?

Где ты там увидел задачу? Там просто иллюстрация, что наследование в ООП
не имеет ничего общего с реальностью, оно абстрактно, всего лишь вынос
общих характеристик и поведения в отдельную структуру и Java с запретом
нормального множественного наследования в этом плане куцый инструмент.
То что функция в жаве не может возвращать кортеж простых значений,
либо один примитив либо объект, тоже не говорит в ее пользу.

Невозможно создать систему исполняющую "хочу чтобы все", ее придется конкретизировать
и решить вполне формализуемый кейс, если задача не формализуется, программу написать
не получится.
...
Рейтинг: 0 / 0
03.02.2020, 14:19
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921835
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Ну тода закроем зоопарк.
...
Рейтинг: 0 / 0
03.02.2020, 14:41
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921875
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
exp98
автор...Вот совсем не интересно. Интересно, если вы выделили чистый домен. И смогли объяснить это на языке бизнеса, используя свой домен.
Я и говорю, все хотят готовые кнопки. А лучше одну большую. Тогда вас всех сферический бизнесмэн посылает и жмёт всё сам, он ведь самый умный, либо нанимает обычного манагера. Сбылась мечта дурака бизнесмэна.

Вы сравниваете абсолютно перпендикулярные вещи.
...
Рейтинг: 0 / 0
03.02.2020, 15:45
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921881
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
mayton
Раз уж взялись за зоопарк, давай рассмотрим наследование на примере зоопарка. Пусть у нас будут
волк, собака, заяц, кошка, жираф, бегемот, зебра, слон. Итак, все животные разные в реальном мире
между ними нет наследования, они независимы, ни в одном из них не сидит другое животное.
Мы написали классы на каждое животное, стали писать функцию отвечающую за перемещение объекта
и выяснилось, они все о четырех конечностях и функция перемещения у них одинакова, что у нас получилось?
Мы написали одинаковый код много раз, а если еще и накосячили, придется исправлять в многих местах и тестировать
каждый объект по отдельности, это хорошо, нет это совсем не хорошо (даже принцип в программировании
на этот счет имеется - DRY). А давай ка мы возьмем и выделим четыре конечности и функцию перемещения
в самостоятельный класс, назовем его "животное бегающее на четырех ногах", являются ли все перечисленные
нами животные животными бегающими на четырех ногах? Да являются, замечательно получили суперкласс
в котором один раз описали количество конечностей и метод перемещения, бинго.


Вот и попробуй решить эту задачу. Я не знаю как ее решать.
Может я подхожу слишком фундаментально?

Про зоопарк? Стратегия, команда, состояние, посетитель -- описываем поведение. Мост, компоновщик, адаптер -- описываем структуру.

Хотим со стороны бизнеса моделировать, берём DDD.
Хотим удобно описывать сценарии, пилим DSL.

И т.д. и т.п. ООП в данном случае это низкоуровневое решение, и не является инструментом для моделирования объектов реального мира.
...
Рейтинг: 0 / 0
03.02.2020, 15:51
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921885
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kealon(Ruslan)
Участник
hVostt,

извиняюсь спросить, а биснес-объекты для фунционирования DSL вы как описываете?
...
Рейтинг: 0 / 0
03.02.2020, 16:02
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921891
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
hVostt
mayton
пропущено...


Вот и попробуй решить эту задачу. Я не знаю как ее решать.
Может я подхожу слишком фундаментально?


Про зоопарк? Стратегия, команда, состояние, посетитель -- описываем поведение. Мост, компоновщик, адаптер -- описываем структуру.

Вот сколько в топике сейчас сидит читателей - столько и будет компоновок классов и шаблонов.
...
Рейтинг: 0 / 0
03.02.2020, 16:17
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921948
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
hVostt
mayton
Вот ФП - это игры разума. Да. Это программирование. Да. Оно позволяет решать задачи.
Обычно кратко. И оригинально. И когда классическое императивное программирование
устаёт само от себя - выдыхается.


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

Достаточно почитать книжку по ООП времён его популяризации. У опытного разработчика волосы зашевелятся, чё за бред эти люди несут?

В подобной теории есть польза только если правильно на это смотреть. Не в лоб.

У ФП подхода в программировании есть конкретные преимущества. Но есть и конкретные недостатки.

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

И не увидите той математической красоты и элегантности, которую некоторые вам впаривают :)


Да хз. Ты видел, например, задачу обхода конем на SQL, или аналогичное на Haskel? разве это не красиво!
...
Рейтинг: 0 / 0
03.02.2020, 18:06
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921949
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
а это ведь не просто красиво. это концепция!
...
Рейтинг: 0 / 0
03.02.2020, 18:07
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921954
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
монады - если в них разобраться, не такой уж и страшный зверь. вообще, все, что идет от математики - это надо. потому что именно она - генератор абстракций. тех абстракций, которые потом как инструмент используются, в частных случаях
...
Рейтинг: 0 / 0
03.02.2020, 18:11
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921955
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
kealon(Ruslan)
hVostt,

извиняюсь спросить, а биснес-объекты для фунционирования DSL вы как описываете?


Так, чтобы можно было писать требуемую бизнес-логику.
Посмотрите, например, на ABAC.
...
Рейтинг: 0 / 0
03.02.2020, 18:12
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921956
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
hVostt
mayton
Я помнится писал где-то про аналогию с наследованием. Это грандиозная мистификация!
Нет никакого наследования (как в генетике например)!
Есть расширение класса. Оно так и называется - extend.


Почему нет? Есть. Но к реальному миру это не имеет отношения. Насчёт расширения, -- ну нет же. Для расширения есть множество различных паттернов и подходов. Тот же Мост, например. Для расширения как раз лучше используется аргрегация, чем наследование.

mayton
Код: java
1.
class Dog extends Wolf {



Собака расширяет волка. И всё. Не наследует. Не копирует. Не инкапсулирует. А просто расширяет.
Это буквальный английский перевод.


Ну вот он и плохой пример для ООП :)
Тут термин extends работает ещё хуже, так как конкретно запутывает, и откровенно нагло врёт разработчику.


вот видишь Хвост, ты уже потерян для функционального программирования
...
Рейтинг: 0 / 0
03.02.2020, 18:13
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921957
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
mayton
Вот сколько в топике сейчас сидит читателей - столько и будет компоновок классов и шаблонов.


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

Предание про Вавилонскую башню слышали?

Это не значит, что все всё должно делать одинаково, но если не говорить на одном языке, вы и кривого сарая не построите. Потому что у каждого "своя компоновка и шаблоны".
...
Рейтинг: 0 / 0
03.02.2020, 18:16
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921959
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
hVostt
mayton
Вот сколько в топике сейчас сидит читателей - столько и будет компоновок классов и шаблонов.


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

Предание про Вавилонскую башню слышали?

Это не значит, что все всё должно делать одинаково, но если не говорить на одном языке, вы и кривого сарая не построите. Потому что у каждого "своя компоновка и шаблоны".


над ООП вырастают, по сути, свои Метаязыки, SOLID и т.п. - это оно и есть. ТС хотел спросить, как я думаю, нет ли такой же фигни в ФП
...
Рейтинг: 0 / 0
03.02.2020, 18:20
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921961
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
love_bach
над ООП вырастают, по сути, свои Метаязыки, SOLID и т.п. - это оно и есть. ТС хотел спросить, как я думаю, нет ли такой же фигни в ФП


Есть, ссылки уже дал skyANA.
...
Рейтинг: 0 / 0
03.02.2020, 18:22
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921962
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
hVostt
love_bach
над ООП вырастают, по сути, свои Метаязыки, SOLID и т.п. - это оно и есть. ТС хотел спросить, как я думаю, нет ли такой же фигни в ФП


Есть, ссылки уже дал skyANA.


это не то
...
Рейтинг: 0 / 0
03.02.2020, 18:23
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921964
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
hVostt
love_bach
над ООП вырастают, по сути, свои Метаязыки, SOLID и т.п. - это оно и есть. ТС хотел спросить, как я думаю, нет ли такой же фигни в ФП


Есть, ссылки уже дал skyANA.


это вообще не то!
ладно, проехали
...
Рейтинг: 0 / 0
03.02.2020, 18:24
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921973
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
love_bach
hVostt
пропущено...


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

Предание про Вавилонскую башню слышали?

Это не значит, что все всё должно делать одинаково, но если не говорить на одном языке, вы и кривого сарая не построите. Потому что у каждого "своя компоновка и шаблоны".


над ООП вырастают, по сути, свои Метаязыки, SOLID и т.п. - это оно и есть. ТС хотел спросить, как я думаю, нет ли такой же фигни в ФП

Я просто подчеркиваю свою мысль. О том что ООП - математически недоказуемо.

ООП разработчик просто кодит и говорит нам - "вот смотрите... я художник. Я так вижу..."
...
Рейтинг: 0 / 0
03.02.2020, 18:32
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921980
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
mayton
love_bach
пропущено...


над ООП вырастают, по сути, свои Метаязыки, SOLID и т.п. - это оно и есть. ТС хотел спросить, как я думаю, нет ли такой же фигни в ФП

Я просто подчеркиваю свою мысль. О том что ООП - математически недоказуемо.

ООП разработчик просто кодит и говорит нам - "вот смотрите... я художник. Я так вижу..."


ООП - это надстройка над императивной массой языков. Для облегчения сопровождения. И если ООП-ским (правильным) правилам следовать, которые, кстате, выходят за язык, они сверху, тогда можно достичь ... чего-то там.
ФП изначально, в своей парадигме, оно против. там есть более выразительные концепции.
...
Рейтинг: 0 / 0
03.02.2020, 18:42
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921991
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
love_bach
hVostt
пропущено...


Есть, ссылки уже дал skyANA.


это не то

Почему не то?
...
Рейтинг: 0 / 0
03.02.2020, 18:56
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39921999
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kealon(Ruslan)
Участник
skyANA
love_bach
пропущено...


это не то

Почему не то?

попытки адаптации всегда ведут к брешам в логике и реализации

можно конечно делать вид, что типа втыкаешь как зарекомендовано, но всегда где нить кого нить да прорвёт
при том что никто и не заметит, а компилятор обмануть заметно сложнее
...
Рейтинг: 0 / 0
03.02.2020, 19:06
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922052
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Offtopic и черный юмор temporary on.
 

iOracleDev

....
ООП для бизнеса на примере правильных сущностей? Давайте рассмотрим простой пример person, employee, department. С точки зрения ООП employee является person...
...

1)
В свое время сидел за соседним столом, рядом с людьми, которые должны были OeBS в Отдел Кадров для угольных шахт продать:

С точки зрения учета кадров на OeBS - employee это совсем не person, а inventory.

Т.к. самая главная задача - учет выданных касок по серейным номерам, т.к. по каскам в случае аварий employee идентифицируют. А этот бизнес процесс, замечательно автоматизируется в OeBS модулем Inventory

2)
Насколько я знаю, в модуле планирования техобслуживания, employe опять таки не person, а банальный Item с нужной галочкой. Т.к. его можно по техкарте на нужную работу назначить. Что employe, что шуроповерт - без разницы.

p.s.
могу ошибаться, не являюсь экспертом в OeBS.
...
Рейтинг: 0 / 0
03.02.2020, 21:30
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922061
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
booby
Участник
Leonid Kudryavtsev,

смотрел, и не рассмотрел в обоих случаях юмора, тем более чёрного.
Оба кейса мною прочитаны как стишок Агнии Барто - гладко, кратко и приятно,
потому что просто и понятно.
Я даже скажу - почему так.
Про БД я что-то слышал, и с какими-то простыми, но типичными случаями, приходится
сталкиваться достаточно регулярно.
И оперировать этим всегда приходится как информационной моделью определенного сорта,
оторванной от её феноменологического описание.
Не осознав, что имеешь дело дело с Item-ом, ты становишься рабом Persona.
Тогда Каюк таку систему находит не сильно запыхавшись.

А люди "из ооп" настолько помешаны на буквальных интерпретациях классификаций,
что на голубом глазу считают, что у них в узлах зебры из зоопарка сидят, унаследованные от ослов.
У Гради Буча борода колом должна вставать, от осознания того, как именно сообщество
восприняло идеи банды четырёх, переданные его словами.
...
Рейтинг: 0 / 0
03.02.2020, 22:03
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922083
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
mayton
Я просто подчеркиваю свою мысль. О том что ООП - математически недоказуемо.

ООП разработчик просто кодит и говорит нам - "вот смотрите... я художник. Я так вижу..."


Вовсе нет. Откуда и с чего вообще такие выводы?
...
Рейтинг: 0 / 0
04.02.2020, 00:12
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922084
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
mayton
О том что ООП - математически недоказуемо.


И что это значит? ООП это инструмент. Звучит так же странно, как молоток -- математически недоказуемо :)
...
Рейтинг: 0 / 0
04.02.2020, 00:12
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922127
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
hVostt
mayton
О том что ООП - математически недоказуемо.


И что это значит? ООП это инструмент. Звучит так же странно, как молоток -- математически недоказуемо :)


это значит, что оно не в языке, за рамками формальной системы
...
Рейтинг: 0 / 0
04.02.2020, 08:32
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922238
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
love_bach
это значит, что оно не в языке, за рамками формальной системы


ООП в разных языках реализовано.
...
Рейтинг: 0 / 0
04.02.2020, 12:50
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922248
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
hVostt
mayton
О том что ООП - математически недоказуемо.


И что это значит? ООП это инструмент. Звучит так же странно, как молоток -- математически недоказуемо :)


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

Далее вы выполнили декомпозицию предметной области на интерфейсы. Классы. И объекты.
И здесь ваша доказательная база очень слаба. Вы не сможете мне доказать что сдалали работу верно.
Ведь у вас нет на это теста.
...
Рейтинг: 0 / 0
04.02.2020, 13:01
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922264
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
mayton
Вы написали функцию. Вы ее модульно протестировали. Вы доказали что ваша функция правильна.
По бизнес-кейсам например.

Далее вы выполнили декомпозицию предметной области на интерфейсы. Классы. И объекты.
И здесь ваша доказательная база очень слаба. Вы не сможете мне доказать что сдалали работу верно.
Ведь у вас нет на это теста.
А можете показать, что модульные тесты на функцию нельзя заменить модульными тестами на методы.
А то у вас есть введение и заключение, но совершенно не просматривается обоснование, которое как-то выпало из середины.
...
Рейтинг: 0 / 0
04.02.2020, 13:30
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922265
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Мы скатываемся в банальность. Разумеется можете написать тест покрывающий методы.

Но это ведь не ООП. Это вы протестировали методы. Вы фактически доказали что ООП работает
как процедурное программирование если сильно захотеть.

Мой вопрос был в другом.
...
Рейтинг: 0 / 0
04.02.2020, 13:38
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922270
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
mayton
Приведу пример. Вы написали функцию. Вы ее модульно протестировали. Вы доказали что ваша функция правильна.
По бизнес-кейсам например.

Далее вы выполнили декомпозицию предметной области на интерфейсы. Классы. И объекты.
И здесь ваша доказательная база очень слаба. Вы не сможете мне доказать что сдалали работу верно.
Ведь у вас нет на это теста.


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

Вот я сделал функцию сортировки.
Можете показать мне такой тест, который доказывает, что функция 100% работает верно. Во всех случаях.
Это какой тест у вас получится такой? Можете показать? На любом языке.
...
Рейтинг: 0 / 0
04.02.2020, 13:47
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922272
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
mayton,

А ещё тест должен доказать сложность функции.
И доказать заявленные требования по ресурсоёмкости.
...
Рейтинг: 0 / 0
04.02.2020, 13:48
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922273
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
mayton,

На всякий случай, вот вам математическое доказательство https://neerc.ifmo.ru/wiki/index.php?title=Быстрая_сортировка
...
Рейтинг: 0 / 0
04.02.2020, 13:49
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922274
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
mayton,

И затем хотелось бы услышать, на что должно быть похоже доказательство ООП, что вообще нужно доказывать? )
...
Рейтинг: 0 / 0
04.02.2020, 13:50
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922284
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
hVostt
mayton
Приведу пример. Вы написали функцию. Вы ее модульно протестировали. Вы доказали что ваша функция правильна.
По бизнес-кейсам например.

Далее вы выполнили декомпозицию предметной области на интерфейсы. Классы. И объекты.
И здесь ваша доказательная база очень слаба. Вы не сможете мне доказать что сдалали работу верно.
Ведь у вас нет на это теста.


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

Вот я сделал функцию сортировки.
Можете показать мне такой тест, который доказывает, что функция 100% работает верно. Во всех случаях.
Это какой тест у вас получится такой? Можете показать? На любом языке.

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

Ты делаешь тест. И делаешь код который заходит в зеленый сегмент этого теста.
...
Рейтинг: 0 / 0
04.02.2020, 14:02
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922285
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
hVostt
mayton,

И затем хотелось бы услышать, на что должно быть похоже доказательство ООП, что вообще нужно доказывать? )

Я уже несколько дней пишу о том что ООП - это просто набор "лучших практик".

А их никто никогда не доказывает. Недоказуемые они.
...
Рейтинг: 0 / 0
04.02.2020, 14:04
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922299
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
mayton
hVostt
mayton,

И затем хотелось бы услышать, на что должно быть похоже доказательство ООП, что вообще нужно доказывать? )

Я уже несколько дней пишу о том что ООП - это просто набор "лучших практик".

А их никто никогда не доказывает. Недоказуемые они.


Задался вопросом, а что собственно написали авторы "лучших практик". По Вики, Г.Буч поучаствовал в создании RUP и Rational Rose (Rational Software Architect )

Соответственно "лучшесть" практик доказуется чисто статистически - с помощью голосования и соцопроса:
1) у кого из участников данного топика стоит на компьютере Rational Rose / Rational Software Architect
2) кто ими пользуется в повседневной работе
...
Рейтинг: 0 / 0
04.02.2020, 14:26
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922307
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
mayton
Очень просто друг. Ты подходишь к бизнесу. Показываешь ему входные данные. Например табличка
каких то бизнес операций. И эта-же таблица после сортировки. И говоришь - это ОК? Бизнес говорит ОК.

Ты делаешь тест. И делаешь код который заходит в зеленый сегмент этого теста.


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

Но бизнесу тесты до фанаря. И ворох входных данных в принципе тоже.
...
Рейтинг: 0 / 0
04.02.2020, 14:36
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922308
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
mayton
Я уже несколько дней пишу о том что ООП - это просто набор "лучших практик".

А их никто никогда не доказывает. Недоказуемые они.


ООП это не набор лучших практик. Это конкретный инструмент, доступный во многих языках программирования на уровне синтаксиса и структур. С какой кстати, это стало практиками?

Хочешь не хочешь, в ЯП с ООП вы будете использовать это ООП, хотя бы как потребитель. Даже если не будете ничего проектировать.
...
Рейтинг: 0 / 0
04.02.2020, 14:38
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922319
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
hVostt

Но бизнесу тесты до фанаря. И ворох входных данных в принципе тоже.

Нет. User-stories могут содержать сэмплы входных данных в качестве примера.
...
Рейтинг: 0 / 0
04.02.2020, 15:13
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922340
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
mayton
hVostt

Но бизнесу тесты до фанаря. И ворох входных данных в принципе тоже.

Нет. User-stories могут содержать сэмплы входных данных в качестве примера.


Это для QA )
...
Рейтинг: 0 / 0
04.02.2020, 15:39
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922353
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
hVostt
mayton
Я уже несколько дней пишу о том что ООП - это просто набор "лучших практик".

А их никто никогда не доказывает. Недоказуемые они.


ООП это не набор лучших практик. Это конкретный инструмент, доступный во многих языках программирования на уровне синтаксиса и структур. С какой кстати, это стало практиками?

Хочешь не хочешь, в ЯП с ООП вы будете использовать это ООП, хотя бы как потребитель. Даже если не будете ничего проектировать.

Я могу взять ООП-подобный язык писать в нем как в НЕ-ООП. Лишив объекты состояния и используя только
state-less методы. В этом случае я просто не буду следовать практикам.

Тоесть сама по себе принадлежность языку семейству ООП-шных вовсе ничего не гарантирует.
Так-же как например в С++ можно писать объектно и процедурно.
...
Рейтинг: 0 / 0
04.02.2020, 15:54
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922354
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
hVostt
mayton
пропущено...

Нет. User-stories могут содержать сэмплы входных данных в качестве примера.


Это для QA )

Ты не поверишь каков бывает ентерпрайз. Вообще стори пишутся гуманитарным языком.
...
Рейтинг: 0 / 0
04.02.2020, 15:55
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922391
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
mayton
Я могу взять ООП-подобный язык писать в нем как в НЕ-ООП. Лишив объекты состояния и используя только
state-less методы. В этом случае я просто не буду следовать практикам.


А я могу и микроскопом гвоздь забить.
А некоторые кулаком или даже лбом :)


mayton
Тоесть сама по себе принадлежность языку семейству ООП-шных вовсе ничего не гарантирует.


Гарантирует функционирование ООП. Гарантирует правильную работу всех заявленных в ООП штук: наследование, инкапсуляцию, полиформизм. Даёт абстракцию для структур из коробки.

mayton
Так-же как например в С++ можно писать объектно и процедурно.


Ну это тоже инструменты. Чтобы вы могли писать объектно, вам нужны объекты. Чтобы писать процедурно, вам нужны процедуры (функции).

Тогда давайте говорить, что понятия "функция" это лучшие практики ))
...
Рейтинг: 0 / 0
04.02.2020, 16:47
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922393
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
mayton
hVosttЭто для QA )

Ты не поверишь каков бывает ентерпрайз. Вообще стори пишутся гуманитарным языком.

Стори пишутся на языке бизнеса, а кто там представитель бизнеса -- гуманитарий, значит гуманитарным языком.
Я поверю, так как работаю в энтерпрайзе большую часть профессиональной карьеры.
...
Рейтинг: 0 / 0
04.02.2020, 16:49
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922401
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
mayton
Я могу взять ООП-подобный язык писать в нем как в НЕ-ООП. Лишив объекты состояния и используя только
state-less методы. В этом случае я просто не буду следовать практикам.


И мы ведь об этом и говорим в данном топике.
Какие есть практики.

ООП это не практика. ВЫ можете очень активно плодить классы, инкапсулировать данные и логику в приватных методах и полях, наследовать вдоль и поперёк. И это вообще ни разу, ни в одном месте не показатель хорошего, качественного и более того -- правильного и рабочего кода.

Практики существуют над инстурментом.

Если не правильно пользоваться молотком, можно лишиться парочку пальцев. Молоток это не практика!
...
Рейтинг: 0 / 0
04.02.2020, 16:53
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922407
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
hVostt

А я могу и микроскопом гвоздь забить.
А некоторые кулаком или даже лбом :)

Хвост но давай вспоминать какие языки вообще обязывают тебя следовать ООП всегда.
Мне почему-то на ум приходит SmallTalk (который я не знаю) но по слухам он был ТруЪ-ООП-шным.
Где даже 1+1 нельзя было сделать без вовлечения объекта целое число.

Все остальные языки реализуют саму ООП-шность по разному и она - не мандаторная.
Хуже всего - в С++. Там больше упор на шаблонизацию чем на объектность.
И схалтурить и шмальнуть себе в ногу там больше шансов чем везде.

Вот я стартую прототип приложения на ООП языке Java (я так часто делаю когда что-то проверить надо).

Код: java
1.
2.
3.
4.
5.
public class Test{
 public static void main(String[] args) {
    ....
 }
}



Я пишу блин процедурно. У меня тут от ООП вообще нет ничего!! У меня ООП появится только когда я этого захочу.

Ты согласен?
...
Рейтинг: 0 / 0
04.02.2020, 16:59
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922420
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
hVostt

Гарантирует функционирование ООП. Гарантирует правильную работу всех заявленных в ООП штук: наследование, инкапсуляцию, полиформизм. Даёт абстракцию для структур из коробки.

Ну смотри. Если программист берет Хаскель (чисто ФП. Породистый. Правильный. Без побочки).
То он нифига не может создать изменяемую переменную. Его язык ограничил! Он говорит - ты
сцуко ДОЛЖЕН сделать код без состояния.

Если я безу C# или Java то я могу делать ООП а могу и не делать. Опция у меня. Понимаешь.

ООП - опционально!
...
Рейтинг: 0 / 0
04.02.2020, 17:07
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922422
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
hVostt

Ну это тоже инструменты. Чтобы вы могли писать объектно, вам нужны объекты. Чтобы писать процедурно, вам нужны процедуры (функции).


Не обязательно ! Примеры:

JPEG Independent Group - библиотека для работы с JPEG'ом

COM - Common Object Model в Windows

FireFox

насколько я помню, (могу местами ошибаться), все с объектами (ООП !) и все на _чистом__ C.
...
Рейтинг: 0 / 0
04.02.2020, 17:11
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922425
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
OpenGL - хотя и чисто-процедурный. Тем не менее имеет объектный вид.
...
Рейтинг: 0 / 0
04.02.2020, 17:15
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922436
Фотография полудух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
полудух
Участник
Leonid Kudryavtsev
насколько я помню, (могу местами ошибаться), все с объектами (ООП !) и все на _чистом__ C.

объекты это ещё не ООП.
в C нет ООП (там только struct).
...
Рейтинг: 0 / 0
04.02.2020, 17:53
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922437
Фотография полудух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
полудух
Участник
mayton
Если я безу C# или Java то я могу делать ООП а могу и не делать. Опция у меня. Понимаешь.

Java можно без ООП?
вроде нельзя.
...
Рейтинг: 0 / 0
04.02.2020, 17:55
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922438
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
А вот еще интересное ООП. Или не-ООП. Или просто структуризация атомов и method-reference в некие
группы.

Код: javascript
1.
2.
3.
4.
let user = {
  name: "John",
  age: 30,
}
...
Рейтинг: 0 / 0
04.02.2020, 17:59
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922440
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
полудух
mayton
Если я безу C# или Java то я могу делать ООП а могу и не делать. Опция у меня. Понимаешь.

Java можно без ООП?
вроде нельзя.

Статический метод main вызывается без создания объекта.

Значит я обманул ООП.
...
Рейтинг: 0 / 0
04.02.2020, 18:00
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922445
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
полудух
Leonid Kudryavtsev
насколько я помню, (могу местами ошибаться), все с объектами (ООП !) и все на _чистом__ C.

объекты это ещё не ООП.
в C нет ООП (там только struct).


Объекты, инкапсуляция, наследование - это еще не ООП ? И все реализовано на чистом C.

И, насколько я помню, в C++ можно вообще без классов писать! код ниже будет ООП или не будет? Там же только struct!
Код: plaintext
1.
2.
3.
4.
5.
6.
struct AA {
  int myVar;
  void myMethod( void ) {
     myVar = 0;
  }
}
...
Рейтинг: 0 / 0
04.02.2020, 18:10
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922446
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
mayton
Ну смотри. Если программист берет Хаскель (чисто ФП. Породистый. Правильный. Без побочки).
То он нифига не может создать изменяемую переменную. Его язык ограничил! Он говорит - ты
сцуко ДОЛЖЕН сделать код без состояния.

Если я безу C# или Java то я могу делать ООП а могу и не делать. Опция у меня. Понимаешь.

ООП - опционально!


Нет, не можешь. ООП не опционально. Как минимум должен быть класс с методом -- точкой входа.
И потом, все библиотечные средства представляют собой классы и интерфейсы.
В C# даже ссылка на метод -- делегат, является объектом соответствующего класса.

Поэтому не придумывайте :)
...
Рейтинг: 0 / 0
04.02.2020, 18:13
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922448
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
mayton
Код: java
1.
2.
3.
4.
5.
public class Test{
 public static void main(String[] args) {
    ....
 }
}




Я пишу блин процедурно. У меня тут от ООП вообще нет ничего!! У меня ООП появится только когда я этого захочу.

Ты согласен?


Не могу согласиться. Вы создали класс с методами. Пусть он один и пусть в нём 100500 методов. Вы в мире ООП :)
...
Рейтинг: 0 / 0
04.02.2020, 18:14
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922450
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
hVostt
mayton
Код: java
1.
2.
3.
4.
5.
public class Test{
 public static void main(String[] args) {
    ....
 }
}




Я пишу блин процедурно. У меня тут от ООП вообще нет ничего!! У меня ООП появится только когда я этого захочу.

Ты согласен?


Не могу согласиться. Вы создали класс с методами. Пусть он один и пусть в нём 100500 методов. Вы в мире ООП :)


А ничего что экземпляра нет?
...
Рейтинг: 0 / 0
04.02.2020, 18:18
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922452
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
mayton,

В C# всё есть объекты, числа, строки.
Да, конечно ещё есть структуры, но они могут наследовать интерфейсы, передаваться по ссылке, иметь закрытые поля и методы.

В общем, такое себе.

Собственно то, о чём вы говорите нужно смотреть в контексте конкретно решаемой задачи.
Можно решить её конечно в процедурном стиле, функциональном стиле, или с декомпозицией на объекты.
Но в любом случае у таких языках как C#, Java у вас будет машап с уклоном в какую-либо сторону.
...
Рейтинг: 0 / 0
04.02.2020, 18:20
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922453
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
mayton
А ничего что экземпляра нет?


Экземпляра класса? С синтаксической точки зрения он есть, это синглетон.
С точки зрения имплементации, есть экземпляр типа.

Но допустим вы не будете использовать библиотечный функционал, который использует ООП по полной.
Будет у вас определённый стиль.
ООП никуда не делось всё равно.
...
Рейтинг: 0 / 0
04.02.2020, 18:22
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922455
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
mayton,

И я вам больше скажу. Можно использовать ООП и писать в расово функциональном стиле при этом :)
...
Рейтинг: 0 / 0
04.02.2020, 18:23
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922456
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
hVostt

Экземпляра класса? С синтаксической точки зрения он есть, это синглетон.

СИНГЛЕТОН ?

Дошли ((( Из всех патернов я знаю ровно один, пример mayton'а явно не синглетон (((
...
Рейтинг: 0 / 0
04.02.2020, 18:24
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922457
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Ладно закроем тему. Я-бы поговорил по Хаскель. Но чуть позже.
...
Рейтинг: 0 / 0
04.02.2020, 18:25
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922475
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Leonid Kudryavtsev
hVostt

Экземпляра класса? С синтаксической точки зрения он есть, это синглетон.

СИНГЛЕТОН ?

Дошли ((( Из всех патернов я знаю ровно один, пример mayton'а явно не синглетон (((

Мы можем спуститься на уровень JVM и рассматривать экземпляр класса как объект.
Но это явно не уровень Language. Это уже реализация машины. В Sun/Oracle так.
В Android может быть другой принцип.
...
Рейтинг: 0 / 0
04.02.2020, 19:19
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922478
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
hVostt
mayton
Я уже несколько дней пишу о том что ООП - это просто набор "лучших практик".

А их никто никогда не доказывает. Недоказуемые они.


ООП это не набор лучших практик. Это конкретный инструмент, доступный во многих языках программирования на уровне синтаксиса и структур. С какой кстати, это стало практиками?

Хочешь не хочешь, в ЯП с ООП вы будете использовать это ООП, хотя бы как потребитель. Даже если не будете ничего проектировать.


нет. в ФП поток, обрабатываемый/порождаемый программой не подразумевает никаких "классов, интерфейсов, наследования". там другие абстракции
...
Рейтинг: 0 / 0
04.02.2020, 19:26
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922481
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
hVostt
mayton
пропущено...

Нет. User-stories могут содержать сэмплы входных данных в качестве примера.


Это для QA )


так можно сказать и про уравнения мат физики.
...
Рейтинг: 0 / 0
04.02.2020, 19:28
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922482
Фотография полудух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
полудух
Участник
Leonid Kudryavtsev
полудух
пропущено...

объекты это ещё не ООП.
в C нет ООП (там только struct).


Объекты, инкапсуляция, наследование - это еще не ООП ? И все реализовано на чистом C.

И, насколько я помню, в C++ можно вообще без классов писать! код ниже будет ООП или не будет? Там же только struct!
Код: plaintext
1.
2.
3.
4.
5.
6.
struct AA {
  int myVar;
  void myMethod( void ) {
     myVar = 0;
  }
}


Надо понимать, что ООП сегодня оброс таким кол-вом левой инфы, что уже чёрт ногу сломит, причём несколько десятилетий уже... Очень усложнили всё и всех запутали.
Сам создатель ООП-а заявлял, что сегодняшний ООП не имеет ничего общего с тем, что он задумывал.
Вот цитата из вики:
авторОбъектно-ориентированное программирование (ООП) — методология программирования, основанная на представлении программы в виде совокупности объектов , каждый из которых является экземпляром определённого класса, а классы образуют иерархию наследования.
Да хрен там , объект это ещё не ООП! Тут только половина правды - "наследование" это уже ООП, а "совокупность объектов" - нет.
У вас же там просто структура без ООП-а (без того ООП-а, когда оно начинает работать, как ООП).

ООП это лишь способ сократить размер кода, убрать повторы, упростить сопровождение. А ему приписывают какие-то левые функции, которые часто вообще не про него.
Что я понимаю под чётким ООП, у него есть вполне определённый набор инструментов:
наследование, абстракция (интерфейсы), инкапсуляция (public/private) И конструкторы/деструкторы (почему-то про них все забывают, а они ведь имбово рулят в том же C++, позволяя на этапе создания класса проверить большинство параметров, чем сильно упрощают отлов багов.
В C++ вообще философия подхода к объектам очень сильно выпрямляет сознание после того же ПХП (откуда я пришёл), там в объекты пихают вообще всё-всё-всё уже, а в C++ нет, там наоборот уменьшают размер объектов и юзают их как мапы фактически).
Ещё есть полиморфизм (способность ф-и обрабатывать разные типы данных), но в C/C++ это обычный челлендж с шаблонами и к ООП не относится (т.е. опять деза, хоть и решает упрощение кода, но не всё то ООП, что упрощает код).

В C же вообще нет ООП, там нет наследования и нет private/protected, только public всегда.
А вместо наследования там это:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
struct parent {
  /* ... */
}

struct child {
  struct parent p;
  /* ... */
}


А между тем, это самый настоящий объект .
Leonid Kudryavtsev
И, насколько я помню, в C++ можно вообще без классов писать!

Да, и создатели языка именно топят за то, чтобы делать классы как можно меньше :
авторC.4: Make a function a member ONLY if it needs direct access to the representation of a class
C.5: Place helper functions in the same namespace as the class they support
Идеальная программа в C++ основана на неймспейсах, ф-ях и структурах, а классы это способ автоматизировать проверку данных на валидность.
Иерархия классов это громоздкая и сложная штука, её надо избегать, но иногда без неё никуда :(
...
Рейтинг: 0 / 0
04.02.2020, 19:34
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922483
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
hVostt
mayton
Ну смотри. Если программист берет Хаскель (чисто ФП. Породистый. Правильный. Без побочки).
То он нифига не может создать изменяемую переменную. Его язык ограничил! Он говорит - ты
сцуко ДОЛЖЕН сделать код без состояния.

Если я безу C# или Java то я могу делать ООП а могу и не делать. Опция у меня. Понимаешь.

ООП - опционально!


Нет, не можешь. ООП не опционально. Как минимум должен быть класс с методом -- точкой входа.
И потом, все библиотечные средства представляют собой классы и интерфейсы.
В C# даже ссылка на метод -- делегат, является объектом соответствующего класса.

Поэтому не придумывайте :)


ООП в решении задачи - это ООП в мозгу решателя. решение дифура - это, пусть вульгарно, "ф-я". в ФП эта вульгарщина введена в формальную систему, там есть "можно доказать". в ООП - нет. просто потому что ООП - это никакая не парадигма, это просто надстройка. и, пока, надстройка над императивными языками.
...
Рейтинг: 0 / 0
04.02.2020, 19:35
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922485
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
love_bach
hVostt
пропущено...


Нет, не можешь. ООП не опционально. Как минимум должен быть класс с методом -- точкой входа.
И потом, все библиотечные средства представляют собой классы и интерфейсы.
В C# даже ссылка на метод -- делегат, является объектом соответствующего класса.

Поэтому не придумывайте :)


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


бест практикс, для сопровождения, ничего более, но и не менее
...
Рейтинг: 0 / 0
04.02.2020, 19:37
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922494
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
полудух
Leonid Kudryavtsev
пропущено...


Объекты, инкапсуляция, наследование - это еще не ООП ? И все реализовано на чистом C.

И, насколько я помню, в C++ можно вообще без классов писать! код ниже будет ООП или не будет? Там же только struct!
Код: plaintext
1.
2.
3.
4.
5.
6.
struct AA {
  int myVar;
  void myMethod( void ) {
     myVar = 0;
  }
}


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

Да хрен там , объект это ещё не ООП! Тут только половина правды - "наследование" это уже ООП, а "совокупность объектов" - нет.
У вас же там просто структура без ООП-а (без того ООП-а, когда оно начинает работать, как ООП).

ООП это лишь способ сократить размер кода, убрать повторы, упростить сопровождение. А ему приписывают какие-то левые функции, которые часто вообще не про него.
Что я понимаю под чётким ООП, у него есть вполне определённый набор инструментов:
наследование, абстракция (интерфейсы), инкапсуляция (public/private) И конструкторы/деструкторы (почему-то про них все забывают, а они ведь имбово рулят в том же C++, позволяя на этапе создания класса проверить большинство параметров, чем сильно упрощают отлов багов.
В C++ вообще философия подхода к объектам очень сильно выпрямляет сознание после того же ПХП (откуда я пришёл), там в объекты пихают вообще всё-всё-всё уже, а в C++ нет, там наоборот уменьшают размер объектов и юзают их как мапы фактически).
Ещё есть полиморфизм (способность ф-и обрабатывать разные типы данных), но в C/C++ это обычный челлендж с шаблонами и к ООП не относится (т.е. опять деза, хоть и решает упрощение кода, но не всё то ООП, что упрощает код).

В C же вообще нет ООП, там нет наследования и нет private/protected, только public всегда.
А вместо наследования там это:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
struct parent {
  /* ... */
}

struct child {
  struct parent p;
  /* ... */
}


А между тем, это самый настоящий объект .
Leonid Kudryavtsev
И, насколько я помню, в C++ можно вообще без классов писать!

Да, и создатели языка именно топят за то, чтобы делать классы как можно меньше :
авторC.4: Make a function a member ONLY if it needs direct access to the representation of a class
C.5: Place helper functions in the same namespace as the class they support
Идеальная программа в C++ основана на неймспейсах, ф-ях и структурах, а классы это способ автоматизировать проверку данных на валидность.
Иерархия классов это громоздкая и сложная штука, её надо избегать, но иногда без неё никуда :(
+
...
Рейтинг: 0 / 0
04.02.2020, 19:58
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922495
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
mayton
OpenGL - хотя и чисто-процедурный. Тем не менее имеет объектный вид.


не соглашусь. он имеет вид "управления объектами по их свойствам"
...
Рейтинг: 0 / 0
04.02.2020, 19:59
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922524
iOracleDev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iOracleDev
Участник
mayton
Мы можем спуститься на уровень JVM и рассматривать экземпляр класса как объект.
Но это явно не уровень Language. Это уже реализация машины. В Sun/Oracle так.

Вообще то экземпляр класса и есть объект, инстанс то бишь, называть статическую часть единую для всех
экземпляров класса экземпляром класса как то неправильно, каламбур получается))

ООП - уровень абстракции позволяющий разбить процедурную монолитную нечитаемую и неподдерживаемую
портянку на отдельные условно-независимые части, работать с кирпичиками и складывать из кирпичиков
человеку гораздо проще чем пытаться уместить в мозг все и сразу, на счет того как разбивать, каждый
разработчик компиляторов смотрит по своему, в любом случае ООП программа может быть декомпозирована
в процедурную (не человеком, человеку сложновато это проделать иначе бы не нужена была ООП-абстракция).
...
Рейтинг: 0 / 0
04.02.2020, 22:12
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922550
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
iOracleDev, так говоришь будто процедурно - это плохо. Все ядра операционных систем написаны на языке
в котором принципиально нет объектов. Наиболее популярные игры конца 2000х написаны на "C".
...
Рейтинг: 0 / 0
05.02.2020, 00:53
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922556
iOracleDev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iOracleDev
Участник
mayton,

Это не плохо, то что ты перечислил это низкоуровневые вещи требующие хорошей работы с железом
и как следствие уровень наиболее близкий к железу, бизнес задачи решать на таком уровне как правило
не удобно, кода слишком много, организация его плохая, вот и выходим на другие уровни абстракции.
...
Рейтинг: 0 / 0
05.02.2020, 01:10
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922559
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
mayton
iOracleDev, так говоришь будто процедурно - это плохо. Все ядра операционных систем написаны на языке
в котором принципиально нет объектов. Наиболее популярные игры конца 2000х написаны на "C".
откуда вы решили, что в С нет объектов? на С прекрасно реализуются все абстракции ООП, пожалуй с инкапсуляцией есть некоторые проблемы. писать в ООП стиле на С муторно довольно, но не бином ньютона никакой.
...
Рейтинг: 0 / 0
05.02.2020, 01:18
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922560
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Мысль здравая.

Господа. В нашем техническом споре наконец появились две оси.
Одна из них
- ООП
- Процедурное
Другая
- Бизнес программирование
- Низкоуровненое (для ядер ОС и игрушек)

Куда здесь приткнуть ФП я пока не знаю или это будет 3-е измерение (куб) или просто
как сегмент известных осей. Но вышеперечисленный квадрант мне нравится тем
что начала и концы осей - суть антагонисты.

По крайней мере они отражают природу нашего спора.
...
Рейтинг: 0 / 0
05.02.2020, 01:21
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922563
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
booby
Участник
mayton,

оси не ясны -
если "ооп - процедурное" края оси,
то вся разница со стороны синтаксиса заключится в узаконивании в ооп кошерного места для глобальных переменных. То место, где сидят глобальные переменные, в ооп называется объектом. В чистом процедурном в этом отношении разноголосица и споры о целесообразности использования глобальных переменных.
вряд ли этого достаточно для объявления их противоположностями.
по поводу всего остального можно спорить.

вторая ось наверно понятнее, но что ею измерять планируешь - требования к инструментам разработки, или требования к программисту?
...
Рейтинг: 0 / 0
05.02.2020, 01:59
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922564
Фотография полудух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
полудух
Участник
iOracleDev
бизнес задачи решать на таком уровне как правило не удобно, кода слишком много, организация его плохая, вот и выходим на другие уровни абстракции.

просто не умеете готовить
mayton
Куда здесь приткнуть ФП я пока не знаю

может начать с обозначения ФП?
чем ФП отличается от процедурного, например?
...
Рейтинг: 0 / 0
05.02.2020, 02:11
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922566
iOracleDev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iOracleDev
Участник
mayton
Одна из них

Императивные, по повышению уровня абстракции (с примерами):
ассемблер -> процедурные (С) -> ООП (C++)

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

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

mayton
Куда здесь приткнуть ФП я пока не знаю

В википедии его вроде в декларативные запихнули, вместе с SQL
...
Рейтинг: 0 / 0
05.02.2020, 02:23
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922573
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
love_bach
 
Спрятал простыню
полудух
пропущено...

Надо понимать, что ООП сегодня оброс таким кол-вом левой инфы, что уже чёрт ногу сломит, причём несколько десятилетий уже... Очень усложнили всё и всех запутали.
Сам создатель ООП-а заявлял, что сегодняшний ООП не имеет ничего общего с тем, что он задумывал.
Вот цитата из вики:
пропущено...

Да хрен там , объект это ещё не ООП! Тут только половина правды - "наследование" это уже ООП, а "совокупность объектов" - нет.
У вас же там просто структура без ООП-а (без того ООП-а, когда оно начинает работать, как ООП).

ООП это лишь способ сократить размер кода, убрать повторы, упростить сопровождение. А ему приписывают какие-то левые функции, которые часто вообще не про него.
Что я понимаю под чётким ООП, у него есть вполне определённый набор инструментов:
наследование, абстракция (интерфейсы), инкапсуляция (public/private) И конструкторы/деструкторы (почему-то про них все забывают, а они ведь имбово рулят в том же C++, позволяя на этапе создания класса проверить большинство параметров, чем сильно упрощают отлов багов.
В C++ вообще философия подхода к объектам очень сильно выпрямляет сознание после того же ПХП (откуда я пришёл), там в объекты пихают вообще всё-всё-всё уже, а в C++ нет, там наоборот уменьшают размер объектов и юзают их как мапы фактически).
Ещё есть полиморфизм (способность ф-и обрабатывать разные типы данных), но в C/C++ это обычный челлендж с шаблонами и к ООП не относится (т.е. опять деза, хоть и решает упрощение кода, но не всё то ООП, что упрощает код).

В C же вообще нет ООП, там нет наследования и нет private/protected, только public всегда.
А вместо наследования там это:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
struct parent {
  /* ... */
}

struct child {
  struct parent p;
  /* ... */
}


А между тем, это самый настоящий объект .
пропущено...

Да, и создатели языка именно топят за то, чтобы делать классы как можно меньше :
пропущено...

Идеальная программа в C++ основана на неймспейсах, ф-ях и структурах, а классы это способ автоматизировать проверку данных на валидность.
Иерархия классов это громоздкая и сложная штука, её надо избегать, но иногда без неё никуда :(

+
И опять это злогремучее избыточное цитирование ...
Вы, что, охудели все?
Или настолько необучаемы, что неспособны использовать механизм ссылок, предоставляемый форумом???
...
Рейтинг: 0 / 0
05.02.2020, 05:21
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922575
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
mayton
В нашем техническом споре наконец появились две оси.
Странное дробление: "ООП и процедурное" против "Деловое и низкоуровневое".

Любое программирование решает задачу и, в этом смысле, оно всегда "деловое". Задачи только разные. Низкоуровневые - в том числе.
А вот "процедурное", "объектное", "декларативное" и "функциональное" - методики решения. Или "вполне общие" или "достаточно узкоспециализированные".

Лично я считаю объектное и процедурное "вполне общим", а декларативное и функциональное - "достаточно узкоспециализированным".
Узкая специализация функциональщины следует из необратимости природы (так называемая стрела времени). Если на графике скалярной функции одной переменной (время -> координата) можно произвольно перемещаться по оси времени, то реальный мир всегда движется из прошлого в будущее - у мира есть состояние.
Закон сохранения энергии накладывает вполне конкретные ограничения на изменения состояния, но состояние существует и меняется со временем.
...
Рейтинг: 0 / 0
05.02.2020, 05:41
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922714
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Leonid Kudryavtsev
СИНГЛЕТОН ?

Дошли ((( Из всех патернов я знаю ровно один, пример mayton'а явно не синглетон (((


Ой да ладно вам. Если не нужно экземпляр передавать по ссылке, все остальные формальности выполнены.
...
Рейтинг: 0 / 0
05.02.2020, 11:45
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922721
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
mayton
Мысль здравая.

Господа. В нашем техническом споре наконец появились две оси.
Одна из них
- ООП
- Процедурное
Другая
- Бизнес программирование
- Низкоуровненое (для ядер ОС и игрушек)

Куда здесь приткнуть ФП я пока не знаю или это будет 3-е измерение (куб) или просто
как сегмент известных осей. Но вышеперечисленный квадрант мне нравится тем
что начала и концы осей - суть антагонисты.

По крайней мере они отражают природу нашего спора.


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

— Эх, я бы использовал ФП, да вот знаний хаскеля нет...
— А я бы бегал по утрам, да вот фитнес-трекера нет...

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

Конечно, F# удобнее для ФП, чем C#, но это не камень преткновения.

В реальном мире смешение техник, под задачу -- наиболее гибкий и эффективный способ разработки.
...
Рейтинг: 0 / 0
05.02.2020, 11:50
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922727
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Я вот посмотрел wiki по top10 languages. И вобщем-то там нет строгой классификации.
Там - фасеты. Или просто сет свойств. Например С++ и Scala попадают в какое-то над-множество
технологий что лежат сразу во всех категориях или обладают всеми свойствами сразу.

Вобщем классификация это - многомерная. Я себе вижу что каждый язык - это точка в булевом
30-мерном пространстве.

Пока я отложу идею классификации.
...
Рейтинг: 0 / 0
05.02.2020, 11:55
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922860
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
hVostt

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

Да я последние 15 лет то и делаю что мешаю разные коктейли из языков и технологий.
Вот уже год озабочен языком (или способом) описание крупнейшей области бизнеса.
Типа мета-данные для аналитики. Пробовал prolog. Щас хочу посмотреть каков Хаскель
в задачах просто описания и поиска фактов.
...
Рейтинг: 0 / 0
05.02.2020, 14:18
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922990
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
iOracleDev

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

Выдвину аксиому, с которой надеюсь большинство согласится

Для БИЗНЕСА - нужен FoxPro
А вот все эти ООП и джава, шарпы - исключительно Г.Бучу, UML-рисовальшикам (т.к. даже назвать их анал итиками язык не поворачивается, они, подозреваю, даже на анал из бизнес процессов не способны) и студентам в свободное от занятий время изобретающих велосипеды типа Hybernate, No-SQL и все такое прочее.

В качестве, опять таки, статистического тестирования данной аксиомы, предлагаю провести опрос:
Кто на работе рисует UML при реальной разработки заказной бизнес-системы?

IMHO & AFAIK
...
Рейтинг: 0 / 0
05.02.2020, 16:07
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922992
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
hVostt
Leonid Kudryavtsev
СИНГЛЕТОН ?

Дошли ((( Из всех патернов я знаю ровно один, пример mayton'а явно не синглетон (((


Ой да ладно вам. Если не нужно экземпляр передавать по ссылке, все остальные формальности выполнены.

mayton

Мы можем спуститься на уровень JVM и рассматривать экземпляр класса как объект.

Даже не аксиома, а теорема (т.к. есть доказательство!):

1) Теорема: Любая программа - реализует паттер синглетон
2) Следствие: Все в этом мире - синглетон

Доказательство:
В любой программе всегда существует экземпляр BIOS --> паттерн синглетон детектед
...
Рейтинг: 0 / 0
05.02.2020, 16:14
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922995
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
hVostt

...
Конечно, F# удобнее для ФП, чем C#, но это не камень преткновения.

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

+100500
...
Рейтинг: 0 / 0
05.02.2020, 16:16
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922996
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
Leonid Kudryavtsev
В любой программе всегда существует экземпляр BIOS --> паттерн синглетон детектед
Нет, обнаружена ложная индукция (неверна исходная посылка). С индукцией тоже всё плохо, но это уже мелочи.
...
Рейтинг: 0 / 0
05.02.2020, 16:21
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39922997
Фотография полудух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
полудух
Участник
Leonid Kudryavtsev
А вот все эти ООП и джава, шарпы - исключительно Г.Бучу, UML-рисовальшикам и студентам в свободное от занятий время изобретающих велосипеды типа Hybernate, No-SQL и все такое прочее.

ну ООП к UML приравнять это уже перебор
...
Рейтинг: 0 / 0
05.02.2020, 16:21
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39923021
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Leonid Kudryavtsev
hVostt
пропущено...


Ой да ладно вам. Если не нужно экземпляр передавать по ссылке, все остальные формальности выполнены.

mayton

Мы можем спуститься на уровень JVM и рассматривать экземпляр класса как объект.

Даже не аксиома, а теорема (т.к. есть доказательство!):

1) Теорема: Любая программа - реализует паттер синглетон
2) Следствие: Все в этом мире - синглетон

Доказательство:
В любой программе всегда существует экземпляр BIOS --> паттерн синглетон детектед

Давай обобщим. В конце концов программы пишут и для мобил и для чипованных карточек.

В любой программе у нас есть возможность использовать глобальную переменную.
...
Рейтинг: 0 / 0
05.02.2020, 16:46
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39923093
exp98
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
exp98
Участник
Leonid Kudryavtsev
Выдвину аксиому, ...Для БИЗНЕСА - нужен FoxPro
для ГУИ БИЗНЕСА нужен "FoxPro", для данных - SQL/FQL.
авторА вот все эти ООП и джава ... жаба - в телефоны, ООП - если б не оно, в винде не случилось бы ускорение сопостоавимых разработок - это факт 90-х ещё.
авторКто на работе рисует UML при реальной разработки заказной бизнес-системы?Был и участником рисования, и необязательно заказной тоже, и необязательно строгий UML, можно и квазиUML. Ведь суть в дальнейшей автоматизации? Просто сам UML дорого стоит.

Т.о. остались дыры классификации "Не ГУИ", "не ООП" ...
...
Рейтинг: 0 / 0
05.02.2020, 19:47
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39923125
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Интересно что Линус Торвальдс и Алан Кей весьма нелицеприятно отзываются о современном ООП.
Один говорит - говно из говна. Другой - "я когда создавал ООП я не имел в виду ТАКОЕ ООП" ....e.t.c.

Вот такие вот пирожки.
...
Рейтинг: 0 / 0
05.02.2020, 21:25
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39923132
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anatoly Moskovsky
Участник
mayton
Интересно что Линус Торвальдс и Алан Кей весьма нелицеприятно отзываются о современном ООП.
Один говорит - говно из говна. Другой - "я когда создавал ООП я не имел в виду ТАКОЕ ООП" ....e.t.c.

Как человек, который с десяток раз переписывал код, потому что АПИ ядра Линукса для драйверов постоянно меняется, полностью согласен с Линусом - то ООП которое он применяет в ядре - полное гуано
...
Рейтинг: 0 / 0
05.02.2020, 22:02
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39923134
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Anatoly Moskovsky
mayton
Интересно что Линус Торвальдс и Алан Кей весьма нелицеприятно отзываются о современном ООП.
Один говорит - говно из говна. Другой - "я когда создавал ООП я не имел в виду ТАКОЕ ООП" ....e.t.c.

Как человек, который с десяток раз переписывал код, потому что АПИ ядра Линукса для драйверов постоянно меняется, полностью согласен с Линусом - то ООП которое он применяет в ядре - полное гуано

А чьи коммиты были?
...
Рейтинг: 0 / 0
05.02.2020, 22:05
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39923141
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anatoly Moskovsky
Участник
mayton
А чьи коммиты были?

А какая разница?
...
Рейтинг: 0 / 0
05.02.2020, 22:23
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39923143
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Ну.. я согласен что Линус иногда бывает мудаковатый. Но на его счету лежит обширная инженерия знаний
от железа сетей и дисков до планирования и прочее. Я думаю что он имеет право на своё мнение в части
ООП. Не потому что ООП плохо. А просто потому что ему (Линусу) ООП не нужно.
...
Рейтинг: 0 / 0
05.02.2020, 22:37
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39923148
Фотография полудух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
полудух
Участник
Anatoly Moskovsky
mayton
Интересно что Линус Торвальдс и Алан Кей весьма нелицеприятно отзываются о современном ООП.
Один говорит - говно из говна. Другой - "я когда создавал ООП я не имел в виду ТАКОЕ ООП" ....e.t.c.

Как человек, который с десяток раз переписывал код, потому что АПИ ядра Линукса для драйверов постоянно меняется, полностью согласен с Линусом - то ООП которое он применяет в ядре - полное гуано

ядро же на C?
в C нет ООП.
...
Рейтинг: 0 / 0
05.02.2020, 23:03
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39923150
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
полудух
в C нет ООП.
а мужики то и не знают, спасибо, что сказал)))
...
Рейтинг: 0 / 0
05.02.2020, 23:19
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39923161
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
booby
Участник
mayton
... Алан Кей весьма нелицеприятно отзываются о современном ООП.
....

Уж больно художественно Кэй на эти темы высказывается.
(Ему бы ещё гитару, которой он в совершенстве владеет, на свои выступления захватывать...)
Мол, у норвежского "ооп" все окна обращены в овраг...
( а как ещё строить, если живёшь в скалистой стране?)

Топит за математику в программировании, говорит объекты это не структуры со связанным с ними кодом, а...

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

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

Языком чесать (т.е. командами обмениваться) им можно так,
а конкурировать, -
по устройству избы,
им не положено....

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

И такой смутный, чудн о й разговор
не понять вне контекста,
где обида, где нож.
Чужой человек
ухватил взглядом тень,
а мысль не поймал.
Здесь бы сесть за стол,
да по.толковать.
...
В общем, видать - был он долго в пути,
и совсем позабыл, кто хозяином здесь...
----------------------------------------------------
-----------------------------------------------------
PS1
вот така мысля (и я не знаю, как ея думать) есть в голове у меня:
--
Страуструп работал-работал профессором, бог знает сколько лет, а потом пнул ногой образование и пошёл в банкиры. Сейчас сотрудник великолепного банка.
Это глубокий ход для человека, считающего себя программистом, а не компьютерным саентистом.
Есть примеры другого, тоже глубокого поведения.
Думаю, для Кнута, например, перестать быть профессором тождественно равно физически умереть.
Хоар пометался туда-сюда, но сейчас я как невероятное бы оценил, если бы он свое профессорское звание променял на должность в любой великолепной компании.

Кей во многих отношениях замечательный человек,
и даже верю в то, что весьма креативный профессор.
Но, сдаётся мне, подвернись хорошее предложение, ему хватило бы креатива метнуться из профессуры в учёные корпоративные консультанты.
Но времена не только его родного Зиракса, но и АйбиЭм и ЭйчПи и многих других потрясающих воображение корпоративных имен, там где они как компании
сворачивали способы мышления о программировании и вычислениях,
уже прошли, скорее к сожалению.
------------------
PS2
Все выше сказанное было сказано
с глубоким уважением ко всем упомянутым персонам.
...
Рейтинг: 0 / 0
06.02.2020, 01:10
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39923163
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
booby
Участник
PS3
Подозреваю, что Торвальдс, на голубом глазу,
хейтит C++ из-за ооп-шного оверхеда.
Мол, знаем мы ваши сказочки про то, что стоимость его зеро.
тока в руках наших опенсорсных писателей зеро волшебным образом превращается в бесконечность.
Потому, пока я живым личным глазом за ядром присматриваю,
никаких плюсов с нулевым оверхедом в моём ядре не будет.
...
Рейтинг: 0 / 0
06.02.2020, 01:18
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39923164
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
booby
Участник
PS4
Что до драйверов, то и в винде - что в ядре, что в драйверах, доля чистого C преобладающая.
Однако именно интерфейсную часть для взаимодействия кода драйверов с ядром
системы, люди сидели и выписывали, кажется, тщательно слюнявя палец и многократно перелистывая в обе стороны странички свежеотпечатанной опп-брошюры для энтузиастов.
И мне это нравится, хоть я и не владею гитарой.

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

Мне кажется, как профессор, Алан Кэй, в этом месте, мог бы
чувствовать себя вполне удовлетворённым.
...
Рейтинг: 0 / 0
06.02.2020, 01:32
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39923165
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
booby
Участник
PS5, предфинальный
"ооп" - это не про смоллток и не про симулу-67, а про "объектно ориентированное проектирование "
Это про то, как карандашиком на листочке бумаги квадратики рисовать,
и придавать смысл использованным на рисунке стрелочкам.

В достаточной степени ошарашивает идея прямого переноса набора терминологии из
"подхода к проектированию" в синтаксис самых великолепных языков.
Это какая-то голубая вода, а не программирование...
...
Рейтинг: 0 / 0
06.02.2020, 01:43
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39923166
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
booby
Участник
ЗЫ6
ах, простите, забыл, что хотел сказать.
(;
...
Рейтинг: 0 / 0
06.02.2020, 01:54
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39923205
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Ну ты букв написал!

А за Высоцкого - спс. Порадовал.
...
Рейтинг: 0 / 0
06.02.2020, 09:47
| Ответить | Цитировать | Написать  
Подходы к построению архитектуры в функциональном программировании
    #39924346
mirudom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mirudom
Участник
maytonОчень просто друг. Ты подходишь к бизнесу. Показываешь ему входные данные. Например табличка
каких то бизнес операций. И эта-же таблица после сортировки. И говоришь - это ОК? Бизнес говорит ОК.Уважаемый mayton,
книга: наука программирования, автор: Девид Грис., но это про КОД. у нас книга вышла в 1984 году

Ваше выссказывание:
maytonЯ просто подчеркиваю свою мысль. О том что ООП - математически недоказуемо.
ООП разработчик просто кодит и говорит нам - "вот смотрите... я художник. Я так вижу..."навеено вашей работой:
maytonДа я последние 15 лет то и делаю что мешаю разные коктейли из языков и технологий.
Вот уже год озабочен языком (или способом) описание крупнейшей области бизнеса.
Типа мета-данные для аналитики. Пробовал prolog. Щас хочу посмотреть каков Хаскель
в задачах просто описания и поиска фактов. Что бы аргументированно сказать о, Вам нужен опыт в ООА/ООД/ООП,
и не просто опыт, а возможность разработки прогушки за достаточно долгий период. Сроки, плюшки, кнуты и тд.
Там (ООА/ООД/ООП), все достаточно строго.
...
Рейтинг: 0 / 0
09.02.2020, 11:49
| Ответить | Цитировать | Написать  
207 сообщений из 207, показаны все 9 страниц
  все  
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Подходы к построению архитектуры в функциональном программировании
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]