Зачем-то в очередной раз послушал Одерского. Не сказал ничего нового. Объявил немутабельный указатель на список и считает сам список немутабельным (в своем первом примере на Скале). Странный человек.

Ох щи. Вот это размазал так размазал. Ты — мой герой сегодня!

Отчётливо слышу, как потихоньку начинает потрескивать пердак у онанимного ООП-хейтера. Зуб даю, сейчас БОМБАНЕТ!

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

Сколько ж ерунды-то ты понаписал

А не Степанов, не?

кстати, с Кнутом дружбу водит. Тоже один из последних специалистов в области программирования

... безвозвратно застрявший в 70-х. Почитай интервью с ним из «Кодеры за работой».

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

Это не от хорошей жизни - нормальных высокоуровневых языков пересчитать хватит пальцев одной руки. И те с приставкой недо-.

инкапсуляцию, полиморфизм и наследование (что и составляет суть ООП)

Что за бред, срочно в сад. Ну или покажите, что, скажем, в хацкеле нема (поддержки со стороны языка), или может это ООП-язык?)

Ну, в ООП под инкапсуляцией понимается прятанье грязных функций под ковер, под полиморфизмом - убогий субтайпинг (со своими неизменными спутниками игрой в ко-/контравариантность и сломанным выводом типов). Такого в хаскеле и правда не найти.

вот, к слову, для того, чтобы понять суть ООП, было бы очень полезно пройти основы так нелюбимой адептами оного ООП теории категорий: научиться думать в терминах взаимодействий интерфейсов и контрактов (морфизмов и универсальных свойств). инкапсуляция - базовый принцип рассуждений в терминах категорий, code reuse - рассмотрение объектов с точностью до изоморфизма (игнорируя внутреннее устройство)

Смотреть надо в сторону паттернов проектирования

наследование(избегание копирования кода методов) + полиморфизм(способность обращаться к субклассам какбудто как с родительским классом) + задание 'интерфейсов'(набор методов, которые можно применить к объекту).

вот, к слову, для того, чтобы понять суть ООП, было бы очень полезно пройти основы так нелюбимой адептами оного ООП теории категорий: научиться думать в терминах взаимодействий интерфейсов и контрактов (морфизмов и универсальных свойств). инкапсуляция - базовый принцип рассуждений в терминах категорий, code reuse - рассмотрение объектов с точностью до изоморфизма (игнорируя внутреннее устройство)

Ещё можно использовать стрелки. Единственный вариант, который я пока вижу. Нужно просто-типизированное LC это будет одна конструкция из стрелок/2-стрелок, нужно LC с зависимыми типами - другая, с субструктурными (линейными, в частности) - ещё третья. Т.е. фиксированное подмножество теории категорий само по себе довольно бедная метатеория, просто язык, в котором можно выразить все эти вещи. Мартин-Лёф предлагал формулировать разные теории типов в рамках метатеории LF, вот также это можно делать в рамках метатеории ТК.

Ну, например, берём декартово-замкнутую категорию Set, она же классический топос, т.е. категория всех малых множеств и тотальных функций, в agda она так и называется - «Set». Берём категорию всех малых категорий и функторов Cat (Set1 в agda) и утверждаем:

• Любой тип который может использоваться (ADTs, GADTs, Inductive families) это объект Set (объект топоса, в общем случае), т.е., как следствие, множество - множество всех термов данного типа.
• Любой параметрически-полиморфный тип это эндофунктор на Set, т.е. специального вида стрелка в Cat. (Непараметрический тип, который объект в Set, это вырожденный случай функтора из терминальной категории (как-то так)).
• Любой конструктор типа данных который может быть это стрелка в Set (стрелка в топосе, вообще).
• Любая функция которая может быть это тоже стрелка в Set, но отдельным классом (чтобы не путать стрелки-конструкторы и стрелки-функции). Как следствие, «функция» - тотальная функция между множествами.
• Любая композиция стрелок с учётом декартовых произведений и экспоненциалов это любой правильно составленный терм в данной системе (тут типизация из коробки).
• Любое определение конкретной редукции это 2-стрелка (струнная диаграмма).
• Любой конкретный ход редукций (вычислений) это композиции 2-стрелок (струнных диаграмм). + Правила построения редукций из коробки.

Например:

-- Тут рисуем коммутативную диаграмму:
ℕ : Set
0 : 1 → ℕ
s : ℕ → ℕ

-- Продолжаем коммутативную диаграмму:
+ : ℕ → (ℕ → ℕ)

-- Рисуем две струнных диаграммы, которые можно сочетать:
e₁(+) : + ∘ a ∘ 0 ⇒ a
e₂(+) : + ∘ a ∘ (s ∘ b) ⇒ s ∘ (+ ∘ a ∘ b)

и это просто ТК (можно представить формальный синтаксис такого языка), безотносительно какого-либо ЯП, но понятно из каких ADT и функции это получилось.

Тут ещё интересно, что можно легко добавлять конструкторы и правила редукций (как если бы в хаскеле можно было дописывать ADT и pattern matching cases по разным модулям).

Сами по себе 2-стрелки это непосредственно струнные диаграммы, т.е., рисуя коммутативные диаграммы, получим схемы типов, рисуя струнные - flow chart.

• Любая конкретная оптимизация это 3-стрелка. Правила построения оптимизаций тоже из коробки.

Например, если есть линейная рекурсия:

f x = z
f y = g (f (h y))

(f не появляется в g и h), т.е.:

-- любая стрелка вида:
f : x + y → r

-- с 2-стрелками вида:
e₁(f) : f ∘ x ⇒ z
e₂(f) : f ∘ y ⇒ g ∘ f ∘ h ∘ y

то она убирается такой 3-стрелкой:

-- Рисуем диаграмму между струнными:
o(f, f′) : e(f) ≡> e(f′ ∘ z)

-- TCO форма:
e₁(f′) : f′ ∘ a ∘ x ⇒ a
e₂(f′) : f′ ∘ a ∘ y ⇒ f′ ∘ (g ∘ a) ∘ (h ∘ y)

и остаётся только TCO.

Процесс унификации по 3-стрелкам это процесс оптимизаций, а процесс унификации по 2-стрелкам - интерпретации или компиляции (тогда нужен target). Как компилировать в target - конструкторы, например, достаточно точно отражаются в си-подобные структуры и объединения в памяти, можно даже в случае (s : ℕ → ℕ) или (_:_ : a → [a] → [a]) или вообще (con : [no `t' appears] → t → t) пытаться делать не связные списки, а аллоцируемые/реаллоцируемые массивы. Про компиляцию редукций ничего не скажу - только, наверно, тут, в первую очередь, нужен критерий линейности представляемого терма и/или его линеаризация.

мне нравится это рассуждение; практически это похоже на использование SKI в оптимизаторе Miranda и на CAM в CAML, с той лишь разницей что ты явно используешь n-категориальный взгляд. но я не вижу, как этот низкоуровневый (в смысле сущностей предметной области) язык может быть эффективно обёрнут до прагматичной семантики

в конце концов, GHC Haskell с rewrite rules уже есть

ща вместо и/или для лучшего понимания ООП вроде как акторов понимания достаточно.

теория категорий сверхабстрактна

в отличии от акторов

It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs.

Волна некомпетентности.

ты вот этим одним показал своё школоло

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

Efficient Programming with Components

http://www.youtube.com/playlist?list=PLHxtyCq_WDLXryyw91lahwdtpZsmo4BGD

чиста для эрудиции

Это как все кричат про ПХП, что он плохой язык, потому, что... школоло на нем плохо пишет.

ПХП плохой, потому что ЕГО плохо пишет школоло

http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

Хотя мне не хватает в с++ foreach.

google:// qt foreach, boost foreach, range-based for

r0ck3r

понять суть ООП

Изначально объектно-ориентированные языки программирования создавались с целью выполнения компьютерного моделирования.

r0ck3r

подскажите что почитать/посмотреть, чтобы вникнуть в предметную область.

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

Погугли, на любой(абсолютно) ЯП можно написать гневную статью, где будет 100% правды.

Я говорил про стандартную С++. Хотя foreach в 11 с++ уже есть по нативу, но что то по умолчанию он не работает. Я не стал ковыряться и выяснять причину его не работу, поэтому испольщую кутюшный вариант или не использую.

Изучи Java, там хорошо реализовано ООП, все принципы есть и наглядно показаны.

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

Относительно хорошо ООП реализовано в Eiffel. Синтаксис только немного многословен(хотя не настолько, как в Java).

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

Вообще-то, ИМХО, 90% случаев применения множественного наследования - это случаи, когда вполне бы сгодились и интерфейсы, которые представляют собой его полезный частный случай. Интерфейсы, на мой взгляд, более строги и безопасны. А с оставшимися 10% надо быть очень осторожным. Та же самая проблема ромба в C++, например, решается исключительно руками.

// Да, я люблю некропостинг.