в принципе интересно послушать
но оставляет впечатление человека с высоким чсв

Кто это?

>>1084449 (OP)
> Bitcoin Is Not a Pyramid.

А он смелый!

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

>>1084482
>>1084527
Да он же тупо зарабатывает, впаривая свою хуйню. Я вот это смотрел и мне за него было пиздец неловко https://www.youtube.com/watch?v=RiXXCYMjqZE

Помню его, показывал какой-то дико уебищный язык.

>>1084449 (OP)
Внимательно рассмотри человека на прилагающейся фотографии. Можешь ли ты представить себе, как этот мужчина плачет и набирает дрожащими пальцами телефон какой-то невнятной бляди, чтобы рассказать о своих чувствах к ней? Можешь представить, что он пропускает в очереди жирную мамашу с выблядком на руках? А то, что он работает пол-года, раздавая листовки, чтобы купить себе iphone? Ты видишь в нем человека, который стесняется сказать родителям, что на свой двадцать четвертый день рождения он хочет выпить с друзьями?
Теперь посмотри на него еще раз. Видишь ли ты на нем стильные брендовые вещи? Может он покрыт вздувшимися мускулами и толстыми венами? Он обладает внешностью киноактера или мужчины-модели?
Позади него стоит дорогой автомобиль?
Посмотри снова на этого мужчину и спроси самого себя, что с ним не так?
Почему в его взгляде железо, в его осанке сталь, а вместо кожи свинец?

Почему-то мне кажется, что у него еврейские корни.

>>1084579
Рыбак рыбака видит издалека.

>>1084576
может потому, что он Венсан Кассель?

>>1084449 (OP)
Вроде грамотный человек, но говорит безосновательные вещи. Откуда он берет свои идеи неясно, но говорит что правильно только так. Я противник ООП как такового, потому что оно не имеет математического базиса. Об ООП всегда будут спорить, потому что это пустышка. О ФП никто не спорит, потому что оно имеет математическую основу. Все концепции ФП известны, спорить там не о чем. Бугаенко занимается антинаучной ерундой. ООП - фарс, никто не знает что это такое и какие у него правила, поэтому о нем всегда будут спорить. На этих спорах Бугаенко пытается пиариться. Его идеи не стоят выеденного яйца. Они ни на что не опираются. Пустота пустотой.

>>1085412
>Откуда он берет свои идеи неясно
По крайне мере, один источник его взглядов известен - это David West со своей книгой "Object Thinking". Есть ещё интервью, где West излагает Бугаенко свои взгляды на ООП: https://jug.ru/2016/09/bugayenko-west/

>>1085459
Ну знаю и что. А кто такой этот Вест? Императивное программирование основывается на работах Тьюринга, функциональное на работах Чёрча. На чем основывается ООП?

>>1085464
>На чем основывается ООП?
Понятия не имею. Это у пропагандистов ООП надо спросить.

Как же меня заебало это ваше айти и уебищные тупые люди в нем.
мимо алгебраист

>>1085465
В том то и дело. Чтобы рассуждать о правильности/неправильности как это делает Бугаенко, нужно на чем то основываться. И основа должна быть математически формализована, это же программирование, а не вязание крючком. Бугаенко просто пиарится. Не думаю что он настолько глуп, чтобы не понимать что его слова безосновательны. Он очень грамотный и рассудительный, я смотрел его доклады. Если бы он хотел рассказывать правильные вещи, он бы изучал теорию CS.

>>1085464
>На чем основывается ООП?
На кромешной поверхностности и ограниченности адептов. ООП применяется для утилизации обширных масс быдла в it. Это лженаука в чистом виде. Его идеологи и последователи фетишизируют понятие (объекта), которое не понимают даже приблизительно. Субъект-объектные оппозиции преодолены философией лет 200 как, только вот инженегры не в курсе.

>>1085473
>Субъект-объектные оппозиции преодолены философией лет 200 как, только вот инженегры не в курсе.
Ничего не понял. Если есть основания ООП, просвети.

Мартыханы просто. Чтобы херачить код как обезьяна с ГЫ, ОБЪЕКТЫ, много ума не надо. А чтобы доказывать нетривиальные теоремы, нужно быть профессором.

>>1085479
>Если есть основания ООП, просвети.
Я как раз про то, что разумных оснований нет. Всё, что сейчас подаётся в терминах "объекта", "объективности" и т.д. - заведомо туфта и скомпрометировано.

>>1085485
Где об этом почитать?

>>1085493
Про что?

> 2017
> обсуждать ООП

>>1085494
Про преодоление субъект-объектных оппозиций и скомпрометированности оных.

Стирка - это отображение кортежей грязных носков и порошка во множество чистых носков.

Покажите мне объект стирки.

>>1085502
В той или иной мере вся посткартезианская философия.

>>1085509
Твоя мамка получает сообщение постирать носки, порошок, прибор для стирки. И стирает.

Чтобы херачить код как обезьяна с ГЫ, ФУНКЦИИ, много ума не надо. А чтобы проектировать приложения в объектно-ориентированной парадигме, нужно быть профессором.

>>1085663
nponeccopом

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

Театр одного шизосемена

>>1085691
Спойлер:

этот шизосемен - ты

>>1085702
Планирую вкатиться в конструктивную математику, какие подводные?

>>1085702
Смешно.

>>1085711
Зачем?

>>1085731
Хочу определить натуральные числа.

>>1085459
>В каждом языке своя модель, в функциональных она основана на математике и матанализе. Легко ли её использовать? Многие ли ваши коллеги хорошо знают матанализ?
>матанализ
Ебаный даун.

>>1085763
Гринтекст - это цитата из статьи по ссылке? Пиздец, не верю, не бывает таких дебилов.

>>1085759
Может тогда теория чисел? Вообще в математике все связано. Одно опирается на другое.

>>1085763
>>1085810
Похоже Вест не шарит совсем.

>>1085763
>матанализ
https://www.youtube.com/watch?v=BxdZfGx9UwU

>>1085896
Хуй знает когда последний раз пересматривал. С годами становится только лучше. Надеюсь, соседей на разбудил.

>>1084519

>>1099471
Харкачую сего господина.

/thread

http://www.yegor256.com/2017/11/14/static-factory-methods.html

>>1099471
>он несет очевидно бредовою хуйню.
обоснуй

>>1111566
Та блять, недавно послушал лекцию. Блять, какая же это хуета. Какая же сука нахуй хуета...

https://youtu.be/lfdAwl3-X_c

>>1085412
> Я противник ООП как такового, потому что оно не имеет математического базиса.
http://lucacardelli.name/Papers/PrimObjImpSIPL.A4.pdf

DAO это позор!
Если вы по какому-то недоразумению используете DAO, немедленно переписывайте под объекты разговаривающие на SQL!
У меня все.
http://www.yegor256.com/2017/12/05/data-access-object.html

ООП — это рак. И его нужно просто выкинуть на помойку. А не разбираться почему оно такое говно.

>>1085677
В голос.

>>1111621
Просто ты неосилятор.
Иди пиши императивные процедуры за еду, макака.

>>1085685
>морфизмах абелевых многообразий, координатных кольцах и вложениях в проективное пространство

у заказчика Пажита цифры не сходятся за 12 декабря 1975 года, и система наебнулась 20 декабря 2017, давай чисти абелево многообразие

>>1111629
Бугаенко, залогинься.

>>1085412
>потому что оно не имеет математического базиса
Пустышка - это про содержимое твоего котелка.
За Луку и двор, стреляю в упор ς-calculus

>>1085493
Ну, допустим http://staffwww.dcs.shef.ac.uk/people/A.Simons/classify/
Только ты паскуда тварь маловерятно что прочитаешь, но хотя бы кукарекать не будешь, в интернетах, про то что оснований нет.

>>1084449 (OP)
Поехавший шизик.

Барух и его друг Женя намного лучше.

>>1111606
>Ctrl-F
>Composition
>Phrase not found

Yasno.

>>1085493
Старые выпуски «Inside Macintosh» годов так 1983-1988.
Затем электронное письмо Гейтса, где он пишет «мы должны изобрести что-то, чтобы IBM не могла запускать бинарные файлы под Win32».
А затем... почитать книги по настоящему программированию, без религиозного фанатизма.

>>1112001
— в смысле, собранные под Win32.

>>1111919
>пук

>>1112001
какие книги? есть список?
спасибо

>>1112181
Два тома поехавшей графомании? неплохо!

>>1112212
>не читал, но осуждаю!

>>1112041
>аноньчик решил выибнуться ссылкой на "формализацию" оопе
>пейпер, который он никогда не читал
>из гуманитарной дрисни от луки не выводится даже определение композиции
>я тибя затролел

--> /b/

>>1112244
причет тут композиция? ты еще пожалуйся что про синглтоны не написали

Поздравляю, вы в ООПе.

>>1112246
Маня, нахуя нужна система, в которой нельзя определить такую базовую операцию, как композиция её термов?

>>1112244
Я не понял, что ты хотел сказать этим зеленым текстом, да мне и похуй.
Как будто бы ты обосрался и вынужденно маневрируешь. Но ты же, очевидно, обосрался, обозначим буквами:

O - обосрался ты
М - маневрируешь

O => M, O
------------
М

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

>>1112268
Читай вводную и итоги, дебил.

>>1112272
>этот делирий питудия
Иди проспись лучше, б/ыдлан.

> да мне и похуй
Ну да, так похуй, что не забыл об этом написать.

>>1112274
давай определение композиции в оопе, даунидзе (которого в пейпере нет)
если дать не можешь - просто иди нахуй

>>1112276
Ты подебил, у меня нет времени отвечать на твою бессодержательную зелень.

>>1112279
>мам сматри я тралю

>>1112277
ты полудурок, программирование - это инженерная специальность и к ментальной гимнасткие она не имеет никакого отношения. программирование намного ближе к строительству зданий, чем к математике

>>1112277
Дебил, пейпер отправная точка, ответ на вопрос о формализации. Хотел бы разобраться в вопросе, прочитал бы несколько страниц.
> We omit how to encode basic data types, control structures, and classes, which can
be treated much as in [4].

>>1112282
Ну и отлично, нахуя тогда эти линки на пейперы, где Лука Карделли на личном примере демострирует что применение к оопе каких-либо формальных методов - это как натягивание гондона на глобус?

>>1112285
>где Лука Карделли на личном примере демострирует что
ТЫ СКОЗАЛ?
Пока только что ты демонстрируешь тупость и убогость ИТТ.

>>1112284
>ответ на вопрос о формализации.
Я про неё не спрашивал (это был другой анон), я лишь указал, что этой системе грош цена, если в ней даже определение композиции дать невозможно.

>>1112287
>там всё у него заебись, а базовые операции комбинирования термов определять нинужно, о них вы можете узнать в книге виликих инженеров Gangbang of forth всего за 29.99$.
Yasno.

>>1112288
Плиз, не надо так. Почитай статью вместо Ctrl+F, поймешь, что возможно и что нет, а так же где можно прочитать про задание композиции.

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

>>1112295
Определение ООП дай (необходимые и достаточные условия). Больше, пока, ничего не надо.

>>1112288
https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D0%BF%D0%BE%D0%B7%D0%B8%D1%86%D0%B8%D1%8F
я удовлетворил твое любопытство?

>>1112297
бля, в том то и проблема - ооп это тупо набор методик на самом то деле, вопрос только в том поддерживаеются ли его три мантры в самом языке и как у конкретного языка, как он спроектирован - по уму через соотв матаппарат либо на коленке
внезапно ооп в написании кода это как какой-нибудь аджайл для обеспечения процесса разработки

>>1112285
а я ебу? эти статьи никакого отношения к программированию не имеют и не научают тебя программированию.
языки программирования проектируются исходя из практических соображений

>>1112303
>языки программирования проектируются исходя из практических соображений
угу, у нас как раз есть 2 языка сделанных на коленке именно из практичных соображений - php и яваскрипт

>>1112302
>через соотв матаппарат

может тебе еще таск в Jira теоремами и формулами оформлять

>>1112303
Ну охуеть теперь, "эти статьи" в основании по кр мере одного ЯП https://en.wikipedia.org/wiki/Obliq, который в своё время имел практическое применение ну и сдох, как сотни других.

>>1112302
>ооп это тупо набор методик на самом то деле

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

>>1112298
Ты даун штоле? Формальное определение давай.
Например:
(.) :: (b -> c) -> (a -> b) -> a -> c

Давай то же самое только для объектов в оопе.

>>1112320
объекты, классы, полиморфизм - это понятия, в первую очередь описываемые системой типов (если они конкретной системой типов вообще поддерживаются)
к вычислительным моделям эти понятия тоже относятся, взаимодействуют с ними, но это уже вторично
считать их синтаксическим сахаром - неверно, потому что как минимум они находятся на уровне семантики языка
например, мы можем говорить что анонимные функции в с++ - это синтаксический сахар, чуть-чуть для удобства изменяющие этот самый control-flow как ты выразился
в то время нельзя ни в коем случае говорить о лямбдах в лиспах как о синтаксическом сахаре, это семантический конструкт языка

>>1112346
Где тут формальное определение, ваннаби?

>>1112353

Сахарок в данном случае - не альтернативный способ записи, но присыпка, которой всей пользуются, но вот что за ней - почему-то не знают.

---
Ну и синтаксический сахар допустим на уровне семантики языка - однако, это отдельное ментально-гимнастическое упражнение разговор о метапрограммировании и всяких препроцессорах на примере js, а не о том, что такое ооп.

>>1112373
Точно такое же формальное, как обычное определение композиции функций:
Пусть F : X → Y и G : F(X) → Z - две функции (F(X) ⊂ Y). Тогда их композицией называется функция G ∘ F : X → Z определённая равенством:
(G ∘ F)(x) = G(F(x)), x ∈ X .

Только расширенное типами. Или же композиции морфизмов.

Давай теперь тащи определение композиции объектов для оопе.
inb4: GoF

>>1112437

>>1112441
Что ты мне за гуманитарную хуйню даёшь, UML-и какие-то, блять, хуемели. Жопу ими подотри. Это формальное определение? Строгость на уровне философского трактата нахуй. Даже ниже, что-то уровня традиций и практик типа "чтобы копьё лучше било мамонта, нужно чтоб его обоссала девственница в полнолуние". И это всё что могли предложить ОО-сектанты, гуманитарный буллщит от дяди Боба под видом некой научности.

Ещё раз, как определена операция композиции (которой в ООП искаробки нет, а как и остальные комбинаторы объектов она осуществляется процедурным быдлокодом; кто бы сомневался, что ОО- это надстройка над процедурщиной и по сути ничем не отличается)? Что является результатом композиции в ООП? Даю подсказку: null.

>>1112437
Притащи формальное определение мамкиного борща

>>1112465
В чём здесь заключается композиция?
Вот у меня есть два объекта, задача определить операцию композиции для них. Типа
a.compostion(b) -> c, чтобы можно было автоматически вывести с из a и b.

>>1112466
ты бы сначала написал что в твоём манямирке является композицией

>>1112465
не понимаю, как какая-то криптическая запись чего-то может быть формальным определением. и зачем этому идиоту понадобилась криптическая запись КОМПОЗИЦИИ. он эзотерик штоле

>>1112468
>>1112474
В сигма исчислении нет операции композиции как ты её видишь, её и в природе то нет, по крайней мере не существовало, пока какой-то шизик не использовал криптическую запись:
> a.compostion(b) -> c
для своих маняпредставлений в голове. Если интересна операционная семантика переопределяемых методов у наследника - читай статью/книгу.

Очередной ООП vs ФП тред, миллион раз уже пережеваный. Вот что вам нудно знать об ООП:

ООП - НЕ парадигма программирования. Парадигм программирования всего три. Подробнее здесь: http://wiki.c2.com/?ThereAreExactlyThreeParadigms.

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

ООП - определенный способ представления программы в голове, а следовательно и способ её структурирования в тексте. Именно его имел в виду Кей, в нем, как ни странно, суть Actor Model, а значит Эрланга и Акки, и во многом именно о нем пишет Егор Бугаенко. Можно сказать что такой подход это гуманитарщина, и быть при этом правым, но не нужно забывать что программы в первую очередь пишутся для людей, а значит способ их изложения и понимания имеет значение. Насколько легко представлять программу как множество объектов, взаимодействующих друг с другом - другой вопрос. Возможно другие способы эффективнее, возможно это вообще индивидуально.

По моему опыту ООП это способ структурирования именно императивных программ. Дело в том что я видел ОО-код на С, видел процедурный код на питоне с джавой, но никогда не видел ОО-ориентрованых програм на функциональных языках. Наверное это из-за того что объекты почти всегда инкапсулируют какое-то мутабельное состояние, иначе они превращаются просто в (параметризируемые) модули, а состояние в ФЯ обычно скрывается и обрабатывается не так, как и императивных.

>>1112711

Чёт в голос с Cunningham's Law.

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

>>1112711
>Парадигм программирования всего три
Как минимум есть еще синхрoнные языки.

>>1111606
Препятствие не в этом. Если бы вы знали сколько, всякой чепухи было формализовано. Проблема в том, что ООП - полная кромешная бессмысленность. Окончательный бред. Шизофазия.

>>1113218
>He likes to say that women are unfit to work as software developers.
ну хоть в чем-то я с ним согласен

>>1113172
>дурачек детектед

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

>>1113251

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

>>1113251
Я тебя не понял. Ты о чём?

А зачем вам нужна какая-то математическая основа под ООП? Я вот сейчас в универе прохожу теорию вычислений и рекурсии, где вот мне как раз про разную такую хуиту >>1112437 впаривают и я реально не понимаю: а зачем мне это всё надо? Мне не знание этой математической поеботы никогда не мешало работать. Ну вот выучил я формулу, запоминил, а дальше-то что мне делать с этими знаниями?

>>1113266
>копипасчу куски кода
Это не ООП, если чё.

>>1113308
ну, епт, мост не построить без сопромата и еще кучу спец математики..
с проектированием яп тоже самое..

>>1113318
Как мне противно стало от твоих реплик, сразу повеяло посраллем, линалом, квантовой гиперполяцией, пингвиномагией, обсуждением очередного фреймворка, хихиканием очкастых прыщавых ботаничек-девственниц, анимефестами, косплеем, коллекцией фигурок героев анимэ, просмотром нового сезона Поней под пледиком, жутким высером компилятора на триста страниц, долгим унылым чтением http://rsdn.org/forum/philosophy/1096982.all

>>1113324
Тебе сколько лет, дядя? Реагируешь как школота, а ссылки даешь как-будто под сорокет уже.

>>1113329
Ну ты еще с wasm.ru притащи что-нибудь. Рсдн протух к 2008-у наверное, очевидно, там нечего ловить молодым.

>>1113308
1) Не мешало работать кем? На кого ты учишься? Программистам достаточно узнать базовые тезисы и результаты, чтобы потом не пытаться решать задачи, эквивалентные проблеме останова на работе.
Если ты учишься на прикладной или чистой математике, то в чем вообще вопрос? На что поступил, тому и учат, пиздуй теоремы доказывать.
2) Не думаю что кому-то мешало работать незнание ООП, особенно до его популяризации в том или ином виде.
3) Математическая основа нужна для того чтобы можно было формально рассуждать о программах. Программирование в текущем виде скорее похоже на приготовление еды, а не на инженерную деятельность. Я говорю именно о кодировании, а не об архитектуре - разделении системы на библиотеки, сервисы и протоколы, а также о развернтывании и мониторинге всех этих подсистем. В этой сфере деятельности обычно намного меньше вкусовщины и больше объективных критерив плохого и хорошего дизайна.
4) Математическая основа нужна для того чтобы не было вот такой хуйни: http://io.livecode.ch/learn/namin/unsound

Вопрос касается ООП, поэтому спрошу тут.
Допустим, я создаю объект А. Этот объект А инжектится в объект Б в конструкторе. Внутри объекта может создаться объект В, в который объект А тоже инжектится.
Это нормальная практика? Или как лучше?

>>1113342
джвачую, математика нинужна

>>1113925
>Это нормальная практика?
Да, это нормальная и запрещённая в современных языках практика, блджад, ёбаной «работы» под огнём оскорблений и обвинений, когда перед носом у тебя висит морковка, а на шее кредит.
>Или как лучше?
Храни данные в виде дерева, пока не требуется что-нибудь особенное (а оно в 99% и не требуется).

>>1113925

Трудно сказать по описанию, так как непонятно, что это за объекты. Но вообще, выглядит странно. Обычно объекты делятся на 2 вида - "сервисы" и "сущности" и если у тебя "сервисы" то конечно создавать их удобнее где-нибудь снаружи.

Когда речь о зависимостях, можно рассуждать с позиций логики, можно ли использовать тот или иной объект отдельно. Ну например, у нас есть класс Товар и мы хотим сделать в нем метод получитьЦенуВВалюте(валюта). Для этого нам придется инжектировать в каждый Товар объект КонверторВалют. Но логично ли, что для создания Товара нужен этот Конвертор? Не очень. Потому, возможно, лучше отказаться от внедрения Конвертора и от метода получения цены в нестандартной валюте. А сделать такой метод где-то в другом месте: получитьЦенуТовара(товар, валюта).

>>1114020

Деревья подходят в основном для учебных задач на 30 строчек про поиск пути. А там у анона, как я понимаю, реальная задача.

>>1114149
>Но вообще, выглядит странно.
Циклические ссылки между объектами запрещены в дотнете.

>>1114149
>Трудно сказать по описанию, так как непонятно, что это за объекты.
Я хуево описал. Вот у меня есть класс. Внутри есть поле со списком и поле с объектом, в который передается этот список в конструкторе. Этот список изменяется в 2-х объектах. Вот это меня смущает.

>>1114327
расписал как боженька

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

А ФП это просто си с ограниченными функциями. По сути то же процедурное программирование - менее абстрактная модель.

>>1114578
всё ООП это антипаттерны. Сам класс это нарушение инкапсуляции. Доступ к переменным класса получает кто угодно. Соответственно поведение невозможно гарантировать и протестировать.
Stateless функции - конечный протестированный кубик, поведение которого никто не может изменить

>>1114580
>Доступ к переменным класса получает кто угодно.
есть права доступа, нюфаня

>>1114578
>Вот есть, например, классическая музыкальная теория: она описывает определенную модель музыки, вводит категории нот, гармонии, структуру музыки и т.д.
А есть шкала Пифагора, которую мне будущая гендиректор московского Международного Дома Музыки рассказывала в 5 классе школы, мы сидели за одной партой. Та тетрадка сохранилась, я всё думаю зайти к ней на концерт и взять автограф. Дроби, которые я никак не мог понять, были для неё живыми, они звучали, как музыка... это и была музыка, а не йобанная «теория музыки».
>Зачем нужны такие теории? Очевидно, для упрощения проектирования.
Вот уж воистину, кто не умеет сам и не умеет учить других, тот учит учить учиться.

>>1114598
Есть public-методы, которые вызываются кем угодно, как угодно, и откуда угодно.

>>1114599
>классическая музыкальная теория:
это че за еба? вы там уже музон расписали?

>>1114598
наследовать может кто угодно. И переопределить методы может кто угодно. И модифицировать внутренние переменные тоже может кто угодно

>>1114602
А ты думал! Правда, «Am→C» не объяснили до сих пор...

Вот шкала Пифагора:
https://www.youtube.com/watch?v=nOXWfzJh2vU
Триста, сто и двести колебаний струны в секунду. ЦЫГАНЭ!!!

>>1114603
>>1114601
Успокойтесь, мани, в 9 жабе это уже порешали модулями, что теперь можно указывать права, какой пакет имеет доступ к какому пакету (до сего момента такие правилы только можно было применить на уровне мавеновских проектов).

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

Код обращается к классу, всё работает. Потом ты подсовываешь потомка этого класса - и оттестированный код ломается

>>1114694
>подсовываешь потомка этого класса - и оттестированный код ломается

подсовывай так чтобы не ломался

>>1114695
лично я вообще отказался от наследования. А без наследования уже нет ООП

>>1114698
Возвращайся, когда выучишь различие между наследованием состояния и наследованием поведения.

>>1114720
ну давай, просвети нас

>>1114775
ясн. Очередной школьник решил задавить интеллектом

>>1114777
Но при этом
1) я абсолютно прав насчет твоих кукареков о наследовании
2) не повелся на твои тухлый развод с последующей бесполезной веткой по олимпийскому перебрасыванию какашек
3) давить тут нечего - если интересно, сам разберешься, а ультимативные заявления о бесполезности чего-либо - бессмысленны.

>>1114780
Ну то есть старая песня с RSDN о том, чтобы «наследовать только интерфейсы», так?..
Может, ещё и данные не менять.

>>1114791
О чем Егорка и тылдычит.

>>1114578
>ООП можно представить как теорию проектирования программ
К сожалению, на данный момент нет никакой теории проектирования программ, ни одна парадигма не дает. В принципе, главное - достичь https://en.wikipedia.org/wiki/Loose_coupling, чего можно добиться в любой парадигме.
>Теория сводит множество решений проблемы к какому-то разумному числу упрощенных абстракций, которые можно анализировать, которые являются такими строительными блоками посредством которых достигается решение проблемы.
ОО-паттерны никак не формализированы, их реализации могут сильно отличаться. Так что анализ приходиться проводить каждый раз с нуля. Мутабельное состояние, которое конечно не является обязательным в ОО-программах, но часто это как раз именно то что инкапсулируется в классах (смю последний абзац в >>1112711), еще сильнее затрудняет анализ. Мне недавно пришлось написать модуль с большим количеством изменений состояния: я просто ахуевал от того насколько сложно с ним работать по сравнению с трансформациями иммутабельных данных, из которых на 95-100% состоит код других модулей и на 75% этого же.
>А ФП это просто си с ограниченными функциями. По сути то же процедурное программирование - менее абстрактная модель.
Вот это просто полностью меняет суть: эти ограничения дают композабельность элементов и возможность формально о них рассуждать. Эти компоненты, приёмы работы с ними и их приложения можно изучать отдельно с реальных выхлопом в виде пейперов (см. хотя бы https://wiki.haskell.org/Research_papers). Большинство из них могут быть перенесены в любой язык в виде библиотек, хоть в Python, хоть в Scala (для неё это уже сделано и достаточно широко используется).

>>1114327
>Долго эта ебля маняматики, фыпе и меня лично в рот и в жопу ещё будет тянутся.. Ох долго
Опять не выучил? Ах да, это же гуманитарщина. Садись, два, петушок.
И пиздуй борщ мамкин доедать - тут, в мире победившей "гуманитарщины", мнение неграмотной манюни никого не интересует.

>>1114327
> но ему так и не понадобилось кучу книг и статей по шаблонам проектирования в ФП
Потому что никто не пишет на чистой функциональщине ничего длиннее сотни строк?

>>1115113
Потому что цитата - враньё человека имеющего о ФП крайне поверхностное представление.

>>1115014
>Ах да, это же гуманитарщина.
Кто бы пиздел. Сидишь и ошибки в тексте выискиваешь, а не смысл пытаешься осязать.

Интересно, а есть ли яростные сторонники функциональной инженерии, которые пытаются все проектирование своих сортиров, велосипедов и домов свести к теоркату.

>>1112470
У вас там реально корень белены? Это многое объясняет.

>>1115728
В мире FP сортир не нужен, потому что иммутабельное говно не может выйти из иммутабельной жопы. А велосипед не умеет ездить, но там есть репликатор, который создает копию велосипеда и наездника на некотором расстоянии в нужном направлении. Время от времени на дорогу выходят таджики с техникой и с матами грузят все уже ненужные копии в Камаз.

>>1113342
Эх, а ведь пидор, который поднасрал в 4) теперь и C# засирает :(

>>1116353
Это плохо?
>>1116405
1) Не всё что ты не понимаешь - тупое дрочерство.
2) Судить о том что реально нужно можно только изучив технологию или подход и области его применимости. Без этого любые слова, не важно поддержи или осуждения - просто пук в лужу.
>>1116824
>Паттерны и принципы проектирования, всякие там SOLID/GRASP/DDD и прочее были созданы не просто так и действительно решают проблемы, сопутствующие разработке средних и крупных по размеру проектов.
Все так, эти принципы действительно призваны обсеспечить loose coupling. Только они часто универсальны для любой парадигмы, несмотря на то что сформулированы в терминах ООП. Например https://softwareengineering.stackexchange.com/questions/165356/equivalent-of-solid-principles-for-functional-programming/171534#171534
Ничто не мешает тебе использовать DDD c ФП, как и layered architecture.
В целом же пост и особенно пассаж о js, map и галерах вообще показывает что отношение к ООП ортогонально
а) знаниям самого ООП
б) уровню интеллекта в целом и профпригодности как программиста в частности.

>>1116824
Добавлю, что, по моим наблюдениям, многие говнокодеры предпочитают ФП потому, что оно очень похоже (для них) на процедурное программирование. Неоднократно слышал от таких "зачем целый класс, когда достаточно одной функции", "конфигурацию можно передавать через параметры и использовать частичное применение", и т.п. С правильным именованием там, зачастую, вообще полный пиздец: код пишется согласно принципу "write once, read never" - и спустя полгода даже его автор будет медленно и мучительно разбирать свои каракули (полагая, как и привыкли физмат-интеллигенты советской закалки, перепутанность признаком хорошего, "умного" дизайна).

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

>>1116824
>против ООП, то ты а) не знаешь, что такое ООП

нормальный человек не должен знать про ООП

всякие там наследования надо учить как особенность компуляторов для уменьшения копирования кода

>>1116940
>Не всё что ты не понимаешь - тупое дрочерство.
А все, кто едят огурцы - умирают.
Каждый инструмент применяется в каком-то контексте.
Если этот контекст - "везде нужно и используется повсеместно", то это не тупое дрочерство, а очень полезная вещь.
Если его контекст - "пишешь никому не нужные обскурные опердени для себя за так", то это тупое дрочерство.
Так что я тебе даже больше скажу - вообще не нужно знать "технологию", чтобы со всей уверенностью сказать, тупое дрочерство это или нет.
(Да, все вроде логично и просто, но тупой фыпе-слесарь вроде тебя до этого не додумается сам, в силу своей ограниченности.)

>2) Судить о том что реально нужно
Свои заявления надо доказывать, долбоеб. Иначе пукаешь в лужу тут только ты.
"Реально нужно" == "облегчает работу, за которую платят деньги", а вовсе не "изучил тяхналахию и сяжу праграмираваю в мамкином подвале такой нитакойкакфсе, обсирая тупых ооп-питухов, заполонивших индусрию".
Кстати, фыпе - не технология, а лишь парадигма, мамин ты невыросший ботаник-кододурачок.

>>1116955
А теперь примени свои критерии дрочерства к своему изучению
>DSP, machine learning, natural language processing, information retrieval
и, например, пхп с джавскриптом и поделись результами. Так мы узнаем какой у тебя IQ - меньше 50 или просто двузначный. Хотя судя по
>тупой фыпе-слесарь
>невыросший ботаник-кододурачок.
>нитакойкакфсе
>я тебе даже больше скажу со всей уверенностью
результат предсказуем.

>>1116941
>предпочитают ФП потому, что оно очень похоже (для них) на процедурное программирование
Да оно не только для них похоже. Это и есть процедурное программирование.
Видел на ютубе выступление дауна, который рассказывал что ФП лучше, потому что для функций проще писать тесты

>>1117264
В процедурном программировании нет контроля за сайд-эффектами и type-driven development.

>>1117314
Теперь есть. Кокие проблемы.

>>1116991
Давай ты сравни востребованность хуяскеля с вот этим
>DSP, machine learning, natural language processing, information retrieval
Я так-то ООП имел в виду, но ты не понял. Тем, что ты перечислил, я лишь эпизодически занимался. Впрочем, все эти области решают совершенно конкретные классы задач, в отличие от хуяскелей.

>>1117331
Покажи, где там в C++ есть контроль за сайд-эффектами.

>>1117362
Ого, ты меня удивил - уклонился от ответа, ведь разговор шел про твои критерии дрочерства. Но и здесь ты обосрался.
Что значит востребованность? Количество вакансий? Вакансии есть с разными требованиями, может и хаскель с NLP быть и Scala с machine learning и information retrieval. В любом случае, таких вакансий очень мало, так что учим срочно пхп с джавскриптом.
Далее, всерьёз сравнивать язык программирования и предметную область может только конченый даун. Предметная область - то о чем ты думаешь, язык - средство выражения мыслей и виде программ. Желательно чтобы программы были корректными и простыми в сопровождении и языки/технологии/парадигмы должны помогать писать их именно такими. Кроме того, часто создание алгоритмов в эти областях и их реализация - обязанности разных людей: специалистов по конкретной области и программистов соответственно. Это /pr, соответственно мы здесь обсуждаем инструменты программистов, не так ли? Если нет, давай обсудим что востребованнее - авионика или джава и сделаем выводы. Оставляю это тебе, ты со всей уверенностью это сможешь сделать.
>DSP, machine learning, natural language processing, information retrieval
>Я так-то ООП имел в виду, но ты не понял
Действительно, как же так. Когда пишут DSP всегда в виду имеют ООП, это же очевидно.
>все эти области решают совершенно конкретные классы задач
Все верно, даже если сюда включить ООП. Но вопрос насколько качественно ООП справляется с решением своей задачи (построении легко поддерживаемых программ) - достаточно дискуссионный. Я, поработав с системами написаными в ООП и ФП, склоняюсь к тому что есть варианты лучше чем как минимум чистая ОО-декомпозиция программ. Хотя может это субъективно, о чем я еще здесь писал: >>1112711

>>1115113
Вряд ли WhatsApp написан в 100 строк

>>1116824
Галерник, я в отличие от тебя, на них не работаю.
Обсуждать с тобою ООП я готов был бы. Но когда ты заикнулся про процедурное программирование сравнивая ФП, разговор продолжать бесмыссленно. Ты даже не понимаешь что то ООП которое выросло из крестов (а не из смолтолк) куда ближе к процедурному программированию чем даже самая говенная реализация ФП.

>>1115014
Я не из РФ.
Ты сам прекрасно понимаешь что ради долбоёбов на дваче, русский учить - смешно.
Хотя, ты мог быть попробовать хоть чем-то аргументировать, как этот - >>1116824
Хотя нет, лучше продолжай дрочить на мои ошибки, не пиши такую хуйню.

>>1116824
И ещё, в догонку
Ты же понимаешь
>Паттерны и принципы проектирования, всякие там SOLID/GRASP/DDD и прочее были созданы не просто так и действительно решают проблемы, сопутствующие разработке средних и крупных по размеру проектов.
Что это к парадигме не привязано? Ты вообще читал моё сообщение? Или увидел как твою священную корову опустили и сразу как животное ответил? И ты знаешь что ни наследование, ни композиция тоже к парадигме не привязано?

>>1118404
Чо ж крольчатину не упомянул? Компиляторы на окамле не вспомнил? Ведь компилеры действительно збс писать на функциональщине.
Нормальные строки в Эрланг так и не завезли?
Не слежу просто.

>>1118412
>русский учить - смешно
Хорошая попытка, но нет: ты все же жиденько обкакался, прям в штаники себе надудолил. Ты пишешь не как взрослый дядя из другой страны, а именно как полуграмотный школьник, не выучивший русский. Так что ставлю тебе два, и можешь уебывать подмываться :3

>кококо кресты плаахииие
https://www.whatsapp.com/join/?dept=software-engineering&id=a0I1H00000LBwp2UAD
>Write clean, awesome and bug free Erlang, C or C++ server code
Уважают крестатых, ты смотри! Даже в такой священной корове фыпешников, как вотсапп ООП и мейнстрим весьма востребованы. Смирись, петушок.

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

>>1118506
>программы читаются и пишутся людьми, а посему гуманитарная составляющая языка
Всё так. Код для людей.

>>1118478
>Хорошая попытка, но нет:
Удвоил.

>>1118506
>нотки презрения к "неосиляторам" - знайте: перед вами обычный сноб, не написавший в своей жизни ничего толкового.
Крайне универсальное и действительное выражение. Можно упростить до обычных крикунов.

>>1118506
Мне скучно и я решил бампнуть, напоминая ваннаби фп-фашистам, что лямбда вычисление выражается в терминах сигма-калькулуса. Хочется посмотреть на пылающие пердаки.

>>1118506
>проще представлять
Кстати, горение проще представлять как истечение флогистона, чем как окисление.

Что-то Егорка больше не делится с нами откровениями. Неужели осознал преимущества функционального программирования?

>>1126589
Ушел в ретрит.

>>1126589
Может, наконец, осилил Smalltalk, осознал всю убогость своего велосипедирования и с горя удавился втихаря уничтожил весь нераспроданный тираж своей графомании.

Лучше сюда накину:

https://www.youtube.com/watch?v=rX0ItVEVjHc

>>1126713

надо знать про байтоблядей.

>>1126716

Вот, просмотрите полностью и вы поймете что байтоёбов нужно гнать и унижать:

https://github.com/CppCon/CppCon2014/blob/master/Presentations/Data-Oriented%20Design%20and%20C%2B%2B/Data-Oriented%20Design%20and%20C%2B%2B%20-%20Mike%20Acton%20-%20CppCon%202014.pptx

>>1126713
Не понял баттхерта, объясни (видео не смотрел).

>>1126790
Им дали полиморфизм времени компиляции и исполнения, вместо этого обезьяны пишут мономорфные процедуры с кастом к void char

>>1126970
@
ЗАТО БЫСТРЕЕ

>>1126569
Зенки-то протри, хуесос.
Тотальное доминирование ООП и тотальный отсос фыпе - лучшее доказательство.

>>1126970
Не понял, кто им дал полиморфизм в си?

>>1127047
CppCon 2014: Mike Acton "Data-Oriented Design and C++"[РАСКРЫТЬ]

>>1127063
>[РАСКРЫТЬ]
Не раскрывается.

>>1126710
Видел это давно. Охуел от еблана. Его там в конце раз шесть обассали.

>>1126790

Смысл в том что этот оратор работает в подразделении Сони, которое разрабатывало для мыловарни анчарч и ластовас. У МОЩНОГО РЕВОЛЮЦИОННОГО ПРОЦЕССОРА (как это утверждалось в 2005 году) Мыловарни 3 на поверку оказалось кастрированное ядро PowerPC G5 с НОУБРАНЧПРЕДИКШН и НОУАВТОПРЕФЕТЧЕМ. У мыловарни 4 с этим чуть получше, но само ядро - энтрилевел для планшетов и нетбуков (потому что им нужно было чтобы в APU видюшка на кристалл чуть помощнее уместилась).

То есть проблема в изначально хуевом, хуево спроектированном железе мыловарен 3 и 4, а не в недостаточном ублажении байтов как этот оратор пиздит.

Мыловарню бы надо бы не использовать, ну или на худой конец сделать порт на отъебись с мылом и текстурами низкоого разрешения, но проблема в том что контора этого оратора, как сказано выше - внутренняя студия Sony и эта самая Соне заставила их делать систем-селлер с грофоном (продажи пс3 в начале были хуевые, потому что выпустили на год позже 360, распиаренная мощь оказалась пшиком, а денег въебали почти 4 ярда).

То есть байторабов заставили делать на говне рекламный продукт с грофоном и байтоебы из своих анальных болей касательно конкретной задачи вывели целую философию по правильному ублажению кеш-линий a.k.a Data-Oriented Development.

>>1127005
Доминирование (где-то) ООП обусловливает некую 'объектность' мышления? Ты понимаешь, насколько это - галиматья. В лучшем случае это можно понимать как обратную индоктринацию. Это - не доказательство.

Чтобы окончить все споры и сомнения, предлагаю найти 2 репозитория очень больших проектов на java и любом ФП-языке (если такие в принципе есть лол, если не найдете можно взять проект на си, почти одно и то-же). И попробовать прочитать код.
ООП это не блажь - в отличие от ФП,- а суровая необходимость для реальных задач, без которой писать программы очень БОЛЬНО.

>>1127165
Хочешь, чтобы все играли по твоим правилам?
>ООП это не блажь - в отличие от ФП,- а суровая необходимость для реальных задач, без которой писать программы очень БОЛЬНО.
ООП - это суровая блажь.
Если вам больно писать программы - не пишите их.

>>1127223
ООП - это дизайн, позволяющий писать сложные программы легче, и к которому люди пришли в результате длительного опыта написания программ.
ФП - это академическое баловство, которое никогда не проектировалось для написания системных программ и приложений.

>>1126713
Не понял, зачем велосипедить арифметику поинтеров и вытаскивать переменные из памяти вручную, если struct придумано именно для этого?
В чем тут оптимизация?

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

>>1127259
Еще раз: берешь два больших репозитория: один ООП, другой функциональный /процедурный, и пытаешься разобраться в архитектуре кода.
Ты не поймешь, пока не увидишь на практике большого проекта. Пока твой манямирок ограничен уровнем хелловорлдов ФП кажется проще, логичнее и лучше, да.

>>1127077
Попробуй в другом браузере.

>>1127231
>ООП - это дизайн, позволяющий писать сложные программы легче
Это такая толстота или ты дальше хеллоувордов не заходил?
ООП дает иллюзию контроля и простоты, но как только логика становиться чуть сложнее круда, понять, что происходит в программе в целом становится невозможным.
>, и к которому люди пришли в результате длительного опыта написания программ.
А это вообще пушка. Даже детсадовцы знают, что ООП зафорсенная парадигма.
>>1127260
Любые исходники на языке, который ты хорошо знаешь и в области, в которой ты разбираешься читаемы. Если ты не осилил ФП, то ты конечно же там нихуя не поймешь.

>>1127304
Ебать дурак. ООП - это, грубо говоря, эффективное разделение труда и ответственностей.
Все мы вместе строим дом. Вася делает объекты двери, Петя делает объекты ступеньки, Коля делает объекты оконные рамы, а Антон строит объекты стены.
И всем похуй кто из них что делает, главное чтобы сделанные ими объекты поддерживали определенный ИНТЕРФЕЙС.
Более того, если мы внезапно обнаружим что у Васиных дверей ржавые петли, мы пошлем Васю нахуй с его дверями и попросим кого-то сделать двери соответствующие нашему интерфейсу.

>>1127325
В итоге вася отвечает за все. За доски, за цемент, за аллаха. При этом неправильный цемент для васи может затронуть производство окон

>>1127328
кто последний пронаследовался, того и косяк

>>1127328
Если ты не можешь наладить производство, то виновата методология. Ясно.

>>1127330
Наследование не является идеей ООП. И светоч ООП кстати считает наследование плохим.

>>1127337
классы без наследований? там они вобще ебанулись уже чтоли?

>>1127339
Классы, кстати, ООП тоже не нужны. Вот в javascript нет ни классов, ни наследования.

>>1127342
норкаманчтоле? там все производное от обджект, есть и классы и наследование, но не такое как в сипласплас

>>1127333
По такой логике надо хуячить на указателях. Не можешь наладить код на указателях - вон из профессии

>>1127330
Ну так может вообще убрать глобальные состояния? Чтобы код от них не зависел и соответсвенно один блок кода не мог сломать другой.
Итого мы приходим к stateless функциям и запрету на пкременные класса

>>1127351
Нету там ничего. оператор new создает пустой объект и передает в функцию как this.

prototype это хак для уменьшения дублирования кода: если функции нет в объекте, то она ищется в объекте prototype.

https://www.airpair.com/javascript/posts/how-does-javascript-prototype-work

>>1127390
так чем тебе это не ооп? вызывается метод через экземпляр объекта класса, как это реализовано похуй

>>1127337
Хуясе оопоблядки маневрируют.

>>1127337
Классы не являются идеей ООП. И светоч ООП кстати считает классы плохими.

>>1127423
http://www.yegor256.com/2016/09/13/inheritance-is-procedural.html

>>1127339
Смотрите, ребеночек открывает для себя мир, лол.

>>1127111
>философию по правильному ублажению кеш-линий a.k.a Data-Oriented Development.
Извини, но дата-ориентед девелопмент - это не то, что ты описал.

>>1127231
>сборщик мусора - это академическое баловство, которое никогда не проектировалось для написания системных программ и приложений.
>лямбды - это академическое баловство, которое никогда не проектировалось для написания системных программ и приложений.
>lock-free concurrency - это академическое баловство, которое никогда не проектировалось для написания системных программ и приложений.
>динамическая типизация - это академическое баловство, которое никогда не проектировалось для написания системных программ и приложений.
>вывод типов - это академическое баловство, которое никогда не проектировалось для написания системных программ и приложений.
>дженерики - это академическое баловство, которое никогда не проектировалось для написания системных программ и приложений.

Что-то мне подсказывает, что это не тролль, а зеленый студентик, который реально в это верит.

>>1127325
>путать модульность с ооп
Блядь, ну почему я опоздал к самой мякотке, лол.

>>1127425
Как это противоречит моему высказыванию?

>>1127390
>Нету там ничего.
Как там в 2007? Дебил ебаный.
http://es6-features.org/#ClassDefinition

>>1127441
сахарный синтаксис для вкатившихся в макакинг джавадаунов

>>1127446
>Нету там ничего.
http://es6-features.org/#ClassDefinition

>>1127437
>>философию по правильному ублажению кеш-линий a.k.a Data-Oriented Development.

Data-Oriented Design*. И да, ты это не мне, а тому обмудку из ноти дог расскажи.

>>1127507
Я не смотрел видос, так что не могу ответить ничего содержательного на это, извини.

>>1127451
а еще можно макрос на си написать. си - ООП

>>1127138
Ебать ты манядурачок.
Конечно же, это доказательство - ведь ООП настолько популярно не потому, что оно есть во всех языках, а потому, что с ним проще человеку, чем без него. Вот и все. Оно тупо удобнее.
И фыпе непопулярно по прямо противоположной причине - оно выворачивает мозги наизнанку. Это как разбираться в замороченном шизофреническом говнокоде, только этот говнокод не в конкретных исходниках, а в дизайне самих инструментов.
Я знаю, что ты щас начнешь повизгивать из-под шконки про "правильные, строгие" доказательства и т.п., но мань, ты учти, что они никого не ебут. ООП облегчает решение рабочих задач - значит, будем его использовать, даже если там утверждается, что дважды два - пять. Нажми на кнопку, получишь результат, хули.
>>1127304
>Любые исходники на языке, который ты хорошо знаешь и в области, в которой ты разбираешься читаемы
Что за хуйню ты несешь? Читаемы на уровне "int a[10]; // массив из 10 интов", что ли?
Ты никогда говнокод не видел? Так вот, в фыпе, по словам тех, кто его много лет практиковал и в итоге послал нахуй (на кывте поищи), код вообще очень часто оказывается даже не говнокодом, а write-once-кодом, когда даже сам автор ни бельмеса не понимает в своей писанине полугодовой давности.
>ООП зафорсенная парадигма
Ну так работает же, в отличие от фыпе.

>>1127259
>лженаучный
>корпоративному быдлу
Ниишник закукарекал.
Иди порешай уравнений на ночь, отсоси бате-маняматяку (он это любит наверняка) и ложись спать. А в понедельник снова в родной НИИ задротить.

>>1127390
Ты, аутист, где работаешь-то хоть, и кем?
Как ты можешь не знать про ES6?

>>1127342
Берешь, открываешь в Chrome devtools, и выполняешь в js-консоли вот это:

var Base = class {
constructor() { console.log("Base ctor") }
};
var Derived = class extends Base {
constructor() { super(); console.log("Derived ctor"); }
};
var instance = new Derived();

Охуеваешь от своего открытия.

>>1127614
И все по-прежнему хорошо.

>>1114603
ты дебил, про final, private, protected слышал?
я в очередной раз убедился в тупости противников ООП

>>1127615
И коллекция изменилась во время перечисления.

>>1127626
Так ты не меняй коллекцию во время перечисления.

>>1127599
>Как ты можешь не знать про ES6?
А почему, собственно, кто-то должен знать про какой-то ES6?
Даже по этой ссылке выше понятно, что классы в js - это сахарный синтаксис для более удобного создания объектов. Оно просто внешне похоже, а внутри это тот-же самый JS. Ни типов, ни всего остального там нету.

>>1127642
>Ебанутые сектанты
Сектанты как-раз догматично защищали это все. А рациональные люди признают, что какие-то идеи были удачными, а какие-то - как наследование, например - на практике обычно создают проблем больше, чем решают их.

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

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

>>1127658
Настоящие пряморукие программисты вообще пишут в машинных кодах, кстати. Абстракции - для криворуких макак, Ъ-программистам оно ненужно.

>>1127540
>а еще можно макрос на си написать. си - ООП
Погугли, что такое "сиплюсплюс", братишка. Ебать ты долбоеб.

Если наследование нинужно, то как быть с

> На острове – дуб, на дубе – сундук,. в сундуке – заяц, в зайце – утка, в утке – яйцо,. в яйце – игла, а на ее конце – Кощеева смерть

иерархией типов?

>>1127667
Всё так и есть что бы было понятнее напишу пример. Вот есть например множество элементов для динамического создания формочек. 90% логики каждого элемента одинаковая. При помощи наследования, эти 90% можно вынести в отдельный класс, а каждый конкретный элемент формы наследовать от этого родительского класса. А иначе пришлось бы каждый раз копировать эти 90%.

>>1127675
> > На острове – дуб, на дубе – сундук,. в сундуке – заяц, в зайце – утка, в утке – яйцо,. в яйце – игла, а на ее конце – Кощеева смерть
Это же композиция, а не наследование. Там же нет острово-дубо-сундуко-зайцо-утко-яйцо-игло-смертомутантов.

>>1127595
> код вообще очень часто оказывается даже не говнокодом, а write-once-кодом, когда даже сам автор ни бельмеса не понимает в своей писанине полугодовой давности.
ФОПЕ ВИНОВАТО АТАТАТА!

Блядь, ты реально такой дебил или прикидываешься?

>>1127628
>>1127633
Затредшотил, ололо.

>>1127678
Открой для себя компоненты DevExpress, где пишут с треугольными скобочками:
Notebook<Page>
Frame<Client>
и т.д.

Это не наследование.

>>1127675
> На острове – дуб
>наследование

Это тред самозашквара адептов истинного ООП из 10 "б"?

>>1127679
Анончик, а ты не забыл ответить на вопросик?

>>1127684
Скорее - читаем жопой. :)

>>1127683
Что еще за DevExpress и что обозначают эти скобочки?

>>1127688
Где там написанном тобой гринтексте ты нашел иерархию типов?

>>1127696

Нет, это ты выдумал за меня. Мне захотелось привести цитату классика из-за спонтанно возникшей аналогии с принципом Барбары Лисков, который чето-то там рассказывает о основополагающем свойстве иерархии.

>>1127681
Да ты сам тупорылый дебил.
В этих проблемах не ООП виновато, и фыпе тоже не позволит их избежать.

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

>>1127724

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

Правда оказалась в том что реальный мир делится на самом деле на четких пацанчиков и лошар и это нисколько не связано ни с местом в производственных отношениях, ни с наличием/средств производства и прочей хуеты.

Так и программирование. Реальный мир подразумевает наличие какого-то состояния, которое претерпевает изменения. Ну вот как было у тебя в корзинке 20 яблок, ты докинул туда еще одно - и вот тебе 21. Казалось бы, где тут хуйню можно придумать? В функционаломирке конечно же.

У них корзина с яблоками - это такой монолитный неизменяемый объект, в который нельзя просто добавить яблоко, нужно облить бензином и сжечь нахуй корзину с 20 яблоками, обоссать перпелище, затем из лозы сплести новую и положить туда 21 яблоко. А если нужно в дом заселить жильца - то взорвем дом, вырежем нахуй всех жильцов, клонируем днк трупов, выростим новых, и наконец построим дом и заселим жильца. Разумеется место таким фантазиям в реальном мире - в дурдоме.

Кто-то забыл принять таблетки.

>>1127737

Функциональные шизики вроде тебя.

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

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

И что реальный смысл сажи - это "он унизил меня и мое ЧСВ своими великолепными непробиваемыми аргументами, у меня горит, я хочу чтобы вся эта ветка потонула как можно скорей и он не сможет более меня унижать."

>>1127678
Одинаковую логику вынести в методы, тем самым избежав проблем от наследования

>>1127724
Мутабельность - зависимость логики от внутренних состояний. При этом эти внутренние состояния может менять кто угодно. Тем самым даже протестированный код может сломаться в любой момент. Опять же проблемы с тестированием, верификацией, правкой.
Поправишь ты это состояние, а оказывается на него был завязан воооон тот кусок говнокода.
Думаешь почему гобальные переменные это плохо? Вот именно поэтому. И состояния класса это точно такие же глобальные переменные, от которых надо отказываться

>>1127732
Положил ты в корзину яблоко. А потом вооон тот наследник воооон в том говнокоде втихую поменял количество этих яблок. И ты никак от этого не защитишся

>>1127801
Понимание уровня функционального петушка.

>>1127804
В смысле никак. Ты что, ебанат?
Ты в реальном мире как защищаешься от того, чтобы кто-то клал или не клал в твою ебучую корзину ебучие яблоки. Если ты, Джони, не хочешь, чтобы в твою ебучую корзину клал яблоки, кроме тебя, то запри корзину нахуй. Если ты, Джони, хочешь чтобы после того, как ты положил в нее ебучее яблоко, и ебучих яблок стало 21, чтобы ты, Джони, даже ты, Джони, не смог положить в эту ебучую корзину яблок, то запри ее нахуй и выброси ключи. Если ты просто хочешь знать, кто и когда и сколько кладет ебучих яблок, в твою ебучую корзину, Джони, то следи за ней, нахуй. Стой и наблюдай, или повесь на свою ебучую корзину ебучий колокольчик. И тогда ты точно будешь обо всем знать, ебучий Джони.

>>1127804

Я правильно понял: наследование плохое, потому что ты не умееш в примеси?

>>1127724
>Меня в совке заставляли думать своей головой и не давали слушать музыку дегенератов
>Ррряяяя совок плохо!
Проиграл с этой пидорашки

>>1127744
>уличил кого-то в подрыве
>накатал стену текста

>>1127744
>>1127801
Вот вы тут и те и другие в треде бредите. Это напоминает спор нескольких петровичей на заводе о том, какой станок лучше, фрезеровальный или сверлильный. При этом вы полностью забывает, что оба станка хороши и никакой из этих двух станков не может быть лучше, так как у них совершенно разные задачи. И лучше всего когда в цехе есть оба вида станков, так как они могут взаимодополнять друг-друга.

>>1127900
ващет фрезеровальный легко заменяет сверлильный.
Сверлильный применяют там, где фрезеровальный это оверинжиниринг

>>1127804
Что за хуйню ты несешь?
Ты бы лучше вспомнил бы проблему "хрупких базовых классов", которая может возникнуть и без оголтелого говнокода, как в твоем примере.

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

>>1127875
>накатал стену текста
Все верно.
Говорят здесь ООП-бояре, а фыпе-холопам никто слова не давал.

>>1127948
Проблема с наследованием в том, что неправильно понимают его суть. Наследование (расширение) типа используется для дизайна типов, и не повторного использования кода.

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

>>1127959
а чем тебе утилитные методы не нравятся для повторного использования кода?

>>1127959
Ну приведи пример неправильного использования наследования в каком-нибудь популярном фреймворке.
Так-то дай дураку стеклянный хуй...

>>1127964
>Так-то дай дураку стеклянный хуй...
И что произойдет? Хирургу придется осколки вытаскивать?

>>1127964
>Ну приведи пример неправильного использования наследования в каком-нибудь популярном фреймворке
android SDK

>>1127900
Презираю таких "котов Леопольдов" с их дебильной примирительной позицией, с этими примитивными аналогиями. Каким надо быть кретином, чтобы не ощущать конфликтность проблемы вокруг ООП?

>>1127972
Конкретнее. Название класса из СДК, от чего он наследует/что от него предполагается наследовать юзеру сдк, почему это неправильно.

>>1127981
ООП совместно с функциональным программированием отлично опробовано в таком языке как например скала.
Да и вообще, очень многие ООП языки программирования перенимают различные концепты функционального программирования. В жаве например недавно появились функции map, flat, flatmap, filter, не говоря уже о лямбдах. Рекурсия опять же есть даже в С.

>>1127981

И в чём по-твоему заключается проблема и её конфликтность? Вот прямо парой постов выше пояснили как используется наследование, через иерархию дизайн, если угодно типов.

Миксины, бтв, в отличии от наследуемых классов не обязаны соблюдать принцип Лисков, таща за собой чамодан ненужных зависимостей - в этом их как правило сильная, и редко слабая сторона.

>>1128005
В том-то и дело, что все успешные примеры внедрения ООП - это низкоуровневые конструкции, отдельные "утилитные" функции, и т.п.
В той же Scala программа в целом строится на принципах ООП, а фыпе там отвечает за мелкие гораздо менее существенные детали реализации.

>>1128005
И никогда не понимал, почему нии-аутисты так дрочат на эту рекурсию.
Просто вызываем функцию, которая решает нашу локальную задачу. Зачем выделять случай, когда это та же самая функция?

>>1128029
Любую рекурсию можно заменить циклом, а любой цикл заменить рекурсией. А так как в расово чистых функциональных языках циклов нет, поэтому в этих языках приходится использовать для реализации циклов рекурсию.

>>1127714
Перечитай цепочку постов, на которые отвечаешь.

>>1128057
Ну в си-то ты едва ли циклом рекурсию заменишь, там же оптимизации нужны, иначе тебе тупо стека не хватит (особенно, учитывая, что сишечка не только на десктопах с гигабайтами используется, вообще-то).
Да и делать этого никому нахуй не упало: когда удобнее применить цикл, применяют цикл. Когда рекурсию - рекурсию.
Да и вообще это все экономия на спичках и мелкие детали реализации. Но фыпе-дауны зачастую этого не понимают, ибо ограниченные уж больно.

>>1128069
>циклом рекурсию
наоборот, цикл рекурсией
быстрофикс

>>1128005
Мне всё равно с чем совместили ООП.
>>1128008
>И в чём по-твоему заключается проблема и её конфликтность?
Проблема только в том, что ООП - полная лажа, категорически недопустимо никогда. Исключительно вредная глупость.

>>1128076

Так и запишем: неосилятор порвался.

>>1128085
Записывайте как угодно.

>>1128076
ООП ЭТО ФАШИЗМ!!1

CIS-ФАШИЗМ ДЛЯ ХУЕМРАЗЕЙ

Раньше я считал что Егорка несет какую-то хуиту. Но чем больше я перечитываю его сочинения, тем все больше я с ним соглашаюсь.
Раньше я думал неправильно и до меня просто не доходили его слова. Но чем больше я читаю, тем более правильнее я начинаю думать.

>>1112834
Чем реактивные отличаются от очень быстрых интерактивных?

>>1127683
Шаблонами разве получится полностью заменить интерфейсы?

>>1128251
То, что вне скобок — шаблоны классов.
То, что в скобках — классы или интерфейсы.
>>1127689
Чаще всего:
То, что вне треугольных скобок — шаблон класса, обычно контейнер,
То, что внутри треугольных скобок — класс или интерфейс, передаваемый в качестве параметра.
Например:
Класс PriceListItem состоит из LinkedListItem<ProductPrice>
Класс NotebookFrameWindow состоит из Notebook<DialogPanel>
и т.д.

Обоим читать «Cracking the Coding Interview» (Gayle Laakmann) вне зависимости от того, сторонники вы или противники. А то работу не найдёте либо манагеры вас сожрут.

>>1128233
Тем, что одно существует и в жизни, а другое — в рекламе мАйкрософт.

>>1084449 (OP)
В целом я с ним согласен. Мне кажется, он пытается все время сказать, что мы должны объекты рассматривать как типы данных и коллекции типов данных.
Например, наши объекты это такие-же данные, как int или float, только более абстрактные. Из этого понимания становится очевидны все принципы ООП. Например, очевидно что объект должен иметь одну ответственность, потому что тип данных, который возвращает разные данные - это плохо, и лучше такой тип разбить на несколько более простых.

>>1128291
Вот что бывает, когда на первом курсе не преподают комплюктер сцайенс (и вообще не преподают).

>>1129165
>Например, наши объекты это такие-же данные, как int или float
2.setValue(3), угу ;)

>Из этого понимания становится очевидны все принципы ООП.
Из этого понимания вырастают иммутабельные структуры данных, настоящая строгая типизация и функциональное программирование. И да, это уже всем давным-давно понятно.

>>1129221
>не отличает структуры данных от самих данных
лол. структуры это всего-лишь один тип данных

>>1129221
> настоящая строгая типизация
> строгая типизация

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

>>1129256
Возвращайся в ньюфаг-тред.

>>1129321
Эх, сейчас бы основывать свои СИЛЬНЫЕ убеждения на абзаце без источников в русской википедии...

>>1129401

Приведи антоним к строгой типизации. Мягкая? Ласковая? Может быть нестрогая? Нет. Это все хуйня. Пара «сильный-слабый» - более близкий вариант с точки зрения построения ассоциативной связи между антонимами weak[ly] и strong[ly].

Это не википедия, это простая логика.

>>1129407
Тебе в /fl, дружище. Тут все-таки доска про разработку софта, а не про стилистику

>>1129473
Какого хуя пост отправился?

Я говорю, что антоним к строгой типизации - хуевая. И все это в любом случае не имеет к содержанию >>1129221-поста в частности и этого треда вообще.

>>1129401
>Возвращайся в ньюфаг-тред.
Ебать дебил. В ФП тебе дали несколько дефолтных типов данных, с которыми можно трахаться. В ООП ты можешь создать свой абсолютно любой тип данных