>>986149 (OP)
>говно говно говно
>Цифр, исследований, предметной полемики с оппонентами - нет как таковых.

>не приводит
>Цифр, исследований, предметной полемики с оппонентами - нет как таковых.
OK

>>986149 (OP)
Ну в ООП-религии есть правильные идеи. Правда, они — капитанство и вообще были придуманы до оопе

Лучший тред зк, бтв. Хоть повылезали из своих берлог и посрались как люди.

>>986164
>повылезали из своих берлог
Охуел что ли, нахуй иди.
голос из берлоги

>>986160
Смотри предыдущий тред.

>>986149 (OP)
>его выбирают те кто программистов нанимает - занавес
Бред сумасшедшего. Бизнесс никогда не спускается настолько глубоко под копот, чтобы еще принимать решения о том каким говном обмазываться - объектным процедурным или функциональным (бтв все три суть одно, но не об этом речь).

>>986149 (OP)
А нанимают теже программисты, которые доросли до архитекторов и менеджеров.

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

>>986218
>А нанимают теже программисты, которые доросли до архитекторов и менеджеров.

У меня для тебя плохие новости.
1. Погромисты не становятся менеджерами.
2. Погромисты не становятся архитекторами.
3. Первоначальным отсевом занимается отдел кадров HRочки няшечки стесняшечки(стервозные безмозглые бляди).
4. Тимлиды и прочие программисты, которые проводят технические собеседования, имеют ООП головного мозга и джаву мозжечка.
Круг ООП замкнулся.

Относительно того, каким должен быть идеальный язык, уже пара статей была написана, первая из них ещё в 2007 году:
http://www.croco.net/croco/papers/stolyarov_2007b.pdf
Если коротко, то в самом языке вообще не должно быть синтаксического сахара, должны быть средства для его создания в библиотеках; библиотеки как раз и должны быть его источником, а равно и источником большинства свойств, которые вы хотите видеть в языке. Сам язык должен быть ещё более низкоуровневым, чем чистый Си, и это должно быть его основное свойство, точнее, одно из двух основных; второе -- широкие возможности по введению новых абстракций. Из перечисленных вами ни один язык не может стать "донором", поскольку они все высокоуровневые.
http://www.stolyarov.info/guestbook

>>986256
Попался, шизик!
Не уйдешь!

>>986256
>Если коротко, то в самом языке вообще не должно быть синтаксического сахара, должны быть средства для его создания в библиотеках; библиотеки как раз и должны быть его источником, а равно и источником большинства свойств, которые вы хотите видеть в языке. Сам язык должен быть ещё более низкоуровневым, чем чистый Си, и это должно быть его основное свойство, точнее, одно из двух основных; второе -- широкие возможности по введению новых абстракций.
Такой язык есть.
LLVM IR называется.
Или ассемблер, как альтернатива.

>>986149 (OP)
Скажите же, что ООП в жаваскрипте нет. А то меня на собесе пытались заставить на нем КЛАСС написать.

>>986269
javascript class первая ссылка в гугле

>>986269
С тех пор как сракле пожрали ЖАББУ и йебеэм купили НОДЭДЖЭЭС теперь всё кобол-ориентированное цифровое гуано будет и в НОДЭДЖЭЭС.

Что тут у нас?? ООП - сложна?!

— Смотри, я… вот у нас здесь функций много… ой-ой… функций много, понимаешь? Смотри, функции, они тебе спать мешают. А я вот, давай вот я функции прямо в структуре объявлю, и они все в структуре будут, и мы их методами назовем, слышишь, членами назовем? И тебе тогда спать, ой, спать будет хорошо. Давай? Ну, куда им ещё, ихнее место-то тока здесь. А структуру - классом.
— Ты можешь просто помолчать, всё, пиздец?!
— А еще в классе два члена сделаем, конструктор и деструктор, и они сами собой эти члены дергаться будут. Вот так, дерг, дерг.
— Заебал, блядь!
— А еще у класса родитель может быть, а этот класс тогда дочка. И у дочки тогда все члены родителя будут, ну они же наследуются, ну. Понимаешь, братишка. У дочки члены родителя будут. И их тоже дергать можно будет.
— Ёб твою мать! Блядь! Иди отсюда на хуй, блядь!
— Но не все члены дергать можно будет, будут публичные члены, которые все могут дергать, вот ты мой публичный член, например, можешь подергать.
— Сука, блядь, пидорас, блядь!
— А другой член только родитель сможет дергать, и больше никто. А еще будут члены, которые только родитель и дочка дергать смогут. Братишка, братишка... Дочка у родителя член дергать сможет, понимаешь, братишка.
— Иди под струю, сука! Мойся!
— А еще можно будет класс-дружочек сделать. И тогда этот дружочек все членики у своего дружочка дергать сможет.
— А блядь на хуй! Ну, иди сюда сука, блядь! Дерьмо собачье, блядь! А блядь!
— А у дочки много родителей будет, и все членики родителей у дочки тогда будут. Их можно будет дергать и другим не мешать дергать, понимаешь?
— Мудак, блядь, ну ты мудак. Я тебя сейчас убью нахуй, а тебя, бля, сейчас убью, блядь!

>>986149 (OP)
Ебать вы только одуплились, читайте Вьетнам компьютерной науки
Мимо-структурно-процедурный-бог

>>986299
опиши еще геттеры и сеттеры, ведь просто открытые переменные не по шариату

>>986416
А потом после очередного релиза у крестопидоров начала течь память и вообще бизнес заебался, что фичи выкатываются хуй знает сколько и с помощью рыночка порешал крестопидоров.

>>986429
>инфернальной
лучше вагинальной. вагинальный ассемблер с клиторотипизацией.

>>986246
1. False, самые лучшие манагеры как раз бывшие программисты.
2. False, очевидную хуйню написал.
3. Разве это проблема? Их же обаять как нехуй делать я не альфач

>>986283
>полноценные классы в жс
Слово class еще не значит, что это полноценный класс в понимании джависта или шарписта. Под капотом те же прототипы.

>>986443
Типа не похуй и типа жанрам думают про оптимизацию и прочие приблуды.

>>986429
Ты джаву изобрел.

>>986468
Слишком высокоуровневая. LLVM вот подходит.

>Таким образом, с помощью LLVM можно создать и статический компилятор, такой как GCC, и среду наподобие 'Java или .NET, и интерпретатор языка программирования в стиле Perl или Lua. И первое, и второе, и третье уже существует на практике.

>На основе LLVM создан компилятор для языков C/C++, Fortran, Objective-C, Ada, D. Компания Apple использует LLVM для компиляции кода шейдеров OpenGL во время выполнения программ (Apple также использует LLVM в качестве основы компилятора для нового языка программирования CLang). LLVM может применяться для выполнения или «докомпиляции» байт-кода Java и CIL (.NET). Но он пригодится не только тем, кто пишет собственный компилятор. LLVM применяют в приложениях, которым требуется встроенный язык программирования, причем скорость выполнения встроенной программы имеет значение.

>>987069
>2. Баттхёрт от ООП испытывают в основном следующие группы граждан:
1. Все.

Даже преподы ООП в вузах.

Помню свою курсовую по ООП.
Игра "жизнь", тема была.

Это ебанный стыд, когда все эти "сущности" в классы определяешь.
Но самое чудесное, это, РЕКУРСИВНЫЕ ЗАВИСИМОСТИ.
От которых препод бугуртил не меньше меня.

>>987137
>преподы
Петухов забыли спросить.


>РЕКУРСИВНЫЕ ЗАВИСИМОСТИ
>я даун, но виноват ЯП

>>987069
>3. При умелом использовании (то есть с учётом всех основных подводных камней) ООП является довольно эффективной техникой структурирования кода.

При умелом использовании, от ООП ничего не остается.
Другими словами, правильное использование ООП - это неиспользование ООП.

Отправитель - сообщение - получатель, это конечно здорово. И хотя вроде как ООП это и есть, на практике, нет, не это.

Поэтому, пусть будет SMR подход SenderMessageReciever. Будет в тыщу раз больше смысла.

И при этом, никаких специальных структур данных.
Сендре и рецивер - функции. Сообщение - обычная переменная\структура.


Ну или если уже ООП, то БЕЗ наследования, вапще.
Только интерфейсы. Сами интерфейсы то-же без наследования(ну нахрен).
Соответственно никаких протектед овверайдед и прочей ереси.

И пожалуй, никаких статических полей конструкторов и ничего статического. Никаких этих прокси фактори.

>>987142
>Петухов забыли спросить.
Ого, круто ты.
Ты еще в школе учишься, или уже на 1вом курсе?
Как оно, у питухов троечку выпрашивать?


>я даун
Я вижу.

>виноват ЯП
Речь идет о ООП. Ты тред попутал.
К рекурсивным зависимостям привело использование ООП парадигмы.

>>987144
>Как оно, у питухов троечку выпрашивать?
Тебе виднее.


>К рекурсивным зависимостям привело использование ООП парадигмы.
Рекурсию придумали программисты. Это сильно.

>>987148
>Тебе виднее.
Тебя отчислили?

>>987149
>Тебя отчислили?
Я хуй знает.

>>987143
>Сами интерфейсы то-же без наследования(ну нахрен).
Как раз в наследовании интерфейсов, т.е. поведения, нет ничего плохого, это совершенно безопасно.

>>987160
>Как раз в наследовании интерфейсов, т.е. поведения, нет ничего плохого, это совершенно безопасно.
Классы наследуют интерфейсы.
Интерфейсы не наследуют интерфейсы.

Наследование интерфейсов интерфейсами бессмысленно чисто архитектурно.
Это плохой дизайн.

>>986149 (OP)
Ишшо адин неасилятор элиминтарнава ооп высрал еще адин пост боли ббггее. Я паржу, атвечу сагай в тваю прыщавую попку и закурю ббггее. Шалом ебанаты ббгг.

>>987069

> Rust как довольно сбалансированный сплав ООП и ФП.

Расскажи, какими уникальными свойствами обладает раст и что делает его сбалансированным.

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

>>987235
Объясните, кто-нибудь, какое отношение 'замыкания' имеют к ФП. Какой смысл 'замыкания' могут иметь в ФП?

>>987237
Ну, наверное, потому что closures подразумевают в язке наличие HOF.

>>987273
В огороде - бузина; в Киеве - дядька
Повторю вопрос: "Какой смысл 'замыкания' имеют в ФП?"
>closures подразумевают в язке наличие HOF
Разве?

>>987296

Смысл, в уменьшении DRY, например.

>>987328
Что-то я понимаю вас всё меньше и меньше.

>>987296
>Разве?
Ну да, по определению.

>В огороде - бузина; в Киеве - дядька
Ты странный. Сам пишеш
> какое отношение 'замыкания' имеют к ФП
Тебе блять оговорят какое, чё припераешься?

>>987354
>говорят

fix

>>987330

В контектсе сравнения ФП и ООП под замыканиями подразумеваются - Higher-order functions.

Это не одно и тоже; под капотом много различий, да даже в рамках одного ООП языка замыкания ведут себя по-разному (ex, proc vs lambda), тем не менее что то, гавно (hof), возвращает (/или передает через аргументы) функцию, что это (замыкание) - анонимный метод.

Какой cмысл в том, что ты можешь использовать один метод, или функцию несколько раз? Самый общий ответ - повышение реюзабельности кода. За другими кейсами предлагаю пройти на википедию.

>>987069
>Rust
>ООП
Лол.

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

>>986269
Ты вобщем-то в любом ООП-подобном языке можешь сделать класс не используя ключевое слово class. Классическое упражнение для студентов приходящих на практику.

>>987137
>Даже преподы ООП в вузах.
Ебать мой хуй, такая хуйня и правда есть? Сколько в зачетке по ООП стоит?

>РЕКУРСИВНЫЕ ЗАВИСИМОСТИ.
Это шож у тебя за язык с РЕКУРСИВНЫМИ типами?

>>987442
>Ебать мой хуй, такая хуйня и правда есть?
У нас было на 3 курсе. Причём нельзя было просто решить задачу, нужно было сделать в концептуальном ОО-стиле, иначе не принимали лабы.

>>987442
>РЕКУРСИВНЫЕ ЗАВИСИМОСТИ.
Похоже этот кретин - >>987449 - имеет в виду упоминание в класс1 класса2, а в класс2 - класса1 соответственно.
Но такое умеет разруливать любой компилятор - если это, конечно, не пасцаль/говнодельфи.
То есть кретины-преподы обучают дебилов-студентов на говнодельфи.
Жизнь справедлива.

>>987454
>Похоже этот кретин
Лол, я просто мимо шёл, хули доебался?

>>987456
>нужно было сделать в концептуальном ОО-стиле, иначе не принимали лабы.
>я просто мимо шёл
Не оправдывайся, просто ты дегенерат и терпила.
Так-то.

>>987449
Не, я понимаю что в преподавание у нас идет биомусор по остаточному принципу, который даже на джуна в пхп-галеру не возьмут, но все же: в чем блять может быть суть предмета ООП? Семестр-год-два года разбирали набор из пяти постулатов?

>>987462
Ты тоже какой-то тупой.
Суть в том что нужно начитать положенные часы и отработать, хаха, "зарплату" преподавателя.
На этом все.
Добро пожаловать в Россию.

>>987466
Ты то я смотрю умный. Преподаватель может чем угодно отчитать эти часы, но в чем состав предмета ООП?

>>987466
Уточняю:

к >>987468

Если я правильно понял пациента, то у него был предмет на котором они исключительно обмазывались мифическим ООП. Ну то есть самостоятельная дисциплина.

>>987468
>Преподаватель может чем угодно отчитать эти часы
Не чем угодно, есть учебный план десятилетней давности которые нахуй никому не надо менять ибо всем похуй.
>в чем состав предмета ООП?
>Семестр-год-два года разбирали набор из пяти постулатов?
Ты уже сам ответил, дурачок.

>>987471
>уже ответил
Я хочу подробностей.

>>987473
Да ты же потралить сюда пришел, какие тебе подробности?

>>987478
Меня уже потралили наличием предмета "ООП" в школе, теперь ваша очередь быть потраленными и выдавать годноту в виде охуительных историй.

>>987482
>выдавать годноту в виде охуительных историй.
А ты мне что?

>>987482
Ты не учился же в шараге на примате, хули тебе пояснять? Там везде ООП проходят. И анон который заикнулся об этом уже пояснил тебе. Просто ты макака которая только кривляться умеет.

>>987502
Благодарю, пригорел.

>>987442
>Ебать мой хуй, такая хуйня и правда есть? Сколько в зачетке по ООП стоит?
110/100

>Это шож у тебя за язык
Были кресты от борланда.
Потом заменили на сисярп.

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

>в чем блять может быть суть предмета ООП?
У нас фактически изучаем языкнейм.

>Семестр-год-два года разбирали набор из пяти постулатов?
Можно и докторскую написать, разбирая набор из 5ти постулатов.

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

>>987517
Сегодня борщец со сметаной или вариант эконом?

>>987517
>Можно и докторскую написать, разбирая набор из 5ти постулатов.
С точки зрения безмозглой пидорашки с каргокультом - несомненно.
>Да, дебилы преподы
Так и есть, и в этом нет ничего смешного.

>>987520
Лол, ясно все с тобой.

>>987517
>Ты хотя-бы вуз закончи, прежде чем подобную грязь выпукивать.
Высококлассные специалисты, способные из биомусора сделать приемлемых для рынка программистов, работающие по ставке ниже в 10-20 раз ниже рыночной. Да, правдоподобно, очень, осталось закурить и пропеть интернационал.

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

Да, так вот, дай-ка я тебя немного в фекалии помокаю.

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

Нейронные сети преподавал профессор с мировым именем, например. У которого кстати совсем немаленький оклад.

Дискретную математику один из ее основателей в СССР, ныне покойный.

Экономику женщина - известный в городе специалист.

>>987522
>эта БОЛЬ неосилятора ООП
А ведь ООП придумали чтобы утилизировать вкатывающуюся массу индусов и прочих интеллектуальных большинство.
Но для русских и это оказалось слишком сложно, лол.

>>987527
>преподавал реальный владелец реальной ойти компании.
Феерический пиздеж, дальше читать нет никакого смысла.

>>987526
> работающие по ставке ниже в 10-20 раз ниже рыночной.
Ебать знаток. Вот отучился бы ты хоть в каком-то крупном областном вузике - хоть бы знал что около половины таких преподов как раз занимается не только преподованием за копейки, а еще и работает в разных конторах и стартапах, кучу всяких спецов из всяких хуяндексов приглашают читать лекции. И прикинь бывает не только макакинг на галерах, а еще и академическая наука, информатика там всякая которую тоже надо двигать.

>>987533
>Россия
>академическая наука
Шутку понял.
Смешно.
Очень смешно.

>>987527
>Веб сервисы у меня, преподавал реальный владелец реальной ойти компании.
Обезумевший погонщик обезумел в край. Сколько человек вообще живет в твоей мухосрани?

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

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

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

>>987543
Ну вот прикинь, не для всех программирование это чисто способ заработка на смузи. Есть еще и такие, кто старается науку двигать. Правда не совсем понятно что их в этой стране держит, но такое есть.

>>987546
>не все еще умерло.
В процессе, ага.
Гниет и воняет вовсю.
Нахуй иди со своим говном, русский.

>>987526
>Высококлассные специалисты, способные из биомусора сделать приемлемых для рынка программистов, работающие по ставке ниже в 10-20 раз ниже рыночной. Да, правдоподобно, очень, осталось закурить и пропеть интернационал.

1. Каждый дрочит на что хочет.
Но да, талантливая молодежь в вузах редко задерживается.
Вот знакомая преподша ушла в R&D самсунга.
Тем не менее, пока ты получаешь степень, нужно преподавать.

2. Я тебе открою тайну, мамин борщехлеб, программирование - низкоквалифицированный тяжёлый труд. С бесконечным ctrl+C ctrl+V.
Не говоря уже про чудные реалии офисов и "корпоративной культуры".

Из гуманистических соображений, можно работать преподавателем. Почему-бы и нет? Не все же мамины нищеброды))))
Когда хочется кушать, конечно, уже другой разговор.

>>987540
>Сколько человек вообще живет в твоей мухосрани?
2млн.
Но моя мухосрань оче академический городок. Вузов на квадрантный метр площади больше чем туалетов.

>>987556
>Из гуманистических соображений
Таких дебилов все меньше, к счастью.
Жизнь научила и рыночек порешал.

>>987557
Нахуй съеби, котосибирское быдло.

>>987560
Мимо.

>>987564
>2млн.
>оче академический городок.
>не котосибирск
Кому ты пиздишь, дебил.

>>987565
>ебля!
>ЁБЛЯ!
Оно еще и девственник, хаха.

>>987566
>дебил
Приятно познакомится.

>>987567
Затралел вапще красава.

>>987568
>нет ты сам дурак
Ясно.

>>987574
Тебе ненужно кстати уроки делать?
Там вроде как близок конец года, всякие финальные контрольные нужно писать.

>>987579
>ненужно
>всякие финальные контрольные нужно писать.
Так пиши, разрешаю.

>>987556
Помню, когда коллега уволился (на тот момент мы работали во freescale), а он был (наверно и есть) крайне патриотических убеждений и пошел работать на военных. Собирали тогда по всей стране людей на приемлемом уровне людей знающих HDL-и и общий кодинг одновременно дабы делать <%информация засекречена%>

Так вот собрали их по первой в МФТИ, выдали все необходимое покупное-контрабандное и назначили цели и задачи, классическое хорошее R&D.

И тут откуда не возьмись прибегает жирнющая бабень, то ли проректор по науке то ли его (ее) зам. И значит - пиздуйте студентов учить! Ишь! Сели, наукой понимаешь занимаются! У нас вон Илларион Валентиныч с 65 года наукой занимается и ничего! Не выебывается, преподает! Вот ваш учебный план, завтра встретить студентов (а дело в начале сентября) - и вперед и с песней!

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

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

>>987554
Тебя это удивит, но говновузики это единственный на данный момент способ рекрутинга для всяких хуяндексов и банковских сервисов. Данную нишу специалистами уровня "Вычи Java за 30 дней" просто не заполнить.

>>987584
>для всяких хуяндексов
Состояние агонии.
>и банковских сервисов
Пока еще дергается, но комплюкторщиков справедливо держит за гной и говно.

>>987582
>пиздуйте студентов учить! Ишь! Сели, наукой понимаешь занимаются! У нас вон Илларион Валентиныч с 65 года наукой занимается и ничего! Не выебывается, преподает! Вот ваш учебный план, завтра встретить студентов (а дело в начале сентября) - и вперед и с песней!
Все правильно сказала, надо было еще ссаной шваброй вас разогнать по загривкам, чтобы дохуя о себе не думали.

>>987593
Илларион Валентиныч, залогиньтесь.

>>987603
Щенок! Наглец! Постыдился бы в такой день!

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

>И тут откуда не возьмись прибегает жирнющая бабень, то ли проректор по науке то ли его (ее) зам. И значит - пиздуйте студентов учить! Ишь! Сели, наукой понимаешь занимаются!
Это ткнз карьерист. Вузики, внезапно, полны ими. Страшное зло.

>>987636
Не понимаю тебя.
А в шарпе классы не наследуют интерфейсы?
О чем ты вообще.

>ВРЁТИ
О чем ты вообще.

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

>Описать их поведение в виде дерева — самый что ни на есть обыкновенный (а не «плохой») дизайн
WTF?
Если уже на то пошло, "значок" интерфейс, а "значок мои документы" конкретная реализация в классе.
Но какое нахуй дерево?

>>987640
>Если уже на то пошло, "значок" интерфейс, а "значок мои документы" конкретная реализация в классе.
>
Т.е. у тебя можно вызывать Dispose у папки с почтой и Execute у корзины?

>>986149 (OP)
>4.jpg
Забавная картинка, прямо таки мир глазами функциональщика: смешаны конкретные сущности и абстрактные понятия, захуячены в кольцо вокруг того, что на самом деле их в себя включает. Но зато все симметрично и красиво расставлено.

>>986256
>идеальный язык
Нинужен. Небогоугодные жабоиндусы сейчас разрабатывают нанотехнологию конпелятора конпеляторов под любую грамматику. Про эффективность скомпилированого кода на произвольном языке говорят, что будет нативная. Кросязыковое взаимодействие тоже вроде как звезут.

Уже вроде есть референс генерейт-кмпиляторы грамматики пистона, паскаля, си и жабаскрипта и хз какие еще.

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

>>987652
>Нет, в жаббашарпах ключевое слово «implements» означает «класс ведёт себя в соответствии с интерфейсом».
1. В шарпе нет такого ключевого слова. Там двоеточие.
2. Ты зойчем к терминологии придерешься? Какая разница, наследует или реализует, как ты необзови козу козой она и останется.

>Я хочу, чтобы ещё и коробка с электронной почтой вела себя как значок и контейнер с чем-то
У тебя есть интерфейс значок.
Есть интерфейс контейнер.
Коробка наследует(имплементирует) значок и контейнер.
Все, никакого дерева.

Ты же какую-то ересть тут сочиняешь.
Иерархия интерфейсов такой же бред как и иерархия классов.

Ненужно через ООП пытаться описывать реальный мир. Нужно создавать адекватные программные сущности.

>>987651
>Т.е. у тебя можно вызывать Dispose у папки с почтой и Execute у корзины?
Они отличаются иконкой, и исполняемой при двойном клике командой.
Наркоман.

>>987748
Т.е. и контекстных меню у тебя нет и функционал ограничен двумя кликами.

>>987699
>говорят, что будет нативная
Я в астрологическом календаре прочитал, что нынче луга в шизике, на полтора месяца.

>>987749
И контекстным меню.
Тебе лишь бы приебаться?

>>987757
Ну этот приеб и составляет разницу между реальностью где интерфейсы имеют наследование и твоим условным примером бесполезной системы без функционала.

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

>>987745
>Какая разница, наследует или реализует, как ты необзови козу козой она и останется.
Из-за множественного наследования. Класс может имплементировать сколько угодно интерфейсов, но множественное наследование приводит вот к чему: в родительских классах могут совпадать названия методов, и какой из них передать наследнику, непонятно.

А теперь разберём по словам всё тобою написанное!

>Коробка наследует значок и контейнер.
Это множественное наследование, уже давно вместо него дженерики.

>Коробка имплементирует значок и контейнер
Это всегда пожалуйста.

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

>>987773
>Из-за множественного наследования. Класс может имплементировать сколько угодно интерфейсов, но множественное наследование приводит вот к чему: в родительских классах могут совпадать названия методов
Множественное.
Наследование.
Интерфейсов.

Ты понимаешь, разницу, между наследование классов, и наследованием интерфейсов?
И
Н
Т
Е
Р
Ф
Е
Й
С
Ы

Нет, этот шизик слишком силен.
Ну его нахуй.

>>987766
Эх, хотел бы я быть тобой. С годами приходится видеть самое разное дерьмо на эту тему, вот, одно из самых безобидных (правда малясь ебанутое, иерархия вывернута в фабрики):

https://docs.oracle.com/javase/7/docs/api/javax/swing/plaf/metal/MetalIconFactory.PaletteCloseIcon.html

А что в продуктах Addobe творится лучше и не знать. Так что пример как раз таки более чем жизненный.

>>987781

Пацаны, ловите джявиста!!!

>>987782
Если бы. Часто приходится писать под тот же Addobe на Си с классами (не C++, именно Си с классами, это там где "наследование" через вложенные структуры и оффсеты до полей, да). И это вполне себе OOP-way, как выражаются авторы. И не поспоришь: все основные постулаты учтены.

>>987780
Так... с самого начала.
1) Наследование реализации (классов), грабли: хрупкий базовый класс.
2) Наследование поведения (интерфейсов), грабли: нет их, но некоторым пнмйш не нравятся описания в виде пнмйш дерева.
3) Множественное наследование реализации (классов), сразу грабли: совпадение имён методов и их параметров.
4) Имплементирование классом нескольких интерфейсов, грабли: нет их, макаки идут пнмйш по граблям — а граблей пнмйш не оказывается на месте.

>>987787
И вот ещё чтоб не забыть:
5) Абстрактные классы: кое-кто упёрся и не захотел делать интерфейсы в своём C++.
6) Дженерики <Здесь, Всё, Что, Угодно> ну типа композиция.
7) RAII, DI: передаём объект в конструктор другого объекта, пока дженерики в Жаббу ещё не завезли.
8) Будет вам и 8 и 9 и так пока крышу не сорвёт вместе с головой.

>>987787
Чем
Наследование классом интерфейса,
отличается от
имплементации классом интерфейса?

>>987790
Очевидно тем что абстрактный класс не обязан этот интерфейс имплементировать.

>>987790
>Наследование классом интерфейса
Есть только в языках, где авторы не хотели делать (или не сделали) интерфейсов, то есть в C++ и Delphi.
Не отличается от
>имплементации классом интерфейса
Ничем.

>>987787
>3) сразу грабли: совпадение имён методов и их параметров
Это грабли только если нет дефолтного механизма разрешения конфликтов. В скале, например, он есть, и проблем как в С++ с множественным наследованием нет.
>4) Имплементирование классом нескольких интерфейсов, грабли: нет
За исключением того, что использовать ранее определенную реализацию можно только через композицию, то есть вручную прокидывать методы и строить заглушки.

>>987795
>наследование = имплементация
>язык
>Delphi
-> /b/

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

И раз мы решили, что интерфейсы не должны наследовать другие интерфейсы, то и абстрактные классы не должны наследовать интерфейсы.

Предлагаю абстрактные классы запретить, как ересь.
Проблемы нет, наследование и имплантация теперь одно и то-же.

>>987800
Иди проспись, походу сессия тебя добила.

>>987796
>Это грабли только если нет дефолтного механизма разрешения конфликтов. В скале, например, он есть, и проблем как в С++ с множественным наследованием нет.

Создавать конфликты чтобы потом их автоматически разрешать?
Ох уж этот чудный джава мир.

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

>>987801
Научись читать посты, на которые ты отвечаешь.

>>987803
>Создавать конфликты чтобы потом их автоматически разрешать?
Так неймспейсы работают в любом языке, например.

>>987808
О! Улиточка!
Охуенно же.
У меня брат ожил.

>>987808
Да, а по делу то можешь то что-то сказать.
Что не устраивает то?

>>987438
в пхп это сделать нельзя, например

>>987839
Полностью абстрактный класс не есть интерфейс.
Это разные инструменты служащие разным целям.
http://stackoverflow.com/questions/1913098/what-is-the-difference-between-an-interface-and-abstract-class

Более того структура вызова для них отличается во многих языках, если абстрактный класс использует single/multi-dispatch для выбора вызываемой функции (в зависимости от того, что это за язык), то интерфейс как правило (в языках поддерживающих интерфейсы) применяет явную спецификацию вызова. И это оправдано с точки зрения архитектуры: абстрактный класс подразумевает (fragile/не-fragile - не важно) базовую имплементацию, а интерфейс - это контракт.

Например:

interface IEnglishDimensions
{
float Length();
float Width();
}
// Declare the metric units interface:
interface IMetricDimensions
{
float Length();
float Width();
}
// Declare the "Box" class that implements the two interfaces:
// IEnglishDimensions and IMetricDimensions:
class Box : IEnglishDimensions, IMetricDimensions
{
// Explicitly implement the members of IEnglishDimensions:
float IEnglishDimensions.Length()
{
}
float IEnglishDimensions.Width()
{
}
// Explicitly implement the members of IMetricDimensions:
float IMetricDimensions.Length()
{
}
float IMetricDimensions.Width()
{
}
}

https://msdn.microsoft.com/en-us/library/aa288461(v=vs.71).aspx

Но, собственно меня позабавило не это, а то что ты сначала приравнял интерфейсы и абстрактные классы, а затем их запретил (неявно при этом запретив и интерфейсы).

test

>>987854
Ты говоришь походу слишком специфично относительно какой-то конкретной реализации.
А ну, как выглядят интерфейсы в С++?

>Но, собственно меня позабавило не это, а то что ты сначала приравнял интерфейсы и абстрактные классы, а затем их запретил
Мда, очень забавно.
>(неявно при этом запретив и интерфейсы).
Нет, неявно я ничего такого не делал.
У тебя проблемы с логикой, серьезные, сириусли. Ты додумываешь 90% содержания написанного.

Все просто и логично.
Раз полностью абстрактный класс и интерфейс дублирующие конструкции, то один явно лишний.

Да, они не совсем одно и то-же, давай разберем ассемблерный код еще по байтам.
Комон.

Я тебе по нескольку раз одно и то-же повторяю, а ты как будто не видишь буков вообще, что-то свое себе фантазируешь.

Речь идет о концепциях, абстракциях. Фирштейн?

>>987871
>А ну, как выглядят интерфейсы в С++?
Никак, их там нет.

>Нет, неявно я ничего такого не делал.
A = B, delete B, use A
Ну да, проблемы с логикой определенно. Ну или с русским языком.

>Все просто и логично.
>Раз полностью абстрактный класс и интерфейс >дублирующие конструкции, то один явно >
>лишний.
>дублирующие конструкции
Это потому что ты так решил?

>>987880
Да.

>>987880
>A = B, delete B, use A
>Ну да, проблемы с логикой определенно. Ну или с русским языком.
Так что не так с логикой, поясни?

У тебя две одинаковых машины, продай одну, второй пользуйся.
У тебя две квартиры, сдавай одну, другой пользуйся.
У тебя два указателя на одну область память, забудь один, другим пользуйся.
У тебя два указателя, освободи память, oh shi!, да ты мыслишь диспозалами.

>>987899
С тобой правда что-то не в порядке.

25 долларов в кармане А, равно 25 долларов в кармане Б?

Если я выну из кармана А 25 долларов, 25 долларов в кармане Б пропадут?

Равенство не означает зависимость.

У тебя правда правда справки нет?

>>987899
>я сдаюсь нахуй
Не сдавайся этому продавцу тортов , борись, я верю в тебя!
мимо угорающий

>>987905
Это не равенство, это присваивание. Какую богословскую семенарию заканчивали?

>>987905
>справки
Кто о чем, а тортик - о наболевшем :3

>>987907
Кулинарный техникум, очевидно же :3

Если 25 долларов - объект, то он пропадет из обоих карманов!!!
А если 25 - примитив - то только из одного.

А все почему? ПРАВИЛЬНО - МАГИЯ.

>>987910
>ПРАВИЛЬНО - МАГИЯ.
И кулинария :3

>>987913
>эти боевые картиночки
Ну что же ты, кулинар :3

>>987912

ПОШЛИ ПОЖАРИМ ТВОЮ КАРТОШЕЧКУ.

>>987910
Был у матери сын и звали его Сычинушка. Написала она у сычинушки на лбу Хуй и стало у нее два сына. И оба долбоебы.

>>987910
>Если 25 долларов - объект, то он пропадет из обоих карманов!!!
А если это два объекта, да с переопределенным = и "==" ?

>>987916
>ПОШЛИ
Никуда ходить не надо, здесь гори.

>>987918

А В МОЕМ ЯЗЫКЕ НЕЛЬЗЯ ПЕРЕОПРЕДЕЛЯТЬ ОПЕРАЦИЮ #==, А #= КОПИРУЕТ УКАЗАТЕЛЬ НА ОБЪЕКТ. СОСИ СОСИСКУ

>>987918
>да с переопределенным
Загон плюсобыдла тут >>979476 (OP)

>>987926
>WTF
Просто наслаждайся цирковым представлением.
мимо любитель тортолюбов

>>987926
По теме еще в том треде все обсудили, теперь это филиал /b.

ПОЖАРИЛ ВОТ ЭТУ >>987919 КАРТОШЕЧКУ. ИДУ СПАТЬ. НО СНАЧАЛА СИЛЬНОЕ ЗАЯВЛЕНИЕ

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

НО ПРОВЕРЯТЬ ЕГО Я КОНЕЧНО ЖЕ НЕ БУДУ .

>>986149 (OP)
индусы привнесли в Микрософт такую замечательную вещь как кастовая система

помните, что Наделла ответил на вопрос "почему женщинам, выполняющим ту же работу так же, MS платит меньше?". он сказал, что главное - не то, как ты работаешь, а твоя карма.

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

индусы до сих пор живут в кастовом обществе, касты не смешиваются между собой и более высшие касты имеют почти белую кожу, а низшие почти черную, как у африканцев. какого цвета Наделла?

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

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

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

звучит дико? зато правда

(c) __kot2

>>986149 (OP)
ООП - это макропаттерн. Он эффективен в тех случаях, в которых есть разрозненные сущности, и вычислительные задачи можно интуитивно разделить между этими сущностями без пересечений.

Большинство задач таковы.

>>988232
>ООП - это макаронаттерн.
Согласен.

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

Большинство задач таковы.

>>988255
Ты хочешь поразить меня тем, что объекты - это модули?

>>988291
Только более удобные в использовании, т.к. в объекте удобней хранить состояние, нежели в переменных или замыканиях. Ну и плюс интерфейсы, инкапсуляция, наследование. Вскукареки про "можно и без ООП" идут нахуй, т.к. с ООП это удобней, ваши проблемы что не осилили.

>>988365
Плюс к тому:
- модуль может быть только один, а обхектов - сколько угодно
- либо следить за разделением вычислений с помощью объектов удобнее, либо я что-то не знаю о процедурщине, которая даёт такой же декларативный контроль

Но ты мне всю малину испортил, надо сначала заманить поциента, а потом уже обработать по-полной.

>>988402
МАМ МАМ! СМОТРИ! Я ТРАЛЛЮ ДВАЧ!

>>988421
Молодец, а теперь чистить зубы и спать.

>>988426
Нихочу. А вдруг кто-то клюнет! Надо заманить, и выжидать.

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

>>988255
>можно интуитивно разделить между этими сущностями
Ну да, ведь у программиста, дар предвидения как у бабы Ванги, а заказчик никогда не требует вот тут вот подмандить поперек ТЗ.

>>988365
Маня, ещё раз ООП - это первоклассные объекты. Это необходимое и достаточное определение. Остальное - это хуйня от тех или других видов сектантов.

>>988443
>ООП - это модули как первоклассные объекты.

Маня, ещё раз, ООП - это объектно-ориентированное программирование. Это необходимое и достаточное определение. Остальное - это хуйня от тех или других видов сектантов.

>>988471
>ООП - это ООП
Блестящее выступление. А теперь - обратно под шконарь.

>>988476

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

>>988471
Ага, и отличается ООП от всего остального тем, что оно объектно ориентированно.

>>988481

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

>>988484

Эй слыш, Отвечай, >>987235 на мой ответ!1!!1!1!

>>988484
>Маловато информации для восстановления событий.
Все так и задумывалось.
Да и не помню я подробностей, это в 2008 было.

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

>что первая итерация ООА, в которой мы берем в качестве абстракций объекты из ололо-реального мира, чаще всего не является последней
В последствии она обрастает макаронами туго запутывающимся в узел.

Если первоначальный дизайн плохой, ничего уже не поможет.


>Скорее всего он просто был некомпетентен в преподаваемом предмете. Такое в российских вузах сплошь и рядом. А может, ты его просто заебал своей тупостью и принял это за бугурт по ООП.
Ты наверное представляешь препода который так с огнем из попки - ФУУУУУ КЛЯТЫЙ ОООП БЛЯ НЕНАВИЖУ СУКА(разбивает комптуер).

А в реальности, было что-то вроде: "не нужно насильно пытаться натянуть ООП на задачу, которая вполне элегантно решается парой циклов".

>>988488
>Rust
Я так и не понял, там корутины есть, хоть в виде библиотеки, или нет.

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

И, маленький шаг немножко приближающий код - это хорошо конечно.
Но когда между исходной точкой, и нормальным дизайном лежит бесконечность, бессмысленный.

Ты можешь только уменьшить боль, теми или иными приемами.

>>988488

> … Машка готовит охуенные борщи…

> … Борщи с майонезом? …

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

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

>>988526
>Здесь ошибка. Очень часто молодые-шутливые погромисты
Слишком глубоко копаешь.

>>988526
>Без совершения вот этих маленьких шажков не будет достаточной для редизайна ясности, кроме того, без полученного в результате вымучивания этих шажков опыта
Двачую мудреца.
Есть некотрая тенденция бросать проекты и начинать их заново, когда в коде случается архитектурно-костыльный пиздец.
Это не правильно, т.к. не дает никакого реального опыта разруливания сложного кода. Этот опыт очень ценен на больших проектах, так как нельзя просто взять и переписать большой и сложный проект с нуля, а значит тренероватьна в поедании кактуса плохого кода нужно на маленьких проектах и не впадая в истерику ГОСПОДЬ ЖГИ.

>>988435
>Схуяли? Модуль всегда доступен по имени, в любой точке программы.
А оно так прямо надо?

>>988920
Конечно же нет, ведь можно в уютненькой иксемелечке напрограммировать IoCи и всё что нужно будет доступно там где нужно. Такое вот бегство ООП в ООП-мирке.

>>986234
>чтобы было дешево, быстро и поддерживалось десятилетиями
Следовательно ООП - это идеально
/thread

>>988435
>Схуяли? Модуль всегда доступен по имени, в любой точке программы.

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

>>988934
Хмлы с иокамми, это сорт оф конфиг. Бегут не от ооп , а от перекомпиляции проекта.

>>989015
Хуиг. Смысл ООП в построении систем из объектов. Индусня вместо того, чтобы инжектить всё средствами своего ОО-язычка опускается до программирования на иксемеле.

>>988989
Разруливается обычными областями видимости.

>>989045
> Разруливается обычными областями видимости.

На пятом уровне вложенности это 8 лишних строк кода на файл, и + 4 уровня табуляции. У меня классы и то меньше, кек (это сарказм)

ну я понимаю пригораниа джава макакменя,там только ООП и фабрика не синглтоне,но всяким питонам и прочей мульипарадигме то хули не нравится?

>>989645
Не осилили.

>>989706
не осилили "что"? Там же все элементарно. Вообще, ни разу не видел нормального яп с мощным ооп , как в java/ruby/c#но в шарпе я не шарю и одновременно полным по функциональной парадигме. Везде либо все уровня хачкеля или лиспа,либо кастрированный функциональный яп,как в петухоне и жабе 8+

>>989777
В шарпе ООП обрезан по самые яйца.

>яп с мощным ооп
С++

>>989777
>ни разу не видел нормального яп с мощным ооп и одновременно полным по функциональной парадигме

посмотри Scala

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

>>989792
>Ну не траль, плес.
В С++ самая полная реализация ООП из всех что я видел.
Если знаешь более полную, молви.

>>989787
>я не кодил на крестах,слышал,что там вроде наоборот,все очень криво.
Не криво точно.

>>986256
>должны быть средства для его создания в библиотеках; библиотеки как раз и должны быть его источником
Ну охуеть теперь, после такого количество этих самых библиотек будет в 9000к раз больше количества соврменных языков и фреймворков т.к. каждый пограмист сочтет своим долгом захуячить что-то свое.

>>989905
Ну не, гоферы - как раз те кто убежал от C++-like ООП, кому интерфейсы милее классов с их наследованием. Как бы я ни относился к го, но то что там нету наследования по-моему совершенно правильно.

>>989777
Освоить два десятка правил - элементарно. Научиться думать - нихуя не элементарно. Было бы ФП мейнстримом - они бы и его "хейтили".

>>989948
Если положить ленивость на сообщения то получатся методы классов. Круг замкнулся.

>>990197
Что-то вспомнилась классификация программистов то-ли из журнала "наука и жизнь", то-ли "химия и жизнь", советского само собой.
Запахло сразу застоявшимся министерским воздухом.

Это тут записывают в коспомолитов, свободных от парадигм?

А эвенты с танцеванием хороводов со вчерашними ООПистами, Функциональщиками и даже Процедурщиками проводятся?

>>990229
Да, раздевайся.

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

Психология опытного разработчика устроена иначе. После нескольких лет работы он знает свой инструмент от и до,
не находит в нём ничего нового, и все свои задачи он знает от и до. Причем задачи для него становятся похожими друг на друга как две капли воды,
ведь процесс познания заключается в изучении множества частных случаев с последующим абстрагированием и выведением общих закономерностей.
В конце концов какая разница, нужно ли мне зипануть два списка, собрать результаты работы двух парсеров или посчитать сумму двух сигналов:
для опытного разработчика всё это - map apply на аппликативных функторах.

Вот тут и начинается самое интересное: с одной стороны язык для опытного разработчика больше не является предметом фапа и изучения,
единственное требование к нему - возможность записать программу в категориях, максимально близким к тем, которыми он мыслит.
С другой - мышление опытного разработчика гораздо более абстрактно и высокоуровнево, чем мышление джуниора, следовательно,
язык должен иметь средства выражения этих абстракций. В этот момент многие разработчики перерастают свой инструмент.
Более удачливые переходят на другой, более развитый. Менее удачливые, у которых нет такой возможности, вообще перестают программировать,
аргументируя это тем, что программирование - тупое, однообразное занятие, и становятся аналитиками или архитекторами
(т.е. фактически тоже меняют инструмент - убогий негибкий язык программирования на гибкий и удобный документ microsoft word).
Восторга джуниоров ни те ни другие как правило не разделяют, просто первые говорят, что LANG_A - убогое говно,
а LANG_B - крутой инструмент для опытных программистов, а вторые говорят, что LANG_A - это нормальный инструмент для подчинённых им обезьянок,
а применения для LANG_B они не видят, поскольку ни они сами, ни их обезьянки этим инструментом не владеют.

И последний вопрос - что же происходит, если LANG_B попадает в руки джуниора? А ничего не происходит,
потому что он просто еще не понимает назначение всех этих абстракций и в лучшем случае программирует на LANG_B как на LANG_A
(обычно более мощные языки позволяют писать на них как на менее мощных, обратное неверно). Я сам неоднократно встречал студентов,
изучавших lisp и prolog в университете (да, сейчас это норма, в моё время никаких лиспов в росийских университетов не было) и совершенно не понимающих,
к чему все эти знания. Какого же было их удивление, когда я показывал им как то, чему их пытались учить, применяется на практике,
как это позволяет делать более грамотную декомпозицию программы, писать более сопровождаемый код,
где лежат пределы выразительности используемого нами языка и как программу можно было бы записать если бы язык был более выразителен.

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

Что тут у нас? Бородатые хипстеры на гироскутерах не осилили SOLID к собесу?

>>990320
Все сливные бачки за сегодня уже автоматизировал, инженер?

>>990325
>SOLID
>не осилили
SOLID - это гумманитарный пиздёж, как и вообще вся литература около ООП. Что там можно не осилить, пять ёбаных правил уровня народных примет и сказаний? Вся эта хуня нужна было только для того, чтоб Мартины Фаулеры и Стивы Макконелы подняли деньжат на свое писанине.

>>990328
> рррряяяя ненужно!!!

иди смузи пить

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

>>990326
Собеседование в люксофт прошел?

>>990317
> В этот момент многие разработчики перерастают свой инструмент.
>Более удачливые переходят на другой, более развитый. Менее удачливые, у которых нет такой возможности,
Это что-же за область такая где реально существует более одного продаваемого мейнстримного языка чтобы можно было сказать что A > B? Ты к нам не из фронтенда, случаем, аппликативно-функторное чудо?

>>990160
Ну, причем или нет оно уже не очень важно как то. Я уже оттолкнулся от эт его идеи и перешагнул ее.

Я когда о всем этом размышляю держу в голове будущую необходимость повсеместного программирования под 20-30 ядер и больше. Сразу как то понятнее становится какой подход имеет будущее, а какой нет.

>>990167
Дык суть в том что бы иметь некие обработчики данных которые можно легко комбинировать цепочками и запускать параллельно. Это могут быть и "чистые" объекты которые просто обрабатывают но ничего не хранят, это могут быть чистые функции, "чистые" акторы и вообще все что угодно подобное.

Ну и где то там сбоку хралища данных которые тоже могут быть реализованы через что угодно лишь бы суть сохранялась.

Вообще без разницы на чем это реализовывать, лишь бы был необходимый минимум инструментов.

>>990422
>лишь бы был необходимый минимум инструментов
Так ФП и дает тебе этот необходимый минимум, твори, пердолься с акторами в функтор, то ж тебе не дает? Только вот в большинстве случаев избавляться от состояний неоправданно сложно; а ведь мы еще помним про то, что вообща вся эта песня с выделением абстракций затеяна с противоположной целью, верно?

>>990422
>Я уже оттолкнулся от эт его идеи и перешагнул ее
О, да у нас тут НИСПРОВЕРГАТЕЛЬ АВТОРИТЕТОВ. Мамку свою ты пока что перешагнул в лучшем случае.

>>990197
>3. Программист мудрый.
>Тем не менее, у программиста мудрого есть любимые языки. Ему может нравится Хаскель, но при этом мудрый будет допиливать рантайм на С++, для мудрого это не западло. На работе мудрый будет поддерживать ту же Скалу, ведь мудрый понимает
Предлагаю переименовать в
>программист с достаточно расшатанным анусом

>Программист мудрый прекрасно понимает, что OOD, Буч, GOF, POOD, SOLID - это нихуя не лажа
Все-таки насрал. Жги еще.

>>990328
>SOLID - это гумманитарный пиздёж
Удваиваю этого господина. Давайте для примера присмотримся к
>single responsibility principle
Единственная ответственность, хм... Но когда Мартина прижали к стенке он завилял как гуманитарная безмозглая сучка, которой он является, и начал чего-то лепетать про - единственную причину для изменения (правда, не уверен что местный контингент в курсе, ну да ладно). Но почему же тогда принцип не назван, ну я не знаю single change reason? Да потому что в словесном сблеве дядюшки Боба нет вообще никакого смысла, вот почему.
Принципы которые нужно применять всегда. Только кроме случаев когда их не нужно применять. А на самом деле все нужно делать с умом. Ну спасибо дядя Боб, теперь то я понял как нужно жить. Но только когда их применять, а когда нет никто не знает. Короче смысла в этих высерах 0.

>>990482
Просто ты аутист и у тебя слабоформализуемых правил переполняется буфер. Можно тебе посочувствовать, конечно.

>>990486
Нашел такую хуйню в треде о колонках
www.youtube.com/watch?v=vaMKFCR7s8w
и вспомнилось про этот тред. Почти как-будто про SOLID-поеботу и ее фанатов-говноедов снято.
А кто не верует - мне-вас-жаль-аутист.

>>990519
https://www.youtube.com/watch?v=vaMKFCR7s8w
fix

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

>>990524
Фраза детектор немощной гуманитарной маньки. С одной помойки с
> у каждого своя правда

>>990459
Если невозможно избавится то и не надо, но надо максимально изолировать.

Да и я писал что я не фанатик одной парадигмы. Я тыкал smalltalk, erlang, prolog, forth, lisp, haskell, go, что бы получить свое понимание различных парадигм. Брать старался те где интересующая идея была почище.

Сейчас наверно все равно уже будет за что браться. Большинство нынешних языков это просто воплощение пересечения идей из старых в разных пропорциях, лол.

>>990467
Я тыкал Кеевский smalltalk. Лет 20-30 зашло бы, но сейчас точно нет.

Сейчас нужен такой же скачок который был когда появился GC, только для параллельного программирования. Что бы ручками не пердолиться, а получать максимальное автоматическое раскидывание по ядрам. А ООП там будет или еще какое ЗПП, неважно это, лишь бы оно максимально облегчало это дело.



Да и вообще все это ерунда такая не стоящая внимания. Надо размышлять над уровнем еще выше, а язык брать любой подходящий под конкретные условия.

>>990482
Сначала прочитай определение обязанности, а потом кукарекай

>>990572
Ты просто выгорел.
Вот и непользуешься ГО.

Поддерживай себе легаси свое, или на пенсию выходи.

>>990578
>Сначала прочитай катехизис и выучи псалтырь, а потом кукарекай

Даже не ожидал срача на два треда. Что же, пришло время расстановки точек над ООП. Тред не читал офк, так что возможно до чего-то вы уже дошли сами.
1) ООП - НЕ парадигма программирования. Парадигм программирования всего три. Подробнее здесь: http://wiki.c2.com/?ThereAreExactlyThreeParadigms.
2) То что подразумевают под ООП в современном мейнстримном виде (как в плюсах, джаве, питоне и т.д.) - не более чем тривиальная надстройка над старыми добрыми структурами, процедурами и указателями на процедуры. Об этом Вирт, Кей и другие говорили еще в 80-е, наверное. Кстати, если у кого есть копипаста от каталог-куна про ООП, быдло и люк, доставте, будет в тему.
3) ООП - определенный способ представления программы в голове, а следовательно и способ её структурирования в тексте. Именно его имел в виду Кей, в нем, как ни странно, суть Actor Model, а значит Эрланга и Акки, и во многом именно о нем пишет небезызвестный Егор Бугаенко (http://www.yegor256.com/tag/oop.html) с чьими тезисами можно быть более или менее согласным, но как минимум познакомиться стоит. Можно говорить что это гуманитарщина, и быть при этом правым, но не нужно забывать что программы в первую очередь пишутся для людей, а значит способ их изложения и понимания имеет значение. Насколько легко преставлять программу как множество объектов, взаимодействующих друг с другом - другой вопрос. Возможно другие способы эффективнее, возможно это вообще индивидуально.
4) Я бы еще сказал что ООП - способ структурирования императивных программ. Дело в том что я видел ОО-код на С, видел процедурный код на питоне с джавой, но никогда не видел ОО-ориентрованых програм на функциональных языках. Наверное это из-за того что объекты почти всегда инкапсулируют какое-то мутабельное состояние, иначе они превращаются просто в (параметризируемые) модули, а состояние в ФЯ обычно скрывается и обрабатывается не так, как и императивных.

>>990657
->
Почитай тут:>>989948 и поймешь про 4 пункт.

Ну я где то выше писал что оно похоже на модули, но пасаны как то скептически на это глянули.

>The Missing Paradigm: GoalBasedProgramming (possibly DeclarativeMetaprogramming)
Вероятно частично Coq, Agda, Lean. Но там что бы въехать надо уже матан и теорию типов дрочить.

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

>>990689
Проверка типов при компиляции
@
Монады возвращающие и передающие по цепочке результат неудачного выполнения операции


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

>>990689
>Они налагают ровно столько же, если не больше ограничений, чем внутренний стейт
Это как раз хорошо. Чем меньше ограничений, тем проще допустить ошибку. Подробнее здесь: https://www.youtube.com/watch?v=GqmsQeSzMdw
>В отличии от стейта, у функции ты не сможешь узнать о допустимости операции не выполнив ее.
Не понял. Функцию всегда можно выполнить. Если нужно проверить контракт - проверяй. Идеально чтобы он был закодирован в системе типов.
>>990678
Пункт 4 больше о моём опыте, мысли вслух так сказать.
В >>989948 описан переход к ФП как к восприятию программы как обработчика потока данных. Тоже довольно известная идея, описанная например здесь: http://www.lihaoyi.com/post/WhatsFunctionalProgrammingAllAbout.html:
С ней я совершенно согласен, но от ООП здесь ничего не остаётся.
Кроме того я не понял
1) как все это связано с количеством ядер, т.е. почему именно 20 нужно, а не два или даже одно
2) как Go вписывается в это восприятие - из того что я видел, он не отличается от других императивных языков, то есть программист думает именно о потоке выполнения инструкций программы.
>Ну я где то выше писал что оно похоже на модули, но пасаны как то скептически на это глянули.
Мнение пасанов из /pr это такой себе показатель. Довольно очевидно что классы это первоклассные параметризируемые модули.
>Coq, Agda, Lean.
Они об автоматическом доказательстве теорем и зависимых типах. Не уверен что они вообще относятся к предмету обсуждения, это не языки общего назначения.
А еще хочу поддвачнуть >>990572, а именно
>Надо размышлять над уровнем еще выше
Главное и самое сложное - правильно выделять подсистемы и интерфейсы между ними. Тут никакие языки не помогут, нужно думать и иметь опыт это к вопросу что в программировании делать после 30. Как закодировать это все - дело тоже не последнее, но реализуемо на любом языке, хоть на паскале.

>>990753
>Функцию всегда можно выполнить
Ложное утверждение. Зависит от уровня доступа (в системном понимании) и последствий. Тебе либо придется размазывать стейт по телу функции в виде условий и вводить дополнительные параметры, либо, например, опрашивать все увязанные на конкретное "выкинутое" состояние компоненты системы каждый раз создавая море нагрузки без всякого функционала.

>>990742
Я про функции и реальный мир, реальный мир и функции.

>>990572
>автоматическое раскидывание по ядрам
Давно есть в Erlang, да и в Go тоже вроде.

Эрланг медленный почти во всем кроме своего основного предназначения, плюс динамика и когда брался не было нормальной возможности работать со стрктурами данных. А вот у Го рантайм конфетка, да. Но синтаксис не конфетка. Впрочем все осговные нужные фичи есть и можно юзать.

>>990933
>Эрланг медленный
Бекенд и не должен быть быстрым-быстрым на одном узле, он должен быть масштабируемым. Приложения на Erlang линейно масштабируются на любое количество узлов, а дикая распределённость из коробки позволяет легко переписать любое приложение на распределённый манер.

> А вот у Го
Вот когда там можно будет с одной ноды приконектиться на другую, не блокируя выполнение ни там, ни там, провести интроспецию, выполнить любой произвольный код, или вообще заменить его другим, и потом детачнуться обратно - вот тогда и конкуренции с Эрлангом и поговорим.

>>990933
>А вот у Го рантайм конфетка, да. Но синтаксис не конфетка. Впрочем все осговные нужные фичи есть и можно юзать.
А Julia видел?
https://julialang.org/

>>990994
>Вот когда там можно будет с одной ноды приконектиться на другую, не блокируя выполнение ни там, ни там, провести интроспецию, выполнить любой произвольный код, или вообще заменить его другим, и потом детачнуться обратно
Это можно в любом языке поддерживающим передачу функций в качестве параметров.

>>991092
>for numerical computing
Не увлекаюсь этим. Ну и языки предпочитаю не трогать до 1.х версии.

>>991102
>Не увлекаюсь этим.

Оно все остальное может.
Корутины есть.
Вот это все.

>>991058
Рискну поспорить с веселой картинкой и "бытовой мудростью", но на мой взгляд идея язык-под-задачу - это полный бред. Все беды от этой хуйни. Языки для маленьких программок - ну да ведь не бывает такого чтобы маленькая программка становилось нихуя не маленькой кучей говна. Зачем нам нормальные методы для работы со строками, у нас ведь язык для многопоточного программирования? Чет медленновато? - ну эт просто этот язык не предназначен для таких нагрузок.
Только языки общего назначения, только хардкор.

>>991106
>>991118
Ну просто на вид там нет ничего нового чего бы я не пощупал в других языках. Хочу вот Mercury пощупать и Idris, Agda, Coq, Lean. Меркури например это пролог перепиленный под чистую функциональщину.

>>991265
А тут не о чем спорить. Я сказал про свой подход, но не сказал что кто-то кроме меня должен его использовать, лол. Ваш выбор на мне никак не скажется, делайте как хотите и что хотите.

>>991092
>Это можно в любом языке поддерживающим передачу функций в качестве параметров.
Только ни в одном я не видел аналога эрланговского ремшела, а hot code reload на таком же уровне есть только в лиспе.

>>991058
>ну карочи язык ыта инструмент
Ой, нахуй иди.

>>991385
Спецязык же.
В других языках это библиотекой делается.

>>991397
Приведи пример таких либ в мейнстримовых языках. А той же яве релоад сделан охуенно сложно и не всегда отрабатывает. А ремшела даже в языках с конкурент примитивами нет (типа кложи, хотя там даже есть тот же REPL).
И что значит спецязык, обычный бекенд язык общего назначения, все виды серверов, от веб- до лдап-, базы данных, и прочее.

>>991407
https://habrahabr.ru/post/253877/

>https://techmight.ru/protsessory-amd-ryzen-whitehaven-predlozhat-16-yader-i-chastotu-3-6-ggts/
>Процессоры будут доступны в нескольких вариантах, а версии высокого уровня будут 16-ядерные и 32-ниточные, что вдвое больше, чем AMD Ryzen 7. 16 ядер — это самое лучшее, что предложит AMD; также будут 12- и 10-ядерные.

>https://techmight.ru/v-avguste-vyjdet-novyj-flagman-intel-core-i9-7920x/
>Неудивительно, что в процессорах Intel Core i9 используются 12 ядер и 24 нити


А будущее оказывается ближе чем я думал, лол.

>>991754
Уже тысячу лет как на ксеонах и прочих ешках. Только что в этом от будущего - не понятно. Это не тысячи тредов, это всего в 4 раза больше чем есть сейчас.

https://ark.intel.com/products/81060/Intel-Xeon-Processor-E5-2698-v3-40M-Cache-2_30-GHz

>>991666
>приводит в пример вненюю прогу

Ну, во-первых, докер не может в хот-релоад, при поставке нового имейджа существующие контейнеры останавливаюся и подымаются новые.
Во-вторых, причём тут вообще докер? Это не замена ремшела. То, что я могу сделать exec внутрь контейнера, это конечно хорошо, но мне нужны не внутренности контейнера, а нужны внутренности прямо сейчас выполняющейся программы, доступ ко всем прямо сейчас существующим в ней сущностям (будь то объекты, процессы или узлы), возможность что-то прямо сейчас доопределить, перезаписать или затерейть. Чем является эрланговский ремшел - так это распределённым REPL'ом с раширенными возможностями. И не нужно никаких сторонних программ, язык поддерживает это из коробки.
И вообще, "Любая достаточно сложная распределённая программа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Erlang.", что наличие всяких быдлиотек и внешних перделок в других языках только подтверждает.

>>991814
https://www.amazon.com/Intel-Xeon-E5-2698-Hexadeca-core-Processor/dp/B00PDD1QES
>$2,650
Всего то. Смысл не в том что где то че то есть. Смысл в том что бы оно массово было везде и была необходимость что то с этим делать.

>>991823
Мы тебе позвоним когда нам это все понадобится.

>>991827
>мне не нужно - никому не нужно
Ясно.
>Мы тебе позвоним
Спасибо, мне и так по две вакансии в неделю на позиции Elixir/Erlang приходят, на данный момент я не рассматриваю новые предложения.

>>991834
>Мне нужно - всем нужно.
Ясно, лол.

>>990217
>потом начинается этап ниспровержения авторитетов на основе собственного ограниченного опыта
Ну немножко не так. Я бы не сказал, что "программист просветлённый" имел бы меньше знаний, чем банда четырёх педерастов, но педерасты тебе говорят: "Если ты пьёшь с ворами, опасайся за свой кошелек." Скорее всего, в отличие от просветленного, они не знают, как использовать расширения Кана для оптимизации монадического говнокода (если ты сам не знаешь, тут описано: https://www.cs.ox.ac.uk/ralf.hinze/publications/MPC12.pdf), или того, что в некоторых случаях можно эффективно не пить с ворами, но это же, блядь, не отменяет того факта, что если ты пьёшь с ворами, нужно опасаться за свой кошелек! Т.е. они совершенно правы во всех своих высказываниях, а заявления ОП-а о том, что всё это лажа - чистой воды нигилизм.

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

>>990473
>Предлагаю переименовать в
>>программист с достаточно расшатанным анусом
А со сжатым анусом ты ничего не сделаешь, потому что живёшь в реальном мире. Та же Скала сделала больше для продвижения ФП-парадигмы, чем Хаскель со всеми его монадами. И вот да, только так дела и делаются, путём компромиссов, путём того, что нужно сознательно жрать говно, потому что если ты просто станешь в позу, то нихуя не произойдёт, а постепенное улучшение медленно но верно ведет к успеху.

>Все-таки насрал. Жги еще.
И что же конкретно тебе не навится в этих практиках? Давай отбросим GOF и OOD, допустим, что это про OO, и ты считаешь, что ОО не нужно. Но вот SOLID (без Liskov substitution, разумеется, потому что это про сабтайпинг, который тоже не нужен). Что в нём не нравится? Это же просто утверждения из серии "за все хорошее, против всего плохого". И да, есть куча людей, которые этого не понимают, и ему постоянно приходится говорить "используй single responsibility principle, используй его, сука!" пока до человека не дойдёт.

>>990994
>Приложения на Erlang линейно масштабируются на любое количество узлов, а дикая распределённость из коробки позволяет легко переписать любое приложение на распределённый манер.
>>990197
>Стоит заметить, что сейчас треднды активно меняются, поэтому вы легко сможете встретить хайпозависимого скалиста, который будет вам цитировать рекламный булшит

А всё-таки неплохую классификацию я придумал. Ну что, будем закапывать восторженного ерлангоёба (закопать его с "линейным масштабированием" очень просто, начиная с закона Амдала, который математически опровергает саму возможность линейного масштабирования, заканчивая чисто практическими аспектами, которые делают невозможной автоматическую масштабируемость "из коробки" для MP модели, частным случаем которой являются акторы), или пусть еще поживёт в своём манямирке? ИМХО пусть живёт, в конце концов ни одному хайпозависимому (кстати, лучше переименовать его в "программист восторженный", звучит круче) ничего нельзя доказать, опыт приходит со временем.

>>992059
>https://en.wikipedia.org/wiki/Funarg_problem).
>Wikipedia does not have an article with this exact name. Please search for Funarg problem). in Wikipedia to check for alternative titles or spellings.
И вот так у тебя всё.

>>992059
> замыкания без мусоросборников не работают ибо Funarg problem
Замыкания это способ решения Funarg problem в языках где для хранения аргументов функций используется стек.