до завтра 15 минут, можно и сегодня написать
Я спать пойду. Напомни ток
Евгений
sleeping
id id id id id id id id id id id id id id id id id id id id id id id id id id id id 42
кана
арность не совпадает
Alexander
ну вроде в случае жадных это должно быть аккуратно записанное \a b -> b ?
Alexander
@elemir90 ^
кана
или не, таки совпадает, хм. Интересный пример
Alexander
Конечно знает, он крут в плане написания кода на хаскеле, я так не умею :( Но типа специалист в одном не значит специалист во всём
у меня вообще с теорией плохо, поэтому я люблю всякие курсы смотреть
sleeping
ты шустрый
sleeping
долго считал?
Валерий
(я случайно ужратый, простите)
sleeping
прикол в том, что ghci и hugs посчитают эту штуку по-разному
Евгений
ну вроде в случае жадных это должно быть аккуратно записанное \a b -> b ?
(lambda x. (lambda y.y)), ага. Вот и вся твоя императивность :)
Alexander
ладно я согласен, что моё определение страдает
Зигохистоморфный
Cheese
(лень двести сообщений читать, но я уверен, что не было)
замыкания — объекты для бедных
объекты — замыкания для бедных
Cheese
это к вопросу о противопоставлении ФП и ООП
sleeping
"An object is data with functions. A closure is a function with data" — John D. Cook
Alexander
кто умеет хорошо читать stg?
Alexander
http://juick.com/qnikst/2882116 <- вот тет есть непонятная штука, может у кого есть идеи?
Alexander
всем спасибо, ответ нашёл
Зигохистоморфный
какой профит от комоноида?
Alexander
такой же как от комонады7
Alexander
если не считать линейных типов
Зигохистоморфный
Monoid -> List -> Free Monad
Comonoid -> Stream -> Cofree Comonad
такой путь (спискок - свободный моноид, стрим - свободный комоноид)?
Евгений
Объекты - это замыкания для бедных. Поэтому ООП есть и в Схеме и даже у меня в языке.
Ilya
а правда, что в реальном мире "есть объекты, и у них есть состояния, а ваш ФП - это абстрактная чушь"?
Misha
Правда, только это не всегда удобная для работы модель
Igor
а правда, что в реальном мире "есть объекты, и у них есть состояния, а ваш ФП - это абстрактная чушь"?
В реальном софте состояние как-то больше в базе хранится
и даже ооп-шники в основном юзают Anemic Domain модели
Alexander
ООП не кеевсеое оно об иерархиях
Alexander
и вот то что в реальном мире существуют однозначные иерархии объектов выглядит сомнительным
Alexander
а объекты как что-то инкаплусирующее состояние моделируются легко
Ilya
и вот то что в реальном мире существуют однозначные иерархии объектов выглядит сомнительным
ну а как же любимое самолёт -> пассажирский самолёт -> boeing 737
Alexander
и все стейт машины и т.п. прекрасно выглядят
Ilya
об однозначных никто не говорит, есть множественное наследование
Alexander
где?
Alexander
из ФЯ есть в плюсах
Alexander
где они настолько криво, насколько это возможно
Alexander
во всех более современных и адекватных языках движутся к интерфейсам и отсутствию иерархий
Alexander
ну примерно то, что тут было в 80х годах
Alexander
:)
Ilya
а в чём такой профит от интерфейсов?
Ilya
каждый раз же нужно заново реализовывать функции?
Ilya
даже те, которыми могут быть одинаковыми для разных типов
Alexander
Есть языки с поддержкой дефолтной имплементации методов в интерфейсах
Ilya
Есть языки с поддержкой дефолтной имплементации методов в интерфейсах
ну это уже похоже на классическое наследование
Cheese
в ФП тоже есть интерфейсы, и помощнее ООПшных
Ilya
Есть языки с поддержкой дефолтной имплементации методов в интерфейсах
интерфейс + дефолтные реализации некоторых (общих) функций = наследование, не?
Anton
Там это отдельно от наследования
Ilya
как реализовано, не очень важно
Ilya
что такого дают экстеншены, что нельзя сделать наследованием
Anton
Там статический диспэтч
Anton
Короче они не виртуальные
Anton
По сути просто функция, которая принимает интерфейс как аргумент
Anton
Наследование как раз про пробрасывание функций от дочерних объектов к базовым с возможностью переопределения
Alexander
наследованием нельзя отобразить реальный мир
Alexander
только если это правильно реализованное множественное наследование
Alexander
а его к сожалению делать не научились
Alexander
интерфейсы это близкий аналог
Alexander
что ООП решает, это уменьшение количества кода (иногда)
Alexander
опыт накопленный Java подсказывает что это тоже не верное утверждение
Alexander
т.к. сразу идут паттерн на паррерне с кучей бойлерплейта
Alexander
а если не следовать заветам, то все разваливается
a66ath
В Common Lisp еще множественное наследование есть
Мерль
интерфейс + дефолтные реализации некоторых (общих) функций = наследование, не?
Нет
В том же русте например есть трейты + генерация нужных методов, а наследования нет
Anton
Вообще наследование две разные вещи подразумевает под собой: во-первых, аггрегацию данных, то есть, базовая структура вкладывается в дочернюю; во-вторых, проброс вызовов функций
Alexander
наследование подразумевает под собой subtyping
Anton
А если этот subtyping разобрать на составляющие?
Anton
Вообще наследование две разные вещи подразумевает под собой: во-первых, аггрегацию данных, то есть, базовая структура вкладывается в дочернюю; во-вторых, проброс вызовов функций
Впрочем да, там всё сложнее, потому что код вложенной структуры может вызывать методы внешней
Anton
Мне кажется, его не любят как раз из-за того, что слишком много всего сразу там происходит
Anton
А бывает subtyping без виртуальных методов?
Alexander
не должно быть, в той или иной имплементации они будут
Alexander
и.к. нужно вызывать метод работающий с объектом тип которого не известен
Зигохистоморфный
интерфейсы это близкий аналог
Трейты в скале, интерфейсы в 8 жаве, с дефолтными методами
Alexander
м?