OOП закапывают в образовании.

Это какая-то особая ересь.
Если ты хочешь развиваться, а не стоять на месте тебе эта практика насилования мозга необходима. Меня причем в этом никто не убеждал и не рассказывал, сам понял. Хотя тащемто да, пхп-обезьянам достаточно абстратного знания того что такое матрица.
Про второе: у нас в универчике есть парочка очень достойных докторов по математике, при этом они кроме математики крайне всесторонне развиты, и при этом имеют глубокие знания по гуманитарным предметам.
Вот только почему-то я ни разу не видел хороших программистов-гуманитариев. Если честно, я редко встречаю гуманитариев которые хоть как-то дают себе отчет в том, что происходит когда они нажимают на кнопочки в компьютере.

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

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

а ооп реализуется и без мутабельных структур

А смысл? Суть ООП — запрятать внутрь объекта мутабельное состояние, и воздействовать на него методами. «Иммутабельная структура» — это точь в точь хаскельный модуль, ООП тут, как и везде, не нужно.

Этот парень тут часто выскакивает с воплями «ынтерпрайз во все поля», «сколько ты зарабатываешь деточка? я вот на джаве точно зарабатываю больше всех», «джава - клеймо интеллекта и большого пениса». Ты его вообще не слушай

Вы же уже вроде скидывали эту дебильную ссылочку

Раз двадцать, не меньше.

ой вей!
пс: как жава пересекается с его аватаркой?

из вводного CS курса

зачем ооп начинающим? для первых шагов я бы вообще basic использовал.

Суть ООП — запрятать внутрь объекта мутабельное состояние

Ты ничего не понимаешь в сути ООП

«Иммутабельная структура» — это точь в точь хаскельный модуль

ага java.lang.String - хаскельный модуль, милок тебе пора к поням

для первых шагов я бы вообще basic использовал.

это как учить сексу на руках

Ты ничего не понимаешь в сути ООП

Ну расскажите о своём видении.

ага java.lang.String - хаскельный модуль, милок тебе пора к поням

Да, это примерно то же, что и Data.String. Скрытие данных есть и там и тут. "Методы" есть и там и тут. Только у вас подлежащее стоит перед сказуемым.

аналогия кривовата.

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

basic вполне себе ЯП

Да но зачем? Нет таких тупых, которые не могли бы научиться програмировать сразу на чем то другом

s/стоит/будет стоять/

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

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

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

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

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

бэйсик, в виду своей элементарности, позволяет не рыспылять внимание на особенности языка

бэйсик - боль.

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

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

Вспомнил

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

Дейкстра

vba это боль

согласен

но я начал свой путь в программировании с qbasic 4.5, и у меня о нем довольно теплые воспоминания

известные личности тоже ошибаются, даже такие как Генри Форд.

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

whynotfp.shtml

http://www.youtube.com/watch?v=5TMojC0Nb6A, и да, он постоянно так делает :)

Суть ООП — запрятать внутрь объекта мутабельное состояние

А если у меня constness + наследование + виртуальные методы + трейты и миксины интерфейсов, то это уже не ООП?

Видать у тебя просто остались теплые вопоминания из дестства/юности

известные личности тоже ошибаются, даже такие как Генри Форд.

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

бэйсик, в виду своей элементарности, позволяет не рыспылять внимание на особенности языка

Тогда уж схема лучше, проще некуда.

Читаю сейчас книгу с интервью разработчиков известных ЯП и студентом автора бейсика был чел, который написал PL/1. Причем чувак написал компилятор примерно в 20-30 тыс. строк и он сразу заработал, без предварительных запусков и тестов. Чисто писанина кода, один запуск и успех.

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

Я никому не молюсь, во мне играет ненависть к языку.

Цитатку я привел как доказательство того, что не я один такой :)

Читаю сейчас книгу с интервью разработчиков известных ЯП и студентом автора бейсика был чел, который написал PL/1

Выкинь эту книгу. PL/I немного старше Бейсика и создан комитетом вполне взрослых людей. Лучше читай Вики.

Дейкстра говорил о бейсике, в котором имена переменных однобуквенные, а в if может стоять только переход на метку.

Я не так интерпретировал. Компиляторы PL/I в те времена писали многие университеты. Чел написал свою реализацию естественно позднее выхода оригинала в 64 году. Так что книгу продолжу читать :-D

Цитата фиговая. Вот цитата Джеки Чана:

Неудачник ищет оправдания, победитель - пути решения проблем

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

Дейкстра не осилил обучать других

Ахаха.

рукалицо

constness

По условию у нас все методы const.

наследование, миксины, виртуальные методы

Это необходимые, но не достаточные условия ООП.

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

mastermind of programming?

Да. Хорошая книга, имхо. Меняет отношение к другим языкам и строит иное мировозрение.

И это правильно.

ООП изначально представляло собой модель чёрных ящиков, обменивающихся сообщениями

В каком году и кто это придумал? Simula появилась в 1967-ом году и новая суть там была в subtyping — то что позже изучалось Abadi, Cardelli, Pierce и о чём можно почитать в TAPL. Работы Odersky и сама Scala, кстати, тоже продолжают эту теорию и практику, соответственно.

У настоящего объекта должно быть внутреннее мутабельное состояние, а константный объект — чем он отличается от простого типизированного значения?

Очевидно тем, что у простого значения простой и единственный тип x : A, а правило типизации для применения выглядит довольно просто как

G |- f : A -> B, x : A
----------------------
    G |- f x : B

тогда как у объекта x целый предпорядок типов, начиная от минимального и до Top, а правило типизации для применения строится с учётом отношения подтипирования:

G |- f : B -> C, x : A
---------------------- forall A <: B
    G |- f x : C

Есть ещё один способ смотреть на классическое ФП с ADT в стиле ML и классическое ООП с классами в стиле Simula:

[1] http://stackoverflow.com/a/2079678/1337941, http://stackoverflow.com/a/871375/1337941.

[2] http://en.wikipedia.org/wiki/Expression_Problem.

[3] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.107.4449 (в примерах совсем нет мутабельности).

То есть суть в том, что в простейшем ФП c ADT легко расширять набор операций и сложно сами данные, в ООП с классами — наоборот, можешь попробовать переписать пример из [3] на инкарнации ФП в виде Haskell и ООП в виде C++. На Haskell простым решением может быть использование parametricity (ad-hoc и обычный параметрический):

{-# LANGUAGE TypeOperators #-}

class Exp t where
  eval :: t -> Int

newtype Nm = Nm { value :: Int }

instance Exp Nm where
  eval = value

data a :+ b = a :+ b

instance (Exp a, Exp b) => Exp (a :+ b) where
  eval (x :+ y) = eval x + eval y

data a :* b = a :* b

instance (Exp a, Exp b) => Exp (a :* b) where
  eval (x :* y) = eval x * eval y

instance Show Nm where
  show = show . value

instance (Show a, Show b) => Show (a :+ b) where
  show (x :+ y) = "(" ++ show x ++ " + " ++ show y ++ ")"

instance (Show a, Show b) => Show (a :* b) where
  show (x :* y) = "(" ++ show x ++ " * " ++ show y ++ ")"

test :: IO ()
test = do
  let e = (Nm 2 :+ Nm 3) :* (Nm 4 :+ Nm 5)
  putStrLn $ show e ++ " = " ++ show (eval e)

но у него очевидный недостаток (он же будет и у решения в плюсовых шаблонах) — структуры термов отражаются в их типах, то есть не получится строить их динамически, чтобы это обойти придётся воспользоваться относительно новыми расширениями GHC — довольно неудобно по сравнению со скалой.

модель чёрных ящиков, обменивающихся сообщениями

Это конкурентность и асинхронность. А методы в ООП вполне синхронные функции. Суть в том чтобы один ящик со своими функциями (методы) помещать (агрегировать, наследовать) в другой ящик, так чтобы после этого второй ящик мог выполнять все функции первого. Ну и в возможности складывать множество ящиков в один (множественное наследование), в абстрактных ящиках задающих интерфейсы как наборы must have функций для любого конкретного ящика в который такой абстрактный ящик положат (traits), в возможности комбинировать абстрактные ящики в новые абстрактные ящики используя их функции (mixins), потом уже в возможности иметь внутри конкретного ящика какое-то состояние (identity), причём функции такого ящика с состоянием могут быть потоко-безопасными, непонятно в чём проблема (STM в Haskell предоставляет полностью (то есть без дедлоков) потоко-безопасные расшариваемые контейнеры).

ООП изначально представляло собой модель чёрных ящиков, обменивающихся сообщениями

В каком году и кто это придумал?

В конце 60-х Кей. Это то «Ъ-ООП», которое он хотел реализовать в Смоллтоке. К этому примыкает и акторная модель Хьюитта (1973).

Туда ему и дорога.

http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented

This has caused endless terminological difficulties especially when considering that the the other major sources of OO thinking--capability architectures and the SIMULA 67 research--were not in the least inspired by ActorsModel thinking.

как-то так, да.

причём функции такого ящика с состоянием могут быть потоко-безопасными, непонятно в чём проблема

Проблема в том, что в распространённых императивных языках (С++, afaik Java) это не так, и, кроме как с помощью внешних инструментов в рантайме, отследить гонки никак нельзя. Если добавить скрытие переменных, всё становится только хуже.

STM тут не при чём, его вроде можно в любой парадигме реализовать.

Я про примитивы синхронизации внутри класса и «красивые» методы наружу, типа как в TBB.

А гонки и с STM не отследить — он тут ни при чём, просто пример, а то «состояние сакс», но всё равно любая неигрушечная функциональщина тащит себе какие-то реализации состояния.

но всё равно любая неигрушечная функциональщина тащит себе какие-то реализации состояния.

Но в функциональщине stateful алгоритм как правило полностью отделён от синхронизации. Алгоритм пишут простые смертные, функцию типа m a -> IO a — люди с PhD.