мне лень продолжать спор и объяснять что я все правильно сказал

Хотя физика это круто

Потому ты жадные вычисления и императивность путаешь :)

я думаю, он знает вещи интереснее

Ещё не сдал матлог (практику) @ 4 курс @ Ещё не отчислили

Ммм, я у тебя хаскель буду читать в этом году

ааааа :D

Я знаю)

Я на нём подовину матлога сдал

У меня есть знакомый, который на хускеле ММФ сдавал

С визуализациями по ГОСТу

Так що оно по разному бывает

Тут люди с ВМ хотят слушать хаскель с КТ

а волльные слушатели в понедельник не запрещены?

йеп, те люди на связи

Нет конечно Обычно только вольные слушатели долго не ходят, забивают

спасибо

ноис

мне лень продолжать спор и объяснять что я все правильно сказал

Я завтра напишу тебе лямбда терм, который в случае жадных вычислений работает как точка с запятой. Типа f a b будет сначала вычислять а, а потом b.

до завтра 15 минут, можно и сегодня написать

я думаю, он знает вещи интереснее

Конечно знает, он крут в плане написания кода на хаскеле, я так не умею :( Но типа специалист в одном не значит специалист во всём

до завтра 15 минут, можно и сегодня написать

Я спать пойду. Напомни ток

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

арность не совпадает

ну вроде в случае жадных это должно быть аккуратно записанное \a b -> b ?

@elemir90 ^

или не, таки совпадает, хм. Интересный пример

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

42

Конечно знает, он крут в плане написания кода на хаскеле, я так не умею :( Но типа специалист в одном не значит специалист во всём

у меня вообще с теорией плохо, поэтому я люблю всякие курсы смотреть

ты шустрый

долго считал?

(я случайно ужратый, простите)

прикол в том, что ghci и hugs посчитают эту штуку по-разному

ну вроде в случае жадных это должно быть аккуратно записанное \a b -> b ?

(lambda x. (lambda y.y)), ага. Вот и вся твоя императивность :)

ладно я согласен, что моё определение страдает

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

fix (const 42)

(лень двести сообщений читать, но я уверен, что не было) замыкания — объекты для бедных объекты — замыкания для бедных

это к вопросу о противопоставлении ФП и ООП

"An object is data with functions. A closure is a function with data" — John D. Cook

кто умеет хорошо читать stg?

http://juick.com/qnikst/2882116 <- вот тет есть непонятная штука, может у кого есть идеи?

всем спасибо, ответ нашёл

какой профит от комоноида?

такой же как от комонады7

если не считать линейных типов

Monoid -> List -> Free Monad Comonoid -> Stream -> Cofree Comonad такой путь (спискок - свободный моноид, стрим - свободный комоноид)?

(лень двести сообщений читать, но я уверен, что не было) замыкания — объекты для бедных объекты — замыкания для бедных

Было

Объекты - это замыкания для бедных. Поэтому ООП есть и в Схеме и даже у меня в языке.

а правда, что в реальном мире "есть объекты, и у них есть состояния, а ваш ФП - это абстрактная чушь"?

Правда, только это не всегда удобная для работы модель

а правда, что в реальном мире "есть объекты, и у них есть состояния, а ваш ФП - это абстрактная чушь"?

В реальном софте состояние как-то больше в базе хранится и даже ооп-шники в основном юзают Anemic Domain модели

ООП не кеевсеое оно об иерархиях

и вот то что в реальном мире существуют однозначные иерархии объектов выглядит сомнительным

а объекты как что-то инкаплусирующее состояние моделируются легко

и вот то что в реальном мире существуют однозначные иерархии объектов выглядит сомнительным

ну а как же любимое самолёт -> пассажирский самолёт -> boeing 737

и все стейт машины и т.п. прекрасно выглядят

об однозначных никто не говорит, есть множественное наследование

где?

из ФЯ есть в плюсах

где они настолько криво, насколько это возможно

во всех более современных и адекватных языках движутся к интерфейсам и отсутствию иерархий

ну примерно то, что тут было в 80х годах

:)

а в чём такой профит от интерфейсов?

каждый раз же нужно заново реализовывать функции?

даже те, которыми могут быть одинаковыми для разных типов

Есть языки с поддержкой дефолтной имплементации методов в интерфейсах

Есть языки с поддержкой дефолтной имплементации методов в интерфейсах

ну это уже похоже на классическое наследование

в ФП тоже есть интерфейсы, и помощнее ООПшных

Есть языки с поддержкой дефолтной имплементации методов в интерфейсах

интерфейс + дефолтные реализации некоторых (общих) функций = наследование, не?

ну это уже похоже на классическое наследование

Наверное, это что-то типа экстеншенов в шарпе

Там это отдельно от наследования

Там это отдельно от наследования

а по сути чем отличается?

как реализовано, не очень важно

что такого дают экстеншены, что нельзя сделать наследованием

Там статический диспэтч

Короче они не виртуальные

По сути просто функция, которая принимает интерфейс как аргумент

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

интерфейс + дефолтные реализации некоторых (общих) функций = наследование, не?

нет

наследованием нельзя отобразить реальный мир

только если это правильно реализованное множественное наследование

а его к сожалению делать не научились

интерфейсы это близкий аналог

что ООП решает, это уменьшение количества кода (иногда)

опыт накопленный Java подсказывает что это тоже не верное утверждение

т.к. сразу идут паттерн на паррерне с кучей бойлерплейта

а если не следовать заветам, то все разваливается

В Common Lisp еще множественное наследование есть

интерфейс + дефолтные реализации некоторых (общих) функций = наследование, не?

Нет В том же русте например есть трейты + генерация нужных методов, а наследования нет

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

наследование подразумевает под собой subtyping

А если этот subtyping разобрать на составляющие?

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

Впрочем да, там всё сложнее, потому что код вложенной структуры может вызывать методы внешней

Мне кажется, его не любят как раз из-за того, что слишком много всего сразу там происходит

А бывает subtyping без виртуальных методов?

не должно быть, в той или иной имплементации они будут

и.к. нужно вызывать метод работающий с объектом тип которого не известен