Subj
в принципе интересно послушать
но оставляет впечатление человека с высоким чсв
но оставляет впечатление человека с высоким чсв
Кто это?
> Bitcoin Is Not a Pyramid.
А он смелый!
разве плохо иметь свое мнение, или он тебе дорогу перебежал?
Да он же тупо зарабатывает, впаривая свою хуйню. Я вот это смотрел и мне за него было пиздец неловко https://www.youtube.com/watch?v=RiXXCYMjqZE
Помню его, показывал какой-то дико уебищный язык.
Внимательно рассмотри человека на прилагающейся фотографии. Можешь ли ты представить себе, как этот мужчина плачет и набирает дрожащими пальцами телефон какой-то невнятной бляди, чтобы рассказать о своих чувствах к ней? Можешь представить, что он пропускает в очереди жирную мамашу с выблядком на руках? А то, что он работает пол-года, раздавая листовки, чтобы купить себе iphone? Ты видишь в нем человека, который стесняется сказать родителям, что на свой двадцать четвертый день рождения он хочет выпить с друзьями?
Теперь посмотри на него еще раз. Видишь ли ты на нем стильные брендовые вещи? Может он покрыт вздувшимися мускулами и толстыми венами? Он обладает внешностью киноактера или мужчины-модели?
Позади него стоит дорогой автомобиль?
Посмотри снова на этого мужчину и спроси самого себя, что с ним не так?
Почему в его взгляде железо, в его осанке сталь, а вместо кожи свинец?
Почему-то мне кажется, что у него еврейские корни.
Рыбак рыбака видит издалека.
может потому, что он Венсан Кассель?
Вроде грамотный человек, но говорит безосновательные вещи. Откуда он берет свои идеи неясно, но говорит что правильно только так. Я противник ООП как такового, потому что оно не имеет математического базиса. Об ООП всегда будут спорить, потому что это пустышка. О ФП никто не спорит, потому что оно имеет математическую основу. Все концепции ФП известны, спорить там не о чем. Бугаенко занимается антинаучной ерундой. ООП - фарс, никто не знает что это такое и какие у него правила, поэтому о нем всегда будут спорить. На этих спорах Бугаенко пытается пиариться. Его идеи не стоят выеденного яйца. Они ни на что не опираются. Пустота пустотой.
>Откуда он берет свои идеи неясно
По крайне мере, один источник его взглядов известен - это David West со своей книгой "Object Thinking". Есть ещё интервью, где West излагает Бугаенко свои взгляды на ООП: https://jug.ru/2016/09/bugayenko-west/
Ну знаю и что. А кто такой этот Вест? Императивное программирование основывается на работах Тьюринга, функциональное на работах Чёрча. На чем основывается ООП?
>На чем основывается ООП?
Понятия не имею. Это у пропагандистов ООП надо спросить.
Как же меня заебало это ваше айти и уебищные тупые люди в нем.
мимо алгебраист
мимо алгебраист
В том то и дело. Чтобы рассуждать о правильности/неправильности как это делает Бугаенко, нужно на чем то основываться. И основа должна быть математически формализована, это же программирование, а не вязание крючком. Бугаенко просто пиарится. Не думаю что он настолько глуп, чтобы не понимать что его слова безосновательны. Он очень грамотный и рассудительный, я смотрел его доклады. Если бы он хотел рассказывать правильные вещи, он бы изучал теорию CS.
>На чем основывается ООП?
На кромешной поверхностности и ограниченности адептов. ООП применяется для утилизации обширных масс быдла в it. Это лженаука в чистом виде. Его идеологи и последователи фетишизируют понятие (объекта), которое не понимают даже приблизительно. Субъект-объектные оппозиции преодолены философией лет 200 как, только вот инженегры не в курсе.
>Субъект-объектные оппозиции преодолены философией лет 200 как, только вот инженегры не в курсе.
Ничего не понял. Если есть основания ООП, просвети.
Мартыханы просто. Чтобы херачить код как обезьяна с ГЫ, ОБЪЕКТЫ, много ума не надо. А чтобы доказывать нетривиальные теоремы, нужно быть профессором.
>Если есть основания ООП, просвети.
Я как раз про то, что разумных оснований нет. Всё, что сейчас подаётся в терминах "объекта", "объективности" и т.д. - заведомо туфта и скомпрометировано.
Где об этом почитать?
Про что?
> 2017
> обсуждать ООП
> обсуждать ООП
Про преодоление субъект-объектных оппозиций и скомпрометированности оных.
Стирка - это отображение кортежей грязных носков и порошка во множество чистых носков.
Покажите мне объект стирки.
В той или иной мере вся посткартезианская философия.
Твоя мамка получает сообщение постирать носки, порошок, прибор для стирки. И стирает.
Чтобы херачить код как обезьяна с ГЫ, ФУНКЦИИ, много ума не надо. А чтобы проектировать приложения в объектно-ориентированной парадигме, нужно быть профессором.
nponeccopом
Представляете, как выглядит разработка приложения командой ФП-господ? Сидят высокие, красивые, атлетично сложенные господа в смокингах и рисуют коммутативные диаграмы, в перерывах рассуждая о морфизмах абелевых многообразий, координатных кольцах и вложениях в проективное пространство. А как то же самое выглядит у ООП-адептов? Типичная команда ООП-мартышек состоит из бомжеватого вида людей и бабомужика-тимлида, спорящих о том, как правильно обращаться к полям класса изнутри - через геттеры или напрямую, и жалующихся на то, что нихуя не получается. В их глазах - усталость и отсутствие перспектив, а на лицах - обезьянья глупость.
Театр одного шизосемена
Спойлер:
этот шизосемен - ты
Известный французский программист на Java Андре Вейль бросил перспективную карьеру "респектабельного" проектировщика в пользу алгебраической геометрии. "ООП - полное дерьмо. Когда я проектирую приложение, я чувствую, что тупею" - признавался Андре. - "Человек, не знающий математики, не способен ни к каким другим наукам. Более того, он даже не способен оценить уровень своего невежества, а потому не ищет от него лекарства" - продолжает ученый.
Планирую вкатиться в конструктивную математику, какие подводные?
Смешно.
Зачем?
Хочу определить натуральные числа.
>В каждом языке своя модель, в функциональных она основана на математике и матанализе. Легко ли её использовать? Многие ли ваши коллеги хорошо знают матанализ?
>матанализ
Ебаный даун.
Гринтекст - это цитата из статьи по ссылке? Пиздец, не верю, не бывает таких дебилов.
Может тогда теория чисел? Вообще в математике все связано. Одно опирается на другое.
Похоже Вест не шарит совсем.
Хуй знает когда последний раз пересматривал. С годами становится только лучше. Надеюсь, соседей на разбудил.
Смотрел его одну лекцию, конечно какой-то смысл в его подходу есть. Но понятно, что если это все на практике реализовать начнет появляться куча проблем, которые будут решаться всякими костылями ввиде паттернов и прочей ебалы.
А по сути, он несет очевидно бредовою хуйню.
Может он сам это понимает и пиарится, за что ему на ебало можно только поссать.
А может он вообще этого не понимает и искренне пытается продвинуть свой шизобред в массы, за что ему тоже можно поссать в ебло.
Так что в любом случае он достоин только порции урины в ебальник.
/thread
Харкачую сего господина.
/thread
>он несет очевидно бредовою хуйню.
обоснуй
Та блять, недавно послушал лекцию. Блять, какая же это хуета. Какая же сука нахуй хуета...
https://youtu.be/lfdAwl3-X_c
> Я противник ООП как такового, потому что оно не имеет математического базиса.
http://lucacardelli.name/Papers/PrimObjImpSIPL.A4.pdf
DAO это позор!
Если вы по какому-то недоразумению используете DAO, немедленно переписывайте под объекты разговаривающие на SQL!
У меня все.
http://www.yegor256.com/2017/12/05/data-access-object.html
Если вы по какому-то недоразумению используете DAO, немедленно переписывайте под объекты разговаривающие на SQL!
У меня все.
http://www.yegor256.com/2017/12/05/data-access-object.html
ООП — это рак. И его нужно просто выкинуть на помойку. А не разбираться почему оно такое говно.
В голос.
Просто ты неосилятор.
Иди пиши императивные процедуры за еду, макака.
>морфизмах абелевых многообразий, координатных кольцах и вложениях в проективное пространство
у заказчика Пажита цифры не сходятся за 12 декабря 1975 года, и система наебнулась 20 декабря 2017, давай чисти абелево многообразие
Бугаенко, залогинься.
>потому что оно не имеет математического базиса
Пустышка - это про содержимое твоего котелка.
За Луку и двор, стреляю в упор ς-calculus
Ну, допустим http://staffwww.dcs.shef.ac.uk/people/A.Simons/classify/
Только ты паскуда тварь маловерятно что прочитаешь, но хотя бы кукарекать не будешь, в интернетах, про то что оснований нет.
Поехавший шизик.
Барух и его друг Женя намного лучше.
>Ctrl-F
>Composition
>Phrase not found
Yasno.
Старые выпуски «Inside Macintosh» годов так 1983-1988.
Затем электронное письмо Гейтса, где он пишет «мы должны изобрести что-то, чтобы IBM не могла запускать бинарные файлы под Win32».
А затем... почитать книги по настоящему программированию, без религиозного фанатизма.
— в смысле, собранные под Win32.
>пук
какие книги? есть список?
спасибо
>какие книги?
Вот эти
Два тома поехавшей графомании? неплохо!
>не читал, но осуждаю!
>аноньчик решил выибнуться ссылкой на "формализацию" оопе
>пейпер, который он никогда не читал
>из гуманитарной дрисни от луки не выводится даже определение композиции
>я тибя затролел
--> /b/
причет тут композиция? ты еще пожалуйся что про синглтоны не написали
Поздравляю, вы в ООПе.
Маня, нахуя нужна система, в которой нельзя определить такую базовую операцию, как композиция её термов?
Я не понял, что ты хотел сказать этим зеленым текстом, да мне и похуй.
Как будто бы ты обосрался и вынужденно маневрируешь. Но ты же, очевидно, обосрался, обозначим буквами:
O - обосрался ты
М - маневрируешь
O => M, O
------------
М
Дебил, ты бы вводную бы прочитал, прежде чем кукарекать.
Читай вводную и итоги, дебил.
>этот делирий питудия
Иди проспись лучше, б/ыдлан.
> да мне и похуй
Ну да, так похуй, что не забыл об этом написать.
давай определение композиции в оопе, даунидзе (которого в пейпере нет)
если дать не можешь - просто иди нахуй
Ты подебил, у меня нет времени отвечать на твою бессодержательную зелень.
>мам сматри я тралю
ты полудурок, программирование - это инженерная специальность и к ментальной гимнасткие она не имеет никакого отношения. программирование намного ближе к строительству зданий, чем к математике
Дебил, пейпер отправная точка, ответ на вопрос о формализации. Хотел бы разобраться в вопросе, прочитал бы несколько страниц.
> We omit how to encode basic data types, control structures, and classes, which can
be treated much as in [4].
Ну и отлично, нахуя тогда эти линки на пейперы, где Лука Карделли на личном примере демострирует что применение к оопе каких-либо формальных методов - это как натягивание гондона на глобус?
>где Лука Карделли на личном примере демострирует что
ТЫ СКОЗАЛ?
Пока только что ты демонстрируешь тупость и убогость ИТТ.
>ответ на вопрос о формализации.
Я про неё не спрашивал (это был другой анон), я лишь указал, что этой системе грош цена, если в ней даже определение композиции дать невозможно.
>там всё у него заебись, а базовые операции комбинирования термов определять нинужно, о них вы можете узнать в книге виликих инженеров Gangbang of forth всего за 29.99$.
Yasno.
Плиз, не надо так. Почитай статью вместо Ctrl+F, поймешь, что возможно и что нет, а так же где можно прочитать про задание композиции.
если речь о теоретическом обосновании ооп
то надо брать конкретную систему типов, которые в свою очередь лежать на конкретных мат аппаратах
ну и смотреть, как в них поддерживаются 2 концепции - возможность наследования типов, второе, как обеспечивается полиморфное поведение
ну а инкапсуляция обычно в довесок, в хороших языках выделяется в отдельную подсистему, какая-нибудь система модулей или че нибудь еще, опять же под эту подсистему приводится соответствующий маттаппарат
примеры приводить не буду и объяснять подробней тоже потому что кто это знает тот и так знает, а неучи либо вообще в ноль понимания либо агрессия
то надо брать конкретную систему типов, которые в свою очередь лежать на конкретных мат аппаратах
ну и смотреть, как в них поддерживаются 2 концепции - возможность наследования типов, второе, как обеспечивается полиморфное поведение
ну а инкапсуляция обычно в довесок, в хороших языках выделяется в отдельную подсистему, какая-нибудь система модулей или че нибудь еще, опять же под эту подсистему приводится соответствующий маттаппарат
примеры приводить не буду и объяснять подробней тоже потому что кто это знает тот и так знает, а неучи либо вообще в ноль понимания либо агрессия
Определение ООП дай (необходимые и достаточные условия). Больше, пока, ничего не надо.
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
я удовлетворил твое любопытство?
бля, в том то и проблема - ооп это тупо набор методик на самом то деле, вопрос только в том поддерживаеются ли его три мантры в самом языке и как у конкретного языка, как он спроектирован - по уму через соотв матаппарат либо на коленке
внезапно ооп в написании кода это как какой-нибудь аджайл для обеспечения процесса разработки
а я ебу? эти статьи никакого отношения к программированию не имеют и не научают тебя программированию.
языки программирования проектируются исходя из практических соображений
>языки программирования проектируются исходя из практических соображений
угу, у нас как раз есть 2 языка сделанных на коленке именно из практичных соображений - php и яваскрипт
>через соотв матаппарат
может тебе еще таск в Jira теоремами и формулами оформлять
Ну охуеть теперь, "эти статьи" в основании по кр мере одного ЯП https://en.wikipedia.org/wiki/Obliq, который в своё время имел практическое применение ну и сдох, как сотни других.
>ооп это тупо набор методик на самом то деле
Есть одна штука которая отличает объектную парадигму от процедурной: вводится понятие control-flow. Все остальное - объекты, классы, полиморфизм - сахарок для управления этим флоу. ООП как набор методик - тоже верное определение, но на другом уровне абстракции, когда хуяк-хуяк и пишем код. мимо простонаблюдатель за ментальными гимнастами в треде
Ты даун штоле? Формальное определение давай.
Например:
(.) :: (b -> c) -> (a -> b) -> a -> c
Давай то же самое только для объектов в оопе.
объекты, классы, полиморфизм - это понятия, в первую очередь описываемые системой типов (если они конкретной системой типов вообще поддерживаются)
к вычислительным моделям эти понятия тоже относятся, взаимодействуют с ними, но это уже вторично
считать их синтаксическим сахаром - неверно, потому что как минимум они находятся на уровне семантики языка
например, мы можем говорить что анонимные функции в с++ - это синтаксический сахар, чуть-чуть для удобства изменяющие этот самый control-flow как ты выразился
в то время нельзя ни в коем случае говорить о лямбдах в лиспах как о синтаксическом сахаре, это семантический конструкт языка
Где тут формальное определение, ваннаби?
Сахарок в данном случае - не альтернативный способ записи, но присыпка, которой всей пользуются, но вот что за ней - почему-то не знают.
---
Ну и синтаксический сахар допустим на уровне семантики языка - однако, это отдельное ментально-гимнастическое упражнение разговор о метапрограммировании и всяких препроцессорах на примере js, а не о том, что такое ооп.
Точно такое же формальное, как обычное определение композиции функций:
Пусть F : X → Y и G : F(X) → Z - две функции (F(X) ⊂ Y). Тогда их композицией называется функция G ∘ F : X → Z определённая равенством:
(G ∘ F)(x) = G(F(x)), x ∈ X .
Только расширенное типами. Или же композиции морфизмов.
Давай теперь тащи определение композиции объектов для оопе.
inb4: GoF
Пикрел отклеился. Вот в контексте сигма исчисления:
Что ты мне за гуманитарную хуйню даёшь, UML-и какие-то, блять, хуемели. Жопу ими подотри. Это формальное определение? Строгость на уровне философского трактата нахуй. Даже ниже, что-то уровня традиций и практик типа "чтобы копьё лучше било мамонта, нужно чтоб его обоссала девственница в полнолуние". И это всё что могли предложить ОО-сектанты, гуманитарный буллщит от дяди Боба под видом некой научности.
Ещё раз, как определена операция композиции (которой в ООП искаробки нет, а как и остальные комбинаторы объектов она осуществляется процедурным быдлокодом; кто бы сомневался, что ОО- это надстройка над процедурщиной и по сути ничем не отличается)? Что является результатом композиции в ООП? Даю подсказку: null.
Притащи формальное определение мамкиного борща
В чём здесь заключается композиция?
Вот у меня есть два объекта, задача определить операцию композиции для них. Типа
a.compostion(b) -> c, чтобы можно было автоматически вывести с из a и b.
Анончик, кушай, что в нашей столовой наливают: борщ философский, а то пока выделываешься - сголодухи копыта кинешь.
ты бы сначала написал что в твоём манямирке является композицией
не понимаю, как какая-то криптическая запись чего-то может быть формальным определением. и зачем этому идиоту понадобилась криптическая запись КОМПОЗИЦИИ. он эзотерик штоле
В сигма исчислении нет операции композиции как ты её видишь, её и в природе то нет, по крайней мере не существовало, пока какой-то шизик не использовал криптическую запись:
> a.compostion(b) -> c
для своих маняпредставлений в голове. Если интересна операционная семантика переопределяемых методов у наследника - читай статью/книгу.
Очередной ООП vs ФП тред, миллион раз уже пережеваный. Вот что вам нудно знать об ООП:
ООП - НЕ парадигма программирования. Парадигм программирования всего три. Подробнее здесь: http://wiki.c2.com/?ThereAreExactlyThreeParadigms.
То что подразумевают под ООП в современном мейнстримном виде (как в плюсах, джаве, питоне и т.д.) - не более чем тривиальная надстройка над старыми добрыми структурами, процедурами и указателями на процедуры. Об этом Вирт, Кей и другие говорили еще в 80-е, наверное.
ООП - определенный способ представления программы в голове, а следовательно и способ её структурирования в тексте. Именно его имел в виду Кей, в нем, как ни странно, суть Actor Model, а значит Эрланга и Акки, и во многом именно о нем пишет Егор Бугаенко. Можно сказать что такой подход это гуманитарщина, и быть при этом правым, но не нужно забывать что программы в первую очередь пишутся для людей, а значит способ их изложения и понимания имеет значение. Насколько легко представлять программу как множество объектов, взаимодействующих друг с другом - другой вопрос. Возможно другие способы эффективнее, возможно это вообще индивидуально.
По моему опыту ООП это способ структурирования именно императивных программ. Дело в том что я видел ОО-код на С, видел процедурный код на питоне с джавой, но никогда не видел ОО-ориентрованых програм на функциональных языках. Наверное это из-за того что объекты почти всегда инкапсулируют какое-то мутабельное состояние, иначе они превращаются просто в (параметризируемые) модули, а состояние в ФЯ обычно скрывается и обрабатывается не так, как и императивных.
ООП - НЕ парадигма программирования. Парадигм программирования всего три. Подробнее здесь: http://wiki.c2.com/?ThereAreExactlyThreeParadigms.
То что подразумевают под ООП в современном мейнстримном виде (как в плюсах, джаве, питоне и т.д.) - не более чем тривиальная надстройка над старыми добрыми структурами, процедурами и указателями на процедуры. Об этом Вирт, Кей и другие говорили еще в 80-е, наверное.
ООП - определенный способ представления программы в голове, а следовательно и способ её структурирования в тексте. Именно его имел в виду Кей, в нем, как ни странно, суть Actor Model, а значит Эрланга и Акки, и во многом именно о нем пишет Егор Бугаенко. Можно сказать что такой подход это гуманитарщина, и быть при этом правым, но не нужно забывать что программы в первую очередь пишутся для людей, а значит способ их изложения и понимания имеет значение. Насколько легко представлять программу как множество объектов, взаимодействующих друг с другом - другой вопрос. Возможно другие способы эффективнее, возможно это вообще индивидуально.
По моему опыту ООП это способ структурирования именно императивных программ. Дело в том что я видел ОО-код на С, видел процедурный код на питоне с джавой, но никогда не видел ОО-ориентрованых програм на функциональных языках. Наверное это из-за того что объекты почти всегда инкапсулируют какое-то мутабельное состояние, иначе они превращаются просто в (параметризируемые) модули, а состояние в ФЯ обычно скрывается и обрабатывается не так, как и императивных.
Чёт в голос с Cunningham's Law.
>То что подразумевают под ООП в современном мейнстримном виде (как в плюсах, джаве, питоне и т.д.) - не более чем тривиальная надстройка
Как будто функциональное программирование не надстройка
>Парадигм программирования всего три
Как минимум есть еще синхрoнные языки.
Препятствие не в этом. Если бы вы знали сколько, всякой чепухи было формализовано. Проблема в том, что ООП - полная кромешная бессмысленность. Окончательный бред. Шизофазия.
>He likes to say that women are unfit to work as software developers.
ну хоть в чем-то я с ним согласен
>дурачек детектед
Я не знаю, есть ли устоявшееся название для этого феномена, но ты - типичный пример винишки-от-программирования.
копипасчу куски кода по всему проекту и угораю над кряхтеньем следующего неудачника котому придется в этом разбираться
Я тебя не понял. Ты о чём?
А зачем вам нужна какая-то математическая основа под ООП? Я вот сейчас в универе прохожу теорию вычислений и рекурсии, где вот мне как раз про разную такую хуиту впаривают и я реально не понимаю: а зачем мне это всё надо? Мне не знание этой математической поеботы никогда не мешало работать. Ну вот выучил я формулу, запоминил, а дальше-то что мне делать с этими знаниями?
>копипасчу куски кода
Это не ООП, если чё.
ну, епт, мост не построить без сопромата и еще кучу спец математики..
с проектированием яп тоже самое..
Как мне противно стало от твоих реплик, сразу повеяло посраллем, линалом, квантовой гиперполяцией, пингвиномагией, обсуждением очередного фреймворка, хихиканием очкастых прыщавых ботаничек-девственниц, анимефестами, косплеем, коллекцией фигурок героев анимэ, просмотром нового сезона Поней под пледиком, жутким высером компилятора на триста страниц, долгим унылым чтением http://rsdn.org/forum/philosophy/1096982.all
Тебе сколько лет, дядя? Реагируешь как школота, а ссылки даешь как-будто под сорокет уже.
Вот и выросло поколение, никогда не разгребавшее архивы форумов.
Наша молодёжь растлена до глубины души, она никогда не будет похожа на молодёжь былых времён.
Молодое поколение сегодняшнегодня не сможет сохранить нашу культуру.
Ну ты еще с wasm.ru притащи что-нибудь. Рсдн протух к 2008-у наверное, очевидно, там нечего ловить молодым.
1) Не мешало работать кем? На кого ты учишься? Программистам достаточно узнать базовые тезисы и результаты, чтобы потом не пытаться решать задачи, эквивалентные проблеме останова на работе.
Если ты учишься на прикладной или чистой математике, то в чем вообще вопрос? На что поступил, тому и учат, пиздуй теоремы доказывать.
2) Не думаю что кому-то мешало работать незнание ООП, особенно до его популяризации в том или ином виде.
3) Математическая основа нужна для того чтобы можно было формально рассуждать о программах. Программирование в текущем виде скорее похоже на приготовление еды, а не на инженерную деятельность. Я говорю именно о кодировании, а не об архитектуре - разделении системы на библиотеки, сервисы и протоколы, а также о развернтывании и мониторинге всех этих подсистем. В этой сфере деятельности обычно намного меньше вкусовщины и больше объективных критерив плохого и хорошего дизайна.
4) Математическая основа нужна для того чтобы не было вот такой хуйни: http://io.livecode.ch/learn/namin/unsound
Вопрос касается ООП, поэтому спрошу тут.
Допустим, я создаю объект А. Этот объект А инжектится в объект Б в конструкторе. Внутри объекта может создаться объект В, в который объект А тоже инжектится.
Это нормальная практика? Или как лучше?
Допустим, я создаю объект А. Этот объект А инжектится в объект Б в конструкторе. Внутри объекта может создаться объект В, в который объект А тоже инжектится.
Это нормальная практика? Или как лучше?
джвачую, математика нинужна
>Это нормальная практика?
Да, это нормальная и запрещённая в современных языках практика, блджад, ёбаной «работы» под огнём оскорблений и обвинений, когда перед носом у тебя висит морковка, а на шее кредит.
>Или как лучше?
Храни данные в виде дерева, пока не требуется что-нибудь особенное (а оно в 99% и не требуется).
Трудно сказать по описанию, так как непонятно, что это за объекты. Но вообще, выглядит странно. Обычно объекты делятся на 2 вида - "сервисы" и "сущности" и если у тебя "сервисы" то конечно создавать их удобнее где-нибудь снаружи.
Когда речь о зависимостях, можно рассуждать с позиций логики, можно ли использовать тот или иной объект отдельно. Ну например, у нас есть класс Товар и мы хотим сделать в нем метод получитьЦенуВВалюте(валюта). Для этого нам придется инжектировать в каждый Товар объект КонверторВалют. Но логично ли, что для создания Товара нужен этот Конвертор? Не очень. Потому, возможно, лучше отказаться от внедрения Конвертора и от метода получения цены в нестандартной валюте. А сделать такой метод где-то в другом месте: получитьЦенуТовара(товар, валюта).
Деревья подходят в основном для учебных задач на 30 строчек про поиск пути. А там у анона, как я понимаю, реальная задача.
>Но вообще, выглядит странно.
Циклические ссылки между объектами запрещены в дотнете.
В целом, ООП, можно описать как малопригодную поебень, которую распиарили гуманитарии чтобы придать псевдоинтеллектуальную ценность своему рабочему быдлокоду и видимость "архитектуры". Отсюда и столько костылей к нему и книг. Какие бы недостатки у ФП ни были, но ему так и не понадобилось кучу книг и статей по шаблонам проектирования в ФП.
Есть некоторые шаблоны, которые не зависят от парадигмы и есть в них смысл.
Но когда делают костыли (шаблоны проектирования ООП) чтобы ебучая парадигма хоть как-то работала, это должно заставить задуматься.. Но нет, почему-то на кактус приседать веселее.
Долго дерьмо ещё это будет тянутся.. Ох долго. Ещё печально эта гордая плашка в резюме "Понимание ООП". Звучит как, "Понимание натуропатии" или как "Глубокое понимание принципов и основы даосизма как архитектуры бытия"
Блядь, ебали бы в друг другу в жопы и не лезли в программирование, эх.
Есть некоторые шаблоны, которые не зависят от парадигмы и есть в них смысл.
Но когда делают костыли (шаблоны проектирования ООП) чтобы ебучая парадигма хоть как-то работала, это должно заставить задуматься.. Но нет, почему-то на кактус приседать веселее.
Долго дерьмо ещё это будет тянутся.. Ох долго. Ещё печально эта гордая плашка в резюме "Понимание ООП". Звучит как, "Понимание натуропатии" или как "Глубокое понимание принципов и основы даосизма как архитектуры бытия"
Блядь, ебали бы в друг другу в жопы и не лезли в программирование, эх.
>Ещё печально эта гордая плашка в резюме "Понимание ООП".
>печально
>печально
>печально
>Трудно сказать по описанию, так как непонятно, что это за объекты.
Я хуево описал. Вот у меня есть класс. Внутри есть поле со списком и поле с объектом, в который передается этот список в конструкторе. Этот список изменяется в 2-х объектах. Вот это меня смущает.
расписал как боженька
Ты не понимаешь сути. Если угодно, ООП можно представить как теорию проектирования программ. Вот есть, например, классическая музыкальная теория: она описывает определенную модель музыки, вводит категории нот, гармонии, структуру музыки и т.д.
ООП это тоже самое, только для программ.
Зачем нужны такие теории? Очевидно, для упрощения проектирования. Теория сводит множество решений проблемы к какому-то разумному числу упрощенных абстракций, которые можно анализировать, которые являются такими строительными блоками посредством которых достигается решение проблемы.
А ФП это просто си с ограниченными функциями. По сути то же процедурное программирование - менее абстрактная модель.
всё ООП это антипаттерны. Сам класс это нарушение инкапсуляции. Доступ к переменным класса получает кто угодно. Соответственно поведение невозможно гарантировать и протестировать.
Stateless функции - конечный протестированный кубик, поведение которого никто не может изменить
>Доступ к переменным класса получает кто угодно.
есть права доступа, нюфаня
>Вот есть, например, классическая музыкальная теория: она описывает определенную модель музыки, вводит категории нот, гармонии, структуру музыки и т.д.
А есть шкала Пифагора, которую мне будущая гендиректор московского Международного Дома Музыки рассказывала в 5 классе школы, мы сидели за одной партой. Та тетрадка сохранилась, я всё думаю зайти к ней на концерт и взять автограф. Дроби, которые я никак не мог понять, были для неё живыми, они звучали, как музыка... это и была музыка, а не йобанная «теория музыки».
>Зачем нужны такие теории? Очевидно, для упрощения проектирования.
Вот уж воистину, кто не умеет сам и не умеет учить других, тот учит учить учиться.
Есть public-методы, которые вызываются кем угодно, как угодно, и откуда угодно.
>классическая музыкальная теория:
это че за еба? вы там уже музон расписали?
наследовать может кто угодно. И переопределить методы может кто угодно. И модифицировать внутренние переменные тоже может кто угодно
А ты думал! Правда, «Am→C» не объяснили до сих пор...
Вот шкала Пифагора:
https://www.youtube.com/watch?v=nOXWfzJh2vU
Триста, сто и двести колебаний струны в секунду. ЦЫГАНЭ!!!
Успокойтесь, мани, в 9 жабе это уже порешали модулями, что теперь можно указывать права, какой пакет имеет доступ к какому пакету (до сего момента такие правилы только можно было применить на уровне мавеновских проектов).
это ничего не исправляет. Суть в том, что само понятие класса предполагает statefull состояние и произвольный доступ к переменным состояния. Старый протестированный код может сломаться в любой момент, даже если ты его не трогаешь
Код обращается к классу, всё работает. Потом ты подсовываешь потомка этого класса - и оттестированный код ломается
>подсовываешь потомка этого класса - и оттестированный код ломается
подсовывай так чтобы не ломался
лично я вообще отказался от наследования. А без наследования уже нет ООП
Возвращайся, когда выучишь различие между наследованием состояния и наследованием поведения.
ну давай, просвети нас
Щас бы объяснять, как гуглить.
ясн. Очередной школьник решил задавить интеллектом
Но при этом
1) я абсолютно прав насчет твоих кукареков о наследовании
2) не повелся на твои тухлый развод с последующей бесполезной веткой по олимпийскому перебрасыванию какашек
3) давить тут нечего - если интересно, сам разберешься, а ультимативные заявления о бесполезности чего-либо - бессмысленны.
Ну то есть старая песня с RSDN о том, чтобы «наследовать только интерфейсы», так?..
Может, ещё и данные не менять.
О чем Егорка и тылдычит.
>ООП можно представить как теорию проектирования программ
К сожалению, на данный момент нет никакой теории проектирования программ, ни одна парадигма не дает. В принципе, главное - достичь https://en.wikipedia.org/wiki/Loose_coupling, чего можно добиться в любой парадигме.
>Теория сводит множество решений проблемы к какому-то разумному числу упрощенных абстракций, которые можно анализировать, которые являются такими строительными блоками посредством которых достигается решение проблемы.
ОО-паттерны никак не формализированы, их реализации могут сильно отличаться. Так что анализ приходиться проводить каждый раз с нуля. Мутабельное состояние, которое конечно не является обязательным в ОО-программах, но часто это как раз именно то что инкапсулируется в классах (смю последний абзац в ), еще сильнее затрудняет анализ. Мне недавно пришлось написать модуль с большим количеством изменений состояния: я просто ахуевал от того насколько сложно с ним работать по сравнению с трансформациями иммутабельных данных, из которых на 95-100% состоит код других модулей и на 75% этого же.
>А ФП это просто си с ограниченными функциями. По сути то же процедурное программирование - менее абстрактная модель.
Вот это просто полностью меняет суть: эти ограничения дают композабельность элементов и возможность формально о них рассуждать. Эти компоненты, приёмы работы с ними и их приложения можно изучать отдельно с реальных выхлопом в виде пейперов (см. хотя бы https://wiki.haskell.org/Research_papers). Большинство из них могут быть перенесены в любой язык в виде библиотек, хоть в Python, хоть в Scala (для неё это уже сделано и достаточно широко используется).
>Долго эта ебля маняматики, фыпе и меня лично в рот и в жопу ещё будет тянутся.. Ох долго
Опять не выучил? Ах да, это же гуманитарщина. Садись, два, петушок.
И пиздуй борщ мамкин доедать - тут, в мире победившей "гуманитарщины", мнение неграмотной манюни никого не интересует.
> но ему так и не понадобилось кучу книг и статей по шаблонам проектирования в ФП
Потому что никто не пишет на чистой функциональщине ничего длиннее сотни строк?
Потому что цитата - враньё человека имеющего о ФП крайне поверхностное представление.
>Ах да, это же гуманитарщина.
Кто бы пиздел. Сидишь и ошибки в тексте выискиваешь, а не смысл пытаешься осязать.
Интересно, а есть ли яростные сторонники функциональной инженерии, которые пытаются все проектирование своих сортиров, велосипедов и домов свести к теоркату.
У вас там реально корень белены? Это многое объясняет.
В мире FP сортир не нужен, потому что иммутабельное говно не может выйти из иммутабельной жопы. А велосипед не умеет ездить, но там есть репликатор, который создает копию велосипеда и наездника на некотором расстоянии в нужном направлении. Время от времени на дорогу выходят таджики с техникой и с матами грузят все уже ненужные копии в Камаз.
Эх, а ведь пидор, который поднасрал в 4) теперь и C# засирает :(
Что интересно: я вот тоже ненавижу "математику в программировании", все это функтоблядство и прочие опердени.
Но, с другой стороны, мне, как правило, очень интересно ее изучать и применять там, где она реально нужна. А это DSP, machine learning, natural language processing, information retrieval (разработка и эксплуатация всяческих поисковых машин), да куча всего. Все очень интересно, в отличие от тупого функтодрочева.
Но, увы, пока на практике мало что из этого применял, а хотелось бы.
> кококо ООП нинужно!!!
ООП нужно. Паттерны и принципы проектирования, всякие там SOLID/GRASP/DDD и прочее были созданы не просто так и действительно решают проблемы, сопутствующие разработке средних и крупных по размеру проектов.
Но современные "разработчики" отупели к хуям настолько, что найти среди тонн мусора хотя бы одного, который хотя бы отдаленно представляет, что такое "обязанность" и "контрактное программирование" на сегодняшний день нереально. Современный мусор, выращенный js-хайпом, не может ни грамотно распределять обязанности, ни правильно называть сущности, даже представления о layered architecture не имеют и не понимают, что пробрасывать сквозь четыре архитектурных слоя сервисы это хуево. Нет понимания, нет представления, есть только "ыыыы ооп в 2к17 ахахах хлюп смузи хлюп короч я дальше говнокод писать"
Дроч на "функциональное программирование" выгоден галерам вроде той, в которой я работаю, потому что представление о разработке в виде "вижу данные - преобразовываю данные" - это максимум, на что способны современные макаки, да и в принципе отлично ложатся на идею впаривания человекочасов говнокода. Рефакторинг? Не, просто .map и заебись. Больше не надо менеджерам учитывать, что таск может быть переоткрыт или уже разработанный функционал может быть задет на следующей итерации.
Короч, если ты, анон, против ООП, то ты а) не знаешь, что такое ООП б) типичный говнокодер даун
Это плохо?
1) Не всё что ты не понимаешь - тупое дрочерство.
2) Судить о том что реально нужно можно только изучив технологию или подход и области его применимости. Без этого любые слова, не важно поддержи или осуждения - просто пук в лужу.
>Паттерны и принципы проектирования, всякие там 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 и галерах вообще показывает что отношение к ООП ортогонально
а) знаниям самого ООП
б) уровню интеллекта в целом и профпригодности как программиста в частности.
Добавлю, что, по моим наблюдениям, многие говнокодеры предпочитают ФП потому, что оно очень похоже (для них) на процедурное программирование. Неоднократно слышал от таких "зачем целый класс, когда достаточно одной функции", "конфигурацию можно передавать через параметры и использовать частичное применение", и т.п. С правильным именованием там, зачастую, вообще полный пиздец: код пишется согласно принципу "write once, read never" - и спустя полгода даже его автор будет медленно и мучительно разбирать свои каракули (полагая, как и привыкли физмат-интеллигенты советской закалки, перепутанность признаком хорошего, "умного" дизайна).
Хотя вот самый успешный фыпе-дрочерский язык - Scala - активнейшим образом использует ООП. Пожалуй, даже отдает именно ООП-стилю предпочтение.
>против ООП, то ты а) не знаешь, что такое ООП
нормальный человек не должен знать про ООП
всякие там наследования надо учить как особенность компуляторов для уменьшения копирования кода
>Не всё что ты не понимаешь - тупое дрочерство.
А все, кто едят огурцы - умирают.
Каждый инструмент применяется в каком-то контексте.
Если этот контекст - "везде нужно и используется повсеместно", то это не тупое дрочерство, а очень полезная вещь.
Если его контекст - "пишешь никому не нужные обскурные опердени для себя за так", то это тупое дрочерство.
Так что я тебе даже больше скажу - вообще не нужно знать "технологию", чтобы со всей уверенностью сказать, тупое дрочерство это или нет.
(Да, все вроде логично и просто, но тупой фыпе-слесарь вроде тебя до этого не додумается сам, в силу своей ограниченности.)
>2) Судить о том что реально нужно
Свои заявления надо доказывать, долбоеб. Иначе пукаешь в лужу тут только ты.
"Реально нужно" == "облегчает работу, за которую платят деньги", а вовсе не "изучил тяхналахию и сяжу праграмираваю в мамкином подвале такой нитакойкакфсе, обсирая тупых ооп-питухов, заполонивших индусрию".
Кстати, фыпе - не технология, а лишь парадигма, мамин ты невыросший ботаник-кододурачок.
А теперь примени свои критерии дрочерства к своему изучению
>DSP, machine learning, natural language processing, information retrieval
и, например, пхп с джавскриптом и поделись результами. Так мы узнаем какой у тебя IQ - меньше 50 или просто двузначный. Хотя судя по
>тупой фыпе-слесарь
>невыросший ботаник-кододурачок.
>нитакойкакфсе
>я тебе даже больше скажу со всей уверенностью
результат предсказуем.
>предпочитают ФП потому, что оно очень похоже (для них) на процедурное программирование
Да оно не только для них похоже. Это и есть процедурное программирование.
Видел на ютубе выступление дауна, который рассказывал что ФП лучше, потому что для функций проще писать тесты
В процедурном программировании нет контроля за сайд-эффектами и type-driven development.
Теперь есть. Кокие проблемы.
Давай ты сравни востребованность хуяскеля с вот этим
>DSP, machine learning, natural language processing, information retrieval
Я так-то ООП имел в виду, но ты не понял. Тем, что ты перечислил, я лишь эпизодически занимался. Впрочем, все эти области решают совершенно конкретные классы задач, в отличие от хуяскелей.
Покажи, где там в C++ есть контроль за сайд-эффектами.
Ого, ты меня удивил - уклонился от ответа, ведь разговор шел про твои критерии дрочерства. Но и здесь ты обосрался.
Что значит востребованность? Количество вакансий? Вакансии есть с разными требованиями, может и хаскель с NLP быть и Scala с machine learning и information retrieval. В любом случае, таких вакансий очень мало, так что учим срочно пхп с джавскриптом.
Далее, всерьёз сравнивать язык программирования и предметную область может только конченый даун. Предметная область - то о чем ты думаешь, язык - средство выражения мыслей и виде программ. Желательно чтобы программы были корректными и простыми в сопровождении и языки/технологии/парадигмы должны помогать писать их именно такими. Кроме того, часто создание алгоритмов в эти областях и их реализация - обязанности разных людей: специалистов по конкретной области и программистов соответственно. Это /pr, соответственно мы здесь обсуждаем инструменты программистов, не так ли? Если нет, давай обсудим что востребованнее - авионика или джава и сделаем выводы. Оставляю это тебе, ты со всей уверенностью это сможешь сделать.
>DSP, machine learning, natural language processing, information retrieval
>Я так-то ООП имел в виду, но ты не понял
Действительно, как же так. Когда пишут DSP всегда в виду имеют ООП, это же очевидно.
>все эти области решают совершенно конкретные классы задач
Все верно, даже если сюда включить ООП. Но вопрос насколько качественно ООП справляется с решением своей задачи (построении легко поддерживаемых программ) - достаточно дискуссионный. Я, поработав с системами написаными в ООП и ФП, склоняюсь к тому что есть варианты лучше чем как минимум чистая ОО-декомпозиция программ. Хотя может это субъективно, о чем я еще здесь писал:
Вряд ли WhatsApp написан в 100 строк
Галерник, я в отличие от тебя, на них не работаю.
Обсуждать с тобою ООП я готов был бы. Но когда ты заикнулся про процедурное программирование сравнивая ФП, разговор продолжать бесмыссленно. Ты даже не понимаешь что то ООП которое выросло из крестов (а не из смолтолк) куда ближе к процедурному программированию чем даже самая говенная реализация ФП.
Я не из РФ.
Ты сам прекрасно понимаешь что ради долбоёбов на дваче, русский учить - смешно.
Хотя, ты мог быть попробовать хоть чем-то аргументировать, как этот -
Хотя нет, лучше продолжай дрочить на мои ошибки, не пиши такую хуйню.
И ещё, в догонку
Ты же понимаешь
>Паттерны и принципы проектирования, всякие там SOLID/GRASP/DDD и прочее были созданы не просто так и действительно решают проблемы, сопутствующие разработке средних и крупных по размеру проектов.
Что это к парадигме не привязано? Ты вообще читал моё сообщение? Или увидел как твою священную корову опустили и сразу как животное ответил? И ты знаешь что ни наследование, ни композиция тоже к парадигме не привязано?
Чо ж крольчатину не упомянул? Компиляторы на окамле не вспомнил? Ведь компилеры действительно збс писать на функциональщине.
Нормальные строки в Эрланг так и не завезли?
Не слежу просто.
>русский учить - смешно
Хорошая попытка, но нет: ты все же жиденько обкакался, прям в штаники себе надудолил. Ты пишешь не как взрослый дядя из другой страны, а именно как полуграмотный школьник, не выучивший русский. Так что ставлю тебе два, и можешь уебывать подмываться :3
>кококо кресты плаахииие
https://www.whatsapp.com/join/?dept=software-engineering&id=a0I1H00000LBwp2UAD
>Write clean, awesome and bug free Erlang, C or C++ server code
Уважают крестатых, ты смотри! Даже в такой священной корове фыпешников, как вотсапп ООП и мейнстрим весьма востребованы. Смирись, петушок.
Смотри сюда теперь, манюнь. Тебе ж не говорят, что фыпе-инструменты в принципе бесполезны и нигде не могут быть применены. Тебе говорят, что всему свое время и место - всему, кроме упертых фыпе-аутистов, которых нужно слать нахуй при любых раскладах.
О, этот шладкий ООП/ФП срач, ммм.
Большинство ФП-фашистов никогда не писали проекты сложнее laba3.exe, поэтому их завораживает математичность языка. Особенно это соблазнительно, когда есть какая-никакая матподготовка и можно траллить наотмашь успешных похапе-макак на зекаче.
Истина же в том, что внезапно программы читаются и пишутся людьми, а посему гуманитарная составляющая языка программирования намного важнее математической чистоты. Хорошая парадигма - это та, что позволяет максимально эффективно уложить абстракции в сраном обезьяньем мозгу.
Какие-то вещи неплохо выражаются при помощи функциональщины, отдельные - весьма эффективно. Но в целом человеку проще представлять себе некое подобие объектов реального мира (которые, кстати, дохуя стейтфул). Именно поэтому ООП и популярно.
ФП - отличная штука. Но если вы слышите в голосе апологета ФП нотки презрения к "неосиляторам" - знайте: перед вами обычный сноб, не написавший в своей жизни ничего толкового.
Большинство ФП-фашистов никогда не писали проекты сложнее laba3.exe, поэтому их завораживает математичность языка. Особенно это соблазнительно, когда есть какая-никакая матподготовка и можно траллить наотмашь успешных похапе-макак на зекаче.
Истина же в том, что внезапно программы читаются и пишутся людьми, а посему гуманитарная составляющая языка программирования намного важнее математической чистоты. Хорошая парадигма - это та, что позволяет максимально эффективно уложить абстракции в сраном обезьяньем мозгу.
Какие-то вещи неплохо выражаются при помощи функциональщины, отдельные - весьма эффективно. Но в целом человеку проще представлять себе некое подобие объектов реального мира (которые, кстати, дохуя стейтфул). Именно поэтому ООП и популярно.
ФП - отличная штука. Но если вы слышите в голосе апологета ФП нотки презрения к "неосиляторам" - знайте: перед вами обычный сноб, не написавший в своей жизни ничего толкового.
>программы читаются и пишутся людьми, а посему гуманитарная составляющая языка
Всё так. Код для людей.
>Хорошая попытка, но нет:
Удвоил.
>нотки презрения к "неосиляторам" - знайте: перед вами обычный сноб, не написавший в своей жизни ничего толкового.
Крайне универсальное и действительное выражение. Можно упростить до обычных крикунов.
Мне скучно и я решил бампнуть, напоминая ваннаби фп-фашистам, что лямбда вычисление выражается в терминах сигма-калькулуса. Хочется посмотреть на пылающие пердаки.
>Но в целом человеку проще представлять себе некое подобие объектов реального мира (которые, кстати, дохуя стейтфул).
Ну а пруфы ты куда дел? По дороге потерял?
>проще представлять
Кстати, горение проще представлять как истечение флогистона, чем как окисление.
Что-то Егорка больше не делится с нами откровениями. Неужели осознал преимущества функционального программирования?
Ушел в ретрит.
Может, наконец, осилил Smalltalk, осознал всю убогость своего велосипедирования и с горя удавился втихаря уничтожил весь нераспроданный тираж своей графомании.
И это типа илитай из дрейкфейс компани, не какая-то простая байтоебская чернь. Бог байтоебов из геймдева.
В качестве результата оптимизации он предлагает вотэто:
Это все что вам
надо знать про байтоблядей.
Вот, просмотрите полностью и вы поймете что байтоёбов нужно гнать и унижать:
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
Не понял баттхерта, объясни (видео не смотрел).
Им дали полиморфизм времени компиляции и исполнения, вместо этого обезьяны пишут мономорфные процедуры с кастом к void char
@
ЗАТО БЫСТРЕЕ
Зенки-то протри, хуесос.
Тотальное доминирование ООП и тотальный отсос фыпе - лучшее доказательство.
Не понял, кто им дал полиморфизм в си?
CppCon 2014: Mike Acton "Data-Oriented Design and C++"[РАСКРЫТЬ]
>[РАСКРЫТЬ]
Не раскрывается.
Видел это давно. Охуел от еблана. Его там в конце раз шесть обассали.
Смысл в том что этот оратор работает в подразделении Сони, которое разрабатывало для мыловарни анчарч и ластовас. У МОЩНОГО РЕВОЛЮЦИОННОГО ПРОЦЕССОРА (как это утверждалось в 2005 году) Мыловарни 3 на поверку оказалось кастрированное ядро PowerPC G5 с НОУБРАНЧПРЕДИКШН и НОУАВТОПРЕФЕТЧЕМ. У мыловарни 4 с этим чуть получше, но само ядро - энтрилевел для планшетов и нетбуков (потому что им нужно было чтобы в APU видюшка на кристалл чуть помощнее уместилась).
То есть проблема в изначально хуевом, хуево спроектированном железе мыловарен 3 и 4, а не в недостаточном ублажении байтов как этот оратор пиздит.
Мыловарню бы надо бы не использовать, ну или на худой конец сделать порт на отъебись с мылом и текстурами низкоого разрешения, но проблема в том что контора этого оратора, как сказано выше - внутренняя студия Sony и эта самая Соне заставила их делать систем-селлер с грофоном (продажи пс3 в начале были хуевые, потому что выпустили на год позже 360, распиаренная мощь оказалась пшиком, а денег въебали почти 4 ярда).
То есть байторабов заставили делать на говне рекламный продукт с грофоном и байтоебы из своих анальных болей касательно конкретной задачи вывели целую философию по правильному ублажению кеш-линий a.k.a Data-Oriented Development.
Доминирование (где-то) ООП обусловливает некую 'объектность' мышления? Ты понимаешь, насколько это - галиматья. В лучшем случае это можно понимать как обратную индоктринацию. Это - не доказательство.
Чтобы окончить все споры и сомнения, предлагаю найти 2 репозитория очень больших проектов на java и любом ФП-языке (если такие в принципе есть лол, если не найдете можно взять проект на си, почти одно и то-же). И попробовать прочитать код.
ООП это не блажь - в отличие от ФП,- а суровая необходимость для реальных задач, без которой писать программы очень БОЛЬНО.
ООП это не блажь - в отличие от ФП,- а суровая необходимость для реальных задач, без которой писать программы очень БОЛЬНО.
Хочешь, чтобы все играли по твоим правилам?
>ООП это не блажь - в отличие от ФП,- а суровая необходимость для реальных задач, без которой писать программы очень БОЛЬНО.
ООП - это суровая блажь.
Если вам больно писать программы - не пишите их.
ООП - это дизайн, позволяющий писать сложные программы легче, и к которому люди пришли в результате длительного опыта написания программ.
ФП - это академическое баловство, которое никогда не проектировалось для написания системных программ и приложений.
Не понял, зачем велосипедить арифметику поинтеров и вытаскивать переменные из памяти вручную, если struct придумано именно для этого?
В чем тут оптимизация?
>ООП - это дизайн, позволяющий писать сложные программы легче, и к которому люди пришли в результате длительного опыта написания программ.
ООП - это лженаучный культ, для того, чтобы морочить голову корпоративному быдлу.
Еще раз: берешь два больших репозитория: один ООП, другой функциональный /процедурный, и пытаешься разобраться в архитектуре кода.
Ты не поймешь, пока не увидишь на практике большого проекта. Пока твой манямирок ограничен уровнем хелловорлдов ФП кажется проще, логичнее и лучше, да.
Попробуй в другом браузере.
>ООП - это дизайн, позволяющий писать сложные программы легче
Это такая толстота или ты дальше хеллоувордов не заходил?
ООП дает иллюзию контроля и простоты, но как только логика становиться чуть сложнее круда, понять, что происходит в программе в целом становится невозможным.
>, и к которому люди пришли в результате длительного опыта написания программ.
А это вообще пушка. Даже детсадовцы знают, что ООП зафорсенная парадигма.
Любые исходники на языке, который ты хорошо знаешь и в области, в которой ты разбираешься читаемы. Если ты не осилил ФП, то ты конечно же там нихуя не поймешь.
Ебать дурак. ООП - это, грубо говоря, эффективное разделение труда и ответственностей.
Все мы вместе строим дом. Вася делает объекты двери, Петя делает объекты ступеньки, Коля делает объекты оконные рамы, а Антон строит объекты стены.
И всем похуй кто из них что делает, главное чтобы сделанные ими объекты поддерживали определенный ИНТЕРФЕЙС.
Более того, если мы внезапно обнаружим что у Васиных дверей ржавые петли, мы пошлем Васю нахуй с его дверями и попросим кого-то сделать двери соответствующие нашему интерфейсу.
В итоге вася отвечает за все. За доски, за цемент, за аллаха. При этом неправильный цемент для васи может затронуть производство окон
кто последний пронаследовался, того и косяк
Если ты не можешь наладить производство, то виновата методология. Ясно.
Наследование не является идеей ООП. И светоч ООП кстати считает наследование плохим.
классы без наследований? там они вобще ебанулись уже чтоли?
Классы, кстати, ООП тоже не нужны. Вот в javascript нет ни классов, ни наследования.
норкаманчтоле? там все производное от обджект, есть и классы и наследование, но не такое как в сипласплас
По такой логике надо хуячить на указателях. Не можешь наладить код на указателях - вон из профессии
Ну так может вообще убрать глобальные состояния? Чтобы код от них не зависел и соответсвенно один блок кода не мог сломать другой.
Итого мы приходим к stateless функциям и запрету на пкременные класса
Нету там ничего. оператор new создает пустой объект и передает в функцию как this.
prototype это хак для уменьшения дублирования кода: если функции нет в объекте, то она ищется в объекте prototype.
https://www.airpair.com/javascript/posts/how-does-javascript-prototype-work
так чем тебе это не ооп? вызывается метод через экземпляр объекта класса, как это реализовано похуй
Хуясе оопоблядки маневрируют.
Классы не являются идеей ООП. И светоч ООП кстати считает классы плохими.
Смотрите, ребеночек открывает для себя мир, лол.
>философию по правильному ублажению кеш-линий a.k.a Data-Oriented Development.
Извини, но дата-ориентед девелопмент - это не то, что ты описал.
>сборщик мусора - это академическое баловство, которое никогда не проектировалось для написания системных программ и приложений.
>лямбды - это академическое баловство, которое никогда не проектировалось для написания системных программ и приложений.
>lock-free concurrency - это академическое баловство, которое никогда не проектировалось для написания системных программ и приложений.
>динамическая типизация - это академическое баловство, которое никогда не проектировалось для написания системных программ и приложений.
>вывод типов - это академическое баловство, которое никогда не проектировалось для написания системных программ и приложений.
>дженерики - это академическое баловство, которое никогда не проектировалось для написания системных программ и приложений.
Что-то мне подсказывает, что это не тролль, а зеленый студентик, который реально в это верит.
>путать модульность с ооп
Блядь, ну почему я опоздал к самой мякотке, лол.
Как это противоречит моему высказыванию?
сахарный синтаксис для вкатившихся в макакинг джавадаунов
>>философию по правильному ублажению кеш-линий a.k.a Data-Oriented Development.
Data-Oriented Design*. И да, ты это не мне, а тому обмудку из ноти дог расскажи.
Я не смотрел видос, так что не могу ответить ничего содержательного на это, извини.
а еще можно макрос на си написать. си - ООП
Ебать ты манядурачок.
Конечно же, это доказательство - ведь ООП настолько популярно не потому, что оно есть во всех языках, а потому, что с ним проще человеку, чем без него. Вот и все. Оно тупо удобнее.
И фыпе непопулярно по прямо противоположной причине - оно выворачивает мозги наизнанку. Это как разбираться в замороченном шизофреническом говнокоде, только этот говнокод не в конкретных исходниках, а в дизайне самих инструментов.
Я знаю, что ты щас начнешь повизгивать из-под шконки про "правильные, строгие" доказательства и т.п., но мань, ты учти, что они никого не ебут. ООП облегчает решение рабочих задач - значит, будем его использовать, даже если там утверждается, что дважды два - пять. Нажми на кнопку, получишь результат, хули.
>Любые исходники на языке, который ты хорошо знаешь и в области, в которой ты разбираешься читаемы
Что за хуйню ты несешь? Читаемы на уровне "int a[10]; // массив из 10 интов", что ли?
Ты никогда говнокод не видел? Так вот, в фыпе, по словам тех, кто его много лет практиковал и в итоге послал нахуй (на кывте поищи), код вообще очень часто оказывается даже не говнокодом, а write-once-кодом, когда даже сам автор ни бельмеса не понимает в своей писанине полугодовой давности.
>ООП зафорсенная парадигма
Ну так работает же, в отличие от фыпе.
>лженаучный
>корпоративному быдлу
Ниишник закукарекал.
Иди порешай уравнений на ночь, отсоси бате-маняматяку (он это любит наверняка) и ложись спать. А в понедельник снова в родной НИИ задротить.
Ты, аутист, где работаешь-то хоть, и кем?
Как ты можешь не знать про ES6?
Берешь, открываешь в 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();
Охуеваешь от своего открытия.
>с ним проще человеку, чем без него
Разве что формочки клепать. Один шаг вправо, один шаг влево — и...
И все по-прежнему хорошо.
ты дебил, про final, private, protected слышал?
я в очередной раз убедился в тупости противников ООП
И коллекция изменилась во время перечисления.
Так ты не меняй коллекцию во время перечисления.
Ловите этого свидетеля ФП-языков, вот да.
>Как ты можешь не знать про ES6?
А почему, собственно, кто-то должен знать про какой-то ES6?
Даже по этой ссылке выше понятно, что классы в js - это сахарный синтаксис для более удобного создания объектов. Оно просто внешне похоже, а внутри это тот-же самый JS. Ни типов, ни всего остального там нету.
90-ЫЕ: НАСЛЕДОВАНИЕ ПОЛИМОРФИЗМ ИНКАПСУЛЯЦИЯ
@
2000-ЫЕ: КО-КО-КО НАСЛЕДОВАНИЕ ЭТО НЕ НАШЕ
@
2010-ЫЕ: КО-КО-КО КЛАССЫ ЭТО НЕ НАШЕ
Ебанутые сектанты даже признать свой обосрамс нормально не могут.
@
2000-ЫЕ: КО-КО-КО НАСЛЕДОВАНИЕ ЭТО НЕ НАШЕ
@
2010-ЫЕ: КО-КО-КО КЛАССЫ ЭТО НЕ НАШЕ
Ебанутые сектанты даже признать свой обосрамс нормально не могут.
>Ебанутые сектанты
Сектанты как-раз догматично защищали это все. А рациональные люди признают, что какие-то идеи были удачными, а какие-то - как наследование, например - на практике обычно создают проблем больше, чем решают их.
Да нихуя ты никому не должен, остынь, маня.
Мы тут сидим, лениво рофлим над тобой, а ты все за чистую монету принимаешь.
Я в твое фыпе не верю по факту, и хоть ты тут усрись - ничего не поменяется. В этом и рофл, собственно - смотреть, как ты ищешь путь в лабиринте с говном, из которого нет выхода.
>наследование, например - на практике обычно создают проблем больше, чем решают их
Ну если программист криворукий, то конечно же наследование создаёт проблемы. Ну а в ряде случаев наследование помогает по крайней мере для борьбы с коппипастой.
>наследование помогает по крайней мере для борьбы с коппипастой.
Настоящие пряморукие программисты вообще пишут в машинных кодах, кстати. Абстракции - для криворуких макак, Ъ-программистам оно ненужно.
>а еще можно макрос на си написать. си - ООП
Погугли, что такое "сиплюсплюс", братишка. Ебать ты долбоеб.
Если наследование нинужно, то как быть с
> На острове – дуб, на дубе – сундук,. в сундуке – заяц, в зайце – утка, в утке – яйцо,. в яйце – игла, а на ее конце – Кощеева смерть
иерархией типов?
> На острове – дуб, на дубе – сундук,. в сундуке – заяц, в зайце – утка, в утке – яйцо,. в яйце – игла, а на ее конце – Кощеева смерть
иерархией типов?
Всё так и есть что бы было понятнее напишу пример. Вот есть например множество элементов для динамического создания формочек. 90% логики каждого элемента одинаковая. При помощи наследования, эти 90% можно вынести в отдельный класс, а каждый конкретный элемент формы наследовать от этого родительского класса. А иначе пришлось бы каждый раз копировать эти 90%.
> > На острове – дуб, на дубе – сундук,. в сундуке – заяц, в зайце – утка, в утке – яйцо,. в яйце – игла, а на ее конце – Кощеева смерть
Это же композиция, а не наследование. Там же нет острово-дубо-сундуко-зайцо-утко-яйцо-игло-смертомутантов.
> код вообще очень часто оказывается даже не говнокодом, а write-once-кодом, когда даже сам автор ни бельмеса не понимает в своей писанине полугодовой давности.
ФОПЕ ВИНОВАТО АТАТАТА!
Блядь, ты реально такой дебил или прикидываешься?
Затредшотил, ололо.
Открой для себя компоненты DevExpress, где пишут с треугольными скобочками:
Notebook<Page>
Frame<Client>
и т.д.
Это не наследование.
> На острове – дуб
>наследование
Это тред самозашквара адептов истинного ООП из 10 "б"?
Анончик, а ты не забыл ответить на вопросик?
Скорее - читаем жопой. :)
Что еще за DevExpress и что обозначают эти скобочки?
Где там написанном тобой гринтексте ты нашел иерархию типов?
Нет, это ты выдумал за меня. Мне захотелось привести цитату классика из-за спонтанно возникшей аналогии с принципом Барбары Лисков, который чето-то там рассказывает о основополагающем свойстве иерархии.
Да ты сам тупорылый дебил.
В этих проблемах не ООП виновато, и фыпе тоже не позволит их избежать.
Основная проблема фп - это отрицание мутабельности. Отрицание происходящей реальности. Отрицание реальных задач -driven-development. Это как совок, где ты должен был верить в псевдонаучную религию, думать на антинаучной лжелогике (диалектической, которую во всем остальном мире признали хуетой), а что бы послушать лед зеппелин - нужно было тайком у пацанчиков в подворотнях выменивать заветный диск на ящик самогона (как вот монады в хацкеле).
Концепция совка строилась на том что есть якобы есть безусловные эксплуататоры, которые угнетают безусловных пролетариев и вот пролетарии когда их победят заживут. Регулярно, начиная и со становления совка (когда освободившихся пролетариев стали эксплуатировать еще жеще), и с начала ВОВ, когда немецкие пролетарии всячески объединялись, и с перестройки, когда одни пролетарии успешно присваивали себе общенародное достояние.
Правда оказалась в том что реальный мир делится на самом деле на четких пацанчиков и лошар и это нисколько не связано ни с местом в производственных отношениях, ни с наличием/средств производства и прочей хуеты.
Так и программирование. Реальный мир подразумевает наличие какого-то состояния, которое претерпевает изменения. Ну вот как было у тебя в корзинке 20 яблок, ты докинул туда еще одно - и вот тебе 21. Казалось бы, где тут хуйню можно придумать? В функционаломирке конечно же.
У них корзина с яблоками - это такой монолитный неизменяемый объект, в который нельзя просто добавить яблоко, нужно облить бензином и сжечь нахуй корзину с 20 яблоками, обоссать перпелище, затем из лозы сплести новую и положить туда 21 яблоко. А если нужно в дом заселить жильца - то взорвем дом, вырежем нахуй всех жильцов, клонируем днк трупов, выростим новых, и наконец построим дом и заселим жильца. Разумеется место таким фантазиям в реальном мире - в дурдоме.
Кто-то забыл принять таблетки.
Функциональные шизики вроде тебя.
Вот всегда забавляет, как баттхертнутые обосрамсы помечают свой подрыв сажей.
Ведь в замутнении от боли подрыва им невдомёк, что смысл сажи- опустить тред на один ниже, что сажа реально работает по своему назначению только при вайпе и в некротредиках, оторые вакаба не успела отправить в дев/нулл.
И что реальный смысл сажи - это "он унизил меня и мое ЧСВ своими великолепными непробиваемыми аргументами, у меня горит, я хочу чтобы вся эта ветка потонула как можно скорей и он не сможет более меня унижать."
Одинаковую логику вынести в методы, тем самым избежав проблем от наследования
Мутабельность - зависимость логики от внутренних состояний. При этом эти внутренние состояния может менять кто угодно. Тем самым даже протестированный код может сломаться в любой момент. Опять же проблемы с тестированием, верификацией, правкой.
Поправишь ты это состояние, а оказывается на него был завязан воооон тот кусок говнокода.
Думаешь почему гобальные переменные это плохо? Вот именно поэтому. И состояния класса это точно такие же глобальные переменные, от которых надо отказываться
Положил ты в корзину яблоко. А потом вооон тот наследник воооон в том говнокоде втихую поменял количество этих яблок. И ты никак от этого не защитишся
Понимание уровня функционального петушка.
В смысле никак. Ты что, ебанат?
Ты в реальном мире как защищаешься от того, чтобы кто-то клал или не клал в твою ебучую корзину ебучие яблоки. Если ты, Джони, не хочешь, чтобы в твою ебучую корзину клал яблоки, кроме тебя, то запри корзину нахуй. Если ты, Джони, хочешь чтобы после того, как ты положил в нее ебучее яблоко, и ебучих яблок стало 21, чтобы ты, Джони, даже ты, Джони, не смог положить в эту ебучую корзину яблок, то запри ее нахуй и выброси ключи. Если ты просто хочешь знать, кто и когда и сколько кладет ебучих яблок, в твою ебучую корзину, Джони, то следи за ней, нахуй. Стой и наблюдай, или повесь на свою ебучую корзину ебучий колокольчик. И тогда ты точно будешь обо всем знать, ебучий Джони.
Я правильно понял: наследование плохое, потому что ты не умееш в примеси?
>Меня в совке заставляли думать своей головой и не давали слушать музыку дегенератов
>Ррряяяя совок плохо!
Проиграл с этой пидорашки
>уличил кого-то в подрыве
>накатал стену текста
Вот вы тут и те и другие в треде бредите. Это напоминает спор нескольких петровичей на заводе о том, какой станок лучше, фрезеровальный или сверлильный. При этом вы полностью забывает, что оба станка хороши и никакой из этих двух станков не может быть лучше, так как у них совершенно разные задачи. И лучше всего когда в цехе есть оба вида станков, так как они могут взаимодополнять друг-друга.
ващет фрезеровальный легко заменяет сверлильный.
Сверлильный применяют там, где фрезеровальный это оверинжиниринг
Что за хуйню ты несешь?
Ты бы лучше вспомнил бы проблему "хрупких базовых классов", которая может возникнуть и без оголтелого говнокода, как в твоем примере.
Но штука в том, что и это встречается в реальном мире повсеместно: если ты изначально что-то неверно понял, и начал что-то делать, исходя из своего неверного понимания, то тебе в будущем придется это переделывать, ибо работать оно не будет, т.к. в функционирование заложены несуществующие закономерности (а именно это показатель неправильности твоего понимания).
>накатал стену текста
Все верно.
Говорят здесь ООП-бояре, а фыпе-холопам никто слова не давал.
Проблема с наследованием в том, что неправильно понимают его суть. Наследование (расширение) типа используется для дизайна типов, и не повторного использования кода.
Наследование может использовано для дизайна типов фреймворка и иногда без него просто не обойтись, как, например, при дизайне UI-фреймворка. Но код из одного домена не должен расширять классы другого домена.
Грубо говоря, все твои классы должны быть финальными с запретом наследования
а чем тебе утилитные методы не нравятся для повторного использования кода?
Ну приведи пример неправильного использования наследования в каком-нибудь популярном фреймворке.
Так-то дай дураку стеклянный хуй...
>Так-то дай дураку стеклянный хуй...
И что произойдет? Хирургу придется осколки вытаскивать?
>Ну приведи пример неправильного использования наследования в каком-нибудь популярном фреймворке
android SDK
Презираю таких "котов Леопольдов" с их дебильной примирительной позицией, с этими примитивными аналогиями. Каким надо быть кретином, чтобы не ощущать конфликтность проблемы вокруг ООП?
Конкретнее. Название класса из СДК, от чего он наследует/что от него предполагается наследовать юзеру сдк, почему это неправильно.
ООП совместно с функциональным программированием отлично опробовано в таком языке как например скала.
Да и вообще, очень многие ООП языки программирования перенимают различные концепты функционального программирования. В жаве например недавно появились функции map, flat, flatmap, filter, не говоря уже о лямбдах. Рекурсия опять же есть даже в С.
И в чём по-твоему заключается проблема и её конфликтность? Вот прямо парой постов выше пояснили как используется наследование, через иерархию дизайн, если угодно типов.
Миксины, бтв, в отличии от наследуемых классов не обязаны соблюдать принцип Лисков, таща за собой чамодан ненужных зависимостей - в этом их как правило сильная, и редко слабая сторона.
В том-то и дело, что все успешные примеры внедрения ООП - это низкоуровневые конструкции, отдельные "утилитные" функции, и т.п.
В той же Scala программа в целом строится на принципах ООП, а фыпе там отвечает за мелкие гораздо менее существенные детали реализации.
И никогда не понимал, почему нии-аутисты так дрочат на эту рекурсию.
Просто вызываем функцию, которая решает нашу локальную задачу. Зачем выделять случай, когда это та же самая функция?
Любую рекурсию можно заменить циклом, а любой цикл заменить рекурсией. А так как в расово чистых функциональных языках циклов нет, поэтому в этих языках приходится использовать для реализации циклов рекурсию.
Перечитай цепочку постов, на которые отвечаешь.
Ну в си-то ты едва ли циклом рекурсию заменишь, там же оптимизации нужны, иначе тебе тупо стека не хватит (особенно, учитывая, что сишечка не только на десктопах с гигабайтами используется, вообще-то).
Да и делать этого никому нахуй не упало: когда удобнее применить цикл, применяют цикл. Когда рекурсию - рекурсию.
Да и вообще это все экономия на спичках и мелкие детали реализации. Но фыпе-дауны зачастую этого не понимают, ибо ограниченные уж больно.
>циклом рекурсию
наоборот, цикл рекурсией
быстрофикс
Мне всё равно с чем совместили ООП.
>И в чём по-твоему заключается проблема и её конфликтность?
Проблема только в том, что ООП - полная лажа, категорически недопустимо никогда. Исключительно вредная глупость.
Так и запишем: неосилятор порвался.
Записывайте как угодно.
ООП ЭТО ФАШИЗМ!!1
CIS-ФАШИЗМ ДЛЯ ХУЕМРАЗЕЙ
Раньше я считал что Егорка несет какую-то хуиту. Но чем больше я перечитываю его сочинения, тем все больше я с ним соглашаюсь.
Раньше я думал неправильно и до меня просто не доходили его слова. Но чем больше я читаю, тем более правильнее я начинаю думать.
Раньше я думал неправильно и до меня просто не доходили его слова. Но чем больше я читаю, тем более правильнее я начинаю думать.
НОСИЛУЮЮЮТ!!1!1
УДОЛИИИИ!!!!!!!!!!!!!!1!11!!
УДОЛИ Я СКОЗААЛЛ!1!!!
Чем реактивные отличаются от очень быстрых интерактивных?
Шаблонами разве получится полностью заменить интерфейсы?
То, что вне скобок — шаблоны классов.
То, что в скобках — классы или интерфейсы.
Чаще всего:
То, что вне треугольных скобок — шаблон класса, обычно контейнер,
То, что внутри треугольных скобок — класс или интерфейс, передаваемый в качестве параметра.
Например:
Класс PriceListItem состоит из LinkedListItem<ProductPrice>
Класс NotebookFrameWindow состоит из Notebook<DialogPanel>
и т.д.
Обоим читать «Cracking the Coding Interview» (Gayle Laakmann) вне зависимости от того, сторонники вы или противники. А то работу не найдёте либо манагеры вас сожрут.
Тем, что одно существует и в жизни, а другое — в рекламе мАйкрософт.
В целом я с ним согласен. Мне кажется, он пытается все время сказать, что мы должны объекты рассматривать как типы данных и коллекции типов данных.
Например, наши объекты это такие-же данные, как int или float, только более абстрактные. Из этого понимания становится очевидны все принципы ООП. Например, очевидно что объект должен иметь одну ответственность, потому что тип данных, который возвращает разные данные - это плохо, и лучше такой тип разбить на несколько более простых.
Вот что бывает, когда на первом курсе не преподают комплюктер сцайенс (и вообще не преподают).
>Например, наши объекты это такие-же данные, как int или float
2.setValue(3), угу ;)
>Из этого понимания становится очевидны все принципы ООП.
Из этого понимания вырастают иммутабельные структуры данных, настоящая строгая типизация и функциональное программирование. И да, это уже всем давным-давно понятно.
>не отличает структуры данных от самих данных
лол. структуры это всего-лишь один тип данных
> настоящая строгая типизация
> строгая типизация
Не знаешь как по-русски термин переводится пиши по-английски, быдло.
Возвращайся в ньюфаг-тред.
Эх, сейчас бы основывать свои СИЛЬНЫЕ убеждения на абзаце без источников в русской википедии...
Приведи антоним к строгой типизации. Мягкая? Ласковая? Может быть нестрогая? Нет. Это все хуйня. Пара «сильный-слабый» - более близкий вариант с точки зрения построения ассоциативной связи между антонимами weak[ly] и strong[ly].
Это не википедия, это простая логика.
Тебе в /fl, дружище. Тут все-таки доска про разработку софта, а не про стилистику
Какого хуя пост отправился?
Я говорю, что антоним к строгой типизации - хуевая. И все это в любом случае не имеет к содержанию -поста в частности и этого треда вообще.
>Возвращайся в ньюфаг-тред.
Ебать дебил. В ФП тебе дали несколько дефолтных типов данных, с которыми можно трахаться. В ООП ты можешь создать свой абсолютно любой тип данных
В таком случае си это ооп язык
В си только 4(?) встроенных типа данных: указатели, примитивные данные, массивы и структуры.
В си можно объявить свою структуру: но любая структура это всего-лишь структура, у нее интерфейс структуры и все.
Тип данных - это интерфейс через который ты взаимодействуешь с данными.
http://www.yegor256.com/award.html
У вас есть реальный шанс заработать 4k$ на своем репозитории. Все что вам нужно, это уметь в ООП.
У вас есть реальный шанс заработать 4k$ на своем репозитории. Все что вам нужно, это уметь в ООП.
>Хорошая парадигма - это та, что позволяет максимально эффективно уложить абстракции в сраном обезьяньем мозгу.
С точностью до наоборот. Это, как раз, - очень плохая 'парадигма'.
> В ООП ты можешь создать свой абсолютно любой тип данных
Точно так же и в ФП. Более того, помимо экзистенциальных типов, можно пойти дальше и строить алгебры с аксиомами.
Давай мне в ФП тип данных КАЛЕНДАРНАЯ ДАТА
Уточни ожидаемое поведение от типа.
А впрочем, стандартное решение должно подойти
https://hackage.haskell.org/package/time-1.9/docs/Data-Time-Calendar.html
>будем его использовать, даже если там утверждается, что дважды два - пять.
Желаю тебе, чтобы банкоматы всегда тебя обсчитывали. Ты этого достоин.
>Дает ссылку на описание нескольких структур и функций для их изменения.
ЛООООООЛ
Это все равно, что если я напишу адрес на бумажке и скажу что это данные о моем доме.
ФП-дауны такие смешные.
Алё, ты обосрался, потому что пытаешься безнадежно спорить о том, в чём не разбираешься.
Вместо того, чтобы ответить на , предпочел какой-то высер из комбинации гринтекста, капслока и бессмысленного набора слов.
Ты действительно будешь спорить с тем, что в ФП языках общего назначения (хачкил, например), отсутствует поддержка пользовательских типов данных?
-отсутствует
+присутствует
Был так изумлён твоей гнойностью, что написал глупость.
фикс
>отсутствует поддержка структур данных?
поддержка структур и нескольких других встроенных типов - присутствует. Собственные типы с собственной логикой - отсутствуют. Создать свой собственный уникальный тип нельзя. Потому что это уже объекты.
Еще раз. Возвращайся в ньюфаг-тред. Ты такую хуйню несешь, что у меня от тебя испанский стыд. Эта доска для совершеннолетних, кстати.
Пожалуйста, открой ВИКИПЕДИЮ и прочитай, что такое объекты.
Я уже привел пример с адресом на бумажке. Это не данные, потому что мне нужно с этой бумажкой к кому-то обратиться, чтобы эти данные расшифровали и дали другие данные, которые мне нужны. Потом уже с этими данными мне опять нужно к кому-то телепать и клянчить другие данные и т.д.
>ко-ко-ко
Аргументы будут? Может ссылки?
Не корми его. Это или зелёный, или дебил. Но с таким апломбом, что объяснять что - либо - пустая трата времени.
>открой ВИКИПЕДИЮ и прочитай, что такое объекты
Зачем мне твою жидопедию открывать. Я и так прекрасно знаю что там написано. Там написано, что объекты - это данные с прикрепленными процедурами. Это не так.
Так-так, пошли веселые инсайдики.
>этот высер руснявого дегенерата
Ясно. Понятно.
Этот руснявый дегенерат - владелец большой компании в США, всемирно известный автор книг и постов.
А чего добился ты, мальчик?
>владелец большой компании в США
>As a founder and CEO of Zerocracy
>We are not fully ready yet. Please, come back in January 2017 February 2018.
>As an investor at SeedRamp.com, I've made a few investments, but I've got no results yet :)
Лох - это судьба.
Ты прав, зря я это.
Он очень долго, тяжело, нудно, гуманитарно и непонятно рассказывает о том, что ООП - плохо, а ФП - хорошо. Судя по всему, источник мутности в том, что он сам пока не до конца разобрался. У Хикки то же самое объяснено четко, коротко и конкретно, engineer-style. Прочитай его.
>ФП - хорошо
ну может как скриптовый язык для математических алгоритмов он и является хорошим в этой своей узкой специализации - с этим никто не спорит,- но за ее пределами в области системного и прикладного программного обеспечения он является не просто плохим, а просто непригодным.
ты просто сразу говори какие у тебя требования к языку.
>а ФП - хорошо
Где там такое написано?
Нахуй иди.
FS@UR
Почему мутабельность - плохо?
Так бох функциональщиков сказал.
Просто все аргументы, которые я вижу это
>ко-ко-ко thread-safe
Во-первых, это это не так (по крайней для программ, которые делают что-то сложнее сложения двух чисел, т.к. любое IO это race condition, а программы без побочных эффектов интересны разве что гуманитариям).
Во-вторых, отказаться от мутабельности - это как если отрезать себе руку, чтобы не порезать в будущем палец. В то время как синхронизация тредов является простым пластырем для небольшой проблемы.
То есть я хочу сказать, что ты намного больше потеряешь в производительности в полностью иммутабельном языке настолько, что даже однопоточная C++ программа будет быстрее, чем какой-то хаскель насилующий все твои восемь ядер.
Зависит от ситуации же. Где-то удобнее иммутабельное api, где-то нет.
Гармония и баланс во всем, пацаны. Серебреной пули здесь не будет.
>программы без побочных эффектов
Ты где-то такие встречал? Покажи хоть одну.
>любое IO это race condition
Докажи.
>В то время как синхронизация тредов является простым пластырем для небольшой проблемы.
Эрзац для неумеющих в полноценный параллелизм.
>Ты где-то такие встречал?
Я думаю большинство ФП-программ такие. Это просто скрипт принимающий данные на входе и выводящий результат в конце.
>Я думаю
Ну так покажи.
>Это просто скрипт принимающий данные на входе и выводящий результат в конце.
А 'вход' и 'выход' - не побочные эффекты?
>просто скрипт
Что ты имеешь в виду?
>Ну так покажи.
Ну конечно, есть какие-то извращенцы пытающиеся в приложения на ФП. Но это очевидно не целевая аудитория языка.
>А 'вход' и 'выход' - не побочные эффекты?
Просто они не имеют никакого значения для самого алгоритма, и во время выполнения алгоритма побочных эффектов нет.
>Что ты имеешь в виду?
Узкоспециализированный алгоритм для решения конкретной проблемы.
>Ну конечно, есть какие-то извращенцы пытающиеся в приложения на ФП. Но это очевидно не целевая аудитория языка.
Я не понял, как ты этим покзываешь пример программы без побочных эффектов.
>Просто они не имеют никакого значения для самого алгоритма
Как это не имеют? Алгоритм не сработает без входных данных, если они ему нужны.
>во время выполнения алгоритма побочных эффектов нет
'Вход' и 'выход' происходят во время выполнения алгоритма.
>Узкоспециализированный алгоритм для решения конкретной проблемы.
Разве бывают другие?
>>Просто они не имеют никакого значения для самого алгоритма
>Как это не имеют? Алгоритм не сработает без входных данных, если они ему нужны.
Потому что концептуально этому алгоритму все равно откуда поступили данные. Их можно ввести хотя прямо в коде. Ничего не поменяется.
Это просто придирки уровня "а вот у тебя в исходном файле написано - значит программа с побочными эффектами". В конце-концов, может это рассматривать так, что программа - это ОС, запускающая какой-то компонент.
Это просто разные уровни абстракции.
>Разве бывают другие?
Бывают. Вот ты же не пишешь свой браузер каждый раз, когда тебе нужно открыть новую страницу.
>браузер
Так это - специализированный алгоритм, решающий конкретную проблему - отображать страницы. Никакие другие задачи он не решает (например). Как и все другие алгоритмы.
Такой Даннинг-Крюгер, что я хуею просто.
>Их можно ввести хотя прямо в коде.
Тогда, это будет программа без 'входа'. А если нет и 'выхода', тогда это будет программа без побочных эффектов. Так покажи такую, чтобы я и ты увидел, кто и для чего пишет такие программы. Твой пример с 'просто скриптом' такой программой не является.
>программа - это ОС, запускающая какой-то компонент.
Это я не понял.
Конкретизируй, где именно.
Я имел ввиду, что для работы алгоритма не нужны побочные эффекты. notepad.exe например тоже не нужны побочные эффекты. А вот браузер в принципе не может работать без побочных эффектов.
>Это я не понял
Это к тому, где начинается твоя программа и кончается другая. Загрузка программы и ее состояния в память это тоже "побочный эффект", создание переменной в памяти это "побочный эффект". Все побочный эффект, даже небо, даже аллах.
Самое понятие программы это просто абстракция. Может, моя программа начинается аккуратно после чтения из файла и кончается ровно перед записью на диск.
>notepad.exe например тоже не нужны побочные эффекты
>Загрузка программы и ее состояния в память это тоже "побочный эффект", создание переменной в памяти это "побочный эффект". Все побочный эффект, даже небо, даже аллах.
Ты уверен, что правильно понимаешь, что такое побочные эффекты?
>Может, моя программа начинается аккуратно после чтения из файла и кончается ровно перед записью на диск.
Твоя программа - это то, что напрограммировал именно ТЫ. Как информация из файла попадёт в твою программу или из программы на диск, минуя побочные эффекты?
Побочные эффекты - это изменение состояния в области видимости алгоритма.
Поэтому побочные эффекты не касающиеся алгоритма не имеют никакого значения для алгоритма.
>Твоя программа - это то, что напрограммировал именно ТЫ.
Окей, я сделал виртуальную машину, которая за меня загружает файл в память и в конце автоматически записыват значение памяти на диск. В своей программе я ничего это не пишу. Побочных эффектов - нет!
Почему глобальные переменные это плохо?
>состояния в области видимости алгоритма
Что это вообще такое?
>Никакие другие задачи он не решает
Oh boy, i wish no one here were so ignorant like you.
Он не очень удачно выразился, но имеет ввиду суть чистых функций.
Что? В каком смысле здесь понимаются чистые фукнкции?
Если ты хочешь что-то оспорить, выражайся конкретнее.
Вот например, в java аргументы командной строки передаются как список строк.
Можно в ФП некий файл передевать как аргументы main функции, а результат этой функции записывать в какой-то файл. Тогда получится такая красивая аналогия, что программа - это функция!
Можно так даже написать функциональную ОС.
Но ведь ФП является частным CP случаем теоремы Брюера , а значит не может идеально подходить для всех видов распределенных вычислений, нет? Зачем писать очередную говноОС?
>Но ведь ФП является частным CP случаем теоремы Брюера
Почему это?
Так я тебя спрашиваю‽
Меня? Я этого не утверждал.
>Окей, я сделал виртуальную машину, которая за меня загружает файл в память и в конце автоматически записыват значение памяти на диск. В своей программе я ничего это не пишу. Побочных эффектов - нет!
Да. Виртуальная машина роизводит побочные эффекты, твоя программа - нет. Что из этого?
Вот пример риального хацкель-кода (чтение и отрисовка кваковской карты в формате bsp). Я вот когда только открывал - думал, все же BSP это чисто математическая хуета еще и с деревьями - должно же быть все на чистых функциях. А вот хуй - IO()IO()IO()IO()IO()IO()IO()IO()IO().
И в этом все ваше функциональное программирование.
https://github.com/rainbyte/frag/blob/master/src/BSP.hs
И в этом все ваше функциональное программирование.
https://github.com/rainbyte/frag/blob/master/src/BSP.hs
> Какой-то дебик переписал кусок idtech3 c сей на хаскелл буква в букву.
> КОКОКО ФП ГОВНОКОКОКУДАХХХ.
Алё, там все монадами прикрыто - функции чистые. По сути, семантика аналогична той шизофазии насчет ВМ, что упоминалась выше.
К слову. В чистом ФП нет понятия чистая функция. И монады тут не при чём.
Почему goto - плохо?
потому создают много зависимостей.
goto не плохо, оно просто устарело и стало не нужно.
как это связано с мутабельностью?
>потому создают много зависимостей.
точно также и мутабельность (зависимость от внутренних состояний)
>В чистом ФП
>чистая функция
>помножил на 0
Ну, тебя никто за язык не тянул. Что ты имел в виду?
>Что ты имел в виду?
Я же написал. У тебя есть возражения?
Ооокай. Что такое "чистое ФП", в твоём понимании?
Аппликативная семантика вычислений (Λ или CL).
Ты хотел сказать стратегия вычислений (call-by-reference)?
Нет. Вся целиком система подстановочного переписывания термов.
>как это связано с мутабельностью?
>оно просто устарело и стало не нужно
>РРРРРРРРРРЯЯЯЯЯ!11!!!
Ниишник, не рвись ты так.
Следуя моей логике, банкомат будет мне выдавать правильно, полагая ради этого, что 2*2=5.
Или выдавать неправильно, но больше, чем нужно.
Ты ведь школотрон, да?
мимо
Продолжаю зоонаблюдения.
Из подвала мамкиного пробздеться выходи хоть иногда, и сразу начнешь понимать, о чем это я.
Поясните, что такое примеси и есть ли оное явление в Цпп.
> что такое примеси
https://en.wikipedia.org/wiki/Mixin
> явление в Цпп
Открываем русскую википедию и читаем:
> не стали реализовывать примеси в Си++ на уровне языка
, читаем до-конца:
> ... примеси могут легко эмулироваться ...
>Он очень долго, тяжело, нудно, гуманитарно и непонятно рассказывает о том, что ООП - плохо, а ФП - хорошо.
Поддвачну этого. Иногда Егорка пишет что-то дельное, а иногда несет такую хуиту, что уши вянут. Он топит за иммутабельность объектов, отсутствие поведений у объектов. Он хочет делать цепочки создания объектов как цепочки вызовов функций в ФП, по сути заменив функции объектами.
Короче, у него какая-то каша в голове и смешение парадигм. Та хуита, которую он пишет не является никаким ООП.
Ему бы понравился язык F#
НЕИЗМЕНЯЕМЫЙ ОБЪЕКТ это просто пиздец какой-то все равно что КВАДРАТНЫЙ КРУГ
Надо же придумать такую хуиту. ФП и ООП не совместимы, кто считает иначе - конченый даун. inb4: мультипарадигменное говнецо в которое поднапрягя пердак смогли засунуть и то и это и оно теперь как-то кое-как работает еле-еле.
Надо же придумать такую хуиту. ФП и ООП не совместимы, кто считает иначе - конченый даун. inb4: мультипарадигменное говнецо в которое поднапрягя пердак смогли засунуть и то и это и оно теперь как-то кое-как работает еле-еле.
Понимаешь дружок, для людей просвященных, твоё заявление сродни утверждению, что 2*2 /= 4 в кольце целых чисел.
пук
Лол, даже пукнуть не умеешь.
Ну, неизменяемый объект - это и вправду оксюморон. А фп и ооп отлично сочетаются (если ты не пурист, конечно), ибо ооп хорошо подходит для реализации низкоуровневых абстракций. Как ассемблер ооп гуд. Проблемы начинаются, когда чередной развесивший уши на радость маркетологам нуб начинает МОДЕЛИРОВАТЬ ПРЕДМЕТНУЮ ОБЛАСТЬ иерархиями классов и объектами. Это - все, клиника, гроб-пизда-кладбище-пидор.
>Ну, неизменяемый объект - это и вправду оксюморон.
Сейчас бы оксюмороном все примитивы-объекты называть.
В конце концов кто-нибудь объяснит, что понимается под объектом в ООП, и почему ООП-щики прицепились к этому слову?
суть ООП вообще ни в каких не объектах и языках программирования. это методика дизайна программ, при которой проблема решается в понятных любому метафорах реальных объектов, как если ты инженер и решаешь реальную проблему с помощью реальных объектов: кирпичей, досок, наемных рабочих.
суть ООП в том, чтобы перестать думать как компьютер.
а писать программу ты можешь хоть на си, это не имеет значения.
иммутабельность, наследование, полиморфизм и т.д. никакого отношения к ООП не имеет - потому что категории компьютера, от которых ООП в принципе абстрагируется.
> наследование помогает по крайней мере для борьбы с коппипастой
Сука, ты ёбнутая, ты про композицию когда-нибудь слышал?
Вот такие умники посоздают по 100500 классов тебе в моделе, да так, что потом вообще самый минимальный рефакторинг будет требовать от тебя создания ещё больше классов богу классов, иначё всё сломается нахуй.
https://en.wikipedia.org/wiki/Composition_over_inheritance
>проблема решается в понятных любому метафорах реальных объектов
Почему именно так? Почему это - метафора? Почему это понятно любому?
>реальных объектов: кирпичей, досок, наемных рабочих
Почему это - объекты? Да ещё и реальные?
Ты сначала научись писать грамотно, лоботряс.
А потом уже своих задротов слушай.
>понимаешь дружок
>для людей просвЯщенных, твоё заявление
Чтобы понять, почему так - нужно разобраться в истории возникновения языков программирования. Например, большое влияние оказали книжки реального архитектора, которые в свое время были очень популярными у погромистов https://en.wikipedia.org/wiki/Christopher_Alexander#Computer_science
Это все есть в книге object thinking, которую Егорка пиарит. Советую ее прочитать хотя бы из любопытства.
Мои грамматические ошибки твою глупость никак не отменяют.
Это какой-то вид argumentum ad antiquitatem? Что угодно можно "объяснить" исторической обусловленностью. Я спрашивал о смысле.
А с остальными вопросами что?
нормально ли, что свойства объектов могут внезапно поменяться?
Например кирпич ВНЕЗАПНО станет мягким, доска ВНЕЗАПНО станет твёрдой, наёмные рабочие внезапно станут статуями.
Не сломается ли что-нибудь от этого? Должно ли окружение вокруг проверять такие изменения каждый раз?
В js есть только объекты. Больше ничего.
Есть еще примитивы, но их можно тоже рассматривать в качестве синглтон объектов, потому как они боксятся, а сделаны разумеется для производительности. (тем более что сейчас ничего не мешает у примитивных добавить в цепочку прототипов прокси объект, отлавливащий сообщения, типа присваивания, и реалиховать поведение прототипов как полноценных объектов, но это ни к чему. проще воспринимать их как синглтоны. когда надо, любой примитив можно обернуть в полноценный независимый объект).
Так. Короче только объекты.
Все объекты делятся на callable и non-callable. Callable это функции, в понимании большинства. Но по факту это все те же объекты, со всеми свойствами что и у других.
Все объекты могут принимать всего несколько типов сообщений - get, set и call. При чем call может принимать только callable объект. при попытке послать call сообщение не-callable объекту будет исключение.
Сообщение get содержит один параметр, сообщение set два. Сообщение call параметром содержит кортеж аргументов, а так контекст this.
Если в объекте (а так же в цепочке прототипов) не назначены слушатели для get и set с определенными параметрами, ищутся слоты с такими именами в объекте и по цепочке. Если находится возвращается то, что в них лежит. Если в них лежит callable объект и ему посылают сообщние call сразу как получили его из слота, то у него будет перегружен контекст (this) на объект из чьего слота его получили. Если только этот объект не был сконструирован стрелочным синтаксисом, иначе контекст перегрузить нельзя. Если после получение callable объекта из слота его сразу не вызвать, а например положить ссылку на него в переменную, то контекст будет сброшен на тот, который был установлен у него в момент его создания (и это не обязательно будет тот же объект из чьего слота его получили).
У callable объектов есть scope (область видимости) и контекст (this) в момент посылки им сообщения call (вызова). scope средствами языка перегрузить нельзя, но некоторые окружения позволяют (например в ноде есть модеуль vm), this перегружается у callable объектов сконструированных не-стрелочным синтаксисом
Классов нет. Есть конструкторы. Любой конструктор принимает новый созданный объект, которому выставлен определенный прототип (другой объект). Оператор instanceof (someObject instanceof SomeClassName) проверяет лишь есть ли в цепочке прототипов у someObject объект который лежит у SomeClassConstructor в слоте с именем prototype. На сам конструктор ему поебать. Чтобы сменить класс, достаточно сменить цепочку прототипов. Даже если объект был сконструированным определенным конструктором.
Так же у объектов есть параметр ограничения доступа, контролирующие его расширяемость или изменяемость (sealed, extensible, frozen). У слотов объекта есть параметры configurable, enumerable, writable. Параметры слотов объекта не влияют на объекты, что в них лежат. Они лишь контролируют доступ к самим слотам.
Все. Никаких классов. Никаких интерфейсов. Как отдельных сущностей. По факту все есть объект и все строит из них.
наследование реализуется выстраиванием цепочки прототипов. Инкапсуляция только на уровне scope'в (читай замыканий).
В остальном все меняется и все динамично, если только специально все не зафризить в момент конструирования. Но обычно этим никто не заморачивается по причине оверхеда и бессмысленности. Разве только фанатики по иммутабельности, н это все из разряда те, кому надо чтобы им по рукам бил компилятор\рантайм\дядя петя. Все "привычные" понятия тянуться в язык для еще более простого вкатывания тех, кто приходит из других языков. Так уж сложилось, что есть куча литературы по привычному, статически классовому ООП, но очень мало по мессадж-пассинг\прототайп-базед\мета-программинг. Все эти притянутые понятия выливают в синтаксический сахар, который не делает ничего полезного, а даже наоборот, еще больше вносит путаницы и от того непонимамания многих вещей в языке. При этом часто этот синтаксический сахар дэже урезан и вспомнинают об этом лишь после (как например проебались с полями в конструкции class и тянут ее теперь только в proposol'ах будущих версий).
JS истинно объектный язык. В современный язык притащили много вкусных вещей для метапрограммирования. Нову примитивную сущность Symbol, и Proxy-объекты. С помощью которых можно еще больше и сильнее перегружать и менять поведение в динамике.
Другое дело, что почти никто не умеет этим пользоваться и не понимает, что такое объектное программирование на самом деле.
Им нужно не объектное, а статически типизированное. А какие именно структуры будут скрываться за этими типами, не собо важно. Важно что это просто структуры и функции, строго привязанные к ним, или иногда менее строго. То, что в Java\C++ это больше структурное программирование, нежели объектное. Объектное программирование не может существовать без динамической среды. Это противоречит самому понятию объекта. А динамическое программирование это слишком сложна и непанятна. И как бы не старались с пеной у рта фанатики кричать про низкий порог входа - низкий он именно что для входа, а не для всего остального. Модификация программ в рантайме всегда было уделом креативно мыслящих людей. Для большинства это слишком сложный уровень высокой абстракции.
>prototype это хак
Это не хак. Это основополагающий принцип Объектной системы. И не только в JS.
Прототипы намного мощней Классовой концепции.
Для вещей, которые не могут просто так взять и поменяться, существует инкапсуляция. А если они могут все таки быть изменены при определенных обстоятельствах, такие изменения диспетчеризируют.
Сломается все если изначально все ыбыло спроектировано так, чтобы это могло сломать, и крипчи внезано мог стать мягким или невидимым, и поменять свойства так, как не предусмотрено системой.
При этом нет ничего страшного, чтобы кирпич например поменял цвет, это вполне естественный процесс и свойство кирпича.
В том или ином виде, если ты позволяешь что-либо менять, ты будешь это предусматривать в любом языке и с любым подходом. В том числе и ФП. Только там ты будешь каждый раз пилить новый кирпич другого цвета.
Вот это - как раз тот клинический случай, про который я говорил в . Тут медицина бессильна, это все, конец.
>Как ассемблер ооп гуд
Штооу?
>А фп и ооп отлично сочетаются
каким образом?
Я написал, каким образом. Перечитай пост еще раз.
>Объектное программирование не может существовать без динамической среды.
Спасибо за пасту хотя я немного пьян, чтобы вычитывать её целиком. Выцепил это утверждение, так как кажется необоснованным. В любом случае, объектность и типизированность скорее ортогональные понятия.
Можешь примеры привести?
>Я написал, каким образом
Невидимым шрифтом?
Быдлокодер, у тебя неправильное восприятие действительности.
Ты попросту тупой, поэтому и делаешь свои дурацкие ошибки (орфографические и пунктуационные. Грамматических у тебя нет, ты даже в этом месте обосрался).
И по той же самой причине ты, полиграф полиграфыч, не понимаешь, о чем я тебе толкую.
>пук
>Ты попросту тупой, поэтому и делаешь свои дурацкие ошибки (орфографические и пунктуационные. Грамматических у тебя нет, ты даже в этом месте обосрался).
А так скобки можно расставлять?
Уроки делай.
>пук
>пук
что конкретно тебе не нравится в таком подходе? по моему это простой и очеввидный способ, который все ооп программисты так или иначе интуитивно используют.
проблема в том, что им не хватает дисциплины, и они в большинстве научены думать как компьютеры и в категориях компьютера и языка программирования,
Ну спроси в понедельник у учительницы.
Не перди в гринтексте, быдлокодер. А то приучишься, и так и будешь на людях пердеть.
Так это ты пердишь, недогадливый. Вместо содержательных высказываний даешь уроки языкознания, что конечно хорошо, но к делу совершенно не относится.
2.setValue(3);
коза.ебись(Онегин);
и что? ты хочешь сказать, что не взаимодействуешь с объектами в реальном мире?
Нет конечно.
«Субъект» и «объект» понятия философские.
И уж точно я не собираюсь писать код в реальном мире, я на такие вакансии не откликаюсь даже.
Нет, это ты зачем-то пердишь, при этом убеждая себя в том, что это я пержу, а не ты.
Я намекаю, что тебе нужно перестать быть ограниченным дурачком, и тогда ты сразу поймешь, что я имею в виду.
>я на такие вакансии не откликаюсь даже
тебе такие вакансии никто и не предложит.
суть в ОО в архитектуре программ. даже твоя мамаша сможет сделать архитектуру ОО программы, ничего не зная о компьютерах. даже чем меньше она знает, чем меньше она испорчена, тем лучше.
вот представь, что тебе нужно сделать todo list, но не на языке программирования, а из физических объектов. как ты его сделаешь?
у тебя есть ручка, бумага и неограниченное число людей. нужно сделать систему списка задач, так, чтобы пользователь сообщал свои задачи и сообщал выполнены ли они.
делай.
>сделать todo list ... из физических объектов.
Это невозможно.
Забавно на самом деле наблюдать, что в профессии, в которой абстрактное мышление первостепенно, бесконечное множество персонажей его не имеет чуть менее, чем полностью.
Мы вам перезвоним.
Лучше не надо.
А придется.
>бесконечное множество персонажей
Являются обычными наследственными дебилами.
Ну и что?
Если бы абстрактное мышление было охуенно нужно и ООП не придумали — то до сих пор все жили бы без софта.
>абстрактное мышление
Уточнил бы, что ты имеешь в виду.
Дебилам вроде тебя не понять.
>что конкретно тебе не нравится в таком подходе?
Только тот факт, что он не работает.
Ну так слесари же. Это даже гуманитарным стилем мышления не назовешь (после какого-нибудь философского как раз такой идиотской каши в голове не будет), это именно слесари. В плохом смысле этого слова.
То есть, инженегры.
Вон из профессии!
Если ты не можешь сделать программу, то ты не программист. Ты секретарь, который знает орфографию и где ставить запятые, но который пишет под диктовку. Ты - не программист.
Программа - есть программа. Не имеет значения для какой-то системы она разрабатывается.
>секретарь, который знает орфографию и где ставить запятые
Все бомбите, полиграф полиграфыч?
Есть тут один... У него не только умение абстрагироваться хромает, он еще и неграмотный.
Я бы держался подальше от профессии, где "делают" todo list из "физических объектов".
>Программа - есть программа.
Вот это да! Правда что ли?
>Я бы держался подальше от профессии, где "делают" todo list из "физических объектов".
Просто ты тупой и не понимаешь абстракции.
Ладно, тогда так. Представь что ты программист в 19 веке. К тебе обратился заказчик, который хочет сделать сервис напоминаний: клиенты бы приходили в офис, оставляли список дел, и им бы на почту приходили напоминания о делах за день.
Составь программу такого сервиса.
что мешает сделать ежедневник?
>не понимаешь абстракции
При чём тут абстракции? Какие абстракции ты имеешь в виду?
>Составь программу такого сервиса.
Ты к чему это всё?
>Просто ты тупой и не понимаешь абстракции.
Просто ты тупой и не отличаешь абстракции от (хуевых) аналогий. Потому что ты слесарь.
Нет, это другое.
>Нет, это другое.
А в чём разница?
Инженер - хорошо, слесарь - плохо.
>что мешает сделать ежедневник
что мешает писать все в notepad.exe, вместо использования веб-сайтов?
>Ты к чему это всё?
К тому, что это проблемы которые решают программисты. Этому должны учить программистов, а не как сортировать массивы на питоне. Последнее это работа секретарей.
У нас учат быть секретарями, а не программистами.
>У нас
Хуево там у вас.
Ты понимаешь, что музыкант это как и скрипач так и композитор?
Вот так же и ты путаешься в понятия. И макака-кодер, и программный инженер и даже архитектор ПО - это всё программисты.
IT-писарь закукарекал.
Да, прекращай уже.
По ходу изобретатели ООП изобрели вот что...
Конечно, программист должен знать свою предметную область. Проблема в том, что Васян, научившийся лабать на гитаре, конечно может написать музыку, но делать он это будет несистематически и по наитию, изобретая велосипеды, наступая на грабли и с кучей говнонот в процессе.
В результате получится какая-нибудь хуита, а винит Васян будет музыкальную теорию. Придумали, там, понимаешь, какие-то лады и гармонии. Вот 3 аккорда - все что нужно знать музыканту!
Ну так ООП-слесарям весь тред про это говорят, но они не слушают и продолжают нести хуйню про деланье туду-листа из физических объектов.
>что мешает писать все в notepad.exe, вместо использования веб-сайтов?
>в 19 веке
Даун даже за нитью разговора не может уследить.
>Васян, научившийся лабать на гитаре
Выебет твою еот и набьет тебе ебало.
Неоднократно.
/дискасс
Так ведь слесарь это ты, если не можешь сделать todo list из физических объектов. Потому что не можешь отвлечься от своих труб и ключей.
Я тебе про то, что музыкантом является как и Васян играющий на гитаре, таки композитор сочиняющий симфонии. А ты не правильно оперируешь понятиями, деля программистов, на каких-то не программистов. Есть большая сфера IT, в ней есть подсфера разработка и создание программного обеспечения - читай программирование, и все кто относятся к сфере программирования - программисты. И не важно, инженерят ли они и проектируют архитектуры ПО, или пишут скрипты для автоматизации. Это все - программирование.
Если ты хочешь кого-то обособить, то используй устоявшиеся названия их сфер деятельности, а не "это не программисты, а секретари".
>музыкантом является как и Васян играющий на гитаре, таки композитор сочиняющий симфонии.
Не обязательно. Можно быть хорошим композитором и плохим музыкантом, и наоборот.
Можно быть замечательным IT-секретарем и мастерски сортировать деревья, но не уметь писать программы.
>Так ведь слесарь это ты,
>если не можешь сделать todo list из физических объектов.
Просто вчитайся в этот текст и подумай головой.
>Можно быть хорошим композитором и плохим музыкантом
Нет, нельзя, дебил. Ты путаешь понятия "музыкант" и "исполнитель".
Куда вчитаться-то? Я уже понял, что ты не очень умный и не понимаешь метафоры, поэтому я привел тебе более понятный пример
>>Просто вчитайся в этот текст и подумай головой.
>Куда вчитаться-то?
Ээ...
>даже твоя мамаша сможет сделать архитектуру ОО программы
Когда "мамаши" с подобным манямирком без около-CS образования/самообразования вкатываются и пытаются писать программы, получается вот так - https://www.youtube.com/watch?v=cDA3_5982h8
Тебе уже сверху написали, что не нужно складывать в одну кучу абстракции и хуевые метафоры.
Крайней степени маня-ОО можно достигнуть только тогда, когда появится настоящий ИИ, который будет думать как человек. Только в этом случае можно будет перестать "думать как машина".
На сегодняшний день ты вынужден писать текст, понятный одновременно и машине, и человеку. Машина ничего не знает об объектах. Хуевые метафоры не имеют ничего общего ни с ОО, ни с ФП.
Лол, спасибо за видос. мимо
>На сегодняшний день ты вынужден писать текст
Текст понятный компьютеру пишут секретари - чернорабочие слесари, которых научили делать одно единственное дело.
>Хуевые метафоры не имеют ничего общего ни с ОО, ни с ФП.
Вот тлолько в ФП их нет (никаких нет), а в ООП - на каждом шагу (одна метафора охфигительней другой).
Прикольно. Но не понятно.
так на ФП и программ нет
>Крайней степени маня-ОО можно достигнуть только тогда, когда появится настоящий ИИ
Лол, затредшотил очередного ООП-шизика.
Сказочные долбоебы, феерические.
поэтому и придумали оо языки, чтобы программы больше походили на то, как мы думаем и как решаем проблемы.
вот только долбоеб придумавший с++ просрал все полимеры, извратив идею оо в то, как ее понимают сейчас
>как мы думаем и как решаем проблемы.
Ты на всех-то не проецируй.
>поэтому и придумали оо языки, чтобы программы больше походили на то, как мы думаем и как решаем проблемы.
ОО языки придумали не для этого. Собственно, цитата от мужика, который придумал сам термин:
>OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.
В таком контексте ООП уже немногим отличается от ФП, поэтому суть твоей позиции я не улавливаю.
>Крайней степени маня-ОО можно достигнуть только тогда, когда появится настоящий ИИ, который будет думать как человек. Только в этом случае можно будет перестать "думать как машина".
Поясняю подробнее. Крайняя степень маня-ОО подразумевает под собой ситуацию, где ты говоришь ИИ "сделай туду лист". Спустя n неудачных итераций ты получаешь свой туду лист и просишь ИИ поиграть со шрифтами.
ФП вс ООП
Вы вернули мне мой 2012
Вы вернули мне мой 2012
>ООП уже немногим отличается от ФП
Оу. Я так и не дождался когда мне расскажут как их умудряются совмещать, а тред берет все новые высоты ебанизма. Теперь это оказывается вообще одно и тоже. Никаких разъяснений конечно не будет, а в голову к этому шизику не заглянешь. А жаль, там наверняка еще тот Омск творится, типа как в фильме Клетка.
> Я так и не дождался когда мне расскажут как их умудряются совмещать
1) Максимальный отказ от наследования, вместо него - композиция
2) Максимальный отказ от переменных класса, по максимуму stateless методы
> вообще одно и тоже
Я не так написал.
>OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things
Если взглянуть на Haskell с его main -> IO, то окажется что это ничто иное как extreme late-binding, где основной пайплайн максимально защищен (protection) путем удержания (retention) сайд-эффектов в монадах (state-process), которые получают сообщения (messaging) и возвращают результат. Весь ваш срач строится на неточностях формулировок и деталях имплементации.
/pr на острие индустрии же.
Во дебил, про смолток он походу вообще не слышал. Перечитай пост, на который отвечаешь, тебе же там все процитировали, дебил.
Все-таки он под лейт-биндингом имел в виду максимальную динамичность дев-енвайренмента, лисп-стайл. Х-ль в этом плане (по понятным причинам) от си не слишком далеко ушел.
Блять, вы тут всерьез строчите десятки сообщений в день?
Хуяскель, лишп, серьезно?
Вы свой задротский 20хх возвращаете?
Вроде вопрос закрыт тыщу лет уже.
http://flyingfrogblog.blogspot.ru/2016/05/disadvantages-of-purely-functional.html
Хуяскель, лишп, серьезно?
Вы свой задротский 20хх возвращаете?
Вроде вопрос закрыт тыщу лет уже.
http://flyingfrogblog.blogspot.ru/2016/05/disadvantages-of-purely-functional.html
>Максимальный отказ от переменных класса, по максимуму stateless методы
Что блядь значит "максимальный"? Полная иммутабельность? Это тогда значит полностью отказ от ООП. Или у тебя тоже НЕИЗМЕНЯЕМЫЕ ОБЪЕКТЫ? Короче прежде чем в тред подпердывать попробуй голову из жопы вынуть может чего годное родишь.
>Если взглянуть на .. то окажется
Только в твоем больном воображении. Хуиту какую-то написал. Но на всякий случай замечу что писать весь код в IO монаде - дурной тон, и вобщем то так никто не делает, если только под сильным наркотиками.
Хуй соси, чмо.
Зачем ты это говно притащил? Совсем дебил? Тред про ООП.
Хуиту какую-то написал.
>писать весь код в IO монаде - дурной тон, и вобщем то так никто не делает, если только под сильным наркотиками.
Что значит "весь код"? Конечным результатом работы программы является эффект, OUT.
У тебя галлюцинации.
1. Максимально возможный, очевидно же.
2. Он все правильно написал, но ты не шаришь, поэтому тебе это кажется "хуитой".
мимо
> purely
Значение знаешь?
>Значение знаешь?
Хуй соси, даун.
Ну и пиши тогда на ассемблере
Нет просто я шарю и он на самом деле написал хуиту.
При чем тут ассемблер? Ты вообще не понимаешь, о чем говоришь.
И нет, ты не шаришь, а в постах того анона нет ошибок.
Кроме того, по странному стечению обстоятельств получается так, что ты, например, и по-русски пишешь ужасно неграмотно, с трудом выражаешь свои мысли. Вообще, в этом треде нетрудно проследить зависимость между мелкобуквенностью, неграмотностью и битардностью с одной стороны, и фанатичной верой в ШВИТОЙ ООП - с другой.
Ну это так, это я не тебе, а просто мысли вслух.
У него большая часть аргументов сводится к производительности. В 2018 году, когда время разработчика настолько дорогое, что взлетают технологии уровня Electron - апелляция к производительности становится совсем неактуальной. Плюс, выше уже заметили про >purely.
Никто, грубо говоря, O(nlogn) на O(n3) менять не будет, это и в сто раз более мощный проц не вытянет, так что мимо.
Это не просадки в производительности, как у Рубей с Питонами, это гооораздо хуже.
>Ну это так, это я не тебе, а просто мысли вслух.
Лол, функтодаун пытается ВЗЯТЬ РЕВАНШ.
Давай-давай, функтодаун, высри еще пепла, а мы поржем.
>При чем тут ассемблер? Ты вообще не понимаешь, о чем говоришь.
Ты считаешь что можно отождествить ООП и ФП потому что в ФП есть МОНАДА и она прям как объект. Я пишу тебе в ответ что это конечно полный бред, но даже если проявить нехуйственную фантазию и допустить что это так, это еще нихуя не значит, ведь большая масса кода ФП не монадическая. Ты в ответ пишешь что это не важно ведь в итоге все выполняется одной большой монаде. Я говорю что с таким же аргументом можно сказать что все выполняется в машинных кодах и писать сразу на них.
Вот так - идеальное резюме текущей дискуссии, а ты хуй простой пытающийся увильнуть из последних сил
>Ты вообще не понимаешь, о чем говоришь
вообще охуеть, с мамкой своей будешь так разговаривать, щегол.
>а в постах того анона нет ошибок
На самом деле в них вообще нихуя нет толком. Просто неведомый мимо хуй сдриснул две строчки хуй пойми о чем, о проблеме о которой можно писать книги.
Мать твою ебал.
>Никто, грубо говоря, O(nlogn) на O(n3) менять не будет
Тыщу раз уже меняли. Байт код > ассемблер > Си > JVM || Лисп машины > интерпретируемые языки > и, наконец, браузер/Electron. При чем, тот же Haskell гораздо быстрее и экономичнее второй половины списка за счет того что компилируется. Современный JS, при этом, по большей части состоит из функциональщины (React/Redux/Saga/Immutable) и все только радуются.
>о проблеме о которой можно писать книги.
О какой проблеме? Сам выдумал какую-то проблему, в очередной раз выдумал хуйню, которой в посте не было, а то, что было - прочел жопой и жопой же высрал очередной ответ с жирным и тупым троллингом уровня средней школы для детей-аутистов из неблагополучных семей.
>уровня средней школы для детей-аутистов из неблагополучных семей
Ну хуй знает, тебе виднее, от стекломоя похоже совсем мозги расплавились и за дискуссией совсем не уследить
Вот функтонеуч и показал себя во всей красе.
Ты вообще знаешь, чем O(nlogn) от O(n3) отличается?
Какой электрон, блять, ЖС медленнее нативного кода раз в пять всего, если не меньше, а O(n3) - катастрофа, когда для 10 элементов массива код выполняется 1 секунду, а для 100 - 1000 секунд, блять.
Если бы он на всех n был в фиксированное количество раз медленнее, это было бы еще терпимо.
>когда для 10 элементов массива код выполняется 1 секунду, а для 100 - 1000 секунд, блять.
А для О(nlogn) при 100 элементах - ту же 1 секунду
Идите нахуй оба, дегенераты.
>РРРЯЯЯ
Не бомби так, неосилятор_ка, а то копотью срать будешь.
>ЖС медленнее нативного кода раз в пять всего
JS во многом и есть нативный код, т.к. половина кода вызывает нативные C++ функции.
На примере простой сортировки он медленнее в 7.5 раз. Использовал JS имплементацию mergeSort - именно mergeSort используется в NodeJS.
Тем не менее, в бенчмарках NodeJS даже с нативными функциями стабильно сливает Хачкелю, сжирая в разы больше памяти.
https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=node&lang2=ghc
Имплементация же всех алгоритмов совершенно не функциональная, везде работа со стейтом - https://benchmarksgame.alioth.debian.org/u64q/program.php?test=fasta&lang=node&id=4
По твоей же логике, JS должен быть гораздо быстрее и экономичнее.
Ты статейку вообще читал, обосрыш?
Зато я ебал твою мамашу.
Кого ты мог ебать, фп-животное?
Ты действительно думаешь, что нас тута двое в треде?
>Ты считаешь что можно отождествить ООП и ФП потому что в ФП есть МОНАДА и она прям как объект.
Шта? Хватит мне приписывать свои шизофренические мысли. Ты вообще не разбираешься в вещах, о которых пытаешься говорить. Собственно, /thread.
Хитрый ход, манада-как-объект-даун, подождать пока тред совсем заглохнет, чтобы в него подпернуть, но нет, извини - ты обосрался.
Шизик, лечись
