>Какие проблемы и задачи оно решает?
Проблему утилизации обширных быдло-масс в ИТ. цитата
мало писал в процедурном стиле раз не понял зачем ООП
>Какие проблемы и задачи оно решает?
Тут целую простыню текста можно расписать по этому поводу, неохота, вдруг ты даже читать не станешь. Поэтому ты расскажи как бы ты в процедурном стиле описал новый тип данных? У тебя есть стандартные типы - целое, число с плавающей точкой, символ, булеан. А тебе нужен, например такой тип как время в формате hh:mm:ss.
>Почему пользоваться классами и объектами, а не допустим списками?
Это всего лишь особенности реализации. В некоторых скриптовых языках объект реализован как ассоциативный массив.
Сейчас набегут
Это не просто список. Его элементы могут быть разных типов, в том числе представлять собой вложенные списки, из чего следует, что такая интерпретация ООП плохо ложится на статическую типизацию.
Технически, ООП не даёт ничего такого, что нельзя было бы сделать без него. Вся разница в удобстве. Запись:
alice.friends.bob
куда понятнее, чем:
> aline[17][4]
/thread
Но в этих записях не раскрывается ни наследование, ни инкапсуляция, ни полиморфизм, которые и составляют ООП.
Просто структуры данных - ещё не ООП.
Реализовать на голом Си виртуальные функции, конечно, возможно, но заебёшься это делать.
>быдло-масс
Разве быдло-массы пишут на Smalltalk? Или ты от скудоумия приплетаешь недо-ООП из Python/Java/C# к настоящему ООП?
О, адепт "настоящего ООП" в треде. Давай, расскажи, как это здорово - падать в рантайме из-за того, что объект "не понял сообщение".
Изи пример. Я разрабатываю ЭБУ, а ты- фару. Мне нужно знать контракт, как управлять тобой: вкл/выкл/коррекция пучка света по вертикали. На остальное мне поебать, как оно там внутри тебя будет реализовано.
Это и есть инкапсуляция.
Далее. У тебя есть моделька самолета и ты просчитываешь, какой мощности должны быть двигатели. На остальное поебать: цвет самолета, количество мест, наличие биотуалетов.
Это и есть абстракция.
Далее. У тебя есть кошечка. Она родила котят. Все котята имеют хаост, усы, по два уха.
Это наследование.
Один котенок - бойкий альфач, а другой- омежка, как ты.
Это полиморфизм.
>Далее. У тебя есть кошечка. Она родила котят. Все котята имеют хаост, усы, по два уха.
>Это наследование.
>Один котенок - бойкий альфач, а другой- омежка, как ты.
>Это полиморфизм.
Пчел, ты...
Не. Быдломассам лестно думать, будто-бы они решают дофига важную задачу в духе объективизЪма. Язык любой.
Это настолько здорово, что адепты псевдо-ООП в любом серьезном проекте внедряют Пружину.
Какое отношение "пружина" имеет к тому, что ты называешь
> псевдо-ООП
?
Ёбу дал, троллолоша?
>падать в рантайме из-за того, что объект "не понял сообщение".
Полный бред. В рантайме падают только статические языки. 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 миллионов
И? Отсутствие классов в языке исключает возможность использовать объектно-ориентированный подход?
И её отсутствие не научит.
Сам факт того, что в языке статическая/динамическая типизация, ни на йоту не научит кого-то чему-то.
Где я писал, что подушка научит?
Дебил с купленными правами будет дебилом с купленными правами на любой машине.
ФП позволяет делать все то же что и ООП. Не вижу у тебя аргументов за ООП. Как не вижу чтобы ты вообще понимал что это такое.
> ФП позволяет делать все то же что и ООП
Машина Тьюринга тоже.
мимо
Он по факту не используется.
>пукинчанский
Вообще-то дело в том, что фп реализуется в терминах ооп, и наоборот. Как машина тьюринга и лямбда-исчисление.
Замыкания - это "объекты для бедных", равно как и объекты - "замыкания для бедных".
Машина Тьюринга не имеет такой гибкости как Комбинаторная логика, Лямбда-исчисление, Рекурсивные функции, которые позволяют из маленького ядра построить любую вычислительную систему. Грубо говоря, они позволяют строить свой язык программирования. Машина Тьюринга не дает такой гибкости. Машина Тьюринга это система с хранением состояния, а это противоречит математике. Состояние это зло, все ошибки происходят из-за него.
>Отсутствие классов в языке исключает возможность использовать объектно-ориентированный подход?
Конечно нет.
>Он по факту не используется.
Ты ничего не знаешь про ООП. Класс - это не ООП. Объекты можно строить из функций.
Можно, но это по факту не используется.
Используется. Если ты не юзал или не видел, то это не значит, что этого не существует.
Я про линукс
СИКП 3 глава. Первое издание выпущено в 1985 году. То есть уже тогда это использовали.
Что Линукс? Разговор был не про него.
>Состояние это зло, все ошибки происходят из-за него.
Не совсем верно. Присвоения это можно и полезно, но только ИНОГДА БЛЯДЬ, а не как в императивных языках где оно везде: и к месту и не к месту.
Оно заебись тогда и только тогда, когда его отсутствие приводит к снижению модульности системы вследствие того, что потроха дочернего модуля (которые могли бы быть выражены стейтом) протекают в родительский.
Например какой-нибудь простенький ГСЧ: берёт текущее время в качестве зерна и делает случайное число. Если его сделать без присвоений, тогда мы вынуждены будем из родительского модуля явно передавать ему зерно, а значит родительский модуль должен будет сам его генерировать, а значит у нас устройство родительского модуля начинает зависеть от устройства дочернего. А ведь нам просто нужно было случайное число, нас не ебёт как там дочерний модуль его рожает.
Но для того чтобы просуммировать последовательность нам присвоение нахуй не всралось. Такие дела.
Замыкания
Ну да, в принципе можно.
>ООП
>ряя инкапсуляция наследование полиморфизм
>открываешь какой-нибудь спринг
>FileUtils
>пошла простыня из статических методов
Что называется объекты завезли а соответствующее мышление не завезли. Как писали портянки процедурные так и пишем.
То что статические методы в принципе существуют (в джаве, которая на минуточку флагман и главный ооп язык) - уже символизирует полный и бесповоротный фейл ооп как парадигмы.
То есть у нас типа "всё есть объект", но на самом деле объекта нет а метод несуществующего объекта (т.е. по сути старую добрую процедуру из си) мы вызвать можем. Охуенно, заебись, дайте два. Зато мы не можем определить процедуру в глобальном скоупе (ты чё, у нас жи ооп). Но сделать ютилити класс и вызывать его методы, не создавая при этом объектов этго класса мы можем. Ага.
Хотя подожди, а чём замыкание не хранение стейта?
Хранение, только для этого не нужно присваивание.
А, да нет, я-то отвечал тому анону который говорил "все ошибки из-за стейта", неясно выразился короче.
Зачем в тред пролезли сектанты иммутабельности?
>Зачем в тред пролезли сектанты потокобезопасности?
Затем.
> символизирует полный и бесповоротный фейл ооп как парадигмы
Нет, это символизирует, что нет универсальных парадигм. Когда борщехлёбы передают в функцию огромный тип с кучей полей, потому что нет классов, и рекурсивно вызывают эту функцию с немного изменённым состоянием, чтобы изменить значение одного поля, тоже ни о чём хорошем не говорит. По сути, они изменяют состояние вручную, как на сишке вручную пишут ООП.
Ничего нового, они набегают в каждый тред про парадигмы.
Я хуйню спорол, хотел сказать что то "ооп" со статическими методами это не ооп никакое, это процедурные портянки натянутые на "гыгы смарите можно кароче функцию в класс засунуть и тогда её вызывать нужно будет не через скобки а через точку"
>ой, ой, ой-ой-ой пацаны у меня поток заблокировался чё делоть???
ФП универсальная парадигма. Лисп универсальный язык.
Ну да, классы-хелперы со статическими методами- это всегда процедурные портянки. Видимо, те, кто это придумал, рассматривали классы не только с позиции ООП, но и с позиции модульности.
Хорошо, что в универсальном мультипарадигменном лиспе есть CLOS.
Нет противоречий между ФП и настоящим ООП. Проблемы только с псевдо-ООП парашей.
https://lispcast.com/is-smalltalk-a-functional-language-is-lisp-object-oriented/
Опять выходишь на связь?
Основан он все равно на Лямбда-исчислении. Можно даже сказать, что это реализация Лямбда-исчисления. Лисп это не Common Lisp, это собирательное название семейства лиспоподобных языков.
Я и не говорил что есть. Классы это не ООП, это сто процентов.
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
Юра, ты как в этот тред-то пролез?
не Пружину, а Весну, ёбик
Не Весну, а Родник, ёбик
Молишься на заокеанского бога?
Сможешь привести примеры использования?
препод в универе сказал что все заебись, а он доктор, а не хуй с двача
Что он преподает, смолтолк что-ли?
>Сомневаюсь
Знаешь как сомнения прояснить? Открой да посмотри
Вангую сейчас начнётся "ряя на любом йазыке можно песать ооп, там тожи йесть элименты ооп", только из элементов ооп там только абстракция (которая свойственная программированию как таковому, не только ооп)
Это похоже на родник, ёбик?
А он кстати как считает? По строкам кода?
Ну я даже не знаю. Работаю .NET макакой второй год, вторая кампания ради зп ушел. Так вот на новой работе на столько издеваются с ASP NET MVC, что они нахуй стейты притащили из ебаных WinForms. Логика размазана по нескольким либам и неймспасам, проблема в том, что оно всё параллельно растет и дуплицирует друг друга и у нас десятки классов, которые должны были быть одним и чтобы просто дернуть table из дб мне нужно через 5 кругов велосипедных абстракций проходить entity не завезли. Нахуй оно надо. Я не говорю, что class based OOP заставляет так писать, но как правило так пишут. Даже на C++ с классами так хуево все не размывают в спагетти, как на Шарпе.
Конечно, анон сейчас скажет, мол ты кампанию хуевую выбрал, но это моя последняя работа в энтерпрайзе и последняя работа с мейнстрим ООП языками.
Конечно, анон сейчас скажет, мол ты кампанию хуевую выбрал, но это моя последняя работа в энтерпрайзе и последняя работа с мейнстрим ООП языками.
Линукс Торвальдс просто ярый противник плюсов и не позволит их совать в ядро.
может еще исходники ffmpеg посмотреть
То есть теперь рефлексия это чисто ОО-фишка?
>Классы это не ООП
>они две недели назад сам уволились
Так смешно наблюдать как ОО-дауны переобуваются последние 30 лет, как только их начали макать в собственное говно.
> переобуваются
Это называется развитие.
И только шизы-ФПшники, у которых развития нет, будут упорствовать в своём невежестве до последнего.
Фактически классы это необязательная (а по мнению некоторых и нежелательная) фича.
Для реализации ооп классы необязательны. Может существовать система, при которой класса как такового нет, а есть первый объект, и последующие объекты, создаваемые по образу первого. И чего мы при таком подходе лишаемся, так это возможности лепить статические методы (нет класса - нет статических методов, их просто некуда писать), а это как раз замечательно.
Потому что "статические методы" должны быть процедурами, коими они концептуально являются, так что программист сразу видит "ага, тут я написал процедуру, следовательно я обосрался".
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.
>развитие
Лол. Таким макаром, лет через цать, окажется, что ооп это фп.
Ты сам понимаешь, что ты пишешь?
Во первых, чтобы избавиться от статических методов-процедур необязательно избавляться от классов, но это не имеет значения, т.к. ООП это всего лишь надстройка над процедурной парадигмой. Под ООП всегда подразумевалось, подразумевается и будет подразумеваться как бы вы не старались, маньки мутабельные структы со связанным неймспейсом, в котором определены процедуры-методы, меняющие поля структа. Т.е. ты всегда пишешь в процедурном стиле, если ты пишешь ООП, вне зависимости от того определяешь ты статические или обычные методы.
Таким образом ООП наследует и преумножает все проблемы процедурной парадигмы.
> лет через цать, окажется, что ооп это фп
Не окажется. Чистое ФП не работает, и ООП никогда к такому не придёт.
> Во первых, чтобы избавиться от статических методов-процедур необязательно избавляться от классов
Никто не говорил что от классов обязательно надо избавляться (мнения на этот счёт расходятся), а из тех, кто всё-таки говорил, никто не утверждал что от классов надо избавляться чисто ради того, чтобы порезать статические методы (их можно и без этого убрать)
>ООП всегда подразумевалось, подразумевается и будет подразумеваться
Да, да, конечно. Извини что тебя затронул. Все будет как ты скажешь.
>Чистое ФП не работает
Оно и не должно быть чистым. Стейт в ряде случаев предпочтителен.
Наследование нужно избегать, это уже сказали. Но бывают случае когда оно нужно и удобно.
Именно поэтому нужны мультипарадигменные языки и с ООП и с ФП.
Из ООП прижился полиморфизм на интерфейсах. Из ФП лямбды, замыкание.
В котлине все классы закрыты по-умолчанию. А дата-классы не наследуются (являются структурами). При этом есть и функции и лямбды.
И что самое мне нравится, можно сделать "жирные функции", то есть когда можешь указать параметры kwargs
foo("my value", end="\n", sep="/")
>Чистое ФП не работает
У тебя?
А еще из ООП прижалась инкапсуляция.
> Оно и не должно быть чистым. Стейт в ряде случаев предпочтителен.
Тогда это уже не кукарекание про самую лучшую парадигму, а выбор инструментов под задачи. К чему программирование идёт, так это к мультипарадигменности уже.
Ни у кого, кроме борщехлёбов, оно не работает. Ни одного крупного проекта на чистом ФП без костылей и извращений не написано.
>а выбор инструментов под задачи
Об этом речь и идёт. Использовать фп везде, где можно - это гуд. Использовать процедуроговнецо там, где без проблем можно писать функционально - не гуд.
Мантры
То есть, у кого-то всё-таки работает? Но не у тебя.
Вот бы ещё те, у кого оно работает, показали хоть один пример, а то остаётся только на слово верить.
Ты заебал, смолток в могиле посылает сам себе сообщения, обж-с скоро к нему присоединится. Этого шизика послушать, так ООП это любая актор-бейсед хуйня, например ерланг. Но факт в том, что 99% программистов услышав слово ООП подумают про джаву, кресты и пхп, а не про ерланг. Можно конечно жить в альтернативном манямирке, где голова это на самом деле жопа и просто никто об этом не знает. Я понимаю почему так может считать Алан Кей, старческая деменция, маразм, вся хуйня, вон его кореш Тед Нельсон ещё больше поехал со своим Xanadu, на который всю жизнь вьебал, а оно никому нахуй не нужно, теперь ходит как дурачек всем рассказывает что НАСТОЯЩИЙ интернет и гиперссылки это вообще не то что все думают, но вот уебанов, которые транслируют старческие бредни я понять не могу.
> Этого шизика послушать, так ООП это любая актор-бейсед хуйня, например ерланг.
Кстати, неоднократно натыкался на тех, кто реально так считает и проводит в пример эрланг.
мимо
>остаётся только на слово верить.
Удел неосиляторов.
Котлин лучше шарпа!
А шарписты такие: "Котлин говно только потому, что он для JVM".
>Проблема проектирования "какающей лошади и летающего пегаса"
>Решение через наследование
https://pl.kotl.in/hclcmiTPB
>Решение через делегирование
https://pl.kotl.in/JCIfJovQW
Да, лучше голый язык без экосистемы создавать.
> А дата-классы не наследуются (
Через месяц в джаве будут records.
Java и Kotlin не конкуренты, они едят с общего стола.
Твои две ссылки не различаются кодом.
Но со временем внук может выкинуть деда из-за стола.
Два архитектурных решения одной задачи.
Нет, там вообще одинаковый код.
Тогда дед выпишет его из наследства.
upd
А теперь разный стал. Может глюкануло.
А вот в пщ-треде как раз заливают, что либы для джавы - это ненужное легаси, а отсутствие либ в пщ - это на самом деле фича такая.
У меня разный, проверил даже без кук. Переоткрой
Котлин не сможет себе прибрать к рукам жвм - засудят.
А оракл может плохо отреагировать, если котлин помимо андроида еще в энтерпрайз ворвется. Поэтому непонятно что будет в будущем.
>фп реализуется в терминах ооп
Определение композиции для ООП в студию.
Уже представляю новость "Оракл подал в суд на жетбреинс за использование платформы Java".
Лол, вчера с десяток строк в градле добавил пачку либ, которые я писал бы так же качественно, наверное, год.
То есть, те либы мне сэкономили тысячи человеко часов работы.
Конечно, наличие большого числа библиотек это зло, питонисты тоже согласяться. гоферы ебанутые
>а отсутствие либ в пщ - это на самом деле фича такая.
Потому что в самой компании гугол тебе любую либу напишут за один час. Но на гитхаб не выложат.
>Котлин не сможет себе прибрать к рукам жвм
OpenJDK может
>А оракл может плохо отреагировать.
Оракл уже реагирует, пилит тонну фич в джаву и релизит каждые полгода как не в себе (смотри видос про планы до 2024). Конкуренция это хорошо.
Котлин это не только JVM, это и native и js.
> >Котлин не сможет себе прибрать к рукам жвм
> OpenJDK может
Они ее не смогут изменять сильно, иначе не пройдут тесты совместимости и их засудят. А менять только один синтаксис, ну такое.
Вот и получается, что пщ - это язык исключительно для внутренних нужд гугла. А кто ещё его юзает - тот ССЗБ.
Котлин на жс это типо gwt 2.0?
Нет, компилятор в js, по типу ts или dart
Зачем менять? Философия котлина зиждется на совместимости с джавой. Я даже не переписывал код на котлин, у меня так джава и котлин вместе
С гуглом суд был по другой причине.
В общем, там все хорошо.
А в котлине дженерики полноценные или как в джяве?
Но это пока совместимость выгодна котлину. А вот если со временем все популярные библиотеки и множество проектов перепишут на котлю, что тогда? Поглощать оракл?
Чуток улучшенные с Reified.
Котлин ограничен JVM
А вдруг они решат и улетят на марс с инопланетянами?
Давай оперировать заявленными фактами.
> Для чего нужно ООП?
Если говорим про реальную пользу для работы, то нужно для того, чтобы ты, в теории, мог расширять функциональность без лишних телодвижений.
Еще можно всякие прикольные штуки, типа внедрения зависимостей делать, благодаря этой хуйне все вообще классно выходит: Скажем, ты написал лог, вынес на уровень интерфейса базовое описание лога:
interface ILog{
void Write(LogLevel level, string message);
}
Потом ты сделал импплементацию этого лога в виде класса ConsoleLog, человек который пользуется интерфейсом, заинжектил этот класс, год все было хорошо, но теперь ваше приложение должно работать как сервис и встала задача писать лог не в консоль, а в файл, еще и в json - формате. Ты за часик сделал новую имплементацию JsonFileLog, и человек просто заинжектил новый класс, при этом в классе, что использует лог ничего не поменялось, но теперь лог пишется в файл. Красота же. А если у вас крутой архитектор, то вы вообще давно сделали так, что для замены лога можно просто прописать в конфигурационном файле какой лог брать в случае запуска и даже пересобирать не придется, ты просто кинешь dll куда надо, в конфиг файле добавишь пару строчек и у клиента теперь лог пишется в файл.
> Почему пользоваться классами и объектами, а не допустим списками? Ведь суть одна и та же.
Далеко не одна и та же.
Пидараш, иди на хуй
Если бы ты со своей шмоней не пиздел лишнего, то и не пошел бы на хуй. П
Пичот? ))0
>Но факт в том, что 99% программистов услышав слово ООП подумают про джаву, кресты и пхп
И кого это должно волновать? Мне, например, похую.
>Можно конечно жить в альтернативном манямирке, где голова это на самом деле жопа и просто никто об этом не знает
99% программистов живут, и чё?
Нацистская германия жила почти в полном составе в альтернативном манямире где арийцы это богоизбранная высшая раса.
Веганы живут в манямире где мясо несъедобно.
Вот только ты верно заметил - от того, что 99% назовут голову жопой, она не станет жопой, а останется головой.
Ты сам начал оскорбления. Теперь не обижайся.
Да я ёбу дал, не реализуется. Только наоборот
>...сделал импплементацию этого лога...
Абажи. Чем это от ФВП отличается?
А на весну это чем похоже?
> Я понимаю почему так может считать Алан Кей, старческая деменция, маразм, вся хуйня
Он на Лиспе всю жизнь пишет.
1
Нет, ну вот котлин и джава совместимы. Можно оставлять джаву в проекте, а новые вещи писать на котлине.
Вдруг жетбраинс захотят сделать какие-то глобальные фичи на уровне jvm.
Вот дженерики нормальные сделать! Тут без изменений в машине ну никак.
>Он на Лиспе всю жизнь пишет.
Поэтому дожил до старых лет?
> Лисп универсальный язык.
)))
>Вдруг жетбраинс захотят сделать какие-то глобальные фичи на уровне jvm.
Они не хотят, мало того что это нарушит лицензии там какие-то, так это еще похерит совместимость со всей джавой.
Поверь, именно это они делать не будут.
А чем это джавовые дженерики неполноценные? Тем что инфа в рантайме вырезается? Так это только и дает возможность сделать продвинутые системы типов, как в скале, например. А том же дотнете в F# как раз не завезли типы высших рангов из-за того, что шарповые дженерики реифицируются.
Если язык достаточно выразительный, то инфо по полиморфным типам можно пихать в рантайм опционально с помощью вшитых в язык ad-hoc решений (звучит плохо, но на деле не так страшно). Примеры: Scala (ClassTag, TypeTag), Haskell (Generic)
То, что реификация дженериков необходима - популярное заблуждение.
Лисп не универсальный наверное нихуя? То ли ты меня троллишь, то ли я пытаюсь. Не, нахуй не нужно. Лисп это батя.
Не, это прост был баян про скобки, универсальность лиспа тут не при чём)))
Если честно, никогда не понимал этот прикол.
>ООП это любая актор-бейсед хуйня, например ерланг
ООП - это когда ты в своем коде можешь выполнять полиморфную функцию, не объявляя прямой зависимости на эту функцию. Так что да, эрланг и акторы - это ООП.
>Я понимаю почему так может считать Алан Кей, старческая деменция, маразм
>Но факт в том, что 99% программистов
То есть когда один выдающийся человек с именем высказывает мнение, то это автоматически маразм, но когда 99% (высранных тобой из жопы) абстрактных людей, высказывают мнение - это автоматически правда? Ты дурачок?
ооп это то, что вы должны знать.
>должны
Кому?
Работодателю, например.
Профессии.
Хороший комикс, забавно и без злобы.
> Какие проблемы и задачи оно решает
Командная работа, масштабирование кода
Любая модуляризация кода увеличивает его пригодность для командной работы, даже процедурная абстракция.
Дебилушка, смолток проиграл потому что это было ультратормозное говнище, и vtables с early-binding по дефолту тупо быстрее. Во-вторых, это просто квинтэссенция динамического петушения когда что угодно может вызывать послать сообщение чему угодно, сообщение может перехватить что угодно и ответить что угодно, самостоятельно решая что ошибка, а что нет.
Ну то есть программировать на этом может быть весело, но для разработки и поддержки реальных систем - это слишком дорого и хуёво.
Единственный способ его реанимировать - всё покрыть хотя бы простой типизацией, вынести месседж пассинг дрисню в отдельное подмножество языка и тоже типизировать. То есть получился бы Kotlin + Typed Akka.
Нахуя ты к двоим обращаешься в единственном числе?
>Ну то есть программировать на этом может быть весело, но для разработки и поддержки реальных систем - это слишком дорого и хуёво.
А почему тогда Эрланг используют?
Используют ли.
Нет, конечно. Это мистификация всё. Заговор масонов.
Ага, всё ведь на пхп и жс пишут.
Прочитал как "заговор массивов"
А ерланге хотя бы разделение есть: вызов функций - это вызов функций, а посылка сообщений - это посылка сообщений.
Плюс в ерланге акторы были чтоб обеспечить конкаренси, изоляцию и, как результат, отказоустойчивость, а в смолтолке не было ничего из этого, зато были акторы для всего просто чтоб были.
>факт в том, что 99% программистов услышав слово ООП подумают про джаву, кресты и пхп
В средневековье 99% жителей планеты думали что Солнце вращается вокруг Земли.
>это было ультратормозное говнище
Как же оно тогда работало на Xerox Alto? Первая ОС где окна можно двигать мышью по экрану была написана на SmallTalk.
> Kotlin
Молчал бы с этим убогим говном для индусов
А сейчас 99% думает что земля вращается вокруг солнца (хотя реально вокруг центра масс солнечной системы, не всегда находящегося внутри гелиосферы), но считает себя умнее. Дебичи не меняются.
>но считает себя умнее
И вполне обоснованно. Считать, что земля вращается вокруг Солнца умнее, чем наоборот.
Причем тут Smalltalk? На видео говорят что программа написана на BCPL.
Так-то есть центр массы галактики и Земля вращается вокруг него, что не мешает ей ещё и вращаться вокруг Солнца. Вот, кстати, интересный вопрос про центр массы вселенной: есть ли он (если не брать за центр вселенной мой хуец, бтв) и будет ли правильно строить модель движения вокруг него?
Если считать вселенную более менее однородной, то центр обозреваемой вселенной где? ... Бинго, you name it, это Земля.
Так Smalltalk еще медленнее.
обмажутся питухоном, а потом у них "смолток медленный"
При чём тут вообще питон?
Но она неоднородна, бесконечное расширение - функция от времени, там где время минимально - масса черных дыр должна быть больше, а значит это и есть центр вселенной?
А вот хуй, для машины с 5Mhz процессором, работает вполне себе сносно.
>При чём тут вообще питон?
мейнстримная ООП параша. Смолток помер не из-за своих хуёвых качеств, а из-за того, что не в том месте и не в то время появился. Сейчас же для успеха языка нужно коммунити и(или) батарейки и(или) корпоративный подсос и(или) кучерявый мессия
Я залез и педивикию и таки
>но в 1990-е Маргарет Геллер и Джон Хукра выяснили, что на масштабах порядка 300 мегапарсеков Вселенная практически однородна[4]
>Смолток помер
В том и дело что не помер.
Это теория из 90, сейчас не всё так однозначно, см.`Великая стена Геркулес-Северная корона`.
< не помер
Чо по вакансиям?
В сравнении с BCPL медленнее.
Популярные гитхаб репы кидай.
>мейнстримная ООП параша.
Это не про питон.
Ну так это собственно сабж. А я хотел посмотреть хотя бы CRUD проект на смоллтоке, а не на сишку.
>CRUD
Пусть индусы на яве пишут.
https://github.com/feenkcom/gtoolkit
https://github.com/PolyMathOrg/PolyMath
Вот это мощный язык, современные теперь кажутся упрощенными для идиотов.
ООП решает проблему локализации кода путём нагромождения миллиона нелокализованных объектов в каждый проект и оверрайда операндов так чтобы было непонятно что они делают. ООП появился из-за общего желания поменьше думать об имплементации и побольше использовать крутые плюшки.
операторов в смысле.
Если при проектировании возникает вопрос "что достойно отдельного объекта?"
Ответ на него достаточно прост. Объекта достойно всё.
Охуенные у тебя аналогии.
Вращение Земли вокруг Солнца - проверяемый факт, определение оопе - придуманная людьми гуманитарная хуйня и споры о том что же такое НАСТОЯЩЕЕ оопе , это как споры как звучит НАСТОЯЩИЙ готик-рок или что НА САМОМ ДЕЛЕ изображено на картине очередного абстракциониста.
>Для чего нужно ООП?
>Какие проблемы и задачи оно решает?
Основная причина использования ООП - это переиспользование кода. ООП свободно позволяет это делать за счет полиморфизма, наследования и инкапсуляции.
Наследование говно, инкапсуляия это сокрытие, а полиморфизм самая годная штука.
>Наследование говно
Нужно для полноценной реализации полиморфизма
>инкапсуляия это сокрытие
Сокрытие деталей имплементации.
>Сокрытие деталей имплементации.
Попался! Это в первую очередь объединение данных и кода, манипулирующий ими.
Сокрытие там как фича.
А то, что это только сокрытие учат только на говнокурсах.
>манипулирующий
-щего
фикс
Сокрытие деталей имплементации подразумевает объединение данных и кода.
Давайте начнем с простого. Опишите интерфейс кошки.
Сокрыть можно и без инкапсуляции.
Если нет инкапсуляции, то сокрытие равноценно не использованию данного типа данных практически свой None. Инкапсуляция в обоих смыслах возможна даже в процедурном C. Другое дело реализовано ли на уровне классов встроенных в язык или каким либо другим способом.
Накладные ушки - это миксин/трейт ?
У кошки в базовой комплектации нет накладных ушек, это инъекция зависимости.
Ctrl + F "Поддержка" - 1 результат.
Писать говно по принципу написал один раз и пошел дальше можно на чём угодно(на фп языках это естественно быстрее), разницы нет. Но вот если тебе(а зачастую не только тебе, а еще другим людям) это надо поддерживать и развивать, то только ООП.
Самые большие затраты при разработке софта - это его поддержка(а не первоначальная разработка, о чем обычно идёт речь в спорах наподобие ОП)
Писать говно по принципу написал один раз и пошел дальше можно на чём угодно(на фп языках это естественно быстрее), разницы нет. Но вот если тебе(а зачастую не только тебе, а еще другим людям) это надо поддерживать и развивать, то только ООП.
Самые большие затраты при разработке софта - это его поддержка(а не первоначальная разработка, о чем обычно идёт речь в спорах наподобие ОП)
>...то только ООП.
Доказывай, чо.
Машина Тьюринга и лямбда исчисление эквивалентны с точки зрения вычислимости. Доказано еще в 30-х. Иди нахуй даун.
>А чем это джавовые дженерики неполноценные
Ну вот как тебе сказать...
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) для каждого моба. Считается что полиморфизм дорого стоит. Пусть меня поправит кто в теме
Ооп ему не нравится. А может ты еще за украинцев?
Obj.func1().func2()
Хорошо что его начали выдавливать по сжв-линии.
Не столько из-за самого полиморфизма (в ООП, конечно, есть косвенный вызов через vtable, но он вроде и в ECS никуда не исчезнет), сколько из-за сложности изменений в ООП, например геймдизайнер поменял тип юнита со среднего танка на тяжелый, тебе придется лезть в разные файлы, менять что от чего наследуется и не наебаться
>центра масс солнечной системы, не всегда находящегося внутри гелиосферы
Знаешь там погрешность порядка двух диаметров солнц максимум, так что.
>НАСТОЯЩИЙ интернет и гиперссылки это вообще не то что все думают
Ну да, другое, а что?
> Под ООП всегда подразумевалось, подразумевается и будет подразумеваться как бы вы не старались, маньки мутабельные структы со связанным неймспейсом, в котором определены процедуры-методы, меняющие поля структа.
Мань, под ООП всегда подразумевалась отправка сообщений объекту, да, вызов метода это тоже отправка сообщения.
>процедуры-методы, меняющие поля структа.
Фабричный метод, который возвращает каждый раз новый объект, смеется тебе в лицо.
Короче, никто не виноват что ты говнокодер и свой опыт проецируешь на остальных.
> гибкости
Эмоциональное слово, не несущее какого-либо объективного определения в данном контексте.
>позволяют из маленького ядра построить любую вычислительную систему
Из машины Тьюринга можно построить любую вычислительную систему. Личералли. Это то что позволяет строить полноценные компьютеры в майнкрафте, к примеру.
>Грубо говоря, они позволяют строить свой язык программирования.
Один из самых первых примеров машины Тьюринга - это когда ячейки хранят буквы, которые интерпретируются. Так что да, машина Тьюринга позволяет строить свой язык программирования и работать уже на нем.
>математике
Математика - лженаука, она изучает несуществующий предмет, покажи мне отдельно существующее число в природе. Их нет.
>Состояние это зло, все ошибки происходят из-за него.
Состояние это добро, все благое происходит из-за него.
>покажи мне отдельно существующее число в природе
Температура - это абстракция. Термодинамика тоже лженаука? Количество - это абстракция, но вполне имеет отношение к реальному миру. Ты же не можешь предположить что у тебя батя вдруг не один, а скажем полтора бати, даже если ты уверен что твоя мамка шлюха.
> Ты же не можешь предположить что у тебя батя вдруг не один, а скажем полтора бати, даже если ты уверен что твоя мамка шлюха.
Крикнул
Ты мне показал батю, а ты мне отдельно число в природе покажи, вумник.
>Почему пользоваться классами и объектами, а не допустим списками? Ведь суть одна и та же.
А как твои списки генерируют СОБЫТИЯ ?
0E2C190E2E2D0E2E2E0E2E2D0E1B2C140E2E2D0E2E1E140E2E1A0E2F1C0E2E1D0E2F2C14
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
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
Поллинг.
Ты со штульманом перепутал.
>Знаешь там погрешность порядка двух диаметров солнц максимум, так что
Так что? А теперь раздели диаметр земной орбиты на два диаметра Солнца и посмотри какое большущее число получится.
МОЧЕРАТОР!!1 ТУТ ЦП!1
>Из машины Тьюринга можно построить любую вычислительную систему.
И? Как из утверждения "на машине тьюринга можно реализовать что-то более выразительное" следует утверждение "машина тьюринга сама столь же выразительна".
Если тебя выразительность машины тьюринга устраивает, то открывай брейнфак и пиши там, никаких функций, объектов, замыканий чтоб я не видел в твоём коде.
>Математика - лженаука, она изучает несуществующий предмет
Вот два пальца, вот три пальца, посчитай вместе будет пять пальцев.
Вот один человек, вот четыре человека, посчитай вместе будет пять человек.
Вот человек говорит с тобой, спрашивает сколько человек в том здании, ты говоришь ему "пять", он представляет себе пять человек.
Охуенно блядь несуществующий.
>покажи мне отдельно существующее число в природе. Их нет.
Из этого не следует, что концепция числа ничего не значит, т.к. всякое число является отображением реальности, как я только что показал на примере пальцев и людей.
Ну насчёт мнимых чисел разве что точно не скажу, а всякое действительное число это совершенно точно способно описывать реальный мир с пальцами, людьми и килограммами.
Так то же самое касается лямбдакалькулюса, который ты противопостовлял Тьюрингу. Вот уж от кого смешно слышать претензии к похожести на брейнфак.
>Вот два пальца, вот три пальца
Это пальцы.
>Вот один человек, вот четыре человека
Это человеки.
Числа мне покажи, джениус. Числа в природе.
Тебе и звук показать нельзя, его же не видно
Звук слышно ушами. Каким органом чувств воспринимаются числа?
Так что это у нас тут? Пациент не способен к простым обобщениям. Из анамнеза: легкая степень олигофрении.
>Звук слышно ушами.
https://www.youtube.com/watch?v=kzo45hWXRWU
Звук слышно мозгом. Так же, как и числа, которые воспринимаются им же
>Каким органом чувств воспринимаются числа?
Мозгом, как и пальцы со звуками.
Для этого правда нужно абстрактное мышление, но судя по тому что ты способен выучить и понимать человеческий язык, что ты нам тут и продемонстрировал, оно у тебя имеется.
Если ты считаешь что способность воспринимать обобщения это для петухов и нинужно, то сразу после того как прочтёшь этот пост тебе следует перестать пользоваться языком, ибо язык это тоже обобщение, ведь в мире не существует слова "яблоко", в мире есть только яблоки, а слова ты уже мозгом воспринимаешь.
>Для этого правда нужно абстрактное мышление
> Картинка с врачом
Так это тебе врач нужен, если у тебя в голове самовозбужденные глюки лженаучные мерещатся.
Абстрактное мышление - самоиндуцированная ментальная глюка.
А сказать-то что хотел?
>Мозг
>огран чувств
Дальше не читал.
Блядь, какой же ты долбоеб. Теперь из-за тебя он оигнорит мой пост, который его разъебывает, доебавшись до какой-то хуйни в твоем моем посте.
>ведь в мире не существует слова "яблоко", в мире есть только яблоки
Верно. Вот и чисел не существует в природе, только несколько яблок.
>в твоем моем посте
Последствия перенесенного гриппа дают о себе знать
Последствия перенесенного гриппа дают о себе знать
Двачую, большая часть того чем так гордятся гении является по факту бредом.
Ну не корона и то уже хорошо.
Ну не. Там наверное про восприятие частоты. Так то я даже с таким знаком https://ru.wikipedia.org/wiki/Зонная_теория_музыкального_слуха
Но сам звук то воспринимается ухом физически. Улитки, барабанны перепонки, наковаленки с молоточками и стремечками, вот это все.
При желании запутанно можно писать на чём угодно, тот анон речь вёл о том, что функциональная нотация ближе и понятнее человеческому существу, чем распутывание цепочек из goto
Правильно сделал. Ведь чтение - это абстракция, а абстракции нинужны, только реальность, только счёт на палочках.
Толсто.
>Ну не. Там наверное про восприятие частоты.
Там про то что один и тот же звук воспринимается по-разному в зависимости от видеоряда. А единственное место, где сигналы от уха и глаз пересекаются - это мозг.
Давай-ка разберём по порядку.
Допустим ты начал разговор, искренне желая помочь избавиться от заблуждений оппоненту, тогда как оппонент заблуждется опять же совершенно искренне (а не толсто тралирует).
Дальше ты видишь, что твой оппонент показывает себя демагогом, реагируя на пост другого человека соответствующим образом.
Теперь ты понимаешь, что твой оппонент - демагог. Можешь ли ты расстроиться из-за того, что не смог разубедить демагога? Нет. Демагога разубедить невозможно, т.к. он не за истиной в дискуссию приходит.
Но ты расстраиваешься. Почему? Ответ прост - потому что ты на самом деле тоже демагог, преследующий цель посоревноваться в ментальной гимнастике. Истина тебе побоку, тебе надо просигналить свой ум и подвешенный язык.
А теперь вопрос - почему меня должно ебать, что я разломал дискуссию двум демагогам? Да сосите хуй, ёпт, меня это только радует.
Не, сам пробовал - пиздец ещё тот.
>А теперь вопрос - почему меня должно ебать, что я разломал дискуссию двум демагогам?
Потому что этот демагог - ты, лол. Вот твои посты.
Я прошел мимо и захотел помочь твоей точке зрения (хотя всю твою ФП-шизу и 0 новых мыслей за последние годы я в рот ебал, ты один из самых скучных долбоебов на борде). Ты спиздил у меня аргумент (потому что сам лучше не придумать не можешь), но при этом полил (как обычно) кучей графоманского дерьма, полного самолюбования. Твой оппонент доебался до этого самолюбования, и ты, как собачка, побежал за ним, в вашем демагогическом самоотсосе.
>кидает понятную нотацию
>пытается высмеять, напирая на непонятность
А что непонятно-то? Вот объявления функций, вот тела функций, вот вызовы функций.
Никаких перещёлкиваний регистриков при этом не происходит, машина никем не командует, в отличие от императивщины, где машина приказывает программисту помнить где там чё в ней хранится. Функциональный и объектный подход - это сила, это путь наверх, императивные портянки это обсасыванье байтов всемогущей машине, это путь во времена рабства.
А я и не утверждал будто я не демагог, лул. Что не отменяет того, что вы двое - демагоги.
>всю твою ФП-шизу
Подожди, в приведённых тобой постах нет ничего про ФП.
Я наткнулся на пост и решил позабавиться над очевидной хуйнёй
>Математика - лженаука, она изучает несуществующий предмет, покажи мне отдельно существующее число в природе.
Не путай меня со своими протыкателями, которые уже миллион лет тебя тралируют тут (сочувствую кстати, если так), я лично и в фп-тред не заходил, если он тут вообще есть.
И кстати вот это - не твой ли пост?
Человеку естественна запись алгоритма, а не функций. Ну кроме полутора савантов.
>кидает понятную нотацию
>брейнфак ym.yn.ym.yn.ym.yn ЗАТО РЕГИСТРЫ НЕ ЩЕЛКАЮТ
У тебя в голове походу что то щелкает
> решил позабавиться над очевидной хуйнёй
>но число в природе так показать и не смог
Хм, с одной стороны верно, но с другой вспомни школу:
"корень из икс это такое число, которое в квадрате даёт икс"
Чисто декларативное описание ведь. А про метод Ньютона никто в школе и не вспоминает. Значит не только алгоритмами нам свойственно мыслить.
>даёт
А, пробежал по треду и понял, что тут произошло.
Вот этот чел - , который пишет зачем-то с большой буквы термины - не я.
Потом пришёл я и встал на его сторону.
Потом пришёл ты и встал на мою сторону.
Потом ты решил, что раз мы защищаем с тем аноном один тезис, следовательно мы - один человек.
Что-ж, ты ошибся.
>функция принимает такие-то аргументы и возвращает такие-то значения
>брейнфак
Походу у тебя в реале фак с твоим брейном произошёл.
>Четкая машина Тьюринга с четкими инструкциями перехода
>брейнфак
Нет, у тебя.
>но число в природе так показать и не смог
А где-то подписывался, что буду число в природе показывать? Я сказал
>>покажи мне отдельно существующее число в природе. Их нет.
>Из этого не следует, что концепция числа ничего не значит, т.к. всякое число является отображением реальности, как я только что показал на примере пальцев и людей.
Число - отображение реальности, её модель, а не сама реальность.
Мы можем с такой моделью ракеты в космос запускать. С такой моделью мы можем спроектировать протоколы для обмена сообщениями на сосаче, значит нам обоим есть выгода от этой модели. Вот и обоснование нужности математики. А шифрование с открытым ключом это вообще на 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 и т.д.
>foreach(r in rect) if m.x>=r.x && m.x<=r.x+r.w и т.д... generateEvent(...)
фикс
>Чисто интуитивно, мне кажется, что под капотом, на уровне ОС или фреймворка там все равно поллинг.
Мало ли что там "всё равно".
В конечном итоге там всё равно несколько регистров, каждый из которых является всего лишь аналогом числовой переменной - но это не значит, что если написать, например, полный аналог Ассемблерного кода на высокоуровневом языке(а это вполне возможно), то будет хорошо.
Если бы цикл Loop на высокоуровневом языке оборачивался с частотой несколько сотен мегагерц... то почему бы и нет ?
Можно было бы тогда даже многозадачные приложения писать, аналогично тому, как пишется многозадачное приложение для микроконтроллера и не нужны никакие "события".
Вернее, "события" делались бы простыми проверками тех или иных условий в беспрерывно работающем цикле. На контроллерах так и делается.
Да и процессор, наверняка, так же, принципиально, работает.
Но вот не крутится цикл Loop в приложении, которое само работает в порядке очереди, притом, не самой приоритетной очереди, в порядке других задач. Этот цикл может оказаться, на самом деле, я не знаю, циклом десятого уровня вложенности, если отсчитывать от цикла работы процессора.
Поэтому стиль программирования для низкоуровневого не стоит применять(хотя работать будет) по отношению к высокоуровневому коду.
Да это все понятно, но никак ты не избавишься от этого евент лупа, сколько не закапывай его под ковер. Как не избавишься от foreach, пиша map/reduce. Ну если тебя так смущает event loop, напиши его где-нибудь в файлике main один раз и спрячь с глаз, а погоди, твой фреймворк с событиями ровно так и поступает.
>но никак ты не избавишься от этого евент лупа, сколько не закапывай его под ковер.
А я и не собирался "избавляться" от евент лупа. Он никуда деться не может.
Просто если мы его будем сами писать в своём коде, он будет выполняться с одной скоростью,
Но если мы "оставим его под ковром", то там он выполняется совсем с другой скоростью, не достижимой для кода, который мы пишем.
Именно поэтому не надо его из под ковра вытаскивать.
Вот аналогия :
Есть внутренняя функция языка "InStrB()", она скрыта от глаз "под капотом" и наверняка написана на машинных инструкциях.
Недавно я попробовал написать её аналог на самом языке - скорость выполнения написанного мною аналога оказалась в тридцать раз медленнее ! - что бы мы не вытаскивали из под капота в код высокоуровневой программы, окажется медленнее, чем вызов интерфейсного метода или оператора или внутренней функции языка.
Там, под ковром(или за методом WinAPI), может и вращается цикл, но он, по любому гораздо подвижнее цикла, который мы можем написать в своём коде.
>Просто если мы его будем сами писать в своём коде, он будет выполняться с одной скоростью,
>Но если мы "оставим его под ковром", то там он выполняется совсем с другой скоростью, не достижимой для кода, который мы пишем.
Что следует из?
>Вот этот чел - , который пишет зачем-то с большой буквы термины - не я.
Имена собственные разве не с большой буквы пишутся?
>Недавно я попробовал написать её аналог на самом языке - скорость выполнения написанного мною аналога оказалась в тридцать раз медленнее
На нормальном языке c++ такой проблемы не возникнет.
Пишутся, конечно. Но названия понятий не относятся к именам собственным.
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.
>Что собственно и требовалось доказать.
Ишь какой, а собственно доказать для начала ты не пробовал?
И какой из них ты?
Аппелирую к Авторитетам, которые все это уже сделали лет 80 назад.
Имя собственное (калька с лат. nomen proprium, которое в свою очередь является калькой с греч. ὄνομα κύριον)[1], собственное имя[2] — имя существительное, обозначающее слово или словосочетание, предназначенное для именования конкретного, вполне определённого предмета или явления, выделяющее этот предмет или явление из ряда однотипных предметов или явлений.
http://gramota.ru/biblio/magazines/gramota/onomastics/28_126
У тебя плохие примеры. Электронно-лучевая трубка собирательное название. Теоремы различные и так принято писать с большой буквы. Насчет физики, химии, и прочего, тут надо смотреть контекст.
Я третий долбоеб, не участвующий в тупых терминологических срачах, а решающий прикладные задачи. И похуй, как это называется: ООП, ФП, АОП, СОП, ХУЙП, НЕБОП, АЛЛАХП.
Естественно у природы никакого понятия количества нет. Как и вещества. Это просто вибрации на закольцованых струнах в 27-мерном пространстве.
Книги Бертрана Мейера есть на русском. Если что.
Сразу пахнуло 90-ми от дизайна.
>имя существительное, обозначающее слово или словосочетание, предназначенное для именования конкретного, вполне определённого предмета или явления, выделяющее этот предмет или явление из ряда однотипных предметов или явлений[/B]
Вот эту часть не учёл. То есть должно существовать некоторое множество обязательно конкретных предметов или явлений, из которого ты выделяешься названием.
Множество людей, множество рек, множество сайтов в интернете, множество компьютерных игр, множество ураганов (все ураганы как ураганы, а ты - "Катрина").
А лямбда-исчисление это из множества чего? Из множества формальных систем? Так формальные системы не конкретны, нельзя подойти, пальцем показать и сказать - "во, смотри, формальная система!"
>Теоремы различные и так принято писать с большой буквы
Не-а. "Я доказал теорему Пифагора" а не "Я доказал Теорему Пифагора".
>не участвующий в тупых терминологических срачах, а решающий прикладные задачи
Какое забавное противопоставление. А одно другому мешает?
Я решаю прикладные задачи так, как мне нравится, и в срачах слушаю аргументы тех, кто делает не так, мотаю на ус и модернизирую свои навыки. Диалектика в действии.
Есть разница между диалогом вида:
- X.
- Ты не прав. Y.
И:
- X
- Интересно, возьму на заметку.
Так она написана в 80-х.
- Мамку ибал!!!!!1111
- Интересно, возьму на заметку.
Взял тебе за метку
>Естественно у природы никакого понятия количества нет.
В природе это есть. Есть озера большие и есть маленькие. Разница в КОЛИЧЕСТВЕ воды. Есть двуногие и четвероногие живые существа. Ты так неумело троллишь или у тебя действительно сдвиг по фазе? Просто если ты не ощущаешь вокруг себя количественные явления, то это умственная отсталость. И вряд ли с таким IQ тебя бы взяли в крутой универ на научную или инженерную специальность.
Взял самому себе за щёку, чекну.
У природы вообще нет "понятий", о которых ты писал, дебс.
>Бог любит нас и на всё Его воля
>Интересно, возьму на заметку.
Анон, ну я же, мать его, инженер. Какой от меня прок если я буду брать на заметку всё подряд без критической оценки?
Если ты мне продаёшь бронежилет, я сначала выстрелю в тебя, а потом куплю, если останется у кого покупать. Тезис должен столкнуться со старательно выкованным мной антитезисом, и лишь то, что останется на этом пожарище, будет истиной. Которую стоит брать на заметку.
А чё у неё есть?
Ничего нет, это всё куски мяса выдумали.
А как люди в космос попали?
А им похуй было, есть что-то в природе или нет, они прикладную задачу решали, лол.
Если твоё количество дискретно, то натуральные числа есть. Если оно непрерывно, то ты попадаешь на апории зенона и прочие парадоксы бесконечного деления пространства.
Мамкины нигилисты, у которых вообще ничего нет - скучные уебки, которым не дают тянки
struct в тех же плюсах вроде. Тот же объект, только без методов. Питоновский named tuple. Словарь из того же питона.
>Поэтому ты расскажи как бы ты в процедурном стиле описал новый тип данных? У тебя есть стандартные типы - целое, число с плавающей точкой, символ, булеан. А тебе нужен, например такой тип как время в формате hh:mm:ss.
Не в процедурном, а в функциональном. Очень просто. С помощью функций. Также как в СИКП реализуют рациональные числа и арифметику над ними.
И наверное для этой прикладной задачи пришлось дохуя всякой хуйни посчитать, да?
Зенону самому тянки не давали.
Нахуя тебе спрашивать тянок, если ты живешь в рабовладельческом строе?
Могу только повторить - если бы ты писал на c++ или asm такой проблемы бы не было.
Приходит Зенон к тянке, а та усмехается - чтобы присунуть на шишечку, надо сначала на пол шишечки. А чтобы на полшишечки, надо сначала на четверть. Зенон обиделся и вышел.
Странно, вот не могу сказать что "в голосину проиграл" с этой шутки, но в то же время мне она кажется весьма остроумной.
>если бы ты писал на c++ или asm такой проблемы бы не было.
Касаемо Ассемблера - в нём нет внутренних функций, помимо элементарных операторов.
А в чём заключается "проблема", о которой ты говоришь ?
Никакая внутренняя функция языка, описанная с помощью других внутренних же функций этого языка не может работать медленнее, чем её костыляторная имитация. Вернее, может конечно. Только вряд ли разработчик языка мог написать такую.
Но ты мог бы посоревноваться с ним сам. Потому что лично я не питаю подобных тщеславных надежд.
Можно. По моему, в стандартном апи пистона так часто делают. Попробуй листалку на urllib написать, например.
Я только классы умею.
Шутка охуенная, но кому ее рассказать
> к тянке
Ржали всем /b/ ))0))0)
Завтра знакомому интеллектуалу расскажу, обязательно ПРООРЁТ.
Простое переиспользование кода. Объекты можно рассматривать как модули. К тому же, ООП решает проблемы древних байтоебских типов.
Никто не использует НЕ ДОЛЖЕН использовать ООП в чистом виде. Но частичное его применение позволит правильно организовать данные программы.
> Религия
> Филология
> Но только не обсуждение сабжа треда
Объекты это философское понятие.
Не стоит впутывать философию в программирование. Это не даст ничего практически полезного. Концепции(такие как ООП) нужны, но не стоит их накладывать на ИРЛ.
Ну тут я бы поспорил, если ты вебмакака-кодер то возможно, а вообще говоря сама сущность объекта, принципы как их выделять из окружающего мира, принципы наименования, долго можно продолжать. Можно еще вспомнить про этическую сторону (не делать программы убивающие людей, отнимающие работу, и т.д.)
>не обсуждение сабжа треда
>сабж треда философский
Да иди ты на хуй!
Поэтому и не разобраться в вашем коде
императивщина считай та де машина тьюринга
>Для чего нужно ООП?
А для нужно погромирование?
Выполнять утверждения. Ряд утверждений, решающих задачу, называется функцией.
Примитив объекта излишен для решения задач.
Ага, а автомобиль - то же колесо.
>функцией
Это разновидность объекта.
У борщехлёбов что ни возьми - функция. Типы - функция, значения - функция, пробелы - фугкция, небо - функция, аллах - функция.
недооценный пост.
Помню, студентом вообще не понимал нахуя они все это придумали. Реальный смысл раскрывается только в командной работе с кучей долбоебов.
Один то ты сможешь договориться сам с собой, а для других долбоебов нужны формальные правила игры.
>пук
)
Борщехлёб, плес.
>написал хуйню
>борщехлёб виноват
)
>Для чего нужно ООП?
Для удешевления труда программистишек, чтобы знали свое место и не задирали носы.
>Какие проблемы и задачи оно решает?
Позволяет писать сложные проекты горсткой дешевых, легко заменяемых индусов. Java, C#, это вот все.
В виртуальном манямире интерпретируемых языков - да.
ооп - один из возможных подходов к композиции структур данных и алгоритмов, обрабатывающих эти данные
вассерман:
главный принцип программирования очевиден: сколь угодно сложную задачу можно разбить на кусочки, настолько простые, что с ними справится кто угодно. С тех пор ничего не изменилось. И этот принцип работает не только в программировании.
объектно-ориентированное программирование, когда программу собирают из структур, содержащих и данные, и методы их обработки.
Вспоминается официальное сообщение о языке Алгол-68: «всякое действие, описанное в настоящем сообщении, может быть заменено любым иным действием, дающим такой же внешний эффект». Эта фундаментальная концепция, на мой взгляд, ещё довольно долго останется одной из ключевых в программировании. Так же, как до того ключевой была идея структурного программирования, то есть той самой декомпозиции сложной задачи на элементарные компоненты, но только в применении, прежде всего, к методам обработки, а уж затем к структурам данных.
главный принцип программирования очевиден: сколь угодно сложную задачу можно разбить на кусочки, настолько простые, что с ними справится кто угодно. С тех пор ничего не изменилось. И этот принцип работает не только в программировании.
объектно-ориентированное программирование, когда программу собирают из структур, содержащих и данные, и методы их обработки.
Вспоминается официальное сообщение о языке Алгол-68: «всякое действие, описанное в настоящем сообщении, может быть заменено любым иным действием, дающим такой же внешний эффект». Эта фундаментальная концепция, на мой взгляд, ещё довольно долго останется одной из ключевых в программировании. Так же, как до того ключевой была идея структурного программирования, то есть той самой декомпозиции сложной задачи на элементарные компоненты, но только в применении, прежде всего, к методам обработки, а уж затем к структурам данных.
Ты о чем бля?
Посмотри определение объекта, все на свете является объектами, поэтому процедурно и функционально ОП является ООП.
Алсо языки не делятся на интерпретируемые и нет, это вопрос реализации. На виртуалках у тебя даже машкод интерпретируется, а виртуальные драйвера были уже в 95 винде.
Это полная хуйня. Так же можно сказать что всё на свете это процесс, или что всё на свете это энергия, или что всё на свете это Аллах.
Объект это слишком абстрактное понятие. Математические объекты и объекты из ООПе - и то и то как бы объекты, но объекты разного толка.
Процитирую классика.
современое ООП:
толпы быдла долбятся головами об стену невидя двери - для них выпиливают люк.
/thread
Да бля, процесс, энергия, Аллах - это объекты, просто потому что так быстрее и удобнее программировать, с опытом узнаешь.
Ололо, ООП-макака кого-то поучать ещё будет.
Вот у меня в эрланге процессы представлены функциями, и программировать многозадачные приложения на нём в разы удобнее и быстрее, чем на какой-нибудь джяве.
>Да бля, процесс, энергия - это объект
Это как если бы глагол являлся существительным - мозг выносит
Interface Pussycat {
Kingdom: Animalia;
Phylum: Chordata;
BioClass: Mammalia;
Order: Carnivora;
Suborder: Feliformia;
Family: Felidae;
Subfamily: Felinae;
Genus: Felis;
Species: FelisCatus;
}
Наличие всех этих интерфейсов, естественно, подразумевается. У нас же тру-ООП.
Двачую, ООП это полный дебилизм
Зачем делать
МояЖопа = новая Жопа(); НовоеГовно = новое Говно(); если(МояЖопа.Говно) МояЖопа.Срать(); иначе МояЖопа.ЗалитьГовна(НовоеГовно);
когда можно просто Срать(Говно)?
Изобрести(процедурное_программирование, заново);
Полиморфизм. Как ты сделаешь dependency injection в процедурном языке? Структура с указателями на функции? По сути ты переизобретаешь ОПП, где все это решается программированием от интерфейсов.
Это 1С?
Для этого достаточно первоклассных модулей, реализующих одинаковый интерфейс. В принципе именно из модулы ООП логически произрастало, пока всякие пидары не сделали из него хуй пойми что.
Инкапсуляция - даёт возможность использовать одинаковые названия для переменных и не бояться, что код наебнется. Служит инструментом для изоляции кода, который будет независим от внешнего кода и будет зависеть от кода в который инкапсулирован, т. е. обязан выполнять определенную политику, которая гарантирует работу кода о котором этот код не знает. Есть у тебя класс с методом, который принимает классы реализующие определенный интерфейс - тебе не нужно знать, что этот метод делает внутри, тебе достаточно реализовать этот интерфейс у своего класса.
Полиморфизм - создал один раз и это работает для многих классов и их наследников, чтобы расширить функционал, тебе не надо лезть в уже существующий код, ты просто наследуешь класс или интерфейс.
Наследование - весь одинаковый функционал, всё общее помещаешь в абстрактные классы, интерфейсы и классы, а конкретное в классы которые их наследуют и реализуют. Всё получается коомпактно и без дублирования.
Полиморфизм - создал один раз и это работает для многих классов и их наследников, чтобы расширить функционал, тебе не надо лезть в уже существующий код, ты просто наследуешь класс или интерфейс.
Наследование - весь одинаковый функционал, всё общее помещаешь в абстрактные классы, интерфейсы и классы, а конкретное в классы которые их наследуют и реализуют. Всё получается коомпактно и без дублирования.
> Для этого достаточно первоклассных модулей, реализующих одинаковый интерфейс.
Это ООП и есть, лол. Только данные и код можно хранить вместе, и не надо каждый раз передавать структуры в функции, как в процедурном программировании.
> пока всякие пидары не сделали из него хуй пойми что
Если ты про наследование, то оно нахуй не нужно. А если про 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/ . Если представить, что таких модулей у меня пять и более, то там вложенность будет просто ебучая. Я не фанат ООП, но тут признаю, что интерфейсы удобнее и гибче.
> Erlang/Elixir/Clojure
Что то из живых языков будет или ограничишься мёртвыми языками на которых кроме "любительская хуета от сектанта #21" ничего нет?
Ну хуй знает, я на эликсире уже лет 5 пишу, вакансии регулярно прилетают, как то не заметил его смерти.
Но вообще забавно как ты, обосравшись, решил сменить тему. Мань, речь шла о том, что есть масса не ОО-языков, в которых есть всё о чём ты пишешь. Причём я привёл пару продакшн-ЯП, которые используются на практике, а не какую-то обскурную экзотику.
Просто, как и я сказал выше, ты зашореная чмоха, которая нихуя кроме ОО-параши в жизни не видела. Само по себе это не порок конечно, люди идут программировать на жабе/похапе не от хорошей жизни, да и на языки и с программированием им насрать по большому счёту, но вот с умным видом что-то пояснять про полиморфизм/икапсуляцию с таким ограниченным кругозором это пиздец позорище.
>что есть масса не ОО-языков, в которых есть всё о чём ты пишешь.
Ты забываешь уточнять, что это только твоё мнение, которое ничем кроме твоего манямирка не подкреплено.
>Причём я привёл пару продакшн-ЯП, которые используются на практике
На С без всякого ООП целые операционные системы писали, представь себе. Вот только каким хуем это наделяет С всем тем, что есть у ООП и каким хуем оно отменяет те возможности, которые ООП предоставляет, одному тебе, долбоебу, известно.
У тебя на всё один аргумент - ЭТО ЕСТЬ И В ФУНКЦИОНАЛЬНОМ ПАГРАМИРАВАНИИ!!! Хотя сама суть разделения на ООП и ФП это отрицает. Т. е. ты с голой жопой идёшь против всего мира, а потом еще и возмущаешься, когда тебя никто всерьез не воспринимает.
С памятью меньше возни, все деструкторы (освободители памяти) не разбросаны по куче функций. Не нужны никакие флаги а-ля когда память размечена, когда не размечена (у меня такие есть где-то).
Что вы несёте, сударь?
Функциональщина (фундаментальная операция - редукция выражения), противопоставляется императивщине (фундаментальная операция - присвоение, т.е. запись блядских нулей и единиц в блядскую ячейку памяти).
ООП это частный случай императивщины, это даже не парадигма, и никаким боком не противопоставление ФП, именно поэтому "ЭТО ЕСТЬ И В ФУНКЦИОНАЛЬНОМ ПАГРАМИРАВАНИИ!!!" - чистейшая правда. Да, оно (классы и объекты) там действительно есть. Чего там нет - так это присвоения.
>это даже не парадигма
Ясно.
> Функциональщина (фундаментальная операция - редукция выражения), противопоставляется императивщине
Нет, это декларативщина противопоставляется императивщине, И она бывает не только функциональной, но и логической, например, Prolog. inb4: Prolog - это функциональщина, и ООП функциональщина, и ассемблер функциональщина, и небо и аллах функциональщина
Нет.
Противопоставления всего два. Первое - "вычислить vs исполнить". Это функциональщина со своими вычислениями против императивщины со своими записями в память (ты будто вообще не читал мой пост). Можно редуцировать это понятие вплоть до лямбда-исчисление против машины Тьюринга.
Второе - "механизм vs декларация", где механизм - "вот конкретная последовательность действий чтобы превратить выражение в результат", а "декларация" - это когда ты описываешь задачу в терминах конечного результата ("я даю тебе значения, ты мне дай предикат который им удовлетворяет"), а программа даёт результат не с помощью чёткого алгоритма, а с помощью перебора.
Ты смешал понятия "ебаться с памятью" и "алгоритм". Алгоритм может быть и без ебли с памятью, как ебля с памятью может быть алгоритма.
Таким образом, "вычисление + декларативность" это логическое программирование, "вычисление + механизм" это как раз-таки функциональщина, а "выполнение + механизм" это императивщина.
А "выполнение + декларативность" - такого не существует. Это по сути своей кнопка "сделать пиздато", которая без ИИ невозможна.
Ещё раз, если непонятно изложил:
"Вычислить" - значит редуцировать некое выражение до примитива, т.е. фундаментальная операция в такой системе - редукция.
"Выполнить" - значит записать некое значение на ленту, т.е. фундаментальная операция - присвоение (на самом деле не только присвоение, а обращение, т.к. мы в ячейки можем как писать, так и читать)
Ебсти память и действовать по алгоритму это разные вещи.
Поэтому пролог это не "логическая декларативщина", а "логическое программирование" это "вычислительная декларативщина", в противовес ФП которое суть "вычислительная алгоритмщина", а со стороны на их противоречие смотрит ассемблер, который суть "исполнительная алгоритмщина"
Нет признаков парадигмы. Признак парадигмы это наличие критерия по которому существовало бы что-то противоположное данной парадигме. Что является противоположностью ООП? То же самое, что является противоположностью языку си: декларативное и вычислительное, в противовес алгоритмической и исполнительной, скажем, джаве.
Просто в понятие "императивность" слито два разных понятия - операция с памятью и действие по алгоритму, которые не обязаны идти рука об руку.
О, крутяк, можете мне пояснить один вопрос: как в принципе можно вообще обходится без присвоения?
Для решения задач вычисления - оно понятно, хотя меня всегда немного смущало, что желательно реализовывать итерации через хвостовую рекурсию, которая исполняется подобно циклу, которых в функциональном подходе нет. Как-то это странно, сначала исключать цикл, а потом пытаться его повторить другим способом, ну да ладно, сейчас не об этом.
А вот если мне нужно не вычислить значение, а скажем получить сообщение по сети? Или построить хэш таблицу? Что в таком случае делается? Или ограничение на присвоение не строгое?
Я тут не помогу, к сожалению.
У меня есть понимание того, чем по сути своей является функциональщина, но я не знаком с языками дрочащими на ФП (именно дрочащими, а не содержащими, хаскель к примеру), и как следствие не знаком с "лучшими практиками" в них.
Как делаю лично я? Пишу функционально всё что могу, а что не могу пишу императивно. Клиент-сервер это как раз классический случай когда без стейта не обойтись. А в общем случае без стейта нельзя обойтись тогда и только тогда, когда у тебя величины могут меняться во времени, например функция, возвращающая рандомное число или сервер, который сидит на потоке и СЛУШАЕТ его, т.е. должен вести себя по разному в зависимости от того, какое сейчас время.
Алсо рекомендую к прочтению третью главу SICP — там неплохо разъяснено про эти тонкости.
Спасибо! Почитаю
>>ООП
>>это даже не парадигма
>Ясно
Напомни-ка мне, из чего состоит объект? Наверное из СОСТОЯНИЯ и методов, да? А что такое СОСТОЯНИЕ, не подскажешь? Наверное такая штука, которая может во времени изменяться, да? Ну прям как переменная, да? Объекты без состояния антипаттерном в ООП являются? Так точно.
Какой из этого вывод? ООП = императивщина. Всё, где есть сайд-эффекты, является императивщиной.
Даже если ты смоллтокоёб с иммутабельными объектами, энивей у тебя что-то помещается в память (пусть даже не ты сам руками помещаешь, а обращаешься через ссылку, но суть та же), это что-то можно оттуда прочесть, а потом сборщик мусора сотрёт.
> энивей у тебя что-то помещается в память
И только в волшебном хачкиле это не так. У него, видать, под капотом всё само делается магией, а не железом.
Причём тут вообще хачкель?
Или это был очередной дебильный намёк, что дескать "ну ахахах смарите раз на уровне ассемблера императивщина значит всё императивщина", нет дорогой мой, парадигма это понятие языковое, если в языке это есть значит это есть, а чё там в компиляторе происходит — его собачье дело. Да в общем-то в тех же лисп-машинах никакого ассемблера нет, шах и мат на самом деле шах и мат был в прошлом предложении поставлен.
>а чё там в компиляторе происходит — его собачье дело
Перезаписал тебе стек, няша. Проверяй
>На С без всякого ООП целые операционные системы писали, представь себе.
На самом деле - со всяким ооп.
https://www.kernel.org/doc/html/v4.13/driver-api/index.html
ебать ты хакир, небось сидишь ещё в реверс треде
В js есть только объекты. Больше ничего.
Есть еще примитивы, но их можно тоже рассматривать в качестве синглтон объектов, потому как они боксятся, а сделаны разумеется для производительности. (тем более что сейчас ничего не мешает у примитивных добавить в цепочку прототипов прокси объект, отлавливащий сообщения, типа присваивания, и реалиховать поведение прототипов как полноценных объектов, но это ни к чему. проще воспринимать их как синглтоны. когда надо, любой примитив можно обернуть в полноценный независимый объект).
Так. Короче только объекты.
Все объекты делятся на callable и non-callable. Callable это функции, в понимании большинства. Но по факту это все те же объекты, со всеми свойствами что и у других.
Все объекты могут принимать всего несколько типов сообщений - get, set и call. При чем call может принимать только callable объект. при попытке послать call сообщение не-callable объекту будет исключение.
Сообщение get содержит один параметр, сообщение set два. Сообщение call параметром содержит кортеж аргументов, а так контекст this.
Если в объекте (а так же в цепочке прототипов) не назначены слушатели для get и set с определенными параметрами, ищутся слоты с такими именами в объекте и по цепочке. Если находится возвращается то, что в них лежит. Если в них лежит callable объект и ему посылают сообщние call сразу как получили его из слота, то у него будет перегружен контекст (this) на объект из чьего слота его получили. Если только этот объект не был сконструирован стрелочным синтаксисом, иначе контекст перегрузить нельзя. Если после получение callable объекта из слота его сразу не вызвать, а например положить ссылку на него в переменную, то контекст будет сброшен на тот, который был установлен у него в момент его создания (и это не обязательно будет тот же объект из чьего слота его получили).
У callable объектов есть scope (область видимости) и контекст (this) в момент посылки им сообщения call (вызова). scope средствами языка перегрузить нельзя, но некоторые окружения позволяют (например в ноде есть модеуль vm), this перегружается у callable объектов сконструированных не-стрелочным синтаксисом
Классов нет. Есть конструкторы. Любой конструктор принимает новый созданный объект, которому выставлен определенный прототип (другой объект). Оператор instanceof (someObject instanceof SomeClassName) проверяет лишь есть ли в цепочке прототипов у someObject объект который лежит у SomeClassConstructor в слоте с именем prototype. На сам конструктор ему поебать. Чтобы сменить класс, достаточно сменить цепочку прототипов. Даже если объект был сконструированным определенным конструктором.
Так же у объектов есть параметр ограничения доступа, контролирующие его расширяемость или изменяемость (sealed, extensible, frozen). У слотов объекта есть параметры configurable, enumerable, writable. Параметры слотов объекта не влияют на объекты, что в них лежат. Они лишь контролируют доступ к самим слотам.
Все. Никаких классов. Никаких интерфейсов. Как отдельных сущностей. По факту все есть объект и все строит из них.
наследование реализуется выстраиванием цепочки прототипов. Инкапсуляция только на уровне scope'в (читай замыканий).
В остальном все меняется и все динамично, если только специально все не зафризить в момент конструирования. Но обычно этим никто не заморачивается по причине оверхеда и бессмысленности. Разве только фанатики по иммутабельности, н это все из разряда те, кому надо чтобы им по рукам бил компилятор\рантайм\дядя петя. Все "привычные" понятия тянуться в язык для еще более простого вкатывания тех, кто приходит из других языков. Так уж сложилось, что есть куча литературы по привычному, статически классовому ООП, но очень мало по мессадж-пассинг\прототайп-базед\мета-программинг. Все эти притянутые понятия выливают в синтаксический сахар, который не делает ничего полезного, а даже наоборот, еще больше вносит путаницы и от того непонимамания многих вещей в языке. При этом часто этот синтаксический сахар дэже урезан и вспомнинают об этом лишь после (как например проебались с полями в конструкции class и тянут ее теперь только в proposol'ах будущих версий).
JS истинно объектный язык. В современный язык притащили много вкусных вещей для метапрограммирования. Нову примитивную сущность Symbol, и Proxy-объекты. С помощью которых можно еще больше и сильнее перегружать и менять поведение в динамике.
Другое дело, что почти никто не умеет этим пользоваться и не понимает, что такое объектное программирование на самом деле.
Им нужно не объектное, а статически типизированное. А какие именно структуры будут скрываться за этими типами, не собо важно. Важно что это просто структуры и функции, строго привязанные к ним, или иногда менее строго. То, что в Java\C++ это больше структурное программирование, нежели объектное. Объектное программирование не может существовать без динамической среды. Это противоречит самому понятию объекта. А динамическое программирование это слишком сложна и непанятна. И как бы не старались с пеной у рта фанатики кричать про низкий порог входа - низкий он именно что для входа, а не для всего остального. Модификация программ в рантайме всегда было уделом креативно мыслящих людей. Для большинства это слишком сложный уровень высокой абстракции.
Есть еще примитивы, но их можно тоже рассматривать в качестве синглтон объектов, потому как они боксятся, а сделаны разумеется для производительности. (тем более что сейчас ничего не мешает у примитивных добавить в цепочку прототипов прокси объект, отлавливащий сообщения, типа присваивания, и реалиховать поведение прототипов как полноценных объектов, но это ни к чему. проще воспринимать их как синглтоны. когда надо, любой примитив можно обернуть в полноценный независимый объект).
Так. Короче только объекты.
Все объекты делятся на 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++ это больше структурное программирование, нежели объектное. Объектное программирование не может существовать без динамической среды. Это противоречит самому понятию объекта. А динамическое программирование это слишком сложна и непанятна. И как бы не старались с пеной у рта фанатики кричать про низкий порог входа - низкий он именно что для входа, а не для всего остального. Модификация программ в рантайме всегда было уделом креативно мыслящих людей. Для большинства это слишком сложный уровень высокой абстракции.
> Далее. У тебя есть кошечка. Она родила котят. Все котята имеют хаост, усы, по два уха. Это наследование.
Вы заебали со своими котятами и фигурами. Реальные примеры из прода будут?
css
на проде наследование ненужно, только интерфейсы.
Окей, допустим ты биолог, ты создаёшь класс Фрукт и наследуешь от него Яблоко...
>Для чего нужно ООП?
Нахуй не нужно на самом деле. Рыночек порешал что на рынке ООП не нужно.
Популярные языки отказываются от ООП. Тот же Javascript, Python, C++ в принципе не заставляют тебя использовать его, а какой-нибудь Go так вообще решил дать пососать.
А много ли языков "заставляет"? Таких только джава да шарфик, и всё. В остальных как были функции, так и есть.
Ну вот эти два, да. Но они очень большие.
> Не заставляют => Отказываются
Ну вот популярные языки не заставляют тебя использовать функциональщину. Это значит, что они от неё отказываются? По такой логике мультипарадигменные языки отказываются вообще от всего просто в силу того, что не заставляют тебя использовать что-то конкретное.
> Python, C++
Больше половины стандартных библиотек написана с помощью ООП, и для их использования приходится его юзать. Не заставляют, да?
> Javascript
Это тот, к которому недавно прикрутили джаваподобные классы?
> Go
С каких пор под ООП понимается то, как сделано в джавашарпах? Smalltalk, видать, не ООП был.
В чем прикол юзать гринтекст приписывая какие-то собственные фантазии оппоненту?
Чтобы ответить на фантазии оппонента, который живёт в манямирке без ООП?
>С каких пор под ООП понимается то, как сделано в джавашарпах? Smalltalk, видать, не ООП был.
Так в том-то и дело что Smalltalk это был именно что ООП. То что Алан Кэй придумал, который был прекрасный математик, джазовый исполнитель и вообще хороший человек. Но вот в промышленной, рыночной разработке вроде никогда не участвовал.
А вот всякие Python и C++ нормальный, тот самый, ООП не использует. Его рыночек порешал в пользу той каши, которая щас называется "Мультипарадигмальные языки общего назначения".
> Ну вот популярные языки не заставляют тебя использовать функциональщину. Это значит, что они от неё отказываются?
Ну да, и от функциональщины тоже. В угоду "практичного, васянского кода который все и пишут.
> Его рыночек порешал в пользу той каши, которая щас называется "Мультипарадигмальные языки общего назначения".
И правильно. Бизнес-задачи на них решаются намного эффективнее, а на сомнительных парадигмах кодеры пусть в свободное время пишут.
> Ну да, и от функциональщины тоже. В угоду "практичного, васянского кода который все и пишут.
Да.
Успехи ООП объясняются только успехами GUI в 90-х. Когда у тебя одни языки без ГЦ, то иерархичная структура объектов-овнеров, события и прочее идеально ложились на ООП. Больше оно никуда не ложилось, данные в реляционных базах лежали, игори вообще на стейтмашине opengl себя нормально чувствовали. Но по инерции люди почему-то подумали, что внедрять ооп - офигенная идея. Но это было именно что по инерции.
С переходом GUI в веб ООП умерло окончательно, потому что в вебе эти подходы не работают совсем.
Заходите в соседний тред про шашечки. Покажите, как спроектировать шашки в тру ооп стиле.
Ну так я ж за это и топлю. Когда я говорю "ФП/ООП никто не использует", я подразумеваю что никто не придерживается тех маняфантазий, которые себе профессора понавыдумывали. Вообще, наука она должна быть описательной, а не предписательной. Когда компьютерные учёные начинают крупным корпорациям пояснять как им писать свой код - это уже за рамки выходит.
Понятно, что современный код это смесь трёх парадигм(СП, ФП, ООП), из них берутся какие-то лучшие моменты, а другие просто рыночком отбрасываются.
Ну чел, там ж на гитхубе их как говна...
>Ну чел, там ж на гитхубе их как говна...
И как долго в этой куче говна надо рыться, чтобы найти эталонную ооп реализацию?
Сморя чё щитать ООП. Вот laravel эт ООП?
Просто понятия эволюционируют, и сейчас под ними понимают не то, что было изначально. Впрочем, под ООП сейчас что только не понимают.
Так на том самом, настоящем ООП вообще никогда не писали. Это не то что всё поменялось
В вебе иерархическая структура так и осталась. И дело не в управлении памятью, а тупо в том, что одни элементы гуя состоят из других элементов поменьше. Даже компоненты в реакте - это тоже одно из видений ООП.
> данные в реляционных базах лежали
Ну а сейчас изобрели монгу, чтобы хранить объекты.
> игори вообще на стейтмашине opengl себя нормально чувствовали
Километровые процедурные портянки, в которых почти никто не мог разобраться. Но геймдев вообще особняком стоит, и парадигмы так свои, уникальные: Data-Driven Design, Entity-Component System (тоже своего рода ООП) и прочее, больше нигде не применимое.
Иерархическая структура есть в любом продукте человеческой мысли из-за особенностей этой мысли. Если называть это ООП, то тогда и ракету Союз можно назвать ООП. Она же из ОБЪЕКТОВ состоит.
Но это все не так, ООП это более конкретная вещь.
Я, например, не считаю, что энтити в геймдеве это ООП, так же, как и то, что хранится в монге, и уж тем более это не про компоненты в реакте. То есть ты сначала дай определение ООП, а потом решим, сдохло оно, или нет. В общепринятом смысле сдохло, см. пикрелейтед.
А то может по твоему определению в хаскеле ООП, а мы тут спорим.
> Иерархическая структура есть в любом продукте человеческой мысли из-за особенностей этой мысли.
Да, в этом и смысл ООП. Ты подразделяешь все данные на некоторые осмысленные сущности, строишь их иерархию и делаешь так, чтобы они обменивались инфой друг с другом. Всё.
> Если называть это ООП, то тогда и ракету Союз можно назвать ООП. Она же из ОБЪЕКТОВ состоит.
Да, как раз потому, что ООП лучше всего описывает объекты реального мира.
> пикрелейтед
Я тогда продолжу твой пикрелейтед и скажу, если ООП сдохло, то остальное и не оживало никогда.
>ты сначала дай определение ООП
Классы, интерфейсы, инкапсуляция, полиморфизм, наследование, паттерны.
Ты ещё абстракцию забыл.
Что конкретно понимается под абстракцией. По-моему она и в остальных парадигмах есть.
https://ru.wikipedia.org/wiki/Абстракция_данных
Судя по определению, это когда ты описываешь некую сущность и оставляешь только самые важные поля, а не пытаешься перечислить вообще все возможные характеристики, какие есть на самом деле.
>Да, в этом и смысл ООП
Это смысл любой инженерной деятельности, включая программирование в данном случае. Назови подход, который не подразумевает иерархию.
>Да, как раз потому, что ООП лучше всего описывает объекты реального мира.
Объекты реального мира лучше всего описывают дифференциальные уравнения, уж в таком мире мы живем
>Я тогда продолжу твой пикрелейтед и скажу, если ООП сдохло, то остальное и не оживало никогда.
Тренды важнее абсолютных значений
Ну так я и говорю, это не отличительная черта ООП, она вообще при любом моделировании используется.
По такому определению rust - ооп. А если убрать классы - то хаскель.
А по какому определению раст с хаскелем не ооп?
> Назови подход, который не подразумевает иерархию.
Нет такого. Потому что остальные подходы - всего лишь подвид ООП.
> Объекты реального мира лучше всего описывают дифференциальные уравнения
Они описывают не сами объекты, а их изменение. Сами объекты - это их свойства. Ничего не говорится о том, как эти свойства изменяются и обрабатываются.
> Тренды важнее абсолютных значений
Конечно. ООП упало до своей асимптоты, ФП доросло до своей асимптоты. Так и останутся. Тренды - это не обязательно линейные функции, иначе гипербола (убывающая экспонента, etc) пересекала бы асимптоту и устремлялась в бесконечность
Окей, но ведь в ФП тоже нет ничего, чего не было бы где-то ещё
Есть, способ изменения состояния. ООП - это расширение СП, и есть присваивание. В ФП же ты должен заново создавать объект с другим состоянием и передавать его в рекурсивную функцию.
Ничто не запретит мне даже в чистой Сишке возвращать новые данные, вместо мутации имеющихся. Сишка стала ФП?
так не работает, ребятки, все эти иммутабельности, композиции функция и т.д. прекрасно _могут_ быть использованы по надобности в 9 языках из 10.
> Сишка стала ФП?
Да, почему нет? То, что язык не приписывает себе какую-то парадигму, ещё не значит, что на нём невозможно так писать.
Чтобы программировать в стиле ФП на сишке придется придерживаться неких правил, за нарушение которых компилятор тебя даже не предупредит.
Отлично. В таком случае все эти ФП/ООП -- свойство конкретного проекта или даже модуля (ибо ничито не помешает мне вставить мутабельный под капотом модуль в иммутабельную обёртку).
А все эти срачи про языки идут лесом. Алсо, процедурная парадигма, как прямо индифферентная к мутабельности -- имеет ввиду и тех и других.
Это уже вопрос к уровню проверок компилятор/линтера. Хаскелл тебя тоже об unsafe под капотом не предупредит.
Да, всё так.
>Нет такого. Потому что остальные подходы - всего лишь подвид ООП.
Ну то есть твое определение не означает ничего. Хуевое определение, возникают сомнения в твоем интеллектуальном уровне, если ты таким пользуешься
ООП не подразумевает иерархию.
Любой язык - ООП. JS - ООП. C - ООП. Хаскелль - ООП. Ассемблер - ООП.
Ну вот видишь, почему не нужно слушать двачеэкспертов. Всегда удивляюсь, как тут люди красиво пиздят с умным видом, а потом просто на ровном месте обсираются. Как недавно например с O(2n).
Так вот как сделано присваивание в хаскеле. А сделано оно так: вместо
a = readFile(); print(a);
пишется что то типа (псевдокод):
main = bind(readfile, (a) => print(a))
bind это одна из операций определенных над монадой.
В итоге вся программа представляет собой выражение, которое возвращает монаду IO. Вот эта монада по сути и есть алгоритм. Хаскель знает как ее "запустить на вычисление", что он и делает, и тогда программа начинает выполняться.
Главный недостаток ООП заключается в следующем: процессы и данные существуют отдельно друг от друга (как в модели деятельности организации, так и в модели программной системы), причем проектирование ведется от процессов к данным. Таким образом, помимо функциональной декомпозиции, существует также структура данных, находящаяся на втором плане.
Немного не в тему, но все равно скажу. Это же заебись что статические методы принадлежат одному классу FileUtills. Все хранятся в одном месте, сразу понятно где искать, читаемость вызова таких функций достигает 9999999. ООП не ООП - какая разница, получилось очень удобно
А про Message Passing и динамизм забыл, хотя это и есть самое главное в ОП, а не классы с наследованием.
Про opaque types современные зумеры наверное и не слышали
Там это дрочат чтобы по максимуму в кэш попадать, data driven
Это чистая субъективщина, но мне кажется, что джава намного легче понимается чем шарпей. Хотя странно, первым языком у меня сам шарп
Ты перепутал, екс-парашу труднее перелопачивать.
Люблю я эту картину, когда собираются вместе ооп-сектанты и ооп-хейтеры и устраивают шизобатлы. А самое смешно, что никто даже не может дать точное определение ООП.
Потому и срутся, что у одного определение противоречит определению другого.
Ты просто дебил и не шаришь. У тебя наверное и имена классов заканчиваются на -er.
мимо егор.
Int Eger.
>Удобно хранить тип данных, вместо с методами работы с ним. Очень блядь удобно. Невыносимо удобно.
Для этого придумали модули и пакеты, в которых хранятся типы и функции с процедурами для работы с ними.
>Модульность есть и в си
В обычном си модульности нет
>Просто если ты не ощущаешь вокруг себя количественные явления, то это умственная отсталость.
У тебя точно умственная отсталость, если ты не различаешь свои субъективные ощущения и объективное существование.
>ооп - один из возможных подходов к композиции структур данных и алгоритмов, обрабатывающих эти данные
Недооценённый пост
>На С без всякого ООП целые операционные системы писали, представь себе. Вот только каким хуем это наделяет С всем тем, что есть у ООП и каким хуем оно отменяет те возможности, которые ООП предоставляет, одному тебе, долбоебу, известно.
Си -- это вообще недоязык высокого уровня, в нём нет ни модульности, ни массивов, это по большому счёту универсальный ассемблер.
Класека, функциональщики сами себе придумали трудность и героически ее преодолели.
> дай определение фрукту
> фрукт это желтое, зеленое, с жидосстью, банан, покупаемое
Удобнее писать через точку
system.getDisplay().getSize()
чем пробрасывать парашу через свободные функции. Ты там одних временных переменных заебешься делать. Будет как во всяких старых винапи
System sys
Display disp
GetCurrentSystem(&sys)
GetDisplay(sys, &disp, TRUE)
SizeClassXXL size
GetSize(disp, (DisplayDevice*)0, size)
Спасибо наелись
Ну да, ведь императивщикам чистота и контролируемые сайд-эффекты не нужны, они и без неё пишут безопасный и композабельный код. А нет, постойте, не пишут.
>Удобнее писать через точку
коза.ебись(онегин)
>system.getDisplay().getSize()
system
|> getDisplay()
|> getSize()
проблемс?
Вот только код в примерах идентичен (за исключением героического оборачивания в монаду)
Удивительное совпадение, да?
Монадическое IO в хаски нужно для отделения чистого кода от эффектов. Императивщики такого разделения не делают, им и так норм.
Erlang — самый ООП язык/рантайм эвер.
Smalltalk же.
Охохо, давайте положим код не в void main, а в main = do, ведь от этого он тут же станет правильнее и безопаснее (нет)
Если наш мир - симуляция, написан ли он в ООП парадигме?
Проведи эксперимент:
Найди объект.
Измени его свойство.
Если для этого не пришлось делать копию -- это не ФП.
Какие проблемы и задачи оно решает?
Почему пользоваться классами и объектами, а не допустим списками? Ведь суть одна и та же.
В ООП объект со своими параметрами.
В списке просто именованный список со своими членами.
Я нуб-студент