Это специфика shell языков. Они все такие не от хорошей жизни. Основное назначение этой группы языков — командный интерпретатор в консоли.
Сложно совместить удобство работы в консоли с удобством написания скриптов.
Вот, например, от 14-ого года. Здесь довольно интересно о совмещении задач обратной кинематики и обратной динамики для построения контура обратной связи. www.cs.cmu.edu/~sfeng/sf_hum14.pdf
В зависимости от терминологии, может и путаются.
Неуверен, что можно рассматривать актора как расширение понятия объекта. Но если их так рассматривать, то вполне может быть.
Я акторы воспринимаю немного по-другому. Скажем так, в функциональном программировании понятия времени нет, а в акторной модели понятие времени есть.
Я специально (возможно несколько неаккуратно) перевернул эту конструкцию, потому что иначе кто-то мог бы сказать, что с точки зрения ФП вся преамбула мутабельных действий над объектом — это просто инициализация. И пришлось бы сказать, что ООП допустимо в инициализации аргументов, что довольно узко.
Мне немного непонятно, почему класс и метод меняют свои смыслы, но да шут с ними...
Я покажу непротиворечивость методом временного разделения. В примере выше мы использовали объекты как аргументы чистых функций, чтобы получить функциональный вывод. Для этого мы потребовали иммутабельности объектов во время вывода. Но как только объект выведен, мы можем отбросить функциональную парадигму и использовать этот объект в полной мере задействуя приёмы ООП. Иммутабельности более не требуется.
Это хорошее замечание. Фокус здесь в том, что инкапсулированность состояния не требует его мутабельности.
Я привожу пример с функциональным выводом геометрических тел в результате выполнения булевых операций над примитивными телами.
Объект геометрического тела в brep представлении является сложным объектом в котором есть несколько уровней заинкапсулированных абстракций, но если мы используем эти объекты иммутабельно, мы можем использовать принципы функционального программирования для построения деревьев вычислений и строгого вывода сложных тел.
Таким образом, ФП может работать вместе с ООП при условии иммутабельности объектов.
Upd: правильнее сказать внешней иммутабельности. То есть объекты должны быть иммутабельно с точки зрения методов, следующих принципам ФП.
И тем не менее наследование инспирировано именно идеями декомпозиции. Было бы довольно неблагодарно и недальновидно забыть о нем, в вопросе происхождения ООП. Мы же не обсуждаем, применять его или нет, но пытаемся понять, что такое ООП в целом.
Ну чтож. С цель развеивания мифов и популяризации ФП, так и запишем. СУЩЕСТВУЮТ ДВЕ ПАРАДИГМЫ ПРОГРАММИРОВАНИЯ, КОТОРЫЕ ИМЕЮТ ЧТО-ТО ВРОДЕ ОПРЕДЕЛЕНИЯ. Пусть все услышат и пусть отныне будет так.
Первая — вынести и переиспользовать часть кода классов кодирующих схожие объекты.
Вторая — идея интерфейса — использовать родительский тип как интерфейс к многим разным вариантам имплементации.
Впоследствии идеи разнесли в концепции миксинов и интерфейсов… Или кто там их как называет, поскольку совместно они работали не очень хорошо.
Проблема наследования в том, что оно стимулирует программиста писать довольно большие иерархии классов, тем самым порождая сильную связность, однако идеи положенные в основу наследования по прежнему актуальны. Ждем более удачные реализации.
-Давайте разбираться!+Давайте скачаем библиотеку!Соответствует.
Практическое применение отрицательного биномиального распределения и расчет доверительных интервалов в контексте стоящей на повестке дня темы.
Очень даже соответствует.
Сложно совместить удобство работы в консоли с удобством написания скриптов.
Ась? Кого позвать?
… Простите… :)
Мне почему-то кажется, что это большинство сравнительно компактно...
www.cs.cmu.edu/~sfeng/sf_hum14.pdf
Подозреваю, что материалы есть и посвежее.
Общественность жаждет уравнений!
Тема не раскрыта :)
Ненавижу двадцать первый век. Опять батарейка в книге села.
В зависимости от терминологии, может и путаются.
Неуверен, что можно рассматривать актора как расширение понятия объекта. Но если их так рассматривать, то вполне может быть.
Я акторы воспринимаю немного по-другому. Скажем так, в функциональном программировании понятия времени нет, а в акторной модели понятие времени есть.
Но это эфемерно как-то...
Я специально (возможно несколько неаккуратно) перевернул эту конструкцию, потому что иначе кто-то мог бы сказать, что с точки зрения ФП вся преамбула мутабельных действий над объектом — это просто инициализация. И пришлось бы сказать, что ООП допустимо в инициализации аргументов, что довольно узко.
Мне немного непонятно, почему класс и метод меняют свои смыслы, но да шут с ними...
Я покажу непротиворечивость методом временного разделения. В примере выше мы использовали объекты как аргументы чистых функций, чтобы получить функциональный вывод. Для этого мы потребовали иммутабельности объектов во время вывода. Но как только объект выведен, мы можем отбросить функциональную парадигму и использовать этот объект в полной мере задействуя приёмы ООП. Иммутабельности более не требуется.
Я привожу пример с функциональным выводом геометрических тел в результате выполнения булевых операций над примитивными телами.
Объект геометрического тела в brep представлении является сложным объектом в котором есть несколько уровней заинкапсулированных абстракций, но если мы используем эти объекты иммутабельно, мы можем использовать принципы функционального программирования для построения деревьев вычислений и строгого вывода сложных тел.
Таким образом, ФП может работать вместе с ООП при условии иммутабельности объектов.
Upd: правильнее сказать внешней иммутабельности. То есть объекты должны быть иммутабельно с точки зрения методов, следующих принципам ФП.
И тем не менее наследование инспирировано именно идеями декомпозиции. Было бы довольно неблагодарно и недальновидно забыть о нем, в вопросе происхождения ООП. Мы же не обсуждаем, применять его или нет, но пытаемся понять, что такое ООП в целом.
А я вам больше скажу… Довольно сложно писать функционально и при этом необъектно.
:-)
Первая — вынести и переиспользовать часть кода классов кодирующих схожие объекты.
Вторая — идея интерфейса — использовать родительский тип как интерфейс к многим разным вариантам имплементации.
Впоследствии идеи разнесли в концепции миксинов и интерфейсов… Или кто там их как называет, поскольку совместно они работали не очень хорошо.
Проблема наследования в том, что оно стимулирует программиста писать довольно большие иерархии классов, тем самым порождая сильную связность, однако идеи положенные в основу наследования по прежнему актуальны. Ждем более удачные реализации.
Но мне кажется сообщество не до конца привыкло к функциональному программированию и некоторые дебаты вокруг него еще продолжаются.
Думаю лет через десять можно будет уже сказать точно.