Какие проблемы и задачи оно решает?
Почему пользоваться классами и объектами, а не допустим списками? Ведь суть одна и та же.
В ООП объект со своими параметрами.
В списке просто именованный список со своими членами.
Я нуб-студент
>Какие проблемы и задачи оно решает?
Проблему утилизации обширных быдло-масс в ИТ. цитата
мало писал в процедурном стиле раз не понял зачем ООП
>Какие проблемы и задачи оно решает?
Тут целую простыню текста можно расписать по этому поводу, неохота, вдруг ты даже читать не станешь. Поэтому ты расскажи как бы ты в процедурном стиле описал новый тип данных? У тебя есть стандартные типы - целое, число с плавающей точкой, символ, булеан. А тебе нужен, например такой тип как время в формате hh:mm:ss.
>Почему пользоваться классами и объектами, а не допустим списками?
Это всего лишь особенности реализации. В некоторых скриптовых языках объект реализован как ассоциативный массив.
Сейчас набегут
Это не просто список. Его элементы могут быть разных типов, в том числе представлять собой вложенные списки, из чего следует, что такая интерпретация ООП плохо ложится на статическую типизацию.
Технически, ООП не даёт ничего такого, что нельзя было бы сделать без него. Вся разница в удобстве. Запись:
alice.friends.bob
куда понятнее, чем:
> aline[17][4]
Изи пример. Я разрабатываю ЭБУ, а ты- фару. Мне нужно знать контракт, как управлять тобой: вкл/выкл/коррекция пучка света по вертикали. На остальное мне поебать, как оно там внутри тебя будет реализовано.
Это и есть инкапсуляция.
Далее. У тебя есть моделька самолета и ты просчитываешь, какой мощности должны быть двигатели. На остальное поебать: цвет самолета, количество мест, наличие биотуалетов.
Это и есть абстракция.
Далее. У тебя есть кошечка. Она родила котят. Все котята имеют хаост, усы, по два уха.
Это наследование.
Один котенок - бойкий альфач, а другой- омежка, как ты.
Это полиморфизм.
>падать в рантайме из-за того, что объект "не понял сообщение".
Полный бред. В рантайме падают только статические языки. Smalltalk по дефолту тебе просто покажет окошко что объект-name не может принять сообщение-name. Pharo, Ruby и Objective-C кидают исключения, которые можно поймать.
> Почему нерабочий софт должен попасть к конечному пользователю?
Запросто попадает. Много раз видел, как программы/либы, написанные на динамической дрисне и позволяющие вызывать несуществующие методы ("посылать сообщения объектам, которые не могут их принять", как вы это называете), срут в консоли, что такого-то метода нет. Спасибо хоть, что не все они аварийно завершаются после этого.
> Проблемы макак, которые не читают документацию и не пишут тесты для своего софта.
Проблема макак в том, что они выбирают языки, на которых прходится писать во много раз больше тестов. Но они этого не делают. На то они и макаки.
Именно что в языках. Одна и та же макака напишет на статическом языке более качественный продукт, чем на динамическом просто потому, что компилятор статического языка чаще будет бить макаку по пальцам, когда интерпретатор динамического будет молчать до последнего.
Тип для чего? Для хранения? Для хранения подошла бы структура с 3 полями. Если нужно какое-то преобразование или получение даты, написал бы функцию. Но все подобные функции уже есть и работают со структурами (в си так). Ооп удобно, когда функционала много, а для простых задач вроде твоей, достаточно описанного выше.
Удобно хранить тип данных, вместо с методами работы с ним. Очень блядь удобно. Невыносимо удобно.
>Если нужно какое-то преобразование или получение даты, написал бы функцию.
Вот блядь некоторые предпочитают не писать велосипеды, а писать полезное ПО.
>о все подобные функции уже есть и работают со структурами (в си так)
Это и есть ООП лол. прикинь да, в си в большинстве серьезных проектов пишут в ООП или с нехуевой примесью ООП
>структура с 3 полями
Вот тут возникает первая проблема. Данные внутри структуры должны быть согласованны, не может быть в сутках 27:83:132.
>преобразование или получение даты, написал бы функцию
Это правильно, но тебе придется написать жирный комментарий: ВРУЧНУЮ ПОЛЯ СТРУКТУРЫ НЕ МЕНЯТЬ! Только через эти функции. Можно еще вести соглашение, например, именовать такие поля, начиная с нижнего подчеркивания: _hh, _mm, _ss. Но где гарантия, что все в проекте будут внимательно читать документацию, или кто-то посчитает, что он то уж точно знает, что делает и ему можно изменять эти поля. Приходится полагаться на внимательность, добросовестность, ум программиста. Но ведь лучше поручить контроль за доступом к полям структуры компилятору, пометив такие поля, как закрытые. Это первое свойство ООП - инкапсуляция.
>Данные внутри структуры должны быть согласованны
Так а структура тут при чем? Согласование еще происходит на этапе получения этой даты в специальной функции. Структура нужна только для хранения.
>ВРУЧНУЮ ПОЛЯ СТРУКТУРЫ НЕ МЕНЯТЬ!
А где гарантия, что какой-нибудь самый умный не решит сделать все приватные поля класса публичными?
>Структура нужна только для хранения.
По ТЗ эта структура должна быть изменяемой, к ней можно добавлять и отнимать секунды, минуты и часы.
>А где гарантия, что какой-нибудь самый умный не решит сделать все приватные поля класса публичными?
Этот факт легко отследить. А вот если во многих местах программы кто попало вопреки соглашениям решил изменять условно-приватные поля, то уже гораздо труднее определить, в каком участке кода произошла ошибка.
Наследование полиморфизм и инкапсуляция, аминь.
Все штуки нужные и реально используются на практике.
Как ты списки то наследовать будешь?
>Удобно хранить тип данных, вместо с методами работы с ним. Очень блядь удобно. Невыносимо удобно.
Ну засунь их в список.
>Вот блядь некоторые предпочитают не писать велосипеды, а писать полезное ПО.
Чё? В ооп типа методы для работы с данными сами пишутся?
>прикинь да, в си в большинстве серьезных проектов пишут в ООП или с нехуевой примесью ООП
Не
ООП нужен для управления сложностью большими проектами.
Пока ты пишешь лабы, странички магазинов и т.п. ты будешь удивляться зачем они нужны.
Когда ты пишешь что-то длиннее нескольких тысяч строк и это должно периодически меняться по желанию заказчика ты будешь удивляться как эти дебилы пытаются сделать что-то без ОПП.
>Когда ты пишешь что-то длиннее нескольких тысяч строк и это должно периодически меняться по желанию заказчика ты будешь удивляться как эти дебилы пытаются сделать что-то без ОПП
>The Linux kernel
>Written in: C and assembly
>139 тысяч строк кода
>это чистое ядро
>с драйверами 15 миллионов
Машина Тьюринга не имеет такой гибкости как Комбинаторная логика, Лямбда-исчисление, Рекурсивные функции, которые позволяют из маленького ядра построить любую вычислительную систему. Грубо говоря, они позволяют строить свой язык программирования. Машина Тьюринга не дает такой гибкости. Машина Тьюринга это система с хранением состояния, а это противоречит математике. Состояние это зло, все ошибки происходят из-за него.
>Состояние это зло, все ошибки происходят из-за него.
Не совсем верно. Присвоения это можно и полезно, но только ИНОГДА БЛЯДЬ, а не как в императивных языках где оно везде: и к месту и не к месту.
Оно заебись тогда и только тогда, когда его отсутствие приводит к снижению модульности системы вследствие того, что потроха дочернего модуля (которые могли бы быть выражены стейтом) протекают в родительский.
Например какой-нибудь простенький ГСЧ: берёт текущее время в качестве зерна и делает случайное число. Если его сделать без присвоений, тогда мы вынуждены будем из родительского модуля явно передавать ему зерно, а значит родительский модуль должен будет сам его генерировать, а значит у нас устройство родительского модуля начинает зависеть от устройства дочернего. А ведь нам просто нужно было случайное число, нас не ебёт как там дочерний модуль его рожает.
Но для того чтобы просуммировать последовательность нам присвоение нахуй не всралось. Такие дела.
>ООП
>ряя инкапсуляция наследование полиморфизм
>открываешь какой-нибудь спринг
>FileUtils
>пошла простыня из статических методов
Что называется объекты завезли а соответствующее мышление не завезли. Как писали портянки процедурные так и пишем.
То что статические методы в принципе существуют (в джаве, которая на минуточку флагман и главный ооп язык) - уже символизирует полный и бесповоротный фейл ооп как парадигмы.
То есть у нас типа "всё есть объект", но на самом деле объекта нет а метод несуществующего объекта (т.е. по сути старую добрую процедуру из си) мы вызвать можем. Охуенно, заебись, дайте два. Зато мы не можем определить процедуру в глобальном скоупе (ты чё, у нас жи ооп). Но сделать ютилити класс и вызывать его методы, не создавая при этом объектов этго класса мы можем. Ага.
> символизирует полный и бесповоротный фейл ооп как парадигмы
Нет, это символизирует, что нет универсальных парадигм. Когда борщехлёбы передают в функцию огромный тип с кучей полей, потому что нет классов, и рекурсивно вызывают эту функцию с немного изменённым состоянием, чтобы изменить значение одного поля, тоже ни о чём хорошем не говорит. По сути, они изменяют состояние вручную, как на сишке вручную пишут ООП.
Нет противоречий между ФП и настоящим ООП. Проблемы только с псевдо-ООП парашей.
https://lispcast.com/is-smalltalk-a-functional-language-is-lisp-object-oriented/
https://medium.com/smalltalk-talk/lisp-smalltalk-and-the-power-of-symmetry-8bd96aaa0c0c
>It’s true that the usual flavor of Object-Oriented Programming (“OOP,” as in “OOPs what was I thinking when I designed this class hierarchy”) has issues. Languages such as Java, C++, and even Python seem to think that “object-oriented” means mostly “classes and inheritance.” Which is sort of like saying that “driving” means mostly “buttons and pedals.” What most of these languages seem to miss is that Smalltalk’s class system, like Lisp’s macro system, is a symptom of the power already available in the language, not its cause. If it didn’t already have it, it wouldn’t really be that hard to add it in yourself.
>Without Smalltalk’s underlying fundamentals, class inheritance becomes nothing more than a tool for code reuse. As such, it is neither the only nor necessarily the best such tool. The real power of Smalltalk’s object system, including its classes, is not inheritance–it’s reflection. Just as Lisp macros are powerful because they can operate on any Lisp code, including themselves, Smalltalk classes are powerful because they themselves are objects. Smalltalk, like Lisp, runs in the same context it’s written in. It’s objects all the way down.
Положняк такой, есть 4 типа Ооп.
ООП-0 - оно же истинное ооп, придуманная теоретиками неюзабельная хуйня наравне с функциональщиной.
ООП-1 - классическое, классовое, реализованное практиками, получило наиболее широкое распространение благодаря c++/java/c#.
ООП-2 - прототипное. Попытка отказаться от классов, применяется в скриптовых языках, особой популярностью не пользуется, даже в js классы добавили.
ООП-3 - различные попытки побороть сложность и проблемы, порожденные классическим ооп-1, главным образом за счет отказа от наследования (go, rust). Пока еще мир не завоевало.
>рассматривали классы не только с позиции ООП
Следовательно ооп нигде не используется, следовательно мы никуда не уходили из мира процедурного программирования.
Модульность есть и в си - вот тебе процедура, вот тебе файл который можно компилировать отдельно от других.
Объекты это модульность в чистом виде и есть, если у тебя проблемы с тем, чтобы обернуть класс в класс-декоратор, который будет добавлять нужный функционал, не нарушая SRP, то у меня для тебя плохие новости - ты не можешь в объектную модульность, ты можешь только в процедурную модульность, поэтому создавай файл с расширением .с и пиши свою хуйню туда.
>придуманная теоретиками неюзабельная хуйня
https://youtu.be/BwPT8_bB8dY?t=501
Юра, ты как в этот тред-то пролез?
>Сомневаюсь
Знаешь как сомнения прояснить? Открой да посмотри
Вангую сейчас начнётся "ряя на любом йазыке можно песать ооп, там тожи йесть элименты ооп", только из элементов ооп там только абстракция (которая свойственная программированию как таковому, не только ооп)
Конечно, анон сейчас скажет, мол ты кампанию хуевую выбрал, но это моя последняя работа в энтерпрайзе и последняя работа с мейнстрим ООП языками.
Фактически классы это необязательная (а по мнению некоторых и нежелательная) фича.
Для реализации ооп классы необязательны. Может существовать система, при которой класса как такового нет, а есть первый объект, и последующие объекты, создаваемые по образу первого. И чего мы при таком подходе лишаемся, так это возможности лепить статические методы (нет класса - нет статических методов, их просто некуда писать), а это как раз замечательно.
Потому что "статические методы" должны быть процедурами, коими они концептуально являются, так что программист сразу видит "ага, тут я написал процедуру, следовательно я обосрался".
https://github.com/github/linguist
>The percentages are calculated based on the bytes of code for each language as reported by the List Languages API.
>развитие
Лол. Таким макаром, лет через цать, окажется, что ооп это фп.
>>1611523
Ты сам понимаешь, что ты пишешь?
Во первых, чтобы избавиться от статических методов-процедур необязательно избавляться от классов, но это не имеет значения, т.к. ООП это всего лишь надстройка над процедурной парадигмой. Под ООП всегда подразумевалось, подразумевается и будет подразумеваться как бы вы не старались, маньки мутабельные структы со связанным неймспейсом, в котором определены процедуры-методы, меняющие поля структа. Т.е. ты всегда пишешь в процедурном стиле, если ты пишешь ООП, вне зависимости от того определяешь ты статические или обычные методы.
Таким образом ООП наследует и преумножает все проблемы процедурной парадигмы.
> Во первых, чтобы избавиться от статических методов-процедур необязательно избавляться от классов
Никто не говорил что от классов обязательно надо избавляться (мнения на этот счёт расходятся), а из тех, кто всё-таки говорил, никто не утверждал что от классов надо избавляться чисто ради того, чтобы порезать статические методы (их можно и без этого убрать)
>ООП всегда подразумевалось, подразумевается и будет подразумеваться
Да, да, конечно. Извини что тебя затронул. Все будет как ты скажешь.
>>1611561
>Чистое ФП не работает
Оно и не должно быть чистым. Стейт в ряде случаев предпочтителен.
Наследование нужно избегать, это уже сказали. Но бывают случае когда оно нужно и удобно.
Именно поэтому нужны мультипарадигменные языки и с ООП и с ФП.
Из ООП прижился полиморфизм на интерфейсах. Из ФП лямбды, замыкание.
В котлине все классы закрыты по-умолчанию. А дата-классы не наследуются (являются структурами). При этом есть и функции и лямбды.
И что самое мне нравится, можно сделать "жирные функции", то есть когда можешь указать параметры kwargs
foo("my value", end="\n", sep="/")
Ты заебал, смолток в могиле посылает сам себе сообщения, обж-с скоро к нему присоединится. Этого шизика послушать, так ООП это любая актор-бейсед хуйня, например ерланг. Но факт в том, что 99% программистов услышав слово ООП подумают про джаву, кресты и пхп, а не про ерланг. Можно конечно жить в альтернативном манямирке, где голова это на самом деле жопа и просто никто об этом не знает. Я понимаю почему так может считать Алан Кей, старческая деменция, маразм, вся хуйня, вон его кореш Тед Нельсон ещё больше поехал со своим Xanadu, на который всю жизнь вьебал, а оно никому нахуй не нужно, теперь ходит как дурачек всем рассказывает что НАСТОЯЩИЙ интернет и гиперссылки это вообще не то что все думают, но вот уебанов, которые транслируют старческие бредни я понять не могу.
>Проблема проектирования "какающей лошади и летающего пегаса"
>Решение через наследование
https://pl.kotl.in/hclcmiTPB
>Решение через делегирование
https://pl.kotl.in/JCIfJovQW
Лол, вчера с десяток строк в градле добавил пачку либ, которые я писал бы так же качественно, наверное, год.
То есть, те либы мне сэкономили тысячи человеко часов работы.
Конечно, наличие большого числа библиотек это зло, питонисты тоже согласяться. гоферы ебанутые
>Котлин не сможет себе прибрать к рукам жвм
OpenJDK может
>А оракл может плохо отреагировать.
Оракл уже реагирует, пилит тонну фич в джаву и релизит каждые полгода как не в себе (смотри видос про планы до 2024). Конкуренция это хорошо.
Котлин это не только JVM, это и native и js.
> Для чего нужно ООП?
Если говорим про реальную пользу для работы, то нужно для того, чтобы ты, в теории, мог расширять функциональность без лишних телодвижений.
Еще можно всякие прикольные штуки, типа внедрения зависимостей делать, благодаря этой хуйне все вообще классно выходит: Скажем, ты написал лог, вынес на уровень интерфейса базовое описание лога:
interface ILog{
void Write(LogLevel level, string message);
}
Потом ты сделал импплементацию этого лога в виде класса ConsoleLog, человек который пользуется интерфейсом, заинжектил этот класс, год все было хорошо, но теперь ваше приложение должно работать как сервис и встала задача писать лог не в консоль, а в файл, еще и в json - формате. Ты за часик сделал новую имплементацию JsonFileLog, и человек просто заинжектил новый класс, при этом в классе, что использует лог ничего не поменялось, но теперь лог пишется в файл. Красота же. А если у вас крутой архитектор, то вы вообще давно сделали так, что для замены лога можно просто прописать в конфигурационном файле какой лог брать в случае запуска и даже пересобирать не придется, ты просто кинешь dll куда надо, в конфиг файле добавишь пару строчек и у клиента теперь лог пишется в файл.
> Почему пользоваться классами и объектами, а не допустим списками? Ведь суть одна и та же.
Далеко не одна и та же.
>Но факт в том, что 99% программистов услышав слово ООП подумают про джаву, кресты и пхп
И кого это должно волновать? Мне, например, похую.
>Можно конечно жить в альтернативном манямирке, где голова это на самом деле жопа и просто никто об этом не знает
99% программистов живут, и чё?
Нацистская германия жила почти в полном составе в альтернативном манямире где арийцы это богоизбранная высшая раса.
Веганы живут в манямире где мясо несъедобно.
Вот только ты верно заметил - от того, что 99% назовут голову жопой, она не станет жопой, а останется головой.
А чем это джавовые дженерики неполноценные? Тем что инфа в рантайме вырезается? Так это только и дает возможность сделать продвинутые системы типов, как в скале, например. А том же дотнете в F# как раз не завезли типы высших рангов из-за того, что шарповые дженерики реифицируются.
Если язык достаточно выразительный, то инфо по полиморфным типам можно пихать в рантайм опционально с помощью вшитых в язык ad-hoc решений (звучит плохо, но на деле не так страшно). Примеры: Scala (ClassTag, TypeTag), Haskell (Generic)
То, что реификация дженериков необходима - популярное заблуждение.
Не знаю, мож не в тему.
https://pp.userapi.com/c849036/v849036303/56f01/s24TaznqQOc.jpg
>ООП это любая актор-бейсед хуйня, например ерланг
ООП - это когда ты в своем коде можешь выполнять полиморфную функцию, не объявляя прямой зависимости на эту функцию. Так что да, эрланг и акторы - это ООП.
>Я понимаю почему так может считать Алан Кей, старческая деменция, маразм
>Но факт в том, что 99% программистов
То есть когда один выдающийся человек с именем высказывает мнение, то это автоматически маразм, но когда 99% (высранных тобой из жопы) абстрактных людей, высказывают мнение - это автоматически правда? Ты дурачок?
> Какие проблемы и задачи оно решает
Командная работа, масштабирование кода
>>1612141
Дебилушка, смолток проиграл потому что это было ультратормозное говнище, и vtables с early-binding по дефолту тупо быстрее. Во-вторых, это просто квинтэссенция динамического петушения когда что угодно может вызывать послать сообщение чему угодно, сообщение может перехватить что угодно и ответить что угодно, самостоятельно решая что ошибка, а что нет.
Ну то есть программировать на этом может быть весело, но для разработки и поддержки реальных систем - это слишком дорого и хуёво.
Единственный способ его реанимировать - всё покрыть хотя бы простой типизацией, вынести месседж пассинг дрисню в отдельное подмножество языка и тоже типизировать. То есть получился бы Kotlin + Typed Akka.
А ерланге хотя бы разделение есть: вызов функций - это вызов функций, а посылка сообщений - это посылка сообщений.
Плюс в ерланге акторы были чтоб обеспечить конкаренси, изоляцию и, как результат, отказоустойчивость, а в смолтолке не было ничего из этого, зато были акторы для всего просто чтоб были.
>Как же оно тогда работало на Xerox Alto?
Вот так.
https://youtu.be/adEr2aRwHnI?t=557
Так-то есть центр массы галактики и Земля вращается вокруг него, что не мешает ей ещё и вращаться вокруг Солнца. Вот, кстати, интересный вопрос про центр массы вселенной: есть ли он (если не брать за центр вселенной мой хуец, бтв) и будет ли правильно строить модель движения вокруг него?
>CRUD
Пусть индусы на яве пишут.
https://github.com/feenkcom/gtoolkit
https://github.com/PolyMathOrg/PolyMath
Охуенные у тебя аналогии.
Вращение Земли вокруг Солнца - проверяемый факт, определение оопе - придуманная людьми гуманитарная хуйня и споры о том что же такое НАСТОЯЩЕЕ оопе , это как споры как звучит НАСТОЯЩИЙ готик-рок или что НА САМОМ ДЕЛЕ изображено на картине очередного абстракциониста.
>Для чего нужно ООП?
>Какие проблемы и задачи оно решает?
Основная причина использования ООП - это переиспользование кода. ООП свободно позволяет это делать за счет полиморфизма, наследования и инкапсуляции.
Если нет инкапсуляции, то сокрытие равноценно не использованию данного типа данных практически свой None. Инкапсуляция в обоих смыслах возможна даже в процедурном C. Другое дело реализовано ли на уровне классов встроенных в язык или каким либо другим способом.
Писать говно по принципу написал один раз и пошел дальше можно на чём угодно(на фп языках это естественно быстрее), разницы нет. Но вот если тебе(а зачастую не только тебе, а еще другим людям) это надо поддерживать и развивать, то только ООП.
Самые большие затраты при разработке софта - это его поддержка(а не первоначальная разработка, о чем обычно идёт речь в спорах наподобие ОП)
>А чем это джавовые дженерики неполноценные
Ну вот как тебе сказать...
https://github.com/AlexKent3141/meta-tictactoe
>Вот тут возникает первая проблема. Данные внутри структуры должны быть согласованны, не может быть в сутках 27:83:132.
В OpenGL последних версий (и в Вулкане, вроде, тоже), например ввели куколд-ООП.
Суть в том что саму структуру в руки тебе не выдают.
Тебе выдают в руки ID, и процедуры типа геттеров-сеттеров в которые ты это id можешь передавать и которое резольвится внутри драйвера в какой-то реальный стейт.
Термин ООП изначально был придуман для Smalltalk.
>гуманитарная хуйня
Нет.
https://en.wikipedia.org/wiki/Alan_Kay
Ты сейчас ооп в js описал
В игорах особенно в массовых онлайн дрочильнях используется другая отличная от ооп концепция - ECS
Все объекты/сущьности размазываются по многим таблицам/спискам. Ты можешь сразу обработать координаты 100500 мобов, а не вызывать monster->move(0, 0) для каждого моба. Считается что полиморфизм дорого стоит. Пусть меня поправит кто в теме
Не столько из-за самого полиморфизма (в ООП, конечно, есть косвенный вызов через vtable, но он вроде и в ECS никуда не исчезнет), сколько из-за сложности изменений в ООП, например геймдизайнер поменял тип юнита со среднего танка на тяжелый, тебе придется лезть в разные файлы, менять что от чего наследуется и не наебаться
> Под ООП всегда подразумевалось, подразумевается и будет подразумеваться как бы вы не старались, маньки мутабельные структы со связанным неймспейсом, в котором определены процедуры-методы, меняющие поля структа.
Мань, под ООП всегда подразумевалась отправка сообщений объекту, да, вызов метода это тоже отправка сообщения.
>процедуры-методы, меняющие поля структа.
Фабричный метод, который возвращает каждый раз новый объект, смеется тебе в лицо.
Короче, никто не виноват что ты говнокодер и свой опыт проецируешь на остальных.
> гибкости
Эмоциональное слово, не несущее какого-либо объективного определения в данном контексте.
>позволяют из маленького ядра построить любую вычислительную систему
Из машины Тьюринга можно построить любую вычислительную систему. Личералли. Это то что позволяет строить полноценные компьютеры в майнкрафте, к примеру.
>Грубо говоря, они позволяют строить свой язык программирования.
Один из самых первых примеров машины Тьюринга - это когда ячейки хранят буквы, которые интерпретируются. Так что да, машина Тьюринга позволяет строить свой язык программирования и работать уже на нем.
>математике
Математика - лженаука, она изучает несуществующий предмет, покажи мне отдельно существующее число в природе. Их нет.
>Состояние это зло, все ошибки происходят из-за него.
Состояние это добро, все благое происходит из-за него.
>покажи мне отдельно существующее число в природе
Температура - это абстракция. Термодинамика тоже лженаука? Количество - это абстракция, но вполне имеет отношение к реальному миру. Ты же не можешь предположить что у тебя батя вдруг не один, а скажем полтора бати, даже если ты уверен что твоя мамка шлюха.
>Почему пользоваться классами и объектами, а не допустим списками? Ведь суть одна и та же.
А как твои списки генерируют СОБЫТИЯ ?
0E2F1B0E2E1E0E2F190E2E2F0E2E210E2E2B0E2E2E0E2E220E1B2C140E2E2F0E2F190E2E2
10E2F1A0E2E2E0E2E1E0E2E1D0E2E210E2E2D0E2F2F0E2E220E2F1A0E2F2F140E2E2A140E
2F190E2E1E0E2E200E2E1E0E2F190E2E1B0E2E190E2F1F0E2E210E2E21140E2E1D0E2E1B0
E2E190E2F200E2E1E0E2F190E2E2E0E2E1B0E1B2C140E2E2C0E2E2E0E2F200E2E19140E2F
1A0E2E2E0E2E1B0E2F1A0E2E1E0E2E2C140E2E190E2F1E0E2F1C0E2E1E0E2E2B0E2E190E1
B2C140E2E2D0E2E19140E2F1A0E2E2E0E2F1A0E2E190E2F200E2E1E140E2E2C0E2E2E0E2F
200E2E1E0E2F190E2E190E2F1B0E2E2E0E2F190E2F2B140E2F1A0E2E2B0E2E210E2E1B0E2
E190E2F2E0E2F1B145259140E2E190E2E2D0E2E2E0E2E2D0E2E2E0E2E1B140E2F1A0E2E1B
0E2E2E0E2E210E2E2C140E2E1D0E2F190E2F1C0E2E1F0E2E2A0E2E190E2E2C140E2E210E2
E2B0E2E21140E2E2F0E2F190E2E2E0E2F1A0E2F1B0E2E2E140E2F190E2E190E2E1D0E2E21
140E2E2B0E2F1C0E2E2B0E2E200E2E2E0E2E1B0E1B2C140E2F210E2E2A0E2E2E0E2E2B0E2
F2C0E2E2D0E2E210E2E2A0E2E21140E2E1B0E2F2B0E2F1B0E2E210E2F190E2E190E2F2E0E
2F1B140E2E2E0E2E1A140E2F1B0E2E1E0E2E1A0E2F2F140E2E2D0E2E2E0E2E1C0E2E210E1
B2C140E2E2F0E2E190E2F190E2E190E2F210E2E19140E2E1B140E2F1F0E2E1E0E2E2B0E2E
2E0E2E2C140E2E2F0E2E210E2E190E2F190E2E210E2F1B0E2F1A0E2F2F140E2E2D0E2E191
40E2E2F0E2E2B0E2E2E0E2F220E2E190E2E1D0E2E2A0E2E190E2F1E140E2E1D0E2E2B0E2F
2F140E2E2D0E2E2E0E2F190E2E2C0E2E210E2F1A0E2E2E0E2E1B170E2C1B0E2E2E0E2F1B1
40E2E2C0E2E1E0E2F1A0E2F1B0E2E2E140E2E1C0E2E1D0E2E1E140E2F1B0E2F2B140E2E2F
0E2E2E0E2F200E2F1C0E2E1B0E2F1A0E2F1B0E2E1B0E2F1C0E2E1E0E2F210E2F2C140E2F1
A0E2E1E0E2E1A0E2F2F140E2E1B140E2F1C0E2F2E0E2F1B0E2E1E0E1B2C140E2E2C0E2E1E
0E2F1A0E2F1B0E2E2E140E2E1C0E2E1D0E2E1E140E2E2D0E2E1E0E2F1B140E2E2C0E2E2E0
E2F200E2E21140E2E2E0E2F1B140E2F1A0E2E2B0E2E2E0E2E1B0E2E19140E2F1A0E2E2E0E
2E1B0E2F1A0E2E1E0E2E2C0E1B2C140E2E2C0E2E1E0E2F1A0E2F1B0E2E2E140E2E1C0E2E1
D0E2E1E140E2E1E0E2F1A0E2F1B0E2F2C140E2E200E2E1E0E2F190E2E2A0E2E190E2E2B0E
2E2E140E2F1B0E2E2E0E2F190E1B2C140E2E19140E2E1D0E2E190E2E1F0E2E1E140E2E1E0
E2F1A0E2E2B0E2E21140E2F1B0E2F2B140E2E2F0E2E2E0E2F1A0E2F1B0E2E210E2F210E2F
2C140E2F1A140E2E2A0E2E2B0E2E210E2F190E2E191416140E2F1A0E2E210E2F1A0E2F1B0
E2E1E0E2E2C0E2E19140E2F210E2E210E2F1D0E2F190E2E2E0E2E1B0E2E190E2E2D0E2E21
0E2F2F140E2E2D0E2E1E140E2E2F0E2E2E0E2E2A0E2E190E2E1F0E2E1E0E2F1B140E2E190
E2E1D0E2E2C0E2E210E2E2D0E2E210E2F1A0E2F1B0E2F190E2E190E2F1F0E2E210E2E2114
0E2F1B0E2E1B0E2E2E0E2E1E0E2E1C0E2E2E14525917140E2C1D0E2E2E0E2E1A0E2F190E2
E2E140E2E2F0E2E2E0E2E1F0E2E190E2E2B0E2E2E0E2E1B0E2E190E2F1B0E2F2C140E2E2D
0E2E19140E2F190E2E1E0E2E200E2E1E0E2F190E2E1B0E2E190E2F2014515D5D595C0E1C2
A0E1B2F0E1B2F555855524F5861174C4C0E1B2F5C580E1B2F
>Из машины Тьюринга можно построить любую вычислительную систему.
И? Как из утверждения "на машине тьюринга можно реализовать что-то более выразительное" следует утверждение "машина тьюринга сама столь же выразительна".
Если тебя выразительность машины тьюринга устраивает, то открывай брейнфак и пиши там, никаких функций, объектов, замыканий чтоб я не видел в твоём коде.
>Математика - лженаука, она изучает несуществующий предмет
Вот два пальца, вот три пальца, посчитай вместе будет пять пальцев.
Вот один человек, вот четыре человека, посчитай вместе будет пять человек.
Вот человек говорит с тобой, спрашивает сколько человек в том здании, ты говоришь ему "пять", он представляет себе пять человек.
Охуенно блядь несуществующий.
>покажи мне отдельно существующее число в природе. Их нет.
Из этого не следует, что концепция числа ничего не значит, т.к. всякое число является отображением реальности, как я только что показал на примере пальцев и людей.
Ну насчёт мнимых чисел разве что точно не скажу, а всякое действительное число это совершенно точно способно описывать реальный мир с пальцами, людьми и килограммами.
Так то же самое касается лямбдакалькулюса, который ты противопостовлял Тьюрингу. Вот уж от кого смешно слышать претензии к похожести на брейнфак.
Так что это у нас тут? Пациент не способен к простым обобщениям. Из анамнеза: легкая степень олигофрении.
>Звук слышно ушами.
https://www.youtube.com/watch?v=kzo45hWXRWU
Звук слышно мозгом. Так же, как и числа, которые воспринимаются им же
>Каким органом чувств воспринимаются числа?
Мозгом, как и пальцы со звуками.
Для этого правда нужно абстрактное мышление, но судя по тому что ты способен выучить и понимать человеческий язык, что ты нам тут и продемонстрировал, оно у тебя имеется.
Если ты считаешь что способность воспринимать обобщения это для петухов и нинужно, то сразу после того как прочтёшь этот пост тебе следует перестать пользоваться языком, ибо язык это тоже обобщение, ведь в мире не существует слова "яблоко", в мире есть только яблоки, а слова ты уже мозгом воспринимаешь.
Последствия перенесенного гриппа дают о себе знать
Ну не. Там наверное про восприятие частоты. Так то я даже с таким знаком https://ru.wikipedia.org/wiki/Зонная_теория_музыкального_слуха
Но сам звук то воспринимается ухом физически. Улитки, барабанны перепонки, наковаленки с молоточками и стремечками, вот это все.
Давай-ка разберём по порядку.
Допустим ты начал разговор, искренне желая помочь избавиться от заблуждений оппоненту, тогда как оппонент заблуждется опять же совершенно искренне (а не толсто тралирует).
Дальше ты видишь, что твой оппонент показывает себя демагогом, реагируя на пост другого человека соответствующим образом.
Теперь ты понимаешь, что твой оппонент - демагог. Можешь ли ты расстроиться из-за того, что не смог разубедить демагога? Нет. Демагога разубедить невозможно, т.к. он не за истиной в дискуссию приходит.
Но ты расстраиваешься. Почему? Ответ прост - потому что ты на самом деле тоже демагог, преследующий цель посоревноваться в ментальной гимнастике. Истина тебе побоку, тебе надо просигналить свой ум и подвешенный язык.
А теперь вопрос - почему меня должно ебать, что я разломал дискуссию двум демагогам? Да сосите хуй, ёпт, меня это только радует.
>А теперь вопрос - почему меня должно ебать, что я разломал дискуссию двум демагогам?
Потому что этот демагог - ты, лол. Вот твои посты.
>>1615581>>1615483>>1615445
Я прошел мимо и захотел помочь твоей точке зрения (хотя всю твою ФП-шизу и 0 новых мыслей за последние годы я в рот ебал, ты один из самых скучных долбоебов на борде). Ты спиздил у меня аргумент (потому что сам лучше не придумать не можешь), но при этом полил (как обычно) кучей графоманского дерьма, полного самолюбования. Твой оппонент доебался до этого самолюбования, и ты, как собачка, побежал за ним, в вашем демагогическом самоотсосе.
>кидает понятную нотацию
>пытается высмеять, напирая на непонятность
А что непонятно-то? Вот объявления функций, вот тела функций, вот вызовы функций.
Никаких перещёлкиваний регистриков при этом не происходит, машина никем не командует, в отличие от императивщины, где машина приказывает программисту помнить где там чё в ней хранится. Функциональный и объектный подход - это сила, это путь наверх, императивные портянки это обсасыванье байтов всемогущей машине, это путь во времена рабства.
А я и не утверждал будто я не демагог, лул. Что не отменяет того, что вы двое - демагоги.
>всю твою ФП-шизу
Подожди, в приведённых тобой постах нет ничего про ФП.
Я наткнулся на пост >>1615263 и решил позабавиться над очевидной хуйнёй
>Математика - лженаука, она изучает несуществующий предмет, покажи мне отдельно существующее число в природе.
Не путай меня со своими протыкателями, которые уже миллион лет тебя тралируют тут (сочувствую кстати, если так), я лично и в фп-тред не заходил, если он тут вообще есть.
А, пробежал по треду и понял, что тут произошло.
Вот этот чел - >>1610689 , который пишет зачем-то с большой буквы термины - не я.
Потом пришёл я и встал на его сторону.
Потом пришёл ты и встал на мою сторону.
Потом ты решил, что раз мы защищаем с тем аноном один тезис, следовательно мы - один человек.
Что-ж, ты ошибся.
>но число в природе так показать и не смог
А где-то подписывался, что буду число в природе показывать? Я сказал
>>покажи мне отдельно существующее число в природе. Их нет.
>Из этого не следует, что концепция числа ничего не значит, т.к. всякое число является отображением реальности, как я только что показал на примере пальцев и людей.
Число - отображение реальности, её модель, а не сама реальность.
Мы можем с такой моделью ракеты в космос запускать. С такой моделью мы можем спроектировать протоколы для обмена сообщениями на сосаче, значит нам обоим есть выгода от этой модели. Вот и обоснование нужности математики. А шифрование с открытым ключом это вообще на 99.9% "ненужная и реально в природе не существующая" математика.
>А где-то подписывался, что буду Бога в природе показывать? >Бог - отображение реальности, её модель, а не сама реальность.
>Мы можем с такой моделью ракеты в космос запускать. С такой моделью мы можем спроектировать протоколы для обмена сообщениями на сосаче, значит нам обоим есть выгода от этой модели. Вот и обоснование нужности Бога. А шифрование с открытым ключом это вообще на 99.9% "ненужный и реально в природе не существующий" Бог
>в программе, записанной совокупностью чётких инструкций перехода, разобраться может разве что мыщьх, которому в детстве хлористого кальция укололи, потому что только аутизм способен заставить человека добровольно становиться рабом машины, следящего за состоянием каждого регистрика
Но нам-то, простым людям, без волшебной инъекции как быть?
Ну если бог это не сама реальность, а мужик на небе, то не мне доказывать его существование.
А доказать математику - запросто. Вот я зашифровал сообщение открытым ключом, вот ты его не можешь за обозримое время расшифровать, через день сдаёшься я тебе даю закрытый ключ и ты расшифровываешь Потом я описываю, как мне это удалось - с помощью несуществующих в природе чисел, и ты такой "ой бля, ну ладно, не существуют и хуй с ними, раз мои задачи решают значит так и быть". Либо ты отказываешься от шифрования, а значит немедленно выходишь с двача, потому что тут https, который не работает, потому что спроектирован с помощью неработающей лженауки.
>у меня пять человек в команде
>отправляемся в поход на неделю
>сколько суточных пайков ложить в мешок?
>хмм, пять умножить на семь?
>не, нихуя, числа сами по себе ничего не означают, а умножить людей на дни и получить пайки я не могу, это бред
>поэтому будет методом проб и ошибок устанавливать нужное число пайков
>точнее не число, а прям вот сами пайки в реальности, а то чисел ведь нет
>если на каннибализм не перейдут, и лишних пайков не останется, значит взяли ровно столько существующих в реальности пайков, сколько нужно
>зато об абстракции не зашкварились
>подожди, а как ты понимаешь такие слова как союзы и предлоги, если они ничего в релаьности не означают?
>заткнись сука
А где-то подписывался, что буду число в природе показывать? Я сказал
>>покажи мне отдельно существующее число в природе. Их нет.
>Из этого не следует, что концепция числа ничего не значит, т.к. всякое число является отображением реальности, как я только что показал на примере пальцев и людей.
Число - отображение реальности, её модель, а не сама реальность.
Мы можем с такой моделью ракеты в космос запускать. С такой моделью мы можем спроектировать протоколы для обмена сообщениями на сосаче, значит нам обоим есть выгода от этой модели. Вот и обоснование нужности математики. А шифрование с открытым ключом это вообще на 99.9% "ненужная и реально в природе не существующая" математика.
>Поллинг.
"Поллинг" и "Событие" - разные вещи.
Где есть возможность применить второе вместо первого, следует использовать именно событие.
Так как поллинг при частом опросе пожирает процессорное время, а если экономить, то между опросами появляется интервал не реагирования, то есть при поллинге возникает одно из двух зол - или затратность при большой скорости реагирования или задержка реагирования при экономии ресурсов.
"Событие" действует иначе :
Никаких судорожных движений код не совершает, при этом временной интервал между наступлением события и реакцией на него - предельно минимален.
Класс имеет встроенный механизм для проектирования событий.
По правде говоря, событийно-управляемое приложение можно написать и без использования классов. Однако списком или структурой такое приложение не ограничится. Это будет, не менее сложный код, чем код, основанный на применении класса и даже тогда возможностей класса он иметь не будет :
Тут ведь в чём "волшебство" ? - из класса можно штамповать любое количество "экземпляров класса"(объекты), всего одной строкой кода.
На самом деле, и тут можно обойтись без применения класса, написав код, между прочим, мало чем, принципиально, отличающийся от класса. И это похвально ибо не секрет, что код, хотя бы на один уровень абстракции ниже, чем более высокоуровневый, имеет возможность оказаться, по сравнению с ним, оптимальным.
Хотя более простым и читабельным - он точно не окажется.
Читабельность наших изваяний может быть востребована в определённом случае : когда у твоего кода много поклонников и критиков.
Но если ты склонен писать только не доступные уразумению бездарных толп, шедевры - то тогда, конечно, не надо гоняться за простотой. Но и о здравом смысле забывать негоже :
А то ведь, была такая передача про Японию, однажды, в телевизоре, дак там один невьебенный Мастер удочек - бамбуковую удочку тридцать лет делал ! - и сделал.
А другой сделал рубанок - дак тот рубанок с доски срезал стружку толщиной восемь микрон, прозрачная !
Надлежит ли нам уподобится этим экспертам ? - скажу честно "хрен его знат".
>"Событие" действует иначе :
>Никаких судорожных движений код не совершает, при этом временной интервал между наступлением события и реакцией на него - предельно минимален.
>Класс имеет встроенный механизм для проектирования событий.
То ли я нихуя не смыслю, то ли ты.
Вот как мне известно: события в компьютерах организуются одним из двух способов: либо event loop, что означает "я дрочу процессор каждые n секунд и мне похуй на быстродействие" (что кстати объясняет почему в некоторых игрушках типа скайрима всё рушится если фпс отклоняется от строго заданного числа - там event loop привязан к частоте кадров), либо аппаратные прерывания (вот тут действительно производительность не страдает, ибо обработчик прерываний запускается не постоянно).
Но как именно в плане быстродействия держать ивент луп может быть быстрее, чем опрашивать объект? Чего я не вижу?
Ух, теоретики как раскукарекались-то.
Чисто интуитивно, мне кажется, что под капотом, на уровне ОС или фреймворка там все равно поллинг. Ну, не считая конечно некоторых аппаратных прерываний процессора. Но думаю их можно исключить из рассмотрения, потому что они там где-то на уровне ядра, драйверов. Да и даже прерывание не бесплатное, не помню сколько, но несколько тактов уйдет на сохранение всех регистров. А дальше мы имеем что-то вроде circular buffer, который постоянно должны проверять в некоем event-loop, по расписанию шедулера, или просто всегда когда можем, когда дойдет выполнение. А наполняется этот буфер уже событиями из других потоков. Так что ИМХО все события это просто синтаксический сахар, и никаких особых трудностией их использовать без классов и объектов никогда не было. А насчет читабельности - ну там просто такой switch с пачкой событий, вполне себе красиво выглядящий.
>Но как именно в плане быстродействия держать ивент луп может быть быстрее, чем опрашивать объект?
Может быть он имел в виду, что опрашиваются все объекты постоянно? Хз. Хотя с другой стороны, а ведь они все равно опрашиваются постоянно. К примеру, событие mouseOver. В любом случае где-то под капотом будет цикл foreach(r in rect) if m.x>=r.x && m.x<=r.x+r.w и т.д.
>Чисто интуитивно, мне кажется, что под капотом, на уровне ОС или фреймворка там все равно поллинг.
Мало ли что там "всё равно".
В конечном итоге там всё равно несколько регистров, каждый из которых является всего лишь аналогом числовой переменной - но это не значит, что если написать, например, полный аналог Ассемблерного кода на высокоуровневом языке(а это вполне возможно), то будет хорошо.
Если бы цикл Loop на высокоуровневом языке оборачивался с частотой несколько сотен мегагерц... то почему бы и нет ?
Можно было бы тогда даже многозадачные приложения писать, аналогично тому, как пишется многозадачное приложение для микроконтроллера и не нужны никакие "события".
Вернее, "события" делались бы простыми проверками тех или иных условий в беспрерывно работающем цикле. На контроллерах так и делается.
Да и процессор, наверняка, так же, принципиально, работает.
Но вот не крутится цикл Loop в приложении, которое само работает в порядке очереди, притом, не самой приоритетной очереди, в порядке других задач. Этот цикл может оказаться, на самом деле, я не знаю, циклом десятого уровня вложенности, если отсчитывать от цикла работы процессора.
Поэтому стиль программирования для низкоуровневого не стоит применять(хотя работать будет) по отношению к высокоуровневому коду.
Да это все понятно, но никак ты не избавишься от этого евент лупа, сколько не закапывай его под ковер. Как не избавишься от foreach, пиша map/reduce. Ну если тебя так смущает event loop, напиши его где-нибудь в файлике main один раз и спрячь с глаз, а погоди, твой фреймворк с событиями ровно так и поступает.
>но никак ты не избавишься от этого евент лупа, сколько не закапывай его под ковер.
А я и не собирался "избавляться" от евент лупа. Он никуда деться не может.
Просто если мы его будем сами писать в своём коде, он будет выполняться с одной скоростью,
Но если мы "оставим его под ковром", то там он выполняется совсем с другой скоростью, не достижимой для кода, который мы пишем.
Именно поэтому не надо его из под ковра вытаскивать.
Вот аналогия :
Есть внутренняя функция языка "InStrB()", она скрыта от глаз "под капотом" и наверняка написана на машинных инструкциях.
Недавно я попробовал написать её аналог на самом языке - скорость выполнения написанного мною аналога оказалась в тридцать раз медленнее ! - что бы мы не вытаскивали из под капота в код высокоуровневой программы, окажется медленнее, чем вызов интерфейсного метода или оператора или внутренней функции языка.
Там, под ковром(или за методом WinAPI), может и вращается цикл, но он, по любому гораздо подвижнее цикла, который мы можем написать в своём коде.
Пишутся, конечно. Но названия понятий не относятся к именам собственным.
https://ru.wikipedia.org/wiki/Имя_собственное
>Что следует из?
Дак я же привёл пример "вытащенной из под капота" функции.
Но ты можешь и сам попробовать ловить "событие" путём опроса значения какой либо переменной с помошью зацикленного условия, с одной стороны.
И использовать системную функцию "MsgWaitForMultipleObjects", с другой.
Протестируй результативность двух вариантов кода :
1. Посмотри чо показывает счётчик загрузки процессора.
2. Измерь интервал, между ожидаемым событием и реакцией на него.
Здесь : http://www.firststeps.ru/mfc/msdn/r.php?85 список ожидающих функций
В природе есть понятие количества. Цифры это абстрактные величины, которые обозначают количества, меры, объемы, единицы измерения. Математика это та наука, которая абстрактное делает явным, пригодным к изучению. Чтобы рассуждать о явлениях, необходим язык, который будет описывать эти явления. Математика дает такие языки. Арифметика это не более чем формальная система, язык описания некоторых явлений.
Одна из самых простых формальных систем - логика высказываний. На ее основе строятся более сложные. В твоих словах есть противоречия логике высказываний. Например, что математика не наука только потому, что в живой природе нет чисел - это наглая ложь. Я уже доказал, что числа всего лишь язык описания количества. Самое явление количества совершенно естественно, оно присутствует в природе, оно незыблемо. Далее не вижу смысла опровергать твои слова, хотя это не сложно сделать. Просто если у тебя в логике высказываний противоречия, то что будет если говорить о более сложных вещах.
Если тебе непонятны эти символы, это не означает, что это что-то сложное, убогое, невыразительное. Вот эти несколько строк кода могут выполнять столько же, сколько сотня строк для Машины Тьюринга. Выходит, что лямбда-асбтракции более выразительны, более лаконичны. Что собственно и требовалось доказать.
Если тебе непонятны goto в машине тьюринга, это не означает что это что-то сложное, убогое, невыразительное. Вот эти несколько goto могут выполнять столько же, сколько сотня строк лямбда калькулуса. Выходит, что машина Тьюринга более выразительна, более лаконична.
Что собственно и требовалось доказать.
>Если тебе непонятны goto в машине тьюринга, это не означает что это что-то сложное, убогое, невыразительное. Вот эти несколько goto могут выполнять столько же, сколько сотня строк лямбда калькулуса. Выходит, что машина Тьюринга более выразительна, более лаконична.
Еще как означает. Из десятка комбинаторов можно сложить сколько угодно мощный язык программирования. И это займет крошечный объем текста. Потому что высокая выразительность, лаконичность. Высокий уровень абстракции. Машина Тьюринга обладает низкой выразительность, лаконичностью, крайне низким уровнем абстракции. Поэтому нельзя на ней сделать тоже самое как с помощью десятка комбинаторов, не написав тысячи строк кода, который к тому же будет еще и дурно пахнуть, будет неподдерживаемым.
Один долбоеб, думающий, что понимает ООП, пытается что-то доказать другому такому же долбоебу.
>На нормальном языке c++ такой проблемы не возникнет.
Дак InStrB это как раз и есть внутренняя функция языка VB6
Просто я сделал то, что не должен был делать :
Я описал функцию с помощью набора других.
Внутренние функции и операторы выполняются быстро, но если вместо того, чтобы просто вызвать функцию или оператор, вызвать набор других, к тому же в сдвоенном цикле - получается "В Сочи через Магочи", на каком бы сверхбыстром языке, это не делалось, даже если сильно верить в обратное.
Это не название географического места и не имя человека (и не один из ещё кучи случаев которые мне лень перечислять).
Потому что в противном случае у нас будут Физика, Химия, Теорема Котельникова, Электронно-лучевая трубка, Электромагнитное излучение и прочие перлы.
Чисел вообще не нужно. Есть понятие количества, которое незыблемо на планете Земля. Можно описывать его как угодно, хоть с помощью палочек, как это делали в старину. Можно с натяжкой сказать, что чисел нет, но если человек отрицает существования количественных явлений вообще, то это попахивает умственной отсталостью.
>Вот эти несколько goto могут выполнять столько же, сколько сотня строк лямбда калькулуса.
В том то и дело, что не могут. Доказывай.
>Выходит, что лямбда-асбтракции более выразительны, более лаконичны
Выйдет, как только будет доказан пункт 1.
>Что собственно и требовалось доказать.
Ишь какой, а собственно доказать для начала ты не пробовал?
Имя собственное (калька с лат. nomen proprium, которое в свою очередь является калькой с греч. ὄνομα κύριον)[1], собственное имя[2] — имя существительное, обозначающее слово или словосочетание, предназначенное для именования конкретного, вполне определённого предмета или явления, выделяющее этот предмет или явление из ряда однотипных предметов или явлений.
http://gramota.ru/biblio/magazines/gramota/onomastics/28_126
У тебя плохие примеры. Электронно-лучевая трубка собирательное название. Теоремы различные и так принято писать с большой буквы. Насчет физики, химии, и прочего, тут надо смотреть контекст.
>имя существительное, обозначающее слово или словосочетание, предназначенное для именования конкретного, вполне определённого предмета или явления, выделяющее этот предмет или явление из ряда однотипных предметов или явлений[/B]
Вот эту часть не учёл. То есть должно существовать некоторое множество обязательно конкретных предметов или явлений, из которого ты выделяешься названием.
Множество людей, множество рек, множество сайтов в интернете, множество компьютерных игр, множество ураганов (все ураганы как ураганы, а ты - "Катрина").
А лямбда-исчисление это из множества чего? Из множества формальных систем? Так формальные системы не конкретны, нельзя подойти, пальцем показать и сказать - "во, смотри, формальная система!"
>Теоремы различные и так принято писать с большой буквы
Не-а. "Я доказал теорему Пифагора" а не "Я доказал Теорему Пифагора".
>не участвующий в тупых терминологических срачах, а решающий прикладные задачи
Какое забавное противопоставление. А одно другому мешает?
Я решаю прикладные задачи так, как мне нравится, и в срачах слушаю аргументы тех, кто делает не так, мотаю на ус и модернизирую свои навыки. Диалектика в действии.
>Естественно у природы никакого понятия количества нет.
В природе это есть. Есть озера большие и есть маленькие. Разница в КОЛИЧЕСТВЕ воды. Есть двуногие и четвероногие живые существа. Ты так неумело троллишь или у тебя действительно сдвиг по фазе? Просто если ты не ощущаешь вокруг себя количественные явления, то это умственная отсталость. И вряд ли с таким IQ тебя бы взяли в крутой универ на научную или инженерную специальность.
>Бог любит нас и на всё Его воля
>Интересно, возьму на заметку.
Анон, ну я же, мать его, инженер. Какой от меня прок если я буду брать на заметку всё подряд без критической оценки?
Если ты мне продаёшь бронежилет, я сначала выстрелю в тебя, а потом куплю, если останется у кого покупать. Тезис должен столкнуться со старательно выкованным мной антитезисом, и лишь то, что останется на этом пожарище, будет истиной. Которую стоит брать на заметку.
>Поэтому ты расскажи как бы ты в процедурном стиле описал новый тип данных? У тебя есть стандартные типы - целое, число с плавающей точкой, символ, булеан. А тебе нужен, например такой тип как время в формате hh:mm:ss.
Не в процедурном, а в функциональном. Очень просто. С помощью функций. Также как в СИКП реализуют рациональные числа и арифметику над ними.
>если бы ты писал на c++ или asm такой проблемы бы не было.
Касаемо Ассемблера - в нём нет внутренних функций, помимо элементарных операторов.
А в чём заключается "проблема", о которой ты говоришь ?
Никакая внутренняя функция языка, описанная с помощью других внутренних же функций этого языка не может работать медленнее, чем её костыляторная имитация. Вернее, может конечно. Только вряд ли разработчик языка мог написать такую.
Но ты мог бы посоревноваться с ним сам. Потому что лично я не питаю подобных тщеславных надежд.
Простое переиспользование кода. Объекты можно рассматривать как модули. К тому же, ООП решает проблемы древних байтоебских типов.
Никто не использует НЕ ДОЛЖЕН использовать ООП в чистом виде. Но частичное его применение позволит правильно организовать данные программы.
Ну тут я бы поспорил, если ты вебмакака-кодер то возможно, а вообще говоря сама сущность объекта, принципы как их выделять из окружающего мира, принципы наименования, долго можно продолжать. Можно еще вспомнить про этическую сторону (не делать программы убивающие людей, отнимающие работу, и т.д.)
>Для чего нужно ООП?
А для нужно погромирование?
>Для чего нужно ООП?
Для удешевления труда программистишек, чтобы знали свое место и не задирали носы.
>Какие проблемы и задачи оно решает?
Позволяет писать сложные проекты горсткой дешевых, легко заменяемых индусов. Java, C#, это вот все.
главный принцип программирования очевиден: сколь угодно сложную задачу можно разбить на кусочки, настолько простые, что с ними справится кто угодно. С тех пор ничего не изменилось. И этот принцип работает не только в программировании.
объектно-ориентированное программирование, когда программу собирают из структур, содержащих и данные, и методы их обработки.
Вспоминается официальное сообщение о языке Алгол-68: «всякое действие, описанное в настоящем сообщении, может быть заменено любым иным действием, дающим такой же внешний эффект». Эта фундаментальная концепция, на мой взгляд, ещё довольно долго останется одной из ключевых в программировании. Так же, как до того ключевой была идея структурного программирования, то есть той самой декомпозиции сложной задачи на элементарные компоненты, но только в применении, прежде всего, к методам обработки, а уж затем к структурам данных.
Это полная хуйня. Так же можно сказать что всё на свете это процесс, или что всё на свете это энергия, или что всё на свете это Аллах.
Объект это слишком абстрактное понятие. Математические объекты и объекты из ООПе - и то и то как бы объекты, но объекты разного толка.
Процитирую классика.
современое ООП:
толпы быдла долбятся головами об стену невидя двери - для них выпиливают люк.
/thread
Interface Pussycat {
Kingdom: Animalia;
Phylum: Chordata;
BioClass: Mammalia;
Order: Carnivora;
Suborder: Feliformia;
Family: Felidae;
Subfamily: Felinae;
Genus: Felis;
Species: FelisCatus;
}
Наличие всех этих интерфейсов, естественно, подразумевается. У нас же тру-ООП.
Двачую, ООП это полный дебилизм
Зачем делать
МояЖопа = новая Жопа(); НовоеГовно = новое Говно(); если(МояЖопа.Говно) МояЖопа.Срать(); иначе МояЖопа.ЗалитьГовна(НовоеГовно);
когда можно просто Срать(Говно)?
Полиморфизм - создал один раз и это работает для многих классов и их наследников, чтобы расширить функционал, тебе не надо лезть в уже существующий код, ты просто наследуешь класс или интерфейс.
Наследование - весь одинаковый функционал, всё общее помещаешь в абстрактные классы, интерфейсы и классы, а конкретное в классы которые их наследуют и реализуют. Всё получается коомпактно и без дублирования.
> Для этого достаточно первоклассных модулей, реализующих одинаковый интерфейс.
Это ООП и есть, лол. Только данные и код можно хранить вместе, и не надо каждый раз передавать структуры в функции, как в процедурном программировании.
> пока всякие пидары не сделали из него хуй пойми что
Если ты про наследование, то оно нахуй не нужно. А если про SOLID, то это лишь способ организации кода, к понятию ООП это ничего принципиально нового не добавляет.
мимо
>Инкапсуляция - даёт возможность использовать одинаковые названия для переменных и не бояться, что код наебнется. Служит инструментом для изоляции кода, который будет независим от внешнего кода и будет зависеть от кода в который инкапсулирован, т. е. обязан выполнять определенную политику, которая гарантирует работу кода о котором этот код не знает.
Этого можно добиться неймспейсами, модулями и замыканиями.
> Есть у тебя класс с методом, который принимает классы реализующие определенный интерфейс - тебе не нужно знать, что этот метод делает внутри, тебе достаточно реализовать этот интерфейс у своего класса.
Как-будто это какая-то эксклюзивная фича ООП. Протоколы/бихейверы/тайпклассы/интерфейсы модулей, и т.д. дают то же самое.
> чтобы расширить функционал ты просто наследуешь класс
Ага, уже представляю этот горизонтальный шум, если каждая хуитка вынесена в отдельный класс, и потом весь этот ворох говна наследуется где-то в классе на три строчки, который непонятно что делает, пока не просмотришь каждый родительский класс и глаза не вытекут нахуй. За все эти развесистые деревья наследования уже начиная со второй половины нулевых стали заслуженно давать по ебалу; современное ООП это вообще не про наследование, наоборот стараются всё делать максимально плоским, насколько возможно, потому что помнят как с наследованием говна поели в 90х-00х. Абстракция через наследование - самая хрупкая абстракция евер, все эти заманчивые книжные примеры для нубов Cow extends Anymal в реальной жизни превращаются в абсолютно убёщное неподдерживаемое говно, такое что потом никакой SOLID, с препроцессором на аннотациях не спасает.
>Этого можно добиться неймспейсами, модулями и замыканиями.
Этого недостаточно, всё тобой перечисленное всего лишь крупнозернистый ООП и не более. Классы, интерфейсы дополняют этот ООП, превращая его в мелкозернистый и обогащая функционал, возможности, облегчая работу для программистов.
>Протоколы/бихейверы/тайпклассы/интерфейсы модулей, и т.д. дают то же самое.
Что-то ты совсем тупенький. ООП как раз и создан для реализации протоколов и поведений. Как ты их без ООП реализовать собрался? Типа "давайте просто на бумажечке запишем, что вот так вот делать будем, а потом каждый будет смотреть на бумажечку, перед тем как код писать"? Вот ООП как раз и избавляет тебя от написания бумажечек, ООП автоматизирует ту часть, которую раньше необходимо было поддерживать вручную. ООП следит за тем чтобы протоколы не нарушались а поведение не становилось непредсказуемым.
>Ага, уже представляю этот горизонтальный шум, если каждая хуитка вынесена в отдельный класс
Ну давайте теперь бензопилами не пользоваться, потому что какой-то васян уронил её на себя и отхуячил половину руки. Чего ты сказать то хотел? Да, нужно учить принципы SOLID, понимать их, для того чтобы строить адекватные ООП архитектуры без раздувания кода. Но это вопрос квалификации пользователя инструмента, который никак не влияет на пользу от использования этого инструмента квалифицированными людьми.
>Этого недостаточно
Чего не достаточно, сектант? Ты вообще читаешь на что ты отвечаешь? Ты пишешь что тебе нужен скоупинг, всё выше перечисленное даёт скоупинг и большинстве случаев инкапсуляцию.
>Что-то ты совсем тупенький. ООП как раз и создан для реализации протоколов и поведений. Как ты их без ООП реализовать собрался?
Пиздос. Ну не знаю, откуда тогда в Erlang/Elixir/Clojure есть бихейверы и протоколы, может сейчас окажется что это ООП всё языки. Я уже молчу про ML-семейство с их системой модулей или хаскельские тайпклассы, которые позволяют добиться этого же и даже больше.
Дальше читать твой пост не вижу смысла. Судя по всему ты какой-то нуб, который нихуя в своей жизни кроме процедурщины и ООП не видел, но берёшься размышлять о полиморфизме и инкапсуляции. Убогий полиморфизм на сабтайпинге и инкапсуляция уровня public/protected/private это лишь один из многих вариантов, причём не самый удачный, получивший широкое распространение по исторической случайности.
Видел такое в окамле. Чем-то напомнило шаблоны из крестов, ведь это тоже самое compile time polymorphism. Классная штука сама по себе, но не очень гибкая, но это может я просто не видел других реализаций? Проблема возникла когда я пытался одновременно замокать Lwt и Lwt_io и делал это с помощью модулей. Мой модуль использовал два модуля которые использовали друг друга, и мне пришлось городить вложенные модули как здесь https://sketch.sh/s/jj2oZ5xAsjBRms5Z2DMTt4/ . Если представить, что таких модулей у меня пять и более, то там вложенность будет просто ебучая. Я не фанат ООП, но тут признаю, что интерфейсы удобнее и гибче.
Ну хуй знает, я на эликсире уже лет 5 пишу, вакансии регулярно прилетают, как то не заметил его смерти.
Но вообще забавно как ты, обосравшись, решил сменить тему. Мань, речь шла о том, что есть масса не ОО-языков, в которых есть всё о чём ты пишешь. Причём я привёл пару продакшн-ЯП, которые используются на практике, а не какую-то обскурную экзотику.
Просто, как и я сказал выше, ты зашореная чмоха, которая нихуя кроме ОО-параши в жизни не видела. Само по себе это не порок конечно, люди идут программировать на жабе/похапе не от хорошей жизни, да и на языки и с программированием им насрать по большому счёту, но вот с умным видом что-то пояснять про полиморфизм/икапсуляцию с таким ограниченным кругозором это пиздец позорище.
>что есть масса не ОО-языков, в которых есть всё о чём ты пишешь.
Ты забываешь уточнять, что это только твоё мнение, которое ничем кроме твоего манямирка не подкреплено.
>Причём я привёл пару продакшн-ЯП, которые используются на практике
На С без всякого ООП целые операционные системы писали, представь себе. Вот только каким хуем это наделяет С всем тем, что есть у ООП и каким хуем оно отменяет те возможности, которые ООП предоставляет, одному тебе, долбоебу, известно.
У тебя на всё один аргумент - ЭТО ЕСТЬ И В ФУНКЦИОНАЛЬНОМ ПАГРАМИРАВАНИИ!!! Хотя сама суть разделения на ООП и ФП это отрицает. Т. е. ты с голой жопой идёшь против всего мира, а потом еще и возмущаешься, когда тебя никто всерьез не воспринимает.
Что вы несёте, сударь?
Функциональщина (фундаментальная операция - редукция выражения), противопоставляется императивщине (фундаментальная операция - присвоение, т.е. запись блядских нулей и единиц в блядскую ячейку памяти).
ООП это частный случай императивщины, это даже не парадигма, и никаким боком не противопоставление ФП, именно поэтому "ЭТО ЕСТЬ И В ФУНКЦИОНАЛЬНОМ ПАГРАМИРАВАНИИ!!!" - чистейшая правда. Да, оно (классы и объекты) там действительно есть. Чего там нет - так это присвоения.
> Функциональщина (фундаментальная операция - редукция выражения), противопоставляется императивщине
Нет, это декларативщина противопоставляется императивщине, И она бывает не только функциональной, но и логической, например, Prolog. inb4: Prolog - это функциональщина, и ООП функциональщина, и ассемблер функциональщина, и небо и аллах функциональщина
Нет.
Противопоставления всего два. Первое - "вычислить vs исполнить". Это функциональщина со своими вычислениями против императивщины со своими записями в память (ты будто вообще не читал мой пост). Можно редуцировать это понятие вплоть до лямбда-исчисление против машины Тьюринга.
Второе - "механизм vs декларация", где механизм - "вот конкретная последовательность действий чтобы превратить выражение в результат", а "декларация" - это когда ты описываешь задачу в терминах конечного результата ("я даю тебе значения, ты мне дай предикат который им удовлетворяет"), а программа даёт результат не с помощью чёткого алгоритма, а с помощью перебора.
Ты смешал понятия "ебаться с памятью" и "алгоритм". Алгоритм может быть и без ебли с памятью, как ебля с памятью может быть алгоритма.
Таким образом, "вычисление + декларативность" это логическое программирование, "вычисление + механизм" это как раз-таки функциональщина, а "выполнение + механизм" это императивщина.
А "выполнение + декларативность" - такого не существует. Это по сути своей кнопка "сделать пиздато", которая без ИИ невозможна.
Ещё раз, если непонятно изложил:
"Вычислить" - значит редуцировать некое выражение до примитива, т.е. фундаментальная операция в такой системе - редукция.
"Выполнить" - значит записать некое значение на ленту, т.е. фундаментальная операция - присвоение (на самом деле не только присвоение, а обращение, т.к. мы в ячейки можем как писать, так и читать)
Ебсти память и действовать по алгоритму это разные вещи.
Поэтому пролог это не "логическая декларативщина", а "логическое программирование" это "вычислительная декларативщина", в противовес ФП которое суть "вычислительная алгоритмщина", а со стороны на их противоречие смотрит ассемблер, который суть "исполнительная алгоритмщина"
Нет признаков парадигмы. Признак парадигмы это наличие критерия по которому существовало бы что-то противоположное данной парадигме. Что является противоположностью ООП? То же самое, что является противоположностью языку си: декларативное и вычислительное, в противовес алгоритмической и исполнительной, скажем, джаве.
Просто в понятие "императивность" слито два разных понятия - операция с памятью и действие по алгоритму, которые не обязаны идти рука об руку.
О, крутяк, можете мне пояснить один вопрос: как в принципе можно вообще обходится без присвоения?
Для решения задач вычисления - оно понятно, хотя меня всегда немного смущало, что желательно реализовывать итерации через хвостовую рекурсию, которая исполняется подобно циклу, которых в функциональном подходе нет. Как-то это странно, сначала исключать цикл, а потом пытаться его повторить другим способом, ну да ладно, сейчас не об этом.
А вот если мне нужно не вычислить значение, а скажем получить сообщение по сети? Или построить хэш таблицу? Что в таком случае делается? Или ограничение на присвоение не строгое?
Я тут не помогу, к сожалению.
У меня есть понимание того, чем по сути своей является функциональщина, но я не знаком с языками дрочащими на ФП (именно дрочащими, а не содержащими, хаскель к примеру), и как следствие не знаком с "лучшими практиками" в них.
Как делаю лично я? Пишу функционально всё что могу, а что не могу пишу императивно. Клиент-сервер это как раз классический случай когда без стейта не обойтись. А в общем случае без стейта нельзя обойтись тогда и только тогда, когда у тебя величины могут меняться во времени, например функция, возвращающая рандомное число или сервер, который сидит на потоке и СЛУШАЕТ его, т.е. должен вести себя по разному в зависимости от того, какое сейчас время.
>>ООП
>>это даже не парадигма
>Ясно
Напомни-ка мне, из чего состоит объект? Наверное из СОСТОЯНИЯ и методов, да? А что такое СОСТОЯНИЕ, не подскажешь? Наверное такая штука, которая может во времени изменяться, да? Ну прям как переменная, да? Объекты без состояния антипаттерном в ООП являются? Так точно.
Какой из этого вывод? ООП = императивщина. Всё, где есть сайд-эффекты, является императивщиной.
Даже если ты смоллтокоёб с иммутабельными объектами, энивей у тебя что-то помещается в память (пусть даже не ты сам руками помещаешь, а обращаешься через ссылку, но суть та же), это что-то можно оттуда прочесть, а потом сборщик мусора сотрёт.
>На С без всякого ООП целые операционные системы писали, представь себе.
На самом деле - со всяким ооп.
https://www.kernel.org/doc/html/v4.13/driver-api/index.html
Есть еще примитивы, но их можно тоже рассматривать в качестве синглтон объектов, потому как они боксятся, а сделаны разумеется для производительности. (тем более что сейчас ничего не мешает у примитивных добавить в цепочку прототипов прокси объект, отлавливащий сообщения, типа присваивания, и реалиховать поведение прототипов как полноценных объектов, но это ни к чему. проще воспринимать их как синглтоны. когда надо, любой примитив можно обернуть в полноценный независимый объект).
Так. Короче только объекты.
Все объекты делятся на 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++ это больше структурное программирование, нежели объектное. Объектное программирование не может существовать без динамической среды. Это противоречит самому понятию объекта. А динамическое программирование это слишком сложна и непанятна. И как бы не старались с пеной у рта фанатики кричать про низкий порог входа - низкий он именно что для входа, а не для всего остального. Модификация программ в рантайме всегда было уделом креативно мыслящих людей. Для большинства это слишком сложный уровень высокой абстракции.
>Для чего нужно ООП?
Нахуй не нужно на самом деле. Рыночек порешал что на рынке ООП не нужно.
Популярные языки отказываются от ООП. Тот же Javascript, Python, C++ в принципе не заставляют тебя использовать его, а какой-нибудь Go так вообще решил дать пососать.
> Не заставляют => Отказываются
Ну вот популярные языки не заставляют тебя использовать функциональщину. Это значит, что они от неё отказываются? По такой логике мультипарадигменные языки отказываются вообще от всего просто в силу того, что не заставляют тебя использовать что-то конкретное.
> Python, C++
Больше половины стандартных библиотек написана с помощью ООП, и для их использования приходится его юзать. Не заставляют, да?
> Javascript
Это тот, к которому недавно прикрутили джаваподобные классы?
> Go
С каких пор под ООП понимается то, как сделано в джавашарпах? Smalltalk, видать, не ООП был.
>С каких пор под ООП понимается то, как сделано в джавашарпах? Smalltalk, видать, не ООП был.
Так в том-то и дело что Smalltalk это был именно что ООП. То что Алан Кэй придумал, который был прекрасный математик, джазовый исполнитель и вообще хороший человек. Но вот в промышленной, рыночной разработке вроде никогда не участвовал.
А вот всякие Python и C++ нормальный, тот самый, ООП не использует. Его рыночек порешал в пользу той каши, которая щас называется "Мультипарадигмальные языки общего назначения".
> Ну вот популярные языки не заставляют тебя использовать функциональщину. Это значит, что они от неё отказываются?
Ну да, и от функциональщины тоже. В угоду "практичного, васянского кода который все и пишут.
> Его рыночек порешал в пользу той каши, которая щас называется "Мультипарадигмальные языки общего назначения".
И правильно. Бизнес-задачи на них решаются намного эффективнее, а на сомнительных парадигмах кодеры пусть в свободное время пишут.
> Ну да, и от функциональщины тоже. В угоду "практичного, васянского кода который все и пишут.
Да.
Успехи ООП объясняются только успехами GUI в 90-х. Когда у тебя одни языки без ГЦ, то иерархичная структура объектов-овнеров, события и прочее идеально ложились на ООП. Больше оно никуда не ложилось, данные в реляционных базах лежали, игори вообще на стейтмашине opengl себя нормально чувствовали. Но по инерции люди почему-то подумали, что внедрять ооп - офигенная идея. Но это было именно что по инерции.
С переходом GUI в веб ООП умерло окончательно, потому что в вебе эти подходы не работают совсем.
>>1718743
Заходите в соседний тред про шашечки. Покажите, как спроектировать шашки в тру ооп стиле.
Ну так я ж за это и топлю. Когда я говорю "ФП/ООП никто не использует", я подразумеваю что никто не придерживается тех маняфантазий, которые себе профессора понавыдумывали. Вообще, наука она должна быть описательной, а не предписательной. Когда компьютерные учёные начинают крупным корпорациям пояснять как им писать свой код - это уже за рамки выходит.
Понятно, что современный код это смесь трёх парадигм(СП, ФП, ООП), из них берутся какие-то лучшие моменты, а другие просто рыночком отбрасываются.
>>1719271
Ну чел, там ж на гитхубе их как говна...
В вебе иерархическая структура так и осталась. И дело не в управлении памятью, а тупо в том, что одни элементы гуя состоят из других элементов поменьше. Даже компоненты в реакте - это тоже одно из видений ООП.
> данные в реляционных базах лежали
Ну а сейчас изобрели монгу, чтобы хранить объекты.
> игори вообще на стейтмашине opengl себя нормально чувствовали
Километровые процедурные портянки, в которых почти никто не мог разобраться. Но геймдев вообще особняком стоит, и парадигмы так свои, уникальные: Data-Driven Design, Entity-Component System (тоже своего рода ООП) и прочее, больше нигде не применимое.
Иерархическая структура есть в любом продукте человеческой мысли из-за особенностей этой мысли. Если называть это ООП, то тогда и ракету Союз можно назвать ООП. Она же из ОБЪЕКТОВ состоит.
Но это все не так, ООП это более конкретная вещь.
Я, например, не считаю, что энтити в геймдеве это ООП, так же, как и то, что хранится в монге, и уж тем более это не про компоненты в реакте. То есть ты сначала дай определение ООП, а потом решим, сдохло оно, или нет. В общепринятом смысле сдохло, см. пикрелейтед.
А то может по твоему определению в хаскеле ООП, а мы тут спорим.
> Иерархическая структура есть в любом продукте человеческой мысли из-за особенностей этой мысли.
Да, в этом и смысл ООП. Ты подразделяешь все данные на некоторые осмысленные сущности, строишь их иерархию и делаешь так, чтобы они обменивались инфой друг с другом. Всё.
> Если называть это ООП, то тогда и ракету Союз можно назвать ООП. Она же из ОБЪЕКТОВ состоит.
Да, как раз потому, что ООП лучше всего описывает объекты реального мира.
> пикрелейтед
Я тогда продолжу твой пикрелейтед и скажу, если ООП сдохло, то остальное и не оживало никогда.
https://ru.wikipedia.org/wiki/Абстракция_данных
Судя по определению, это когда ты описываешь некую сущность и оставляешь только самые важные поля, а не пытаешься перечислить вообще все возможные характеристики, какие есть на самом деле.
>Да, в этом и смысл ООП
Это смысл любой инженерной деятельности, включая программирование в данном случае. Назови подход, который не подразумевает иерархию.
>Да, как раз потому, что ООП лучше всего описывает объекты реального мира.
Объекты реального мира лучше всего описывают дифференциальные уравнения, уж в таком мире мы живем
>Я тогда продолжу твой пикрелейтед и скажу, если ООП сдохло, то остальное и не оживало никогда.
Тренды важнее абсолютных значений
> Назови подход, который не подразумевает иерархию.
Нет такого. Потому что остальные подходы - всего лишь подвид ООП.
> Объекты реального мира лучше всего описывают дифференциальные уравнения
Они описывают не сами объекты, а их изменение. Сами объекты - это их свойства. Ничего не говорится о том, как эти свойства изменяются и обрабатываются.
> Тренды важнее абсолютных значений
Конечно. ООП упало до своей асимптоты, ФП доросло до своей асимптоты. Так и останутся. Тренды - это не обязательно линейные функции, иначе гипербола (убывающая экспонента, etc) пересекала бы асимптоту и устремлялась в бесконечность
Отлично. В таком случае все эти ФП/ООП -- свойство конкретного проекта или даже модуля (ибо ничито не помешает мне вставить мутабельный под капотом модуль в иммутабельную обёртку).
А все эти срачи про языки идут лесом. Алсо, процедурная парадигма, как прямо индифферентная к мутабельности -- имеет ввиду и тех и других.
Ну вот видишь, почему не нужно слушать двачеэкспертов. Всегда удивляюсь, как тут люди красиво пиздят с умным видом, а потом просто на ровном месте обсираются. Как недавно например с O(2n).
Так вот как сделано присваивание в хаскеле. А сделано оно так: вместо
a = readFile(); print(a);
пишется что то типа (псевдокод):
main = bind(readfile, (a) => print(a))
bind это одна из операций определенных над монадой.
В итоге вся программа представляет собой выражение, которое возвращает монаду IO. Вот эта монада по сути и есть алгоритм. Хаскель знает как ее "запустить на вычисление", что он и делает, и тогда программа начинает выполняться.
Немного не в тему, но все равно скажу. Это же заебись что статические методы принадлежат одному классу FileUtills. Все хранятся в одном месте, сразу понятно где искать, читаемость вызова таких функций достигает 9999999. ООП не ООП - какая разница, получилось очень удобно
>На С без всякого ООП целые операционные системы писали, представь себе. Вот только каким хуем это наделяет С всем тем, что есть у ООП и каким хуем оно отменяет те возможности, которые ООП предоставляет, одному тебе, долбоебу, известно.
Си -- это вообще недоязык высокого уровня, в нём нет ни модульности, ни массивов, это по большому счёту универсальный ассемблер.
Удобнее писать через точку
system.getDisplay().getSize()
чем пробрасывать парашу через свободные функции. Ты там одних временных переменных заебешься делать. Будет как во всяких старых винапи
System sys
Display disp
GetCurrentSystem(&sys)
GetDisplay(sys, &disp, TRUE)
SizeClassXXL size
GetSize(disp, (DisplayDevice*)0, size)
Спасибо наелись