Давным давно писали программы в процедурном стиле, то есть смотрели на программу, как на последовательность выполнения команд. Программа получила входные данные, обработала их и выдала выходные данные. Потом программы усложнялись. Программисты поняли, что сложную систему удобнее представлять как систему взаимодействующих объектов. Добавили в языки специальный синтаксис для упрощения этой процедуры и получили ООП.
Ооп это доминирующая парадигма.
>кортни кокс никогда не сядет тебе на ебало
нахуй жить
Пока существует только один ЯП где объектно-ориентированное программирование реализовано в полной мере, это SmallTalk. Все остальное это либо попытки сделать SmallTalk c блэкджеком и шлюхами (Objective-C, Ruby), или псевдо-ООП параша (Java, C++, C#, Python, JS, etc).
Что-то не таким уж и жизнеспособным оказалось "настоящее ООП", раз уж прижился только его форк. На бумаге-то, может, всё было хорошо, но практика показала, что возможность "передачи сообщений" объектам, которые эти сообщения не понимают - это не верх инженерной мысли, а свидетельство наличия ошибок в программе.
А в динамической параше можно сколько угодно вызывать несуществующие методы. Бонусом будет падение программы в рантайме. Прям как обращение к несуществующим переменным.
> Давным давно писали программы в процедурном стиле и программистов становилось все больше
> а потом решили повысить порог вхождения и придумали ООП
проиграл с манявхождениями. порог вхождения от этого не увеличивается, только разве уменьшается. что бы раньше наверстать гуев на си в гтк нужно было гуглить элемент и смотреть пару сотен методов, где хуй поймешь что и с чем связанно, никаких наследований не было, и приходилось все пихать в один стракт, а потом кастовать в нужный тип... сейчас из-за ебучего ооп, любая макака может взять кьют, где все для дурачков расписанно и имеет строгие методы, реализовать эту парашу может даже самая последняя обезьяна, ни разу не работающая до этого с ооп. так что имхо порог только снизился, а манянаследования и маняполиморфизмы это только подтверждение моему высказыванию
Если на двух пальцах - это неплохой (и, в целом, пока что единственный реально работающий на больших масштабах) способ организации кода. Значительная часть написанного про ООП - не то чтобы прям полная шняга, но скорее трансляция завышенных ожиданий.
Классическое ООП а-ля Smalltalk не полетело потому же, почему с трудом летят event-driven архитектуры вообще. Java породила множество страданий, которые, в свою очередь, породили два направления: "возврат к истокам" в сторону процедурщины в пртмитивных языках вроде Lua и Go с одной стороны и движение в сторону трейтов а-ля Rust. Если опять-таки на пальцах - наследование реализации порождало больше проблем, чем решало, и от него начали уходить.
Холиварить на эти темы забавно, но бессмысленно. Самая жирная еда - школохаскеллисты, которым нужна МАТЕМАТИЧЕСКАЯ ШТРОГОШТЬ.
накодить на функциональщине можно тоже самое и оно будет даже получше в среднем, все таки иммутабельность и идемпотентность, НО кодеров на функциональщине мало, их услуги стоят дороже, их не хайпуют смузихлебы.
почему их мало, порог вхождения выше, например упомянутая жава, а точнее жвм хостит вполне годный кложур, но въехать в него тяжело, придется жевать и саму жабу.
Мимо любитель на СИ.
Как я понимаю, ООП подразумевает привязку методов к типу (если я правильно выражаюсь). Т.е. класс несет в себе исчерпывающую информацию о том, как с этим типом взаимодействовать и что с ним можно и что нельзя.
(понятно что есть исключения).
А является ли ООП, если методы писать отдельно от типов данных и после уже привязывать к ним (без наследования). И вообще является ли это жизнеспособной концепцией?
>единственный реально работающий на больших масштабах
Давай, расскажи мне тут про свое больное спидом говно мамонта.
>кодеров на функциональщине мало, их услуги стоят дороже, их не хайпуют смузихлебы
Иными словами, функциональщина хуже ложится на устройство человеческого мозга, а всем надо, чтобы ложилась легко. Это не значит, что она плоха - есть отдельные задачи, где она (или ее элементы) прекрасно заходит, поэтому первоклассными функциями в ООП-языках или конструкциями вроде match в Rust никого не удивить. А писать иммутабельно-идемпотентно никто и в ООП не мешает.
>>1584003
>ECS и всякие PubSubы это не оно?
Оно, и event soursing оно. Но строить и отлаживать такие архитектуры сложно, мы не делаем этого без крайней необходимости.
>>1584017
>расскажи мне тут
А вот и первый пациент в этом итт.
ECS - это конкретно частная борьба с частной проблемой (промахи кеша) частных процессоров (ущербных IBM Cell из PlayStation 3 и IBM Xenon из Xbox 360, у которых одна и та же ущербная кастрированная архитектура без предсказателя предвыборки и переходов ) в одной конкретной частной манянише - геймдеве.
Сейчас эта хуерга на слуху потому что эту хуергу пытаются запихнуть в популярный на мобилках школодвиг Unity3D, поскольку данная проблема говножелеза вылезла уже с говнопроцами на арм из говномобилок и говнопланшетов которые тротлят от перегрева при нагрузке >50%.
>Давным давно писали программы в процедурном стиле, то есть смотрели на программу, как на последовательность выполнения команд. Программа получила входные данные, обработала их и выдала выходные данные. Потом программы усложнялись. Программисты поняли, что сложную систему удобнее представлять как систему взаимодействующих объектов. Добавили в языки специальный синтаксис для упрощения этой процедуры и получили ООП.
Нет.
Программисты поняли что в их анусы залезла невидимая рука стремительно развивающегося рынка и больше нельзя лениво пробежаться по грабелькам, половить сегфолты, пострелять в ногу и поподрывать пукан недельку в отладчике - конкурент выпустит на рыночек продукт ровно на эту неделю раньше тебя.
А объекты, в которых теперь заукливался код позволяли эффективнее расширять штат рабов и обеспечивать более эффективное разделение труда.
Собственно, хуева куча сверхсложного софта написана на сях, та же шинда и юниксы-линуксы с разными СУБД, просто написаны они до 90х годов.
In computer programming, a trait is a concept used in object-oriented programming, which represents a set of methods that can be used to extend the functionality of a class.
https://en.m.wikipedia.org/wiki/Trait_(computer_programming)
Хотя в некоторых языках, типа скалки, трейтами можно расширять не только классы, но и объекты.
>В хаскеле нет трейтов.
Там есть тайпклассы, с которых раст слизал трейты.
>Как и классов с объектами (в ООПшном смысле)
Так их и в расте нет.
>которыми их можно было бы расширить.
Что ты подразумеваешь под расширением? Что можно вызывать функцию не func data, а data.method()? Почему в первом случае это не расширение, а во втором нет?
>Иными словами, функциональщина хуже ложится на устройство человеческого мозг
Это индивидуально и зависит от способа восприятия и мышления.
Операционная семантика и аппликативный порядок - это не что-то очевидное и интуитивное, как принято думать, ей тоже нужно учится.
Когда я первый раз увидел на уроке информатики x = x + 1, я охуел и был разочарован. Потом мне объяснили, что на самом деле x это такая коробочка где лежит 1 и что туда можно положить что-то другое, а ещё что то что в коробочке лежит можно изменять. Потом когда на асме программировали, стало понятно о чем это, что вот есть машина, есть команды, значения идут в регистры, потом производится операция, результат появляется здесь, потом ты его записываешь в память по такому то адресую и так далее.
То есть вот так с нуля думать об операциях, меняющих некое состояние нет никаких оснований. Если на свежую голову учить детонационной или аксиоматической семантике, что ты нихуя не вычисляешь, а просто записываешь правила и отношения, то потом вся эта императивная дрочь со стейтом и процедурками будет казаться какой-то дикой хуйней, плохо ложащейся на человеческий мозг.
Я программирую онли ФП уже более пяти лет и даже при том что у меня было пару лет опыта на ОО-языках, мне намного проще и удобней думать функционально.
Более того, ООП само по себе никак не помогает и, если разобраться, толком не имеет содержания. «Все есть объект» - ну охуенно и че? Может мы можем вывести какие-то свойства этих объектов и свойства их отношений с другими объектами? Что это нам даёт?
На самом деле это просто ещё одно средство структурирования императивного кода, не несущего принципиально ничего нового.
Начинал с Erlang, потом Elixir, вот чуть более года параллельно ещё на скалке. Ерланг пропихнул в конторе где работал, применил его для нескольких кейсов, потом брал сторонние мелкопроекты уровня запила плагинов к джаберу, потом знакомая HR позвала на Elixir/Phoenix проект на ремоут, потом работал на еликсире в местном мелкоконсалтинге на скандинавию, потом работал в основном ремоут на UK. Сейчас на ремоуте парт тайм на одного немца с криптостартапом и параллельно парт тайм на скалке на калифорнийском игровом проекте.
Потому что тайпклассы это тайпклассы, а трейты это трейты.
Вот в ПХП нет ни пользовательских типов, ни их классов, а трейты есть.
Отличие трейтов от интерфейсов с дженериками заключается в позднем связывании, за счёт которого: а) трейты можно настакать друг за другом в нужной последовательности, б) можно расширять объекты, а не только классы.
>что ты подразумеваешь под расширением класса
class MyClass extends MySuperClass with MyTrait1 with MyTrait2 { ... }
>или объекта
val t = new MyClass with MyTrait { ... }
Например, в трейте ты можешь объявить какое-то поле/метод (можно абстрактные) и потом класс или объект на момент инстанцирования, который его использует будет иметь этот поле/метод.
abstract class SavingsAccount extends Account with Logger {
__def withdraw(amount: Double) {
____if (amount > balance) log("Insufficient funds")
____else ...
__ }
...}
Более того, если ты можешь использовать цепочку трейтов:
trait TimestampLogger extends ConsoleLogger {
__override def log(msg: String) {
____super.log(s"${java.time.Instant.now()} $msg")
__}
}
trait ShortLogger extends ConsoleLogger {
__override def log(msg: String) {
____super.log(if (msg.length <= 15) msg else s"${msg.substring(0, 12)}...")
__}
}
val acct1 = new SavingsAccount with TimestampLogger with ShortLogger
val acct2 = new SavingsAccount with ShortLogger with TimestampLogger
acct1 при овердраве залогирует: Sun Feb 06 17:45:45 ICT 2011 Insufficient...
А acct2: Sun Feb 06 1...
В хаскеле же нет ни объектов, ни классов.
Классы типов позволяют добиться перегрузки, но они работают на типах, а не на объектах.
>форк
Это не форк. Pharo, Squeak, Dolphin это все диалекты. Попытки воссоздать и адаптировать под современные компьютеры оригинальный Smalltalk, который был на Xerox Alto.
>объектно-ориентированное программирование
такой же единорог, как и многопоточка. никто не знает как правильно и поэтому придумывают костыли
Есть функциональщина.
ООП ХУЙ
А у вас как прошел вечер, уважаемые?
моар моники
Ну сотри корочи. Вначале ебашили действия подряд. Потом такие: "а неплохо было бы этот кусок повторить". Запилим переходы! И запилили. И там короче заебись теперь можно даже пропускать куски! А потом ты такой хули я перехожу А ОН СУКА ОБРАТНО НЕ ВОЗВРАЩАЕТСЯ! Ну и запилили вызовы и возвраты. И теперь у нас сука ПРОЦЕДУРНОЕ ПРОГРАММИРОВАНИЕ™. А потом ты такой бля а хули я перехожу А ОН МНЕ СТЕК ВЫЗОВОВ РАСПИДОРАШИВАЕТ?! Ну все такие ПЕРЕХОД - это зло. И такие Бёмом и Якопини пояснили их криком "ПЕРЕХОД НИНУЖЕН!11" Ну его такие выпиливают заменяя СТРУКТУРАМИ УПРАВЛЕНИЯ™. Структурное программирование у нас же! Ок. Потом ты такой а хули я глобальную переменную изменяю и потом переёбываюсь с ней по всей программе?! ИНКАПСУЛЯЦИЯ!!11 И вот уже Вирт пилит модульное программирование. Модульное программирование канеш хорошо но тебе же всё мало! Тебе надо делать массивы модулей и структуры с полями-модулями! Ну ты такой экспортируешь тип структуры из модуля и кукарекаешь на весь Bell Labs: "АБСТРАКЦИЯ!!11" как финальный аккорд ПРОГРАММИРОВАНИЯ С АБСТРАКТНЫМИ ТИПАМИ ДАННЫХ! Все почти хорошо но ты замечаешь что приходится придрачивать поля-модули к модулю внедряя в поле-модуль специфичныи функции того модуля! Ну ты такой СДЕЛАЮ НА МАКРОСАХ ЗА 20 МИНУТ!1 Сделал. А потом заёбываешься перекомпилять поля-модули под каждый чих модуля и агрясь на размер кода зопиливаешь те самые функции в отдельную структуру и переопределяя их в рантайме становишься королём ОБЪЕКТНО-ОРИЕНТИРОВАННОЙ ПАРАДИГМЫ со страусиной типизацией!111 Вот так ёпана
>код в студию
В смысле? Ты не можешь создать объект Message и передать его другому объекту?
Ну вот тебе псевдокод тогда:
messageObject.setPayload('eto huita');
somethingObject.handleMessage(messageObject);
Так же невозбранно можно юзать разные паттерны - наблюдатель, цепочка обязанностей и тд, обрабатывая эти сообщения как тебе удобно в текущем кейсе.
Я, может, этого корявого выражения не понимаю: возможность "передачи сообщений" объектам? Просто не первый раз его встречаю, вот и спросил.
Ну и наезды на ООП в его текущем виде считаю неправильными - на бумажке и в теории оно всегда красиво выглядит, но реальность всегда такова, что идеальных конструкций тут хрен сделаешь и приходится идти на компромиссы. Можно долго махать языком, доказывая, что какой-то шибко умный язык из-под институтской шконки сделан по всем правилам, но в этом мало толку пока этот язык не начнёт решать реальные задачи в промышленных масштабах.
Ну так где ж тут месседж-пассинг, если это просто вызов методов через vtables? Под месседж-пассингом обычно подразумевается суперпозднее связывание, когда всё такое динамическое-хуическое. Если интересно что имеется в виду, вместо тысячи слов просто поставь себе Smalltalk, желательно с IDE, попиши какой-то код и всё быстро станет понятно базарю ещё захочешь
>Ну и наезды на ООП...
Популярность (во многом уже былая) ООП - это историческая случайность + агрессивный маркетинг и желание людей писать и продавать книжки о полугуманитарной хуйне. Отсутствие вменяемой формальной системы в основании приводит к тому, что парадигма не является полной системой хоть в каком-то смысле, а является скорее набором традиций и советов древних, типа "чтобы копьё лучше било мамонта, надо чтобы девственница обоссала его в полнолуние". Вообще само наличие классических ОО патернов, как неких стандартных решений - означает, что в рамках этой парадигмы постоянно возникают одни и те же проблемы, что в свою очередь указывает на хуёвость и непродуманность самой парадигмы.
> Я, может, этого корявого выражения не понимаю: возможность "передачи сообщений" объектам? Просто не первый раз его встречаю, вот и спросил.
Просто кто-то когда-то выдумал терминологию такую, никакой другой ещё не было, но требовалась. У тебя же не возникает вопросов, почему методы называются методами, хотя никакой методологии вроде бы нет.
Другой вопрос, что смоллтолк предлагает откладывать проверку того, что "сообщение понятно объекту" (метод существует) до самого последнего, что сейчас осталось уделом динамикодрисни, и в нормальных языках такого нет. Что ж, это отдельная историческая веха развития ООП, структурное программирование в нынешнем виде тоже не сразу появилось. И чьи-то попытки сейчас цепляться якобы за тру-ООП (устаревший подход к ООП) выглядят глупо и наивно.
>Ну так где ж тут месседж-пассинг
Википедия, раздел про ООП:
https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D0%BC%D0%B5%D0%BD_%D1%81%D0%BE%D0%BE%D0%B1%D1%89%D0%B5%D0%BD%D0%B8%D1%8F%D0%BC%D0%B8#cite_note-1
Модель акторов, на основе которой строился смолток, как раз куда более проработана, чем мейнстримовый гумманитарный ОО-булщит. Когда действительно всё есть объект, и всему можно послать сообщение, а его приём и обработка зависит целиком от получателя - это конечно же является динамической дрисней, но это позволяет писать очень гибкие, изменяемые системы. Взять даже смолтолковскую среду разработки: даже сегодня нормальный REPL не доступен большинству разработчиков, а в те бордатые годы это было как магия.
Ну и не будем забывать, что все вещи вроде рефакторинга, юнит-тестов, паттернов и много другого, что используется по сей день, пришло именно из смолтолка.
Проебал он плюсам исключительно из-за зашорености байтоговнариков, до последнего остававшихся верным своим указателям и низкоуровневому дрочу, которые и кресты-то с трудом восприняли.
Вы просто ещё не дозрели до правильного взаимодействия через сообщения. Вы или заблокируете поток, или скушаете всю память буфера, или будете городить костыли с опросом в цикле, который хорошо и бесполезно загрузит CPU.
"Вы" это не конкретно к тебе обращение, а к подавляющему большинству программистов.
>или заблокируете поток, или скушаете всю память буфера, или будете городить костыли с опросом в цикле, который хорошо и бесполезно загрузит CPU.
>
Сначала заблокируют, затем, в попытке обойти блокировку, переполнят все буфера, наконец решат проблему поллингом.
> Ты кто вообще?
anonymous
> написал полезного и знаменитого,
Да много чего накостылил и наговнокодил. Например то, что сейчас продётся, написал в составе большой команды разработчиков. Вышеописанное, типа блокировок, переполнения буферов и опроса - это из собственного опыта и смотря как другие программисты задачи решают. Затем достиг просветления и теперь имею право говорить теми словами, которые тебя задели.
И да, если ты пользуешь события, например, через Windows Message Queues, то там накосячить трудно - всё уже за тебя другие люди придумали. Но в целом с событиями мало кто может работать, если шаг влево или вправо отойти от семафоров.
Смари, есть значит физический объект. Он может двигаться в пространстве, с ним можно взаимодейстовать согласно его применению, если он функциональный. И весь этот этикет поведения объекта тебе нужно описать. Класс - это ебучий завод, который делает объекты по макету. Ты так же можешь теперь инкапсулировать метод. Скажем вот есть завод бинзопил. И теперь в народе ходит выражение "пилить как бензопилой". Если ты сделал метод пиления бензопилой приватным, то такое выражение в твоей деревне не все знают и не все понимают, только те, у кого бензопила есть. А если это защищённый метод, то "так пиздато как бинзопилой пилить ничем нельзя" и все ходят и завидуют этой бинзопиле, что не могут так же, потому что не такая как все, недоступная. Ещё класс можно собрать из абстрактных классов. Скажем есть класс "циркулярное движение" и ты его применяешь как технологию на своём заводе бинзопил, потому что куда без него. Ты можешь конечно изобрести свой велосипед, но ты же программист и уже скорее всего мудрец, который учится на чужом опыте, так что нужно заимствовать. Ну ты понял кароче, проецируй знания
Концепция классов довольно проста и понятна.
О шаблона так не скажешь, особенно если их самому реализовывать. Но при этом использование шаблонов чертовски упрощает написание программы. Можно сосредоточиться на вещах более высокой абстракции. В целом, при использовании шаблонов, исходный код получается более компактным и зачастую более легко читаем.
Могу даже пошутить слегка. Программистов на С++ можно разделить на три категории - кто всё пишет на шаблонах, кто всё делает на своих самописных классах, и кто пишет шаблоны.
Написать хороший шаблон нужна высокая квалификация, это топ. Делать всё на классах это мидл, а кто пользует чужие шаблоны и всё пишет только на шаблонах, это low.
Ну смотри - кодишь ты себе такой кодишь, пишешь разные алгоритмы, реализует структуры, задачки решаешь. А потом решаешь вкатиться на работу и тут тебе хуякс - фабрики хуябрики, синглтоны хуйглатоны, абстрактные мета виртуальные в рот невъебенные свистопирдюлькинские методы, стратегии, адаптеры и прочие крайне полезные изъебы без изъянов. Да ебись оно все в рот конем решаешь ты и идёшь учиться в кулинарный техникум.
Так микросервисы это унылое говно же. Это идея из того же разряда, что и так называемый язык программирования Go, идея что можно нихуя не знать и не уметь и при этом писать сложные программы. Т.е. вместо сложной программы с архитектурой, хуярится N плоских и примитивных микросервисов, которые может написать на говне любой первокурсник с лабой, и над всем этим наворачивается кучерявая инфраструктура. Т.е. задачи софтваре ижениринга решаются инфраструктурными методами.
>сравнивает элемент, лежащий в основании языка/парадигмы и некие "устойчивые практики", возникшие у пользователей языка, как результат отсутствия необходимых элементов в их языке/парадигме
Скажи честно, тебе же ещё нет 18? Может бы лучше съебёшь обратно в б/ыдлятню лампово тралить тупостью друзяшек апельсинусов?
Вообще ты промахнулся, паттерны можно было бы сравнить, допустим, с комбинаторами из ФП.
Вот только комбинатор в ФП - это простая композиция функций, в то время как в ООП композиция объектов никак не определена - объекты комбинируются обычным процедурным быдлокодом.
Определение композиции объектов в ООПе в студию.
В ФП:
(a -> b) . (b -> c) = (a -> c)
В ООП:
??? null
>>1816936
>мне не нужна точность и формализация в основании моей парадигмы, я вполне доволен использовать "будничные практики", ну ничего что строгость кода где-то между юридическим документом и философским трактатом, мне даже нравится оставаться после работы отлавливать баги, а по выходным пытаться переписать всё это неконсистентное говнище нормально в который раз, зато свободка и ничего не нужно определять
Я тебя понял.