>говно говно говно
>Цифр, исследований, предметной полемики с оппонентами - нет как таковых.
>не приводит
>Цифр, исследований, предметной полемики с оппонентами - нет как таковых.
OK
Ну в ООП-религии есть правильные идеи. Правда, они — капитанство и вообще были придуманы до оопе
Лучший тред зк, бтв. Хоть повылезали из своих берлог и посрались как люди.
>повылезали из своих берлог
Охуел что ли, нахуй иди.
голос из берлоги
Смотри предыдущий тред.
>его выбирают те кто программистов нанимает - занавес
Бред сумасшедшего. Бизнесс никогда не спускается настолько глубоко под копот, чтобы еще принимать решения о том каким говном обмазываться - объектным процедурным или функциональным (бтв все три суть одно, но не об этом речь).
А нанимают теже программисты, которые доросли до архитекторов и менеджеров.
Решает, но косвенно. Бизнесу нужно, чтобы было дешево, быстро и поддерживалось десятилетиями. Очевидно, что жабка и прочие ооп-быдлонедоязыки, с парадигмами делай-не-думая, идеально подходят под эти требования.
>А нанимают теже программисты, которые доросли до архитекторов и менеджеров.
У меня для тебя плохие новости.
1. Погромисты не становятся менеджерами.
2. Погромисты не становятся архитекторами.
3. Первоначальным отсевом занимается отдел кадров HRочки няшечки стесняшечки(стервозные безмозглые бляди).
4. Тимлиды и прочие программисты, которые проводят технические собеседования, имеют ООП головного мозга и джаву мозжечка.
Круг ООП замкнулся.
Относительно того, каким должен быть идеальный язык, уже пара статей была написана, первая из них ещё в 2007 году:
http://www.croco.net/croco/papers/stolyarov_2007b.pdf
Если коротко, то в самом языке вообще не должно быть синтаксического сахара, должны быть средства для его создания в библиотеках; библиотеки как раз и должны быть его источником, а равно и источником большинства свойств, которые вы хотите видеть в языке. Сам язык должен быть ещё более низкоуровневым, чем чистый Си, и это должно быть его основное свойство, точнее, одно из двух основных; второе -- широкие возможности по введению новых абстракций. Из перечисленных вами ни один язык не может стать "донором", поскольку они все высокоуровневые.
http://www.stolyarov.info/guestbook
http://www.croco.net/croco/papers/stolyarov_2007b.pdf
Если коротко, то в самом языке вообще не должно быть синтаксического сахара, должны быть средства для его создания в библиотеках; библиотеки как раз и должны быть его источником, а равно и источником большинства свойств, которые вы хотите видеть в языке. Сам язык должен быть ещё более низкоуровневым, чем чистый Си, и это должно быть его основное свойство, точнее, одно из двух основных; второе -- широкие возможности по введению новых абстракций. Из перечисленных вами ни один язык не может стать "донором", поскольку они все высокоуровневые.
http://www.stolyarov.info/guestbook
Попался, шизик!
Не уйдешь!
>Если коротко, то в самом языке вообще не должно быть синтаксического сахара, должны быть средства для его создания в библиотеках; библиотеки как раз и должны быть его источником, а равно и источником большинства свойств, которые вы хотите видеть в языке. Сам язык должен быть ещё более низкоуровневым, чем чистый Си, и это должно быть его основное свойство, точнее, одно из двух основных; второе -- широкие возможности по введению новых абстракций.
Такой язык есть.
LLVM IR называется.
Или ассемблер, как альтернатива.
Скажите же, что ООП в жаваскрипте нет. А то меня на собесе пытались заставить на нем КЛАСС написать.
javascript class первая ссылка в гугле
>ООП в жаваскрипте нет
ООП на основе прототипов в нем было даже до того, как появились полноценные классы.
С тех пор как сракле пожрали ЖАББУ и йебеэм купили НОДЭДЖЭЭС теперь всё кобол-ориентированное цифровое гуано будет и в НОДЭДЖЭЭС.
Что тут у нас?? ООП - сложна?!
— Смотри, я… вот у нас здесь функций много… ой-ой… функций много, понимаешь? Смотри, функции, они тебе спать мешают. А я вот, давай вот я функции прямо в структуре объявлю, и они все в структуре будут, и мы их методами назовем, слышишь, членами назовем? И тебе тогда спать, ой, спать будет хорошо. Давай? Ну, куда им ещё, ихнее место-то тока здесь. А структуру - классом.
— Ты можешь просто помолчать, всё, пиздец?!
— А еще в классе два члена сделаем, конструктор и деструктор, и они сами собой эти члены дергаться будут. Вот так, дерг, дерг.
— Заебал, блядь!
— А еще у класса родитель может быть, а этот класс тогда дочка. И у дочки тогда все члены родителя будут, ну они же наследуются, ну. Понимаешь, братишка. У дочки члены родителя будут. И их тоже дергать можно будет.
— Ёб твою мать! Блядь! Иди отсюда на хуй, блядь!
— Но не все члены дергать можно будет, будут публичные члены, которые все могут дергать, вот ты мой публичный член, например, можешь подергать.
— Сука, блядь, пидорас, блядь!
— А другой член только родитель сможет дергать, и больше никто. А еще будут члены, которые только родитель и дочка дергать смогут. Братишка, братишка... Дочка у родителя член дергать сможет, понимаешь, братишка.
— Иди под струю, сука! Мойся!
— А еще можно будет класс-дружочек сделать. И тогда этот дружочек все членики у своего дружочка дергать сможет.
— А блядь на хуй! Ну, иди сюда сука, блядь! Дерьмо собачье, блядь! А блядь!
— А у дочки много родителей будет, и все членики родителей у дочки тогда будут. Их можно будет дергать и другим не мешать дергать, понимаешь?
— Мудак, блядь, ну ты мудак. Я тебя сейчас убью нахуй, а тебя, бля, сейчас убью, блядь!
— Ты можешь просто помолчать, всё, пиздец?!
— А еще в классе два члена сделаем, конструктор и деструктор, и они сами собой эти члены дергаться будут. Вот так, дерг, дерг.
— Заебал, блядь!
— А еще у класса родитель может быть, а этот класс тогда дочка. И у дочки тогда все члены родителя будут, ну они же наследуются, ну. Понимаешь, братишка. У дочки члены родителя будут. И их тоже дергать можно будет.
— Ёб твою мать! Блядь! Иди отсюда на хуй, блядь!
— Но не все члены дергать можно будет, будут публичные члены, которые все могут дергать, вот ты мой публичный член, например, можешь подергать.
— Сука, блядь, пидорас, блядь!
— А другой член только родитель сможет дергать, и больше никто. А еще будут члены, которые только родитель и дочка дергать смогут. Братишка, братишка... Дочка у родителя член дергать сможет, понимаешь, братишка.
— Иди под струю, сука! Мойся!
— А еще можно будет класс-дружочек сделать. И тогда этот дружочек все членики у своего дружочка дергать сможет.
— А блядь на хуй! Ну, иди сюда сука, блядь! Дерьмо собачье, блядь! А блядь!
— А у дочки много родителей будет, и все членики родителей у дочки тогда будут. Их можно будет дергать и другим не мешать дергать, понимаешь?
— Мудак, блядь, ну ты мудак. Я тебя сейчас убью нахуй, а тебя, бля, сейчас убью, блядь!
Ебать вы только одуплились, читайте Вьетнам компьютерной науки
Мимо-структурно-процедурный-бог
>пригоревшему под конец предыдущего треда джявисту посвящается
К нам в айти отдел пришёл новый сотрудник. Нужно сказать, что у нас в отделе работают почтенные крестогоспода. Новичка посадили за компьютер, но не успели даже дать задание, как он начал кодить. Начальник из любопытства подошёл посмотреть, что он там написал. В течении секунд тридцати он побледнел, затем посинел, затем покраснел, а потом трясущимся от нескрываемого гнева голосом сказал:
- Это же Абстрактная фабрика! На чём ты кодил до этого?
- На Джаве.
- Жабапидор! - в один голос заорали все 20 человек.
- Жабапидор! Жабапидор! Жабапидор!
Кто-то включил сирену. Над дверьми замигали красные лампочки тревоги. На окнах мгновенно сомкнулись плотные жалюзи. В офисе одновременно бывает два отдела человек по сорок. На обеде вся эта толпа собирается на первом этаже, где яблоку негде упасть. А поэтому, как охранники ни пытались вырвать джавапидора из рук разъяренной толпы, им это не удалось. По всему офису стоял сплошной рев:
- Жабапидор!
В коридоре его сразу же сбили с ног. Используя галстук как поводок, его тащили через весь коридор, передавая из рук в руки. Поэтому получалось так, что никакого движения в коридоре не происходит, но и джавапидора тоже нет. Его заволокли в каптерку под лестницей, где хранятся ведра и швабры с тряпками, и там закрыли. Под конец рабочего дня он всё же появился. За получасовой обед его изнасиловали несколько человек. Сопротивляться было бы бесполезно. Через день на нем чистым оставалось одно лицо, а на теле не было живого места. Он превращался в мразь, в животное. Его били все, даже дизайнеры и уборщицы. Его заставляли есть говно и опарышей. В очко ему совали битые лампочки, живых птиц и змей. Он стал «дельфином» – в нужнике пятнадцать дырок, он ныряет в первую, выныривает, ныряет во вторую... И так – до конца. От него постоянно воняло. С ним невозможно было рядом находиться. Был такой случай: к нам устроился работать Степаныч. Степаныч сидит на толчке, а кто-то снизу через очко хватает его за яйца. Степаныч с воплем вылетает в коридор без штанов. Напротив - айти отдел. Смех не стихал долго... Потом Степаныч забил его кирзовым сапогом насмерть. Менты как узнали, что сдох джавапидор даже дело заводить не стали.
К нам в айти отдел пришёл новый сотрудник. Нужно сказать, что у нас в отделе работают почтенные крестогоспода. Новичка посадили за компьютер, но не успели даже дать задание, как он начал кодить. Начальник из любопытства подошёл посмотреть, что он там написал. В течении секунд тридцати он побледнел, затем посинел, затем покраснел, а потом трясущимся от нескрываемого гнева голосом сказал:
- Это же Абстрактная фабрика! На чём ты кодил до этого?
- На Джаве.
- Жабапидор! - в один голос заорали все 20 человек.
- Жабапидор! Жабапидор! Жабапидор!
Кто-то включил сирену. Над дверьми замигали красные лампочки тревоги. На окнах мгновенно сомкнулись плотные жалюзи. В офисе одновременно бывает два отдела человек по сорок. На обеде вся эта толпа собирается на первом этаже, где яблоку негде упасть. А поэтому, как охранники ни пытались вырвать джавапидора из рук разъяренной толпы, им это не удалось. По всему офису стоял сплошной рев:
- Жабапидор!
В коридоре его сразу же сбили с ног. Используя галстук как поводок, его тащили через весь коридор, передавая из рук в руки. Поэтому получалось так, что никакого движения в коридоре не происходит, но и джавапидора тоже нет. Его заволокли в каптерку под лестницей, где хранятся ведра и швабры с тряпками, и там закрыли. Под конец рабочего дня он всё же появился. За получасовой обед его изнасиловали несколько человек. Сопротивляться было бы бесполезно. Через день на нем чистым оставалось одно лицо, а на теле не было живого места. Он превращался в мразь, в животное. Его били все, даже дизайнеры и уборщицы. Его заставляли есть говно и опарышей. В очко ему совали битые лампочки, живых птиц и змей. Он стал «дельфином» – в нужнике пятнадцать дырок, он ныряет в первую, выныривает, ныряет во вторую... И так – до конца. От него постоянно воняло. С ним невозможно было рядом находиться. Был такой случай: к нам устроился работать Степаныч. Степаныч сидит на толчке, а кто-то снизу через очко хватает его за яйца. Степаныч с воплем вылетает в коридор без штанов. Напротив - айти отдел. Смех не стихал долго... Потом Степаныч забил его кирзовым сапогом насмерть. Менты как узнали, что сдох джавапидор даже дело заводить не стали.
опиши еще геттеры и сеттеры, ведь просто открытые переменные не по шариату
А потом после очередного релиза у крестопидоров начала течь память и вообще бизнес заебался, что фичи выкатываются хуй знает сколько и с помощью рыночка порешал крестопидоров.
Там идеи верные, но попытки реализации так себе.
А реализация должна быть по настоящему инфернальной.
Берем теорем прувер, пишем на нем ассемблер. Но ассемблер не простой, а с типами учитывающими в том числе эффективность того или иного участка кода по памяти/скорости выполнения. Да и вообще с типами учитывающими очень многое, а не только то что важно там математикам в своих теориях. Далее нам необходим такой инфернальный компилятор, хотя скорее нечто среднее между llvm и компилятором. Ну что бы он например мог используя те хитровыебанные типы и информацию из рантайма сам мог выбрать наиболее подходящий алгоритм во время выполнения. Ну типа в данный момент времени памяти много, а ресурсов проца не очень и он мог бы взять какой нибудь жрущий много памяти алгоритм с мемоизацией, например.
Дальше мы лабаем инфернальное подобие сишечки при запуске которого не понятно подсчитает ли он факториал или решит что оптимальнейшим решением в данной ситуации будет заставить программиста подсчитать его. Но что б там все внутри чекалось и непредсказуемая хуйня точно была исключена.
Ах да, еще надо как то сделать так что бы он учитывал особенности конкретного железа.
Ну короче надо хитрые типы сначала к llvm присобачить, а потом глянуть чо как выйдет.
>инфернальной
лучше вагинальной. вагинальный ассемблер с клиторотипизацией.
1. False, самые лучшие манагеры как раз бывшие программисты.
2. False, очевидную хуйню написал.
3. Разве это проблема? Их же обаять как нехуй делать я не альфач
>полноценные классы в жс
Слово class еще не значит, что это полноценный класс в понимании джависта или шарписта. Под капотом те же прототипы.
Типа не похуй и типа жанрам думают про оптимизацию и прочие приблуды.
>самые лучшие манагеры как раз бывшие программисты.
Ты джаву изобрел.
Слишком высокоуровневая. 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 применяют в приложениях, которым требуется встроенный язык программирования, причем скорость выполнения встроенной программы имеет значение.
В треде про ООП борщехлёбы, веб-макаки и индусы-джявисты пиздят про LLVM, на котором даже хеллоуворлд напейсать не способны. Все как обычно.
Давайте все же вернемся к ООП. Из прошлого треда мы поняли следующее:
1. Строгого определения ООП не существует, и это всякий раз добавляет остроты в подобные дискуссии. Предлагаю все же остановиться на следующих критичных, на мой взгляд, свойствах: а) существует возможность связать каким-то образом данные и методы, которые с ними работают; б) существует иерархия типов, и экземпляр всякого подтипа может быть использован там, где требуется надтип; в) существует соглашение, согласно которому область видимости конкретных данных и функций ограничивается. Это не совсем канонiчная форма трех слонов, но зато из такого описания сразу видно, что ООП - это именно метод структурирования программы, а не свойство языка. Можно писать ООП-программы практически на любом языке; другое что поддержка понятий ООП на уровне языка сильно упрощает это занятие.
2. Баттхёрт от ООП испытывают в основном следующие группы граждан: неосиляторы (как правило, не умеющие толком структурировать свои программы ни одним из известных человечеству способов), джява-ветераны (так как джява, во-первых, создавалась скорее для обуздания деструктивных способностей толп полуобразованных индусов, нежели для ведения эффективной разработки профессионалами; а во-вторых, создавалась очень давно, когда многие подводные камни ООП ещё не были известны), ну и, наконец, всеми нежно любимые бородатые педики на гироскутерах (поскольку швитой серебрянопульный грааль погроммирования в блогах и свитерах уже давно смещается в сторону ФП).
3. При умелом использовании (то есть с учётом всех основных подводных камней) ООП является довольно эффективной техникой структурирования кода. Поиск продолжается, в частности, мне чрезвычайно импонирует Rust как довольно сбалансированный сплав ООП и ФП.
>2. Баттхёрт от ООП испытывают в основном следующие группы граждан:
1. Все.
Даже преподы ООП в вузах.
Помню свою курсовую по ООП.
Игра "жизнь", тема была.
Это ебанный стыд, когда все эти "сущности" в классы определяешь.
Но самое чудесное, это, РЕКУРСИВНЫЕ ЗАВИСИМОСТИ.
От которых препод бугуртил не меньше меня.
>преподы
Петухов забыли спросить.
>РЕКУРСИВНЫЕ ЗАВИСИМОСТИ
>я даун, но виноват ЯП
>3. При умелом использовании (то есть с учётом всех основных подводных камней) ООП является довольно эффективной техникой структурирования кода.
При умелом использовании, от ООП ничего не остается.
Другими словами, правильное использование ООП - это неиспользование ООП.
Отправитель - сообщение - получатель, это конечно здорово. И хотя вроде как ООП это и есть, на практике, нет, не это.
Поэтому, пусть будет SMR подход SenderMessageReciever. Будет в тыщу раз больше смысла.
И при этом, никаких специальных структур данных.
Сендре и рецивер - функции. Сообщение - обычная переменная\структура.
Ну или если уже ООП, то БЕЗ наследования, вапще.
Только интерфейсы. Сами интерфейсы то-же без наследования(ну нахрен).
Соответственно никаких протектед овверайдед и прочей ереси.
И пожалуй, никаких статических полей конструкторов и ничего статического. Никаких этих прокси фактори.
>Петухов забыли спросить.
Ого, круто ты.
Ты еще в школе учишься, или уже на 1вом курсе?
Как оно, у питухов троечку выпрашивать?
>я даун
Я вижу.
>виноват ЯП
Речь идет о ООП. Ты тред попутал.
К рекурсивным зависимостям привело использование ООП парадигмы.
>Как оно, у питухов троечку выпрашивать?
Тебе виднее.
>К рекурсивным зависимостям привело использование ООП парадигмы.
Рекурсию придумали программисты. Это сильно.
>Тебе виднее.
Тебя отчислили?
>Тебя отчислили?
Я хуй знает.
>Сами интерфейсы то-же без наследования(ну нахрен).
Как раз в наследовании интерфейсов, т.е. поведения, нет ничего плохого, это совершенно безопасно.
>Как раз в наследовании интерфейсов, т.е. поведения, нет ничего плохого, это совершенно безопасно.
Классы наследуют интерфейсы.
Интерфейсы не наследуют интерфейсы.
Наследование интерфейсов интерфейсами бессмысленно чисто архитектурно.
Это плохой дизайн.
Ишшо адин неасилятор элиминтарнава ооп высрал еще адин пост боли ббггее. Я паржу, атвечу сагай в тваю прыщавую попку и закурю ббггее. Шалом ебанаты ббгг.
> Rust как довольно сбалансированный сплав ООП и ФП.
Расскажи, какими уникальными свойствами обладает раст и что делает его сбалансированным.
Потому как замыкания, рекурсия - вот это функциональное говно, есть едва-ли во всех мультипарадигменных ЯП. Ок, чистоты нет. Так чего тебе не хватает? Мне вот с коррутинов и многопоточности иногда бомбит, т.е. ООП, конечно же прекрасен, но там где надо в парралельные вычисления, там запутанные состояния объектов мешают. А уж если что-то изменится НЕ ВОВРЕМЯ, вот тогда весело будет. Иногда хочется обмазаться чистотой, но и все, пожалуй.
Объясните, кто-нибудь, какое отношение 'замыкания' имеют к ФП. Какой смысл 'замыкания' могут иметь в ФП?
Ну, наверное, потому что closures подразумевают в язке наличие HOF.
В огороде - бузина; в Киеве - дядька
Повторю вопрос: "Какой смысл 'замыкания' имеют в ФП?"
>closures подразумевают в язке наличие HOF
Разве?
Смысл, в уменьшении DRY, например.
Что-то я понимаю вас всё меньше и меньше.
>Разве?
Ну да, по определению.
>В огороде - бузина; в Киеве - дядька
Ты странный. Сам пишеш
> какое отношение 'замыкания' имеют к ФП
Тебе блять оговорят какое, чё припераешься?
>говорят
fix
В контектсе сравнения ФП и ООП под замыканиями подразумеваются - Higher-order functions.
Это не одно и тоже; под капотом много различий, да даже в рамках одного ООП языка замыкания ведут себя по-разному (ex, proc vs lambda), тем не менее что то, гавно (hof), возвращает (/или передает через аргументы) функцию, что это (замыкание) - анонимный метод.
Какой cмысл в том, что ты можешь использовать один метод, или функцию несколько раз? Самый общий ответ - повышение реюзабельности кода. За другими кейсами предлагаю пройти на википедию.
>Rust
>ООП
Лол.
>что ООП - это именно метод структурирования программы
Нормальные люди ООП так и понимают, лол. А бугуртящие неосиляторы продалжают искать таблетку от всех проблем.
Ты вобщем-то в любом ООП-подобном языке можешь сделать класс не используя ключевое слово class. Классическое упражнение для студентов приходящих на практику.
>Даже преподы ООП в вузах.
Ебать мой хуй, такая хуйня и правда есть? Сколько в зачетке по ООП стоит?
>РЕКУРСИВНЫЕ ЗАВИСИМОСТИ.
Это шож у тебя за язык с РЕКУРСИВНЫМИ типами?
>Ебать мой хуй, такая хуйня и правда есть?
У нас было на 3 курсе. Причём нельзя было просто решить задачу, нужно было сделать в концептуальном ОО-стиле, иначе не принимали лабы.
>РЕКУРСИВНЫЕ ЗАВИСИМОСТИ.
Похоже этот кретин - - имеет в виду упоминание в класс1 класса2, а в класс2 - класса1 соответственно.
Но такое умеет разруливать любой компилятор - если это, конечно, не пасцаль/говнодельфи.
То есть кретины-преподы обучают дебилов-студентов на говнодельфи.
Жизнь справедлива.
>Похоже этот кретин
Лол, я просто мимо шёл, хули доебался?
>нужно было сделать в концептуальном ОО-стиле, иначе не принимали лабы.
>я просто мимо шёл
Не оправдывайся, просто ты дегенерат и терпила.
Так-то.
Не, я понимаю что в преподавание у нас идет биомусор по остаточному принципу, который даже на джуна в пхп-галеру не возьмут, но все же: в чем блять может быть суть предмета ООП? Семестр-год-два года разбирали набор из пяти постулатов?
Ты тоже какой-то тупой.
Суть в том что нужно начитать положенные часы и отработать, хаха, "зарплату" преподавателя.
На этом все.
Добро пожаловать в Россию.
Ты то я смотрю умный. Преподаватель может чем угодно отчитать эти часы, но в чем состав предмета ООП?
Уточняю:
к
Если я правильно понял пациента, то у него был предмет на котором они исключительно обмазывались мифическим ООП. Ну то есть самостоятельная дисциплина.
>Преподаватель может чем угодно отчитать эти часы
Не чем угодно, есть учебный план десятилетней давности которые нахуй никому не надо менять ибо всем похуй.
>в чем состав предмета ООП?
>Семестр-год-два года разбирали набор из пяти постулатов?
Ты уже сам ответил, дурачок.
>уже ответил
Я хочу подробностей.
Да ты же потралить сюда пришел, какие тебе подробности?
Меня уже потралили наличием предмета "ООП" в школе, теперь ваша очередь быть потраленными и выдавать годноту в виде охуительных историй.
>выдавать годноту в виде охуительных историй.
А ты мне что?
Ты не учился же в шараге на примате, хули тебе пояснять? Там везде ООП проходят. И анон который заикнулся об этом уже пояснил тебе. Просто ты макака которая только кривляться умеет.
Благодарю, пригорел.
>Ебать мой хуй, такая хуйня и правда есть? Сколько в зачетке по ООП стоит?
110/100
>Это шож у тебя за язык
Были кресты от борланда.
Потом заменили на сисярп.
>Не, я понимаю что в преподавание у нас идет биомусор по остаточному принципу, который даже на джуна в пхп-галеру не возьмут
Ты хотя-бы вуз закончи, прежде чем подобную грязь выпукивать.
>в чем блять может быть суть предмета ООП?
У нас фактически изучаем языкнейм.
>Семестр-год-два года разбирали набор из пяти постулатов?
Можно и докторскую написать, разбирая набор из 5ти постулатов.
Да, сорян, я забыл, ты просто демонстрируешь свое презрение к знанию, интеллекту.
Да, дебилы очкастые преподы, гыгы, лол.
Сегодня борщец со сметаной или вариант эконом?
>Можно и докторскую написать, разбирая набор из 5ти постулатов.
С точки зрения безмозглой пидорашки с каргокультом - несомненно.
>Да, дебилы преподы
Так и есть, и в этом нет ничего смешного.
Лол, ясно все с тобой.
>Ты хотя-бы вуз закончи, прежде чем подобную грязь выпукивать.
Высококлассные специалисты, способные из биомусора сделать приемлемых для рынка программистов, работающие по ставке ниже в 10-20 раз ниже рыночной. Да, правдоподобно, очень, осталось закурить и пропеть интернационал.
>Не, я понимаю что в преподавание у нас идет биомусор по остаточному принципу, который даже на джуна в пхп-галеру не возьмут
Да, так вот, дай-ка я тебя немного в фекалии помокаю.
Веб сервисы у меня, преподавал реальный владелец реальной ойти компании.
Который потом брал к себе желающих на стажировку с последующим трудоустройством.
Нейронные сети преподавал профессор с мировым именем, например. У которого кстати совсем немаленький оклад.
Дискретную математику один из ее основателей в СССР, ныне покойный.
Экономику женщина - известный в городе специалист.
>эта БОЛЬ неосилятора ООП
А ведь ООП придумали чтобы утилизировать вкатывающуюся массу индусов и прочих интеллектуальных большинство.
Но для русских и это оказалось слишком сложно, лол.
>преподавал реальный владелец реальной ойти компании.
Феерический пиздеж, дальше читать нет никакого смысла.
> работающие по ставке ниже в 10-20 раз ниже рыночной.
Ебать знаток. Вот отучился бы ты хоть в каком-то крупном областном вузике - хоть бы знал что около половины таких преподов как раз занимается не только преподованием за копейки, а еще и работает в разных конторах и стартапах, кучу всяких спецов из всяких хуяндексов приглашают читать лекции. И прикинь бывает не только макакинг на галерах, а еще и академическая наука, информатика там всякая которую тоже надо двигать.
>Россия
>академическая наука
Шутку понял.
Смешно.
Очень смешно.
>Веб сервисы у меня, преподавал реальный владелец реальной ойти компании.
Обезумевший погонщик обезумел в край. Сколько человек вообще живет в твоей мухосрани?
По остальным областям - не сомневаюсь что преподаватели могут быть годными, но это мягко говоря разговор о другом.
Ага, охуительные научные проекты и стартапы что можно не проебываясь еще и дебилов учить. Ну-ну.
Представляешь, но тут тоже нужна подготовка всяких спецов хотя бы для разработки коммерческих систем, бизнесовой хуйни всякой и прочего. И это, академики тут тоже выживают, вопреки, но таки не все еще умерло.
Ну вот прикинь, не для всех программирование это чисто способ заработка на смузи. Есть еще и такие, кто старается науку двигать. Правда не совсем понятно что их в этой стране держит, но такое есть.
>не все еще умерло.
В процессе, ага.
Гниет и воняет вовсю.
Нахуй иди со своим говном, русский.
>Высококлассные специалисты, способные из биомусора сделать приемлемых для рынка программистов, работающие по ставке ниже в 10-20 раз ниже рыночной. Да, правдоподобно, очень, осталось закурить и пропеть интернационал.
1. Каждый дрочит на что хочет.
Но да, талантливая молодежь в вузах редко задерживается.
Вот знакомая преподша ушла в R&D самсунга.
Тем не менее, пока ты получаешь степень, нужно преподавать.
2. Я тебе открою тайну, мамин борщехлеб, программирование - низкоквалифицированный тяжёлый труд. С бесконечным ctrl+C ctrl+V.
Не говоря уже про чудные реалии офисов и "корпоративной культуры".
Из гуманистических соображений, можно работать преподавателем. Почему-бы и нет? Не все же мамины нищеброды))))
Когда хочется кушать, конечно, уже другой разговор.
>Сколько человек вообще живет в твоей мухосрани?
2млн.
Но моя мухосрань оче академический городок. Вузов на квадрантный метр площади больше чем туалетов.
>Из гуманистических соображений
Таких дебилов все меньше, к счастью.
Жизнь научила и рыночек порешал.
Нахуй съеби, котосибирское быдло.
Мимо.
Гыгы, дебилы, умники. ПОРЖАЛ!
Жопа, хуй, пиздай ебля!
ЁБЛЯ!
>2млн.
>оче академический городок.
>не котосибирск
Кому ты пиздишь, дебил.
>ебля!
>ЁБЛЯ!
Оно еще и девственник, хаха.
>дебил
Приятно познакомится.
Затралел вапще красава.
>нет ты сам дурак
Ясно.
Тебе ненужно кстати уроки делать?
Там вроде как близок конец года, всякие финальные контрольные нужно писать.
>ненужно
>всякие финальные контрольные нужно писать.
Так пиши, разрешаю.
Помню, когда коллега уволился (на тот момент мы работали во freescale), а он был (наверно и есть) крайне патриотических убеждений и пошел работать на военных. Собирали тогда по всей стране людей на приемлемом уровне людей знающих HDL-и и общий кодинг одновременно дабы делать <%информация засекречена%>
Так вот собрали их по первой в МФТИ, выдали все необходимое покупное-контрабандное и назначили цели и задачи, классическое хорошее R&D.
И тут откуда не возьмись прибегает жирнющая бабень, то ли проректор по науке то ли его (ее) зам. И значит - пиздуйте студентов учить! Ишь! Сели, наукой понимаешь занимаются! У нас вон Илларион Валентиныч с 65 года наукой занимается и ничего! Не выебывается, преподает! Вот ваш учебный план, завтра встретить студентов (а дело в начале сентября) - и вперед и с песней!
Вобщем, от статьи тетеньку спасло лишь то, что заслуженный работник лауреат дохулиарда премий и прочих наград. Но, сменить место работы в любом случае пришлось: такой заказчик, такое доверие оказано - и такой конфуз.
А ты говоришь преподавать. К сожалению (а может и к счастью?) во всем что так или иначе связано с it ( причем не важно софт это или хард ) - в преподавание даже в госе идут по остаточному принципу. Т.е. те, кто даже в госе никому не нужны. Ну или аспиранты, но это тот редкий случай когда студентам везет и они не понимая своего счастья его проебывают. Но это крайне редко, хороших аспирантов тоже стараются к делу привлечь на полной основе.
Тебя это удивит, но говновузики это единственный на данный момент способ рекрутинга для всяких хуяндексов и банковских сервисов. Данную нишу специалистами уровня "Вычи Java за 30 дней" просто не заполнить.
>для всяких хуяндексов
Состояние агонии.
>и банковских сервисов
Пока еще дергается, но комплюкторщиков справедливо держит за гной и говно.
>пиздуйте студентов учить! Ишь! Сели, наукой понимаешь занимаются! У нас вон Илларион Валентиныч с 65 года наукой занимается и ничего! Не выебывается, преподает! Вот ваш учебный план, завтра встретить студентов (а дело в начале сентября) - и вперед и с песней!
Все правильно сказала, надо было еще ссаной шваброй вас разогнать по загривкам, чтобы дохуя о себе не думали.
Илларион Валентиныч, залогиньтесь.
Щенок! Наглец! Постыдился бы в такой день!
>А ты говоришь преподавать. К сожалению (а может и к счастью?) во всем что так или иначе связано с it ( причем не важно софт это или хард ) - в преподавание даже в госе идут по остаточному принципу. Т.е. те, кто даже в госе никому не нужны. Ну или аспиранты, но это тот редкий случай когда студентам везет и они не понимая своего счастья его проебывают. Но это крайне редко, хороших аспирантов тоже стараются к делу привлечь на полной основе.
Угу.
>И тут откуда не возьмись прибегает жирнющая бабень, то ли проректор по науке то ли его (ее) зам. И значит - пиздуйте студентов учить! Ишь! Сели, наукой понимаешь занимаются!
Это ткнз карьерист. Вузики, внезапно, полны ими. Страшное зло.
>Классы наследуют интерфейсы.
Только в делфи и плюсах, где вместо труЪ интерфейсов используются абстрактные классы.
>Интерфейсы не наследуют интерфейсы.
ВРЁТИ.
>Наследование интерфейсов интерфейсами бессмысленно чисто архитектурно.
>Это плохой дизайн.
Ну вот смотри, на рабочем столе показаны значки: каталог, значок программы, коробка с электронной почтой, помойное вядро... у них совпадает поведение но разная реализация.
Описать их поведение в виде дерева — самый что ни на есть обыкновенный (а не «плохой») дизайн. Реализацию их наследовать никто не заставляет.
+ ещё картинка в тему, далее Гугл надеюсь поможет.
Не понимаю тебя.
А в шарпе классы не наследуют интерфейсы?
О чем ты вообще.
>ВРЁТИ
О чем ты вообще.
>Ну вот смотри, на рабочем столе показаны значки: каталог, значок программы, коробка с электронной почтой, помойное вядро... у них совпадает поведение но разная реализация.
Одна у них реализация.
И разное поведение.
Ненужно котлеты с борщом путать.
>Описать их поведение в виде дерева — самый что ни на есть обыкновенный (а не «плохой») дизайн
WTF?
Если уже на то пошло, "значок" интерфейс, а "значок мои документы" конкретная реализация в классе.
Но какое нахуй дерево?
>Если уже на то пошло, "значок" интерфейс, а "значок мои документы" конкретная реализация в классе.
>
Т.е. у тебя можно вызывать Dispose у папки с почтой и Execute у корзины?
>А в шарпе классы не наследуют интерфейсы?
Нет, в жаббашарпах ключевое слово «implements» означает «класс ведёт себя в соответствии с интерфейсом».
>Одна у них реализация.
>И разное поведение.
На этот случай в современные я/п завезли дженерики:
ПомойноеВядро<Кукарек, Кококо> вэ = new ПомойноеВядро(большое);
>Если уже на то пошло, "значок" интерфейс, а "значок мои документы" конкретная реализация в классе.
Именно.
>Но какое нахуй дерево?
Я хочу, чтобы ещё и коробка с электронной почтой вела себя как значок и контейнер с чем-то, но её реализацию... напишет вообще другой кто-нибудь, не я.
>4.jpg
Забавная картинка, прямо таки мир глазами функциональщика: смешаны конкретные сущности и абстрактные понятия, захуячены в кольцо вокруг того, что на самом деле их в себя включает. Но зато все симметрично и красиво расставлено.
>идеальный язык
Нинужен. Небогоугодные жабоиндусы сейчас разрабатывают нанотехнологию конпелятора конпеляторов под любую грамматику. Про эффективность скомпилированого кода на произвольном языке говорят, что будет нативная. Кросязыковое взаимодействие тоже вроде как звезут.
Уже вроде есть референс генерейт-кмпиляторы грамматики пистона, паскаля, си и жабаскрипта и хз какие еще.
Сама иде мне нра, т.к. ее хотят бустнуть до использования даже средними умами, а свои языки будут уже идальными дслами.
>Нет, в жаббашарпах ключевое слово «implements» означает «класс ведёт себя в соответствии с интерфейсом».
1. В шарпе нет такого ключевого слова. Там двоеточие.
2. Ты зойчем к терминологии придерешься? Какая разница, наследует или реализует, как ты необзови козу козой она и останется.
>Я хочу, чтобы ещё и коробка с электронной почтой вела себя как значок и контейнер с чем-то
У тебя есть интерфейс значок.
Есть интерфейс контейнер.
Коробка наследует(имплементирует) значок и контейнер.
Все, никакого дерева.
Ты же какую-то ересть тут сочиняешь.
Иерархия интерфейсов такой же бред как и иерархия классов.
Ненужно через ООП пытаться описывать реальный мир. Нужно создавать адекватные программные сущности.
>Т.е. у тебя можно вызывать Dispose у папки с почтой и Execute у корзины?
Они отличаются иконкой, и исполняемой при двойном клике командой.
Наркоман.
Т.е. и контекстных меню у тебя нет и функционал ограничен двумя кликами.
>говорят, что будет нативная
Я в астрологическом календаре прочитал, что нынче луга в шизике, на полтора месяца.
И контекстным меню.
Тебе лишь бы приебаться?
Ну этот приеб и составляет разницу между реальностью где интерфейсы имеют наследование и твоим условным примером бесполезной системы без функционала.
>Ну этот приеб и составляет разницу между реальностью где интерфейсы имеют наследование и твоим условным примером бесполезной системы без функционала.
В реальности, никто не описывает ярлыки подобным ебнутым ООП.
Ты мне скажи, ты там торты не ешь часом?
>Какая разница, наследует или реализует, как ты необзови козу козой она и останется.
Из-за множественного наследования. Класс может имплементировать сколько угодно интерфейсов, но множественное наследование приводит вот к чему: в родительских классах могут совпадать названия методов, и какой из них передать наследнику, непонятно.
А теперь разберём по словам всё тобою написанное!
>Коробка наследует значок и контейнер.
Это множественное наследование, уже давно вместо него дженерики.
>Коробка имплементирует значок и контейнер
Это всегда пожалуйста.
>Как раз в наследовании интерфейсов, т.е. поведения, нет ничего плохого, это совершенно безопасно
Нужно не наследование, а операции как у множеств - объединение, пересечение. Наследование предполагает иерархическую структуру, а они очень плохо работают для упорядочивания сущностей.
>Из-за множественного наследования. Класс может имплементировать сколько угодно интерфейсов, но множественное наследование приводит вот к чему: в родительских классах могут совпадать названия методов
Множественное.
Наследование.
Интерфейсов.
Ты понимаешь, разницу, между наследование классов, и наследованием интерфейсов?
И
Н
Т
Е
Р
Ф
Е
Й
С
Ы
Нет, этот шизик слишком силен.
Ну его нахуй.
Эх, хотел бы я быть тобой. С годами приходится видеть самое разное дерьмо на эту тему, вот, одно из самых безобидных (правда малясь ебанутое, иерархия вывернута в фабрики):
https://docs.oracle.com/javase/7/docs/api/javax/swing/plaf/metal/MetalIconFactory.PaletteCloseIcon.html
А что в продуктах Addobe творится лучше и не знать. Так что пример как раз таки более чем жизненный.
Пацаны, ловите джявиста!!!
Если бы. Часто приходится писать под тот же Addobe на Си с классами (не C++, именно Си с классами, это там где "наследование" через вложенные структуры и оффсеты до полей, да). И это вполне себе OOP-way, как выражаются авторы. И не поспоришь: все основные постулаты учтены.
Так... с самого начала.
1) Наследование реализации (классов), грабли: хрупкий базовый класс.
2) Наследование поведения (интерфейсов), грабли: нет их, но некоторым пнмйш не нравятся описания в виде пнмйш дерева.
3) Множественное наследование реализации (классов), сразу грабли: совпадение имён методов и их параметров.
4) Имплементирование классом нескольких интерфейсов, грабли: нет их, макаки идут пнмйш по граблям — а граблей пнмйш не оказывается на месте.
И вот ещё чтоб не забыть:
5) Абстрактные классы: кое-кто упёрся и не захотел делать интерфейсы в своём C++.
6) Дженерики <Здесь, Всё, Что, Угодно> ну типа композиция.
7) RAII, DI: передаём объект в конструктор другого объекта, пока дженерики в Жаббу ещё не завезли.
8) Будет вам и 8 и 9 и так пока крышу не сорвёт вместе с головой.
Чем
Наследование классом интерфейса,
отличается от
имплементации классом интерфейса?
Очевидно тем что абстрактный класс не обязан этот интерфейс имплементировать.
>Наследование классом интерфейса
Есть только в языках, где авторы не хотели делать (или не сделали) интерфейсов, то есть в C++ и Delphi.
Не отличается от
>имплементации классом интерфейса
Ничем.
>3) сразу грабли: совпадение имён методов и их параметров
Это грабли только если нет дефолтного механизма разрешения конфликтов. В скале, например, он есть, и проблем как в С++ с множественным наследованием нет.
>4) Имплементирование классом нескольких интерфейсов, грабли: нет
За исключением того, что использовать ранее определенную реализацию можно только через композицию, то есть вручную прокидывать методы и строить заглушки.
>наследование = имплементация
>язык
>Delphi
-> /b/
>Очевидно тем что абстрактный класс не обязан этот интерфейс имплементировать.
Окей, разница существует только для абстрактных классов.
Нужно понимать, что полностью абстрактный класс и есть интерфейс, и вообще незачем их мешать вместе с интерфейсами.
И раз мы решили, что интерфейсы не должны наследовать другие интерфейсы, то и абстрактные классы не должны наследовать интерфейсы.
Предлагаю абстрактные классы запретить, как ересь.
Проблемы нет, наследование и имплантация теперь одно и то-же.
Иди проспись, походу сессия тебя добила.
>Это грабли только если нет дефолтного механизма разрешения конфликтов. В скале, например, он есть, и проблем как в С++ с множественным наследованием нет.
Создавать конфликты чтобы потом их автоматически разрешать?
Ох уж этот чудный джава мир.
>Ничем.
Ну вот и я о том-же.
Речь же изначально шла об этом.
Никаких абстрактных классов я не упоминал. Но нет, мейлачеры читают посты задом наперед и наискосок.
Научись читать посты, на которые ты отвечаешь.
>Создавать конфликты чтобы потом их автоматически разрешать?
Так неймспейсы работают в любом языке, например.
>Нужно понимать, что полностью абстрактный класс и есть интерфейс, и вообще незачем их мешать вместе с интерфейсами.
>Предлагаю абстрактные классы запретить, как ересь.
Баю-бай.
О! Улиточка!
Охуенно же.
У меня брат ожил.
Да, а по делу то можешь то что-то сказать.
Что не устраивает то?
в пхп это сделать нельзя, например
Полностью абстрактный класс не есть интерфейс.
Это разные инструменты служащие разным целям.
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
Ты говоришь походу слишком специфично относительно какой-то конкретной реализации.
А ну, как выглядят интерфейсы в С++?
>Но, собственно меня позабавило не это, а то что ты сначала приравнял интерфейсы и абстрактные классы, а затем их запретил
Мда, очень забавно.
>(неявно при этом запретив и интерфейсы).
Нет, неявно я ничего такого не делал.
У тебя проблемы с логикой, серьезные, сириусли. Ты додумываешь 90% содержания написанного.
Все просто и логично.
Раз полностью абстрактный класс и интерфейс дублирующие конструкции, то один явно лишний.
Да, они не совсем одно и то-же, давай разберем ассемблерный код еще по байтам.
Комон.
Я тебе по нескольку раз одно и то-же повторяю, а ты как будто не видишь буков вообще, что-то свое себе фантазируешь.
Речь идет о концепциях, абстракциях. Фирштейн?
>А ну, как выглядят интерфейсы в С++?
Никак, их там нет.
>Нет, неявно я ничего такого не делал.
A = B, delete B, use A
Ну да, проблемы с логикой определенно. Ну или с русским языком.
>Все просто и логично.
>Раз полностью абстрактный класс и интерфейс >дублирующие конструкции, то один явно >
>лишний.
>дублирующие конструкции
Это потому что ты так решил?
Да.
>A = B, delete B, use A
>Ну да, проблемы с логикой определенно. Ну или с русским языком.
Так что не так с логикой, поясни?
У тебя две одинаковых машины, продай одну, второй пользуйся.
У тебя две квартиры, сдавай одну, другой пользуйся.
У тебя два указателя на одну область память, забудь один, другим пользуйся.
У тебя два указателя, освободи память, oh shi!, да ты мыслишь диспозалами.
>У тебя две
>A = B
Все, я сдаюсь нахуй, это пиздец.
С тобой правда что-то не в порядке.
25 долларов в кармане А, равно 25 долларов в кармане Б?
Если я выну из кармана А 25 долларов, 25 долларов в кармане Б пропадут?
Равенство не означает зависимость.
У тебя правда правда справки нет?
>я сдаюсь нахуй
Не сдавайся этому продавцу тортов , борись, я верю в тебя!
мимо угорающий
Это не равенство, это присваивание. Какую богословскую семенарию заканчивали?
>справки
Кто о чем, а тортик - о наболевшем :3
Кулинарный техникум, очевидно же :3
Если 25 долларов - объект, то он пропадет из обоих карманов!!!
А если 25 - примитив - то только из одного.
А все почему? ПРАВИЛЬНО - МАГИЯ.
А если 25 - примитив - то только из одного.
А все почему? ПРАВИЛЬНО - МАГИЯ.
>ПРАВИЛЬНО - МАГИЯ.
И кулинария :3
>эти боевые картиночки
Ну что же ты, кулинар :3
ПОШЛИ ПОЖАРИМ ТВОЮ КАРТОШЕЧКУ.
Был у матери сын и звали его Сычинушка. Написала она у сычинушки на лбу Хуй и стало у нее два сына. И оба долбоебы.
>Если 25 долларов - объект, то он пропадет из обоих карманов!!!
А если это два объекта, да с переопределенным = и "==" ?
>ПОШЛИ
Никуда ходить не надо, здесь гори.
А В МОЕМ ЯЗЫКЕ НЕЛЬЗЯ ПЕРЕОПРЕДЕЛЯТЬ ОПЕРАЦИЮ #==, А #= КОПИРУЕТ УКАЗАТЕЛЬ НА ОБЪЕКТ. СОСИ СОСИСКУ
>да с переопределенным
Загон плюсобыдла тут
WTF
>WTF
Просто наслаждайся цирковым представлением.
мимо любитель тортолюбов
По теме еще в том треде все обсудили, теперь это филиал /b.
ПОЖАРИЛ ВОТ ЭТУ КАРТОШЕЧКУ. ИДУ СПАТЬ. НО СНАЧАЛА СИЛЬНОЕ ЗАЯВЛЕНИЕ
Абстрактные классы используются для выстраивания иерархии типов, тогда как интерфейсы не типизируются, они - не тип данных.
НО ПРОВЕРЯТЬ ЕГО Я КОНЕЧНО ЖЕ НЕ БУДУ .
Абстрактные классы используются для выстраивания иерархии типов, тогда как интерфейсы не типизируются, они - не тип данных.
НО ПРОВЕРЯТЬ ЕГО Я КОНЕЧНО ЖЕ НЕ БУДУ .
индусы привнесли в Микрософт такую замечательную вещь как кастовая система
помните, что Наделла ответил на вопрос "почему женщинам, выполняющим ту же работу так же, MS платит меньше?". он сказал, что главное - не то, как ты работаешь, а твоя карма.
то, насколько хороша твоя карма, определяется твоей кастой. про касту можно было бы вообще не заикаться, да вот только цвет кожи выдает ее с головой.
индусы до сих пор живут в кастовом обществе, касты не смешиваются между собой и более высшие касты имеют почти белую кожу, а низшие почти черную, как у африканцев. какого цвета Наделла?
несмотря на то, что индусов в MS около половины, я ни разу в MS не видел ни одного черного индуса в руководстве и ни одного белого программиста. а что поделать - карма.
Ни один программист никогда не сможет занять сколько-нибудь высокий пост в MS.
Наделла - это человек, который всю жизнь только руководил. Он не имеет ни малейшего представления о том, что такое программирование. Каста и карма не позволяют ему делать это. Он считает программистов в MS просто своими чернорабочими на плантациях, которым карма уготовила судьбу раба под его, наисветлейшего, руководством.
звучит дико? зато правда
(c) __kot2
ООП - это макропаттерн. Он эффективен в тех случаях, в которых есть разрозненные сущности, и вычислительные задачи можно интуитивно разделить между этими сущностями без пересечений.
Большинство задач таковы.
>ООП - это макаронаттерн.
Согласен.
Модули - это макропаттерн. Он эффективен в тех случаях, в которых есть разрозненные сущности, и вычислительные задачи можно интуитивно разделить между этими сущностями без пересечений.
Большинство задач таковы.
Ты хочешь поразить меня тем, что объекты - это модули?
Только более удобные в использовании, т.к. в объекте удобней хранить состояние, нежели в переменных или замыканиях. Ну и плюс интерфейсы, инкапсуляция, наследование. Вскукареки про "можно и без ООП" идут нахуй, т.к. с ООП это удобней, ваши проблемы что не осилили.
Плюс к тому:
- модуль может быть только один, а обхектов - сколько угодно
- либо следить за разделением вычислений с помощью объектов удобнее, либо я что-то не знаю о процедурщине, которая даёт такой же декларативный контроль
Но ты мне всю малину испортил, надо сначала заманить поциента, а потом уже обработать по-полной.
МАМ МАМ! СМОТРИ! Я ТРАЛЛЮ ДВАЧ!
Молодец, а теперь чистить зубы и спать.
Нихочу. А вдруг кто-то клюнет! Надо заманить, и выжидать.
>Только более удобные в использовании
Схуяли? Модуль всегда доступен по имени, в любой точке программы. Чтобы использовать объект надо прокидывать ссылку на него, пердолиться с хранением, владением, временем жизни.
>можно интуитивно разделить между этими сущностями
Ну да, ведь у программиста, дар предвидения как у бабы Ванги, а заказчик никогда не требует вот тут вот подмандить поперек ТЗ.
Маня, ещё раз ООП - это первоклассные объекты. Это необходимое и достаточное определение. Остальное - это хуйня от тех или других видов сектантов.
>ООП - это модули как первоклассные объекты.
Маня, ещё раз, ООП - это объектно-ориентированное программирование. Это необходимое и достаточное определение. Остальное - это хуйня от тех или других видов сектантов.
>ООП - это ООП
Блестящее выступление. А теперь - обратно под шконарь.
А ФП - функциональное программирование! Как я тебя отчебуерчил!!! По-сути возразить не сможешь, даже не пытайся.
Ага, и отличается ООП от всего остального тем, что оно объектно ориентированно.
В прошлом треде функционало-петушки жаловались, мол в реальном мирке плохо - стейты нужны. А где стейты, там один шаг до ориентированности, этой, объектной. Так что ООП ничем от ФП не отличается, те же яйца, только в профиль.
Во, пошла жара помаленьку. Совсем уже разленились, даже холивар начать без батькиного потсрачника не могут.
>Даже преподы ООП в вузах.
Проиграл с препода ООП.
>Помню свою курсовую по ООП.
>Игра "жизнь", тема была.
>Это ебанный стыд, когда все эти "сущности" в классы определяешь.
>Но самое чудесное, это, РЕКУРСИВНЫЕ ЗАВИСИМОСТИ.
Маловато информации для восстановления событий. Во-первых, что такое "рекурсивные зависимости"? Я такого понятия в ООП что-то не припомню, дай определение или пример, плиз, что ты под этим понимаешь. Во-вторых, не нужно насильно пытаться натянуть ООП на задачу, которая вполне элегантно решается парой циклов; хотя именно для обучения такое бывает полезно - как раз, чтобы понять, что первая итерация ООА, в которой мы берем в качестве абстракций объекты из ололо-реального мира, чаще всего не является последней, и закончить мы можем совсем с другими абстракциями.
>От которых препод бугуртил не меньше меня.
Скорее всего он просто был некомпетентен в преподаваемом предмете. Такое в российских вузах сплошь и рядом. А может, ты его просто заебал своей тупостью и принял это за бугурт по ООП.
>Даже преподы ООП в вузах.
Проиграл с препода ООП.
>Помню свою курсовую по ООП.
>Игра "жизнь", тема была.
>Это ебанный стыд, когда все эти "сущности" в классы определяешь.
>Но самое чудесное, это, РЕКУРСИВНЫЕ ЗАВИСИМОСТИ.
Маловато информации для восстановления событий. Во-первых, что такое "рекурсивные зависимости"? Я такого понятия в ООП что-то не припомню, дай определение или пример, плиз, что ты под этим понимаешь. Во-вторых, не нужно насильно пытаться натянуть ООП на задачу, которая вполне элегантно решается парой циклов; хотя именно для обучения такое бывает полезно - как раз, чтобы понять, что первая итерация ООА, в которой мы берем в качестве абстракций объекты из ололо-реального мира, чаще всего не является последней, и закончить мы можем совсем с другими абстракциями.
>От которых препод бугуртил не меньше меня.
Скорее всего он просто был некомпетентен в преподаваемом предмете. Такое в российских вузах сплошь и рядом. А может, ты его просто заебал своей тупостью и принял это за бугурт по ООП.
Эй слыш, Отвечай, на мой ответ!1!!1!1!
>Расскажи, какими уникальными свойствами обладает раст и что делает его сбалансированным.
Не готов пока прям по пунктам ответить, так как пока еще не напейсал на нём ничего существенного, изучение продвигается медленно - работы много. Пока что это больше на уровне интуиции, которая за 20+ да, я седомудый дед-пердед лет коммерческого погроммирования у меня изрядно прокачалась.
>Потому как замыкания, рекурсия - вот это функциональное говно, есть едва-ли во всех мультипарадигменных ЯП.
В большинстве случаев они представляют собой туалетные бумажки для локальных набросков, а не инструмент структурирования. Ну тип незачем сразу бежать создавать класс для какого-нибудь листенера, когда можно захуярить по-быстрому замыкание или анонимный класс. Все эти анонимные абстракции неплохо работают только тогда, когда не забывают все-таки выделять из них нормальные абстракции по мере развития. Я вот в прошлом треде еще выступал за человеческий язык как зеркало чистоты кода, а когда нет языка - начинается хуйня. Школотроны и хипсторы внезапно как раз вот эти промокашки и ценят в ФП. Дескать, если мы соорудили-таки нашу злоебучую абстрактную фабрику неведомых фасолин, но не обозвали ее позорным именем, а тактично промолчали - то все сразу стало кошерненько. Ага, хуй там ночевал.
>Мне вот с коррутинов и многопоточности иногда бомбит, т.е. ООП, конечно же прекрасен, но там где надо в парралельные вычисления, там запутанные состояния объектов мешают.
Именно. Плюс в Rust меня цепляет революционная, прямо скажем, модель очистки памяти, сильный вывод типов и модель владения-одалживания данных. Ну и ООП там любопытно реализовано, настраивает на хорошие практики.
А, ну и ZERO COST ABSTRACTIONS, куда ж без них. В общем, многое из того, от чего меня выворачивало в крестах, там элиминировано.
>Маловато информации для восстановления событий.
Все так и задумывалось.
Да и не помню я подробностей, это в 2008 было.
>Во-вторых, не нужно насильно пытаться натянуть ООП на задачу, которая вполне элегантно решается парой циклов;
Именно.
>что первая итерация ООА, в которой мы берем в качестве абстракций объекты из ололо-реального мира, чаще всего не является последней
В последствии она обрастает макаронами туго запутывающимся в узел.
Если первоначальный дизайн плохой, ничего уже не поможет.
>Скорее всего он просто был некомпетентен в преподаваемом предмете. Такое в российских вузах сплошь и рядом. А может, ты его просто заебал своей тупостью и принял это за бугурт по ООП.
Ты наверное представляешь препода который так с огнем из попки - ФУУУУУ КЛЯТЫЙ ОООП БЛЯ НЕНАВИЖУ СУКА(разбивает комптуер).
А в реальности, было что-то вроде: "не нужно насильно пытаться натянуть ООП на задачу, которая вполне элегантно решается парой циклов".
>Rust
Я так и не понял, там корутины есть, хоть в виде библиотеки, или нет.
>Если первоначальный дизайн плохой, ничего уже не поможет.
Вот это утверждение в корне неверно. Для любого откровенно неидеального дизайна существует некий достаточно маленький, чтобы легко поместиться в голове, шаг, приближающий код к более хорошему дизайну. К сожалению, этим искусством овладеть довольно трудно.
>>Rust
>Я так и не понял, там корутины есть, хоть в виде библиотеки, или нет.
Сперва были, потом выпилили в пользу нативных тредов, теперь вроде есть в токио и аналогичных либах, но я с ними еще не возился.
Да, и что ты подразумевал под РЕКУРСИВНЫМИ ЗАВИСИМОСТЯМИ?
>Вот это утверждение в корне неверно. Для любого откровенно неидеального дизайна существует некий достаточно маленький, чтобы легко поместиться в голове, шаг, приближающий код к более хорошему дизайну. К сожалению, этим искусством овладеть довольно трудно.
Ну, с кажем так, если это искусство, и им еще и трудно овладеть, то утверждение большей частью верно.
И, маленький шаг немножко приближающий код - это хорошо конечно.
Но когда между исходной точкой, и нормальным дизайном лежит бесконечность, бессмысленный.
Ты можешь только уменьшить боль, теми или иными приемами.
>Ну, с кажем так, если это искусство, и им еще и трудно овладеть, то утверждение большей частью верно.
Погромирование - это внезапно СЛОЖНА. Им трудно овладеть зато оно тобой легко овладеет, и не раз.
>И, маленький шаг немножко приближающий код - это хорошо конечно.
>Но когда между исходной точкой, и нормальным дизайном лежит бесконечность, бессмысленный.
Здесь ошибка. Очень часто молодые-шутливые погромисты думают ОЙ ВСЁ, ЖГИ, Г-ДЬ, ЗДЕСЬ УЖЕ НИЧЕГО НЕ ИСПРАВИТЬ - и варят вторую кастрюлю макарон рядом с первой. Это неэффективно. Без совершения вот этих маленьких шажков не будет достаточной для редизайна ясности, кроме того, без полученного в результате вымучивания этих шажков опыта (в том числе и отрицательного) раз за разом будут получаться одни и те же макароны, только по-разному завязанные.
> … Машка готовит охуенные борщи…
> … Борщи с майонезом? …
> Не готов пока ответить, но жопа у неё цепляет - революционная, да и в других местах; там любопытно реализовано, настраивает на хорошие практики.
Я тебя понял, анончик. Ты просто влюбился, но Машкин борщец пока не хлебал, поэтому в теме о супах пояснить за него не можешь. Даже несмотря на то, что сам - тот еще борщеед, да и вообще - кулинар.
>Погромирование - это внезапно СЛОЖНА.
->
>Здесь ошибка. Очень часто молодые-шутливые погромисты
Слишком глубоко копаешь.
>Без совершения вот этих маленьких шажков не будет достаточной для редизайна ясности, кроме того, без полученного в результате вымучивания этих шажков опыта
Двачую мудреца.
Есть некотрая тенденция бросать проекты и начинать их заново, когда в коде случается архитектурно-костыльный пиздец.
Это не правильно, т.к. не дает никакого реального опыта разруливания сложного кода. Этот опыт очень ценен на больших проектах, так как нельзя просто взять и переписать большой и сложный проект с нуля, а значит тренероватьна в поедании кактуса плохого кода нужно на маленьких проектах и не впадая в истерику ГОСПОДЬ ЖГИ.
Да, именно так. Очень точно описаны мои отношения с растом.
>Схуяли? Модуль всегда доступен по имени, в любой точке программы.
А оно так прямо надо?
Конечно же нет, ведь можно в уютненькой иксемелечке напрограммировать IoCи и всё что нужно будет доступно там где нужно. Такое вот бегство ООП в ООП-мирке.
>чтобы было дешево, быстро и поддерживалось десятилетиями
Следовательно ООП - это идеально
/thread
>Схуяли? Модуль всегда доступен по имени, в любой точке программы.
И это хуевый дизайн когда подгруженные модули срут в глобал неймспейс, а решается это _исключительно_ через натягивание трусов через голову.
Хмлы с иокамми, это сорт оф конфиг. Бегут не от ооп , а от перекомпиляции проекта.
Хуиг. Смысл ООП в построении систем из объектов. Индусня вместо того, чтобы инжектить всё средствами своего ОО-язычка опускается до программирования на иксемеле.
Разруливается обычными областями видимости.
> Разруливается обычными областями видимости.
На пятом уровне вложенности это 8 лишних строк кода на файл, и + 4 уровня табуляции. У меня классы и то меньше, кек (это сарказм)
Зачем это на llvm писать хэллоуворды?
Размышляя над твоим постом промелькнула мысль что ООП родилось из желания бить сущности на модули, а потом получать доступ к функциям из вложенных модулей через точку.
moduleA.ModuleB.Fun1
moduleA.moduleB.moduleC.FunX
Если мыслить так то ООП оно везде есть.
2. Да в целом да, наверно.
>3. При умелом использовании (то есть с учётом всех основных подводных камней) ООП является довольно эффективной техникой структурирования кода.
Вот тут в точку. Особенно если смотреть на него с точки зрения модулей.
>Поиск продолжается, в частности, мне чрезвычайно импонирует Rust как довольно сбалансированный сплав ООП и ФП.
Таки просто разучиваешь основные идеи, синтезируешь в голове общую концепцию из самого годного, а потом просто используешь эту концепцию в любом языке. Берешь естественно подходящий.
Это типа как обучаясь обращаться с различным (холодным) оружием постепенно в сознании вырисовывается какая то общая суть проявляющаяся в обращении с каждым из них. Потом эта суть используется в обращении с каждым следующим параллельно взращиваясь и развиваясь при этом.
И затем ты пишешь на любом языке, но ни каком конкретном из них. Ты просто воплощаешь ту общую суть всех в конкретную форму форму текущего.
И серебряная пуля это именно взращивание собственного понимания сути используемых и использованных когда то в разных языках идей, а не поиск какого то одного ультимативного.
Разрабатывайте анус мышление, короче.
ну я понимаю пригораниа джава макакменя,там только ООП и фабрика не синглтоне,но всяким питонам и прочей мульипарадигме то хули не нравится?
Не осилили.
>что ООП родилось из желания бить сущности на модули, а потом получать доступ к функциям из вложенных модулей через точку
Различные способы структурирования программ раздаются из необходимости строить сложные системы. Сложные - это такие, что полностью уложить в голове все нюансы работы программы в отдельный момент времени невозможно. По большому счету человечество на данный момент придумало только один способ борьбы со сложностью задач: дробить их на набор менее сложных и решать по отдельности. В случае программирования это делается посредством выделения абстракций, ООП - один из способов выделять абстракции.
Упомянутое тобой "выделение модулей", собственно, мало что даёт в этом смысле. Обращение через точку - это просто сахарок, точно так же можно было бы передать некие данные в виде набора аргументов в функцию.
Основная задача ООП - обеспечить полиморфизм через организацию иерархии типов. Из этого уже произрастают все остальные свойства и возможности ООП, и именно это делает возможной инверсию управления - один из самых мощных механизмов ООП.
не осилили "что"? Там же все элементарно. Вообще, ни разу не видел нормального яп с мощным ооп , как в java/ruby/c#но в шарпе я не шарю и одновременно полным по функциональной парадигме. Везде либо все уровня хачкеля или лиспа,либо кастрированный функциональный яп,как в петухоне и жабе 8+
В шарпе ООП обрезан по самые яйца.
>яп с мощным ооп
С++
>ни разу не видел нормального яп с мощным ооп и одновременно полным по функциональной парадигме
посмотри Scala
я не кодил на крестах,слышал,что там вроде наоборот,все очень криво. Хотя я скорее поверю в то,что у двачера синдром утенка,чем в то, что на крестах что то может быть не полным и мощным
>нормального яп с мощным ооп
А в чем измеряется МОЩНОСТЬ ООП, каковы критерии?
>С++
Ну не траль, плес.
>Ну не траль, плес.
В С++ самая полная реализация ООП из всех что я видел.
Если знаешь более полную, молви.
>я не кодил на крестах,слышал,что там вроде наоборот,все очень криво.
Не криво точно.
>самая полная реализация ООП
Не успели мы измерить мощность ООП, как у нас появился новый критерий - ПОЛНОТА РЕАЛИЗАЦИИ ООП. Там у гоферов часом тредик не прорвало? В наши времена именно они чаще других разговаривают лозунгами или оперируют выводами из определений, которых никто и никогда не давал.
>И затем ты пишешь на любом языке, но ни каком конкретном из них.
Каждый программист в течение своей жизни непеременно проебывает некоторое время в этом сладостном заблуждении. Увы, языки диктуют свои правила порождения обстракций, и нарушать эти правила можно лишь с большой осторожностью. Ссать против ветра не очень-то эффективно, если мы не ставим конечной целью быть обоссанным с ног до головы, конечно же. Цель чаще всего прямо противоположная.
>должны быть средства для его создания в библиотеках; библиотеки как раз и должны быть его источником
Ну охуеть теперь, после такого количество этих самых библиотек будет в 9000к раз больше количества соврменных языков и фреймворков т.к. каждый пограмист сочтет своим долгом захуячить что-то свое.
Ну не, гоферы - как раз те кто убежал от C++-like ООП, кому интерфейсы милее классов с их наследованием. Как бы я ни относился к го, но то что там нету наследования по-моему совершенно правильно.
Я может быть с тобой согласен, а может быть и нет.
Но у меня в голове сейчас крутится одна единственная идея которая как то не здорово оттягивает внимание на себя.
Ща попытаюсь провести вас по ней:
https://habrahabr.ru/company/hexlet/blog/303754/
>Удивительно, но его мысл про ООП ограничивались этим:
>>ООП для меня это сообщения, локальное удержание и защита, скрытие состояния и позднее связывание всего. Это можно сделать в Smalltalk и в LISP.
>И ничего про наследование. Это не тот ООП, который мы знаем сегодня:
>>Мне жаль, что давным давно я использовал термин «объект» для этой темы, потому что из-за этого многие люди фокусируются на меньшей из идей.
>Большая идея, которой не хватает современным статически-типизированным ОО-языкам:
>>Большая идея это «сообщения»
>Он считает, что нужно фокусироваться на сообщениях, слабой связи и взаимодействии модулей, а не на внутренностях объекта:
>>Ключ к созданию хороших масштабируемых систем это проработка механизмов общения модулей, а не проработка их внутренних свойств и поведения.
Берем Кеевскую идею о сообщениях, потом немного заглядываем в будущее и учитываем то что когда нибудь придется писать под 20+ ядерные процессоры повсеместно. Из-за чего разумным требованием становится нативное и легкое использования многоядерных систем, даже не через либы, а что б прям в в самом ядре языка было запилено.
Вспоминаем про Го:
Канал имеет две основные операции, отправлениеи получение, вместе известные
как коммуникации (communications). Инструкция отправления передает через канал
значение из одной go-подпрограммы другой, выполняющей соответствующее вы
ражение получения. Обе операции записываются с использованием оператора <-. В
инструкции отправления <- разделяет канал и значение. В выражении получения <-
предшествует операнду канала. Выражение получения, результат которого не исполь
зуется, является корректной инструкцией.
ch <- х // Инструкция отправления
х = <-ch // Выражение получения в инструкции присваивания
<-ch // Инструкция получения; результат не используется
Уже подходит под то что нам надо. Оно с буфером бывает и без. Без - синхронное, а с ним уже нет.
Вот тут уже ближе к Кеевскому ООП, пинаем сообщение в канал, в канале сидит объект и что то с ним делает.
Но некоторые парни пошли еще дальше и запилили конструкцию вида:
IO <- obj1 <- obj2 <- obj3 <- ... objN <- message
Похоже уже и на ФП и на ООП.
Но парни пошли дальше, они отпилили состояние у этих объектов, добавили ленивость что бы наши "сообщения" обрабатывались по одному и получили тот самый хаскелл.
fun = f1 f2 f3 [1,2,3,...]
Который вместо того что бы кушать то что подают на входе целиком берет и откусывает по одному кусочку. Я вот тут долго не мог осмыслить в чем же соль то. Но потом как то резко дошло что хаскелл это язык для потоковой обработки данных. Целью которого является точно тоже самое что и у эрланга - пропускать через себя потоки данных. Но только что б еще статика была, а не динамика. С такой точки зрения вместо классической "пишем монолит" этот язык понимается довольно легко. Язык где это сразу видно это эрланг, где почти сразу - Го.
И вот мне кажется что такие языки "пропускающие" через себя кусочки данных и являются чем то наиболее близким к Кеевскому ООП. Только надо воспринимать там все не как функции или объекты, а как элементы цепи обработчиков потоков данных. Этакий конвейер на входе в который подаются какие то данные, потом это все идет потоком через различные узкоспециализированные машины которые их преобразуют и на выходе уже получают что-то.
https://www.youtube.com/watch?v=GyodDV-291g
-------
А сейчас я подумал что возможно иметь какой либо стейт в языках это вообще ошибка. Т.е. он нужен конечно, но он должен быть вынесен куда то. Ну из реальных примеров это SQL и базы данных, где сам язык только дергает или добавляет что то откуда то и куда то. А как раз таки неизменяемые часто используемые данные должны быть забиты в константы.
Ну вот используя то что выше в абзаце написано, можно теперь будет везде использовать цепочки обработчиков и хранилища данных разбивая это имеющимися средствами языка. Ну типа одни классы только хранят что-то, другие только обрабатывают и т.д. А писать что-то что совершенно противоестественно данному конкретному языку конечно не нужно. Используем те абстракции которые есть, но по своему немного.
Речь не о самом Go (язык как язык, довольно удачный местами). Просто Google довольно большие силы вбухал в продвижение языка, в том числе при помощи множества заявлений в духе "учение Маркса правильно, потому что оно верно". У меня на работе есть, к примеру, коллега, довольно сильный программист, но попал под эти сектантские напевы и покатился под откос, потому что внезапно ПЕРЕНЯЛ у гуглячьих маркетологов искусство доказательства хуйни через хуйню и теперь применяет его в технических дискуссиях (где его обычно совместными усилиями удается вытащить за шкирку из выгребной ямы) и, что хуже, в собственных решениях (а вот тут уже вытаскивать некому, утрата критического мышления по отношению к собственному творчеству невосполнима).
>И вот мне кажется что такие языки "пропускающие" через себя кусочки данных и являются чем то наиболее близким к Кеевскому ООП.
NIET. Задача обработки потока данных отлично ложится на абстракции ФП, это ты верно подметил, но вот кеевские сообщения тут ни при чем. Их идея не в асинхронности (этот фактор рапрекрасно завяжет в узел как крестоподобные, так и кеевские объекты), а в изоляции и виртуализации получателя.
Освоить два десятка правил - элементарно. Научиться думать - нихуя не элементарно. Было бы ФП мейнстримом - они бы и его "хейтили".
Если положить ленивость на сообщения то получатся методы классов. Круг замкнулся.
>OOD, Буч, GOF, POOD, SOLID - это лажа все, братан.
Предложу свою классификацию профессионального развития программиста:
1. Программист хайпозависимый. Это самая первая ступень. Такой программист не имеет достаточного опыта, чтобы сформировать собственное мнение, он просто пересказывает рекламные брошюры производителей товара. Лет 10 на рынке доминировало ООП, поэтому почти все хайпозависимые являются ООП-шникамми. Типичный хайпозависимый пишет на Ждаве или Питоне, некоторые экземпляры, желающие быть нетакимикаквсе выбирают Раст, Эрланг или Руби. Стоит заметить, что сейчас треднды активно меняются, поэтому вы легко сможете встретить хайпозависимого скалиста, который будет вам цитировать рекламный булшит от авторов Акки, но быстро сольётся, если вы попросите его привести примеры реальных юзкейсов, в которых ему помогла акторная модель.
2. Программист просветленный. Тут слово "просветленный" следовало бы взать в кавычки. Просветленный - это хайпозависимый, который внезапно для себя открыл альтернативную технологию. Например, ООП-шник, внезапно изучивший Хаскель. Обычно такой шаг сопровождается жестким разрывом шаблона, вызванным тем, что куча вселенских проблем захайпованного говна, для решения которых просветленный годами изучал монструозные фреймворки и штудировал тонны макулатуры, в альтернативной парадигме попросту не существует. Само собой разумеется, просветленный начинает думать, что его наябывали, а теперь-то он познал истину. Типичный просветленный пишет на упомянутом Хаскеле, но только дома и только парсеры монадных комбинаторов, на работе он продолжает хуярить на каком-нибудь сишарпе. Просветленный считает себя носителем скрываемой от остальных истины, он создаёт треды про то, как ООП сосёт, про то, что OOD, Буч, GOF - говно и легко детектится по кеч-фразам вроде "говно++" (ну да, С++ - действительно ужасный язык, я его не люблю, но просветлённый будет вам доказывать, что С++ - это вообще причина всех бед современной IT индустрии).
3. Программист мудрый. Как правило, программист мудрый уже прошел путь "просветления", он знает доминирующие парадигмы и имеет опыт применения их на практике, знает их достоинства и недостатки. Программист мудрый никогда не скажет вам, на каких языках программирования он пишет, ведь он владеет любыми, для него все эти различия как-то стираются. Тем не менее, у программиста мудрого есть любимые языки. Ему может нравится Хаскель, но при этом мудрый будет допиливать рантайм на С++, для мудрого это не западло. На работе мудрый будет поддерживать ту же Скалу, ведь мудрый понимает, что невозможно взять и всей индустрией разом перепрыгнуть с ООП на ФП, есть объектиные факторы, и мудрый будет предпринимать конкретные шаги для продвижения. Программист мудрый прекрасно понимает, что OOD, Буч, GOF, POOD, SOLID - это нихуя не лажа, это очень правильные практики, через которые все должны пройти, это не наёбка, а этапы взросления. И если у мудрого появляется чувак (а, как правило, мудрый - это не сам-себе-кодер, а лидер команды) который пищет хуйню даже по меркам Буча, мудрый посылает его практики Буча изучать, ведь в перечисленных практиках нет плохого ровным счетом нихуя, есть только отрицание программиста просветленного.
Что-то вспомнилась классификация программистов то-ли из журнала "наука и жизнь", то-ли "химия и жизнь", советского само собой.
Запахло сразу застоявшимся министерским воздухом.
Эта классификацию плюс-минус к любому знанию относится. Сперва недостаток знаний вынуждает полагаться на авторитетов, со всей сопустствующей рационализацией, потом начинается этап ниспровержения авторитетов на основе собственного ограниченного опыта, потом начинается этап признания таки правоты авторитетов с рядом неочевидных оговорок.
Это тут записывают в коспомолитов, свободных от парадигм?
А эвенты с танцеванием хороводов со вчерашними ООПистами, Функциональщиками и даже Процедурщиками проводятся?
А эвенты с танцеванием хороводов со вчерашними ООПистами, Функциональщиками и даже Процедурщиками проводятся?
>И если у мудрого появляется чувак
Да, раздевайся.
Фундаментальная ошибка местной студентоты и джуниоров, рассуждающих о ненужности лямбд и т.п., в том,
что они пытаются рассуждать о языках программирования практически не имея никакого опыта разработки.
Написавшим свой первый тетрис, калькулятор и теперь вооон тот отчет для Клавдии Ильиничны за 35 тысяч рублей в месяц,
им всё кажется новым и интересным, даже какашки в песочнице, а синдром утёнка заставляет их думать, что первый язык,
за программирование на котором им дали первые деньги на карманные расходы, и есть самый лучший, самый мощный и самый правильный, а все, кто не с нами - те глупее нас.
Психология опытного разработчика устроена иначе. После нескольких лет работы он знает свой инструмент от и до,
не находит в нём ничего нового, и все свои задачи он знает от и до. Причем задачи для него становятся похожими друг на друга как две капли воды,
ведь процесс познания заключается в изучении множества частных случаев с последующим абстрагированием и выведением общих закономерностей.
В конце концов какая разница, нужно ли мне зипануть два списка, собрать результаты работы двух парсеров или посчитать сумму двух сигналов:
для опытного разработчика всё это - map apply на аппликативных функторах.
Вот тут и начинается самое интересное: с одной стороны язык для опытного разработчика больше не является предметом фапа и изучения,
единственное требование к нему - возможность записать программу в категориях, максимально близким к тем, которыми он мыслит.
С другой - мышление опытного разработчика гораздо более абстрактно и высокоуровнево, чем мышление джуниора, следовательно,
язык должен иметь средства выражения этих абстракций. В этот момент многие разработчики перерастают свой инструмент.
Более удачливые переходят на другой, более развитый. Менее удачливые, у которых нет такой возможности, вообще перестают программировать,
аргументируя это тем, что программирование - тупое, однообразное занятие, и становятся аналитиками или архитекторами
(т.е. фактически тоже меняют инструмент - убогий негибкий язык программирования на гибкий и удобный документ microsoft word).
Восторга джуниоров ни те ни другие как правило не разделяют, просто первые говорят, что LANG_A - убогое говно,
а LANG_B - крутой инструмент для опытных программистов, а вторые говорят, что LANG_A - это нормальный инструмент для подчинённых им обезьянок,
а применения для LANG_B они не видят, поскольку ни они сами, ни их обезьянки этим инструментом не владеют.
И последний вопрос - что же происходит, если LANG_B попадает в руки джуниора? А ничего не происходит,
потому что он просто еще не понимает назначение всех этих абстракций и в лучшем случае программирует на LANG_B как на LANG_A
(обычно более мощные языки позволяют писать на них как на менее мощных, обратное неверно). Я сам неоднократно встречал студентов,
изучавших lisp и prolog в университете (да, сейчас это норма, в моё время никаких лиспов в росийских университетов не было) и совершенно не понимающих,
к чему все эти знания. Какого же было их удивление, когда я показывал им как то, чему их пытались учить, применяется на практике,
как это позволяет делать более грамотную декомпозицию программы, писать более сопровождаемый код,
где лежат пределы выразительности используемого нами языка и как программу можно было бы записать если бы язык был более выразителен.
что они пытаются рассуждать о языках программирования практически не имея никакого опыта разработки.
Написавшим свой первый тетрис, калькулятор и теперь вооон тот отчет для Клавдии Ильиничны за 35 тысяч рублей в месяц,
им всё кажется новым и интересным, даже какашки в песочнице, а синдром утёнка заставляет их думать, что первый язык,
за программирование на котором им дали первые деньги на карманные расходы, и есть самый лучший, самый мощный и самый правильный, а все, кто не с нами - те глупее нас.
Психология опытного разработчика устроена иначе. После нескольких лет работы он знает свой инструмент от и до,
не находит в нём ничего нового, и все свои задачи он знает от и до. Причем задачи для него становятся похожими друг на друга как две капли воды,
ведь процесс познания заключается в изучении множества частных случаев с последующим абстрагированием и выведением общих закономерностей.
В конце концов какая разница, нужно ли мне зипануть два списка, собрать результаты работы двух парсеров или посчитать сумму двух сигналов:
для опытного разработчика всё это - map apply на аппликативных функторах.
Вот тут и начинается самое интересное: с одной стороны язык для опытного разработчика больше не является предметом фапа и изучения,
единственное требование к нему - возможность записать программу в категориях, максимально близким к тем, которыми он мыслит.
С другой - мышление опытного разработчика гораздо более абстрактно и высокоуровнево, чем мышление джуниора, следовательно,
язык должен иметь средства выражения этих абстракций. В этот момент многие разработчики перерастают свой инструмент.
Более удачливые переходят на другой, более развитый. Менее удачливые, у которых нет такой возможности, вообще перестают программировать,
аргументируя это тем, что программирование - тупое, однообразное занятие, и становятся аналитиками или архитекторами
(т.е. фактически тоже меняют инструмент - убогий негибкий язык программирования на гибкий и удобный документ microsoft word).
Восторга джуниоров ни те ни другие как правило не разделяют, просто первые говорят, что LANG_A - убогое говно,
а LANG_B - крутой инструмент для опытных программистов, а вторые говорят, что LANG_A - это нормальный инструмент для подчинённых им обезьянок,
а применения для LANG_B они не видят, поскольку ни они сами, ни их обезьянки этим инструментом не владеют.
И последний вопрос - что же происходит, если LANG_B попадает в руки джуниора? А ничего не происходит,
потому что он просто еще не понимает назначение всех этих абстракций и в лучшем случае программирует на LANG_B как на LANG_A
(обычно более мощные языки позволяют писать на них как на менее мощных, обратное неверно). Я сам неоднократно встречал студентов,
изучавших lisp и prolog в университете (да, сейчас это норма, в моё время никаких лиспов в росийских университетов не было) и совершенно не понимающих,
к чему все эти знания. Какого же было их удивление, когда я показывал им как то, чему их пытались учить, применяется на практике,
как это позволяет делать более грамотную декомпозицию программы, писать более сопровождаемый код,
где лежат пределы выразительности используемого нами языка и как программу можно было бы записать если бы язык был более выразителен.
>Психология опытного разработчика устроена иначе. После нескольких лет работы он знает свой инструмент от и до, не находит в нём ничего нового, и все свои задачи он знает от и до. Причем задачи для него становятся похожими друг на друга как две капли воды
Это про унылых крудошлепов и фронтэндщиков. Кем, в общем-то, и являются все эти хаскель-тролли (не говоря уже о лисперах).
Что тут у нас? Бородатые хипстеры на гироскутерах не осилили SOLID к собесу?
Все сливные бачки за сегодня уже автоматизировал, инженер?
>SOLID
>не осилили
SOLID - это гумманитарный пиздёж, как и вообще вся литература около ООП. Что там можно не осилить, пять ёбаных правил уровня народных примет и сказаний? Вся эта хуня нужна было только для того, чтоб Мартины Фаулеры и Стивы Макконелы подняли деньжат на свое писанине.
> рррряяяя ненужно!!!
иди смузи пить
SOLID - в своих кейсах решает поставленные задачи, чего нельзя сказать о DRY - принципе разработке, призывающим не писать код ради кода - но тогда интерфейсы оказываются избыточными и ненужными, что очевидно ведет к потере гибкости в выборе инструмента.
>Это тут записывают в коспомолитов, свободных от парадигм?
Это разновидность второй стадии вот отсюда или отсюда .
Собеседование в люксофт прошел?
> В этот момент многие разработчики перерастают свой инструмент.
>Более удачливые переходят на другой, более развитый. Менее удачливые, у которых нет такой возможности,
Это что-же за область такая где реально существует более одного продаваемого мейнстримного языка чтобы можно было сказать что A > B? Ты к нам не из фронтенда, случаем, аппликативно-функторное чудо?
Ну, причем или нет оно уже не очень важно как то. Я уже оттолкнулся от эт его идеи и перешагнул ее.
Я когда о всем этом размышляю держу в голове будущую необходимость повсеместного программирования под 20-30 ядер и больше. Сразу как то понятнее становится какой подход имеет будущее, а какой нет.
Дык суть в том что бы иметь некие обработчики данных которые можно легко комбинировать цепочками и запускать параллельно. Это могут быть и "чистые" объекты которые просто обрабатывают но ничего не хранят, это могут быть чистые функции, "чистые" акторы и вообще все что угодно подобное.
Ну и где то там сбоку хралища данных которые тоже могут быть реализованы через что угодно лишь бы суть сохранялась.
Вообще без разницы на чем это реализовывать, лишь бы был необходимый минимум инструментов.
>Круг замкнулся.
>лишь бы был необходимый минимум инструментов
Так ФП и дает тебе этот необходимый минимум, твори, пердолься с акторами в функтор, то ж тебе не дает? Только вот в большинстве случаев избавляться от состояний неоправданно сложно; а ведь мы еще помним про то, что вообща вся эта песня с выделением абстракций затеяна с противоположной целью, верно?
>Я уже оттолкнулся от эт его идеи и перешагнул ее
О, да у нас тут НИСПРОВЕРГАТЕЛЬ АВТОРИТЕТОВ. Мамку свою ты пока что перешагнул в лучшем случае.
>3. Программист мудрый.
>Тем не менее, у программиста мудрого есть любимые языки. Ему может нравится Хаскель, но при этом мудрый будет допиливать рантайм на С++, для мудрого это не западло. На работе мудрый будет поддерживать ту же Скалу, ведь мудрый понимает
Предлагаю переименовать в
>программист с достаточно расшатанным анусом
>Программист мудрый прекрасно понимает, что OOD, Буч, GOF, POOD, SOLID - это нихуя не лажа
Все-таки насрал. Жги еще.
>SOLID - это гумманитарный пиздёж
Удваиваю этого господина. Давайте для примера присмотримся к
>single responsibility principle
Единственная ответственность, хм... Но когда Мартина прижали к стенке он завилял как гуманитарная безмозглая сучка, которой он является, и начал чего-то лепетать про - единственную причину для изменения (правда, не уверен что местный контингент в курсе, ну да ладно). Но почему же тогда принцип не назван, ну я не знаю single change reason? Да потому что в словесном сблеве дядюшки Боба нет вообще никакого смысла, вот почему.
Принципы которые нужно применять всегда. Только кроме случаев когда их не нужно применять. А на самом деле все нужно делать с умом. Ну спасибо дядя Боб, теперь то я понял как нужно жить. Но только когда их применять, а когда нет никто не знает. Короче смысла в этих высерах 0.
Просто ты аутист и у тебя слабоформализуемых правил переполняется буфер. Можно тебе посочувствовать, конечно.
Нашел такую хуйню в треде о колонках
www.youtube.com/watch?v=vaMKFCR7s8w
и вспомнилось про этот тред. Почти как-будто про SOLID-поеботу и ее фанатов-говноедов снято.
А кто не верует - мне-вас-жаль-аутист.
>А на самом деле все нужно делать с умом
This. Если бы можно было без этого обойтись, давно бы уже сделали робота, который пишет любые программы. А мамкины борщехлёбы из перезвоним-треда скорее удавятся, чем мозг включат.
Фраза детектор немощной гуманитарной маньки. С одной помойки с
> у каждого своя правда
Если невозможно избавится то и не надо, но надо максимально изолировать.
Да и я писал что я не фанатик одной парадигмы. Я тыкал smalltalk, erlang, prolog, forth, lisp, haskell, go, что бы получить свое понимание различных парадигм. Брать старался те где интересующая идея была почище.
Сейчас наверно все равно уже будет за что браться. Большинство нынешних языков это просто воплощение пересечения идей из старых в разных пропорциях, лол.
Я тыкал Кеевский smalltalk. Лет 20-30 зашло бы, но сейчас точно нет.
Сейчас нужен такой же скачок который был когда появился GC, только для параллельного программирования. Что бы ручками не пердолиться, а получать максимальное автоматическое раскидывание по ядрам. А ООП там будет или еще какое ЗПП, неважно это, лишь бы оно максимально облегчало это дело.
Да и вообще все это ерунда такая не стоящая внимания. Надо размышлять над уровнем еще выше, а язык брать любой подходящий под конкретные условия.
Сначала прочитай определение обязанности, а потом кукарекай
Ты просто выгорел.
Вот и непользуешься ГО.
Поддерживай себе легаси свое, или на пенсию выходи.
>Сначала прочитай катехизис и выучи псалтырь, а потом кукарекай
Оке. Пошел догорать.
Даже не ожидал срача на два треда. Что же, пришло время расстановки точек над ООП. Тред не читал офк, так что возможно до чего-то вы уже дошли сами.
1) ООП - НЕ парадигма программирования. Парадигм программирования всего три. Подробнее здесь: http://wiki.c2.com/?ThereAreExactlyThreeParadigms.
2) То что подразумевают под ООП в современном мейнстримном виде (как в плюсах, джаве, питоне и т.д.) - не более чем тривиальная надстройка над старыми добрыми структурами, процедурами и указателями на процедуры. Об этом Вирт, Кей и другие говорили еще в 80-е, наверное. Кстати, если у кого есть копипаста от каталог-куна про ООП, быдло и люк, доставте, будет в тему.
3) ООП - определенный способ представления программы в голове, а следовательно и способ её структурирования в тексте. Именно его имел в виду Кей, в нем, как ни странно, суть Actor Model, а значит Эрланга и Акки, и во многом именно о нем пишет небезызвестный Егор Бугаенко (http://www.yegor256.com/tag/oop.html) с чьими тезисами можно быть более или менее согласным, но как минимум познакомиться стоит. Можно говорить что это гуманитарщина, и быть при этом правым, но не нужно забывать что программы в первую очередь пишутся для людей, а значит способ их изложения и понимания имеет значение. Насколько легко преставлять программу как множество объектов, взаимодействующих друг с другом - другой вопрос. Возможно другие способы эффективнее, возможно это вообще индивидуально.
4) Я бы еще сказал что ООП - способ структурирования императивных программ. Дело в том что я видел ОО-код на С, видел процедурный код на питоне с джавой, но никогда не видел ОО-ориентрованых програм на функциональных языках. Наверное это из-за того что объекты почти всегда инкапсулируют какое-то мутабельное состояние, иначе они превращаются просто в (параметризируемые) модули, а состояние в ФЯ обычно скрывается и обрабатывается не так, как и императивных.
1) ООП - НЕ парадигма программирования. Парадигм программирования всего три. Подробнее здесь: http://wiki.c2.com/?ThereAreExactlyThreeParadigms.
2) То что подразумевают под ООП в современном мейнстримном виде (как в плюсах, джаве, питоне и т.д.) - не более чем тривиальная надстройка над старыми добрыми структурами, процедурами и указателями на процедуры. Об этом Вирт, Кей и другие говорили еще в 80-е, наверное. Кстати, если у кого есть копипаста от каталог-куна про ООП, быдло и люк, доставте, будет в тему.
3) ООП - определенный способ представления программы в голове, а следовательно и способ её структурирования в тексте. Именно его имел в виду Кей, в нем, как ни странно, суть Actor Model, а значит Эрланга и Акки, и во многом именно о нем пишет небезызвестный Егор Бугаенко (http://www.yegor256.com/tag/oop.html) с чьими тезисами можно быть более или менее согласным, но как минимум познакомиться стоит. Можно говорить что это гуманитарщина, и быть при этом правым, но не нужно забывать что программы в первую очередь пишутся для людей, а значит способ их изложения и понимания имеет значение. Насколько легко преставлять программу как множество объектов, взаимодействующих друг с другом - другой вопрос. Возможно другие способы эффективнее, возможно это вообще индивидуально.
4) Я бы еще сказал что ООП - способ структурирования императивных программ. Дело в том что я видел ОО-код на С, видел процедурный код на питоне с джавой, но никогда не видел ОО-ориентрованых програм на функциональных языках. Наверное это из-за того что объекты почти всегда инкапсулируют какое-то мутабельное состояние, иначе они превращаются просто в (параметризируемые) модули, а состояние в ФЯ обычно скрывается и обрабатывается не так, как и императивных.
->
Почитай тут: и поймешь про 4 пункт.
Ну я где то выше писал что оно похоже на модули, но пасаны как то скептически на это глянули.
>The Missing Paradigm: GoalBasedProgramming (possibly DeclarativeMetaprogramming)
Вероятно частично Coq, Agda, Lean. Но там что бы въехать надо уже матан и теорию типов дрочить.
>можно легко комбинировать цепочками и запускать параллельн
>чистые функции
Они налагают ровно столько же, если не больше ограничений, чем внутренний стейт. В отличии от стейта, у функции ты не сможешь узнать о допустимости операции не выполнив ее.
Проверка типов при компиляции
@
Монады возвращающие и передающие по цепочке результат неудачного выполнения операции
Ты либо не пихнешь левое значение туда куда не надо, либо монадка вернет болт в качестве результата.
>Они налагают ровно столько же, если не больше ограничений, чем внутренний стейт
Это как раз хорошо. Чем меньше ограничений, тем проще допустить ошибку. Подробнее здесь: https://www.youtube.com/watch?v=GqmsQeSzMdw
>В отличии от стейта, у функции ты не сможешь узнать о допустимости операции не выполнив ее.
Не понял. Функцию всегда можно выполнить. Если нужно проверить контракт - проверяй. Идеально чтобы он был закодирован в системе типов.
Пункт 4 больше о моём опыте, мысли вслух так сказать.
В описан переход к ФП как к восприятию программы как обработчика потока данных. Тоже довольно известная идея, описанная например здесь: http://www.lihaoyi.com/post/WhatsFunctionalProgrammingAllAbout.html:
С ней я совершенно согласен, но от ООП здесь ничего не остаётся.
Кроме того я не понял
1) как все это связано с количеством ядер, т.е. почему именно 20 нужно, а не два или даже одно
2) как Go вписывается в это восприятие - из того что я видел, он не отличается от других императивных языков, то есть программист думает именно о потоке выполнения инструкций программы.
>Ну я где то выше писал что оно похоже на модули, но пасаны как то скептически на это глянули.
Мнение пасанов из /pr это такой себе показатель. Довольно очевидно что классы это первоклассные параметризируемые модули.
>Coq, Agda, Lean.
Они об автоматическом доказательстве теорем и зависимых типах. Не уверен что они вообще относятся к предмету обсуждения, это не языки общего назначения.
А еще хочу поддвачнуть , а именно
>Надо размышлять над уровнем еще выше
Главное и самое сложное - правильно выделять подсистемы и интерфейсы между ними. Тут никакие языки не помогут, нужно думать и иметь опыт это к вопросу что в программировании делать после 30. Как закодировать это все - дело тоже не последнее, но реализуемо на любом языке, хоть на паскале.
>Функцию всегда можно выполнить
Ложное утверждение. Зависит от уровня доступа (в системном понимании) и последствий. Тебе либо придется размазывать стейт по телу функции в виде условий и вводить дополнительные параметры, либо, например, опрашивать все увязанные на конкретное "выкинутое" состояние компоненты системы каждый раз создавая море нагрузки без всякого функционала.
Я про функции и реальный мир, реальный мир и функции.
>автоматическое раскидывание по ядрам
Давно есть в Erlang, да и в Go тоже вроде.
Эрланг медленный почти во всем кроме своего основного предназначения, плюс динамика и когда брался не было нормальной возможности работать со стрктурами данных. А вот у Го рантайм конфетка, да. Но синтаксис не конфетка. Впрочем все осговные нужные фичи есть и можно юзать.
>Эрланг медленный
Бекенд и не должен быть быстрым-быстрым на одном узле, он должен быть масштабируемым. Приложения на Erlang линейно масштабируются на любое количество узлов, а дикая распределённость из коробки позволяет легко переписать любое приложение на распределённый манер.
> А вот у Го
Вот когда там можно будет с одной ноды приконектиться на другую, не блокируя выполнение ни там, ни там, провести интроспецию, выполнить любой произвольный код, или вообще заменить его другим, и потом детачнуться обратно - вот тогда и конкуренции с Эрлангом и поговорим.
Сейчас бы сравнивать язык общего назначения и "фреймворк" для пердолинга с массированным потоком сообщений. Один хорош для одного другой для другого. Ну там ложку бы надо использовать когда супчик ешь, а когда не ешь можно и не использовать.
>С ней я совершенно согласен, но от ООП здесь ничего не остаётся.
Я может еретик, но мне по душе только гошный вариант ООП, где наследование заменено на встраивание и похоже на композицию функций чем то.
>1) как все это связано с количеством ядер, т.е. почему именно 20 нужно, а не два или даже одно
А потому что до большинства не дойдет что пора браться за ложку пока супчик не станет совсем жидким. 16-20 и больше это просто цифра ассоциируемая в моей голове со словом "много". Т.е. это как бы момент когда в голове что то щелкает и человек понимает что тут уже простыми костылями не отделаешься, и надо принципиально менять весь подход.
>2) как Go вписывается в это восприятие - из того что я видел, он не отличается от других императивных языков, то есть программист думает именно о потоке выполнения инструкций программы.
Каналы и параллельность забиты в самое ядро языка, а не в либы. Можно самые базовые алгоритмы реализовывать через каналы, например. Хотя синтаксис еще старый и деревянный конечно.
>Они об автоматическом доказательстве теорем и зависимых типах. Не уверен что они вообще относятся к предмету обсуждения, это не языки общего назначения.
Ну тут пока и для меня темная область. Просто прикинул что может быть там есть возможности для:
>Основные операции, необходимые для >GoalBasedProgramming являются:
>(А) описание целей
>(Б) описание ограничений на действия
Но может быть там должен быть какой нибудь мутант из Mercury, этих теорем пруверов и еще чего то.
Ну тут я честно короче скажу что все это предположения основанные на том что мой мозг увидел нечто подобное в этих штуках. Но я только статьи читал о них, руками еще не тыкал.
>А вот у Го рантайм конфетка, да. Но синтаксис не конфетка. Впрочем все осговные нужные фичи есть и можно юзать.
А Julia видел?
https://julialang.org/
>Вот когда там можно будет с одной ноды приконектиться на другую, не блокируя выполнение ни там, ни там, провести интроспецию, выполнить любой произвольный код, или вообще заменить его другим, и потом детачнуться обратно
Это можно в любом языке поддерживающим передачу функций в качестве параметров.
>for numerical computing
Не увлекаюсь этим. Ну и языки предпочитаю не трогать до 1.х версии.
> Не увлекаюсь
И зря, кря-кря.
>Не увлекаюсь этим.
Оно все остальное может.
Корутины есть.
Вот это все.
Рискну поспорить с веселой картинкой и "бытовой мудростью", но на мой взгляд идея язык-под-задачу - это полный бред. Все беды от этой хуйни. Языки для маленьких программок - ну да ведь не бывает такого чтобы маленькая программка становилось нихуя не маленькой кучей говна. Зачем нам нормальные методы для работы со строками, у нас ведь язык для многопоточного программирования? Чет медленновато? - ну эт просто этот язык не предназначен для таких нагрузок.
Только языки общего назначения, только хардкор.
Ну просто на вид там нет ничего нового чего бы я не пощупал в других языках. Хочу вот Mercury пощупать и Idris, Agda, Coq, Lean. Меркури например это пролог перепиленный под чистую функциональщину.
А тут не о чем спорить. Я сказал про свой подход, но не сказал что кто-то кроме меня должен его использовать, лол. Ваш выбор на мне никак не скажется, делайте как хотите и что хотите.
>Это можно в любом языке поддерживающим передачу функций в качестве параметров.
Только ни в одном я не видел аналога эрланговского ремшела, а hot code reload на таком же уровне есть только в лиспе.
>ну карочи язык ыта инструмент
Ой, нахуй иди.
Спецязык же.
В других языках это библиотекой делается.
Приведи пример таких либ в мейнстримовых языках. А той же яве релоад сделан охуенно сложно и не всегда отрабатывает. А ремшела даже в языках с конкурент примитивами нет (типа кложи, хотя там даже есть тот же REPL).
И что значит спецязык, обычный бекенд язык общего назначения, все виды серверов, от веб- до лдап-, базы данных, и прочее.
>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 нити
А будущее оказывается ближе чем я думал, лол.
>Процессоры будут доступны в нескольких вариантах, а версии высокого уровня будут 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 нити
А будущее оказывается ближе чем я думал, лол.
Уже тысячу лет как на ксеонах и прочих ешках. Только что в этом от будущего - не понятно. Это не тысячи тредов, это всего в 4 раза больше чем есть сейчас.
https://ark.intel.com/products/81060/Intel-Xeon-Processor-E5-2698-v3-40M-Cache-2_30-GHz
>приводит в пример вненюю прогу
Ну, во-первых, докер не может в хот-релоад, при поставке нового имейджа существующие контейнеры останавливаюся и подымаются новые.
Во-вторых, причём тут вообще докер? Это не замена ремшела. То, что я могу сделать exec внутрь контейнера, это конечно хорошо, но мне нужны не внутренности контейнера, а нужны внутренности прямо сейчас выполняющейся программы, доступ ко всем прямо сейчас существующим в ней сущностям (будь то объекты, процессы или узлы), возможность что-то прямо сейчас доопределить, перезаписать или затерейть. Чем является эрланговский ремшел - так это распределённым REPL'ом с раширенными возможностями. И не нужно никаких сторонних программ, язык поддерживает это из коробки.
И вообще, "Любая достаточно сложная распределённая программа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Erlang.", что наличие всяких быдлиотек и внешних перделок в других языках только подтверждает.
https://www.amazon.com/Intel-Xeon-E5-2698-Hexadeca-core-Processor/dp/B00PDD1QES
>$2,650
Всего то. Смысл не в том что где то че то есть. Смысл в том что бы оно массово было везде и была необходимость что то с этим делать.
Мы тебе позвоним когда нам это все понадобится.
>мне не нужно - никому не нужно
Ясно.
>Мы тебе позвоним
Спасибо, мне и так по две вакансии в неделю на позиции Elixir/Erlang приходят, на данный момент я не рассматриваю новые предложения.
>Мне нужно - всем нужно.
Ясно, лол.
>потом начинается этап ниспровержения авторитетов на основе собственного ограниченного опыта
Ну немножко не так. Я бы не сказал, что "программист просветлённый" имел бы меньше знаний, чем банда четырёх педерастов, но педерасты тебе говорят: "Если ты пьёшь с ворами, опасайся за свой кошелек." Скорее всего, в отличие от просветленного, они не знают, как использовать расширения Кана для оптимизации монадического говнокода (если ты сам не знаешь, тут описано: https://www.cs.ox.ac.uk/ralf.hinze/publications/MPC12.pdf), или того, что в некоторых случаях можно эффективно не пить с ворами, но это же, блядь, не отменяет того факта, что если ты пьёшь с ворами, нужно опасаться за свой кошелек! Т.е. они совершенно правы во всех своих высказываниях, а заявления ОП-а о том, что всё это лажа - чистой воды нигилизм.
Банда четырёх педерастов совершенно правильно описывает типовые подходы в ООП для решения типовых проблем. Мартин Фаулер абсолютно верно пишет, чем плохой код отличается от совсем хуёвого и как из совсем хуёвого сделать просто плохой. Да, всё это в рамках ОО парадигмы. Но если отбросить ОО-специфичные вещи, то всё ими сказанное будет применимо и к другим парадигмам.
>Предлагаю переименовать в
>>программист с достаточно расшатанным анусом
А со сжатым анусом ты ничего не сделаешь, потому что живёшь в реальном мире. Та же Скала сделала больше для продвижения ФП-парадигмы, чем Хаскель со всеми его монадами. И вот да, только так дела и делаются, путём компромиссов, путём того, что нужно сознательно жрать говно, потому что если ты просто станешь в позу, то нихуя не произойдёт, а постепенное улучшение медленно но верно ведет к успеху.
>Все-таки насрал. Жги еще.
И что же конкретно тебе не навится в этих практиках? Давай отбросим GOF и OOD, допустим, что это про OO, и ты считаешь, что ОО не нужно. Но вот SOLID (без Liskov substitution, разумеется, потому что это про сабтайпинг, который тоже не нужен). Что в нём не нравится? Это же просто утверждения из серии "за все хорошее, против всего плохого". И да, есть куча людей, которые этого не понимают, и ему постоянно приходится говорить "используй single responsibility principle, используй его, сука!" пока до человека не дойдёт.
>Приложения на Erlang линейно масштабируются на любое количество узлов, а дикая распределённость из коробки позволяет легко переписать любое приложение на распределённый манер.
>Стоит заметить, что сейчас треднды активно меняются, поэтому вы легко сможете встретить хайпозависимого скалиста, который будет вам цитировать рекламный булшит
А всё-таки неплохую классификацию я придумал. Ну что, будем закапывать восторженного ерлангоёба (закопать его с "линейным масштабированием" очень просто, начиная с закона Амдала, который математически опровергает саму возможность линейного масштабирования, заканчивая чисто практическими аспектами, которые делают невозможной автоматическую масштабируемость "из коробки" для MP модели, частным случаем которой являются акторы), или пусть еще поживёт в своём манямирке? ИМХО пусть живёт, в конце концов ни одному хайпозависимому (кстати, лучше переименовать его в "программист восторженный", звучит круче) ничего нельзя доказать, опыт приходит со временем.
Ой, блядь, прочитал шапку старого треда, и понял, что ОП- обычный процедурный обмудок. А я тут распинался, типа думая, что ОП - какой-нибудь функциональщик. Господи, до чего же деградировал зк за время моего отсутсвия. Короче, ОП, ты меня слышишь? Ты на какой процедурщине пишешь, на Говне или на Говне++? У вас там модули завезли? Если не завезли и всё пишется инклудами, то открой для себя Паскаль. В Паскале вроде уж есть модули. Как освоишь, просто прикинь, что могут быть инстанцируемые модули. Ну т.е. модуль, который в рантайме создавать можно и ссылаться на него. Это и есть объект. Как освоишь объект, переходи к замыканиям. Правда для них тебе придётся с Говна++ спрыгнуть, замыкания без мусоросборников не работают ибо Funarg problem (https://en.wikipedia.org/wiki/Funarg_problem). И вот после того, как ты все это освоишь, возвращайся и мы с тобой попиздим о том, что ООП не нужно. А пока https://www.youtube.com/watch?v=YEfCGJBxLEg
>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.
И вот так у тебя всё.
> замыкания без мусоросборников не работают ибо Funarg problem
Замыкания это способ решения Funarg problem в языках где для хранения аргументов функций используется стек.
Ух, сколько мамкиных функциональщиков закукарекало заместо монады. Спасибо и за адекватные набросы, я уж думал, все затухнет под вялое булькание любителей таких эрлангов.
>Если ты пьёшь с ворами, опасайся за свой кошелек
В целом да, там везде капитанство у отцов. Но тут такой нюанс: сперва начинающий программист хмыкает, пожимает плечами и отбрасывает в сторону всяких фаулеров, а потом через несколько лет возвращается изрядно потрепанный, перечитывает и восклицает: ох, сука, а ведь мне говорили, хули я их не послушал! То есть осознать ценность этого знания сразу не получается. Смысл творения тех же четырех - не в том, что нужно везде хуярить фасады с синглтонами, а в том, что нужно в своем коде, решающим совершенно конкретную прикладную задачу, учиться выделять общие подходы. И тогда не будет никакой боли от раздирающих анус в кровь абстрактных фасолин, как не будет и самих фасолин.
>только так дела и делаются, путём компромиссов
Золотые слова.
>сабтайпинг, который тоже не нужен
Без сабтайпинга нельзя (точнее, сложно и не нужно). Интерфейсы-шминтерфейсы - это тоже сабтайпинг, просто вырожденное мультинаследование от чисто абстрактных классов. Но в вырожденном случае бывает, что можно и без L обойтись (но опять-таки ничего плохого этот принцип не советует).
>Если ты пьёшь с ворами, опасайся за свой кошелек
В целом да, там везде капитанство у отцов. Но тут такой нюанс: сперва начинающий программист хмыкает, пожимает плечами и отбрасывает в сторону всяких фаулеров, а потом через несколько лет возвращается изрядно потрепанный, перечитывает и восклицает: ох, сука, а ведь мне говорили, хули я их не послушал! То есть осознать ценность этого знания сразу не получается. Смысл творения тех же четырех - не в том, что нужно везде хуярить фасады с синглтонами, а в том, что нужно в своем коде, решающим совершенно конкретную прикладную задачу, учиться выделять общие подходы. И тогда не будет никакой боли от раздирающих анус в кровь абстрактных фасолин, как не будет и самих фасолин.
>только так дела и делаются, путём компромиссов
Золотые слова.
>сабтайпинг, который тоже не нужен
Без сабтайпинга нельзя (точнее, сложно и не нужно). Интерфейсы-шминтерфейсы - это тоже сабтайпинг, просто вырожденное мультинаследование от чисто абстрактных классов. Но в вырожденном случае бывает, что можно и без L обойтись (но опять-таки ничего плохого этот принцип не советует).
В этом посте прекрасно все - девочка из пиздоглазого мультика на картинке, битые ссылки, агрессивное невежество. Шарманъ.
Та все, остались школота, мегаосиляторы неспособные тезисно обосновать, их братья - адепты "языка под задачу", и философы школы универсального просветленного знания
>Смысл творения тех же четырех - не в том, что нужно везде хуярить фасады с синглтонами, а в том, что нужно в своем коде, решающим совершенно конкретную прикладную задачу, учиться выделять общие подходы.
Смысл творения четырех - это написать пародию на книжку про паттерны в архитектуре (в той, которые дома, а не CS). Она глупая и бестолковая, вместо реальных паттернов рассматриваются некоторых костыли некоторых языков, а паттерны друг друга повторяют. Ужасная книга.
Суги, не бабахай.
>мегаосиляторы неспособные тезисно обосновать, их братья - адепты "языка под задачу", и философы школы универсального просветленного знания
Но это все один я, лол.
Ну и еще один пасан интересный который не ставит пробелы после ссылок из-за чего тут некоторые считают их битыми.
А ООП в целом годная парадигма если обуздать наследование. Да в целом для школы универсального просветленного знания все годное, лол.
>ООП в целом годная парадигма
для желающих
>сознательно жрать говно
и других накормить.
для желающих
>сознательно жрать говно
и других накормить.
Хацкельшкольник такой хацкель и такой школьник.
Но я про Кеевское ООП, а не про то что реализовали по мотивам. А Кеевское ООП это внезапно эрланг и го.
>SOLID
>ООП
>А со сжатым анусом ты ничего не сделаешь
Золотые слова.
Все так.
>как ты все это освоишь, возвращайся и мы
>и мы
>мы
Кто тут нас говорит о себе в третьем лице?
Кто такой ути-пути-пути?
Кто такой тортик кушать не хочет?
>программы в первую очередь пишутся для людей
Сидит токой, чиловек, и интерпритирует программу. Заносит значения в ригистры, делоет всякие бинарние опирации.
да ето так
Программист на ассемблере так и делает. И вы делали, если бы не те кому программирование на асме не всралось в свое время.
я прямо сижу и вижу как программист на кокосемблере интерпритирует
А ты попробуй сам, лол.
> интерпретировал тебе за щеку
Попробовал, лол. Приходи еще!
Что уже сломался что ли? лол
интерпритируемый ко-ко-семблер, это абсурдно также как и проститутка, что хвалится своей невинностью в борделе.
Да чет вообще, да. СЛОМАЛСЯ
у меня от тебя СЮРРЕАЛИЗМ.
Дебилы уровня /зк as is.
Давай я напишу тебе многабукв, о том, что трава зеленая, ООП - техника, но не религия, программист с расширением ануса синтезирует парадигмы в целостное восприятие мира - а ты мне за это анус вылижешь лол?
Хотя не буду, уже все написали, но анус таки можешь вылизать, разрешаю.
> синтезирует парадигмы в целостное восприятие мира
А чего тут сложного то? Ищешь что-то общее, попутно отбрасывая откровенно хуевое и получаешь квинтэссенцию полезного. Попутно еще учитываешь будущие изменения в индустрии и вуаля.
>А чего тут сложного то?
Если стоишь на ногах, то сделать очередной шаг и правда, - совсем не сложно.
Когда учишься ходить - тысячу раз упадешь, перед своим первым, маленьким шагом, карапузик.
Сложность программирования в нетривиальности обучения ему, недостаточно напрягать мыщцы ануса чтобы научится программировать, а вот ходить ты может и научишься.
В контексте вопроса, даже на поиск чего-то общего, тебе требуется понимание отдельного. Хорошо, допустим мы прочитали википедию и теперь знаем что такое инверсия зависимостей - но понимаем ли её? Понимаешь ли ты, какие проблемы она решает, в какой сахар оборачивается на том, или ином языке? Понимаешь ли, к каким проблемам ведет чрезмерное употребление данного говна? Нихрена ты не понимаешь, Джон Сноу, википедии мало. Пусть даже там выверенные определения - нужен опыт и видение, для понимания этих определений. И когда ты в десятый раз перепишешь свое говно такое видение приходит. Поздравляю ты понял инверсию, но для формирования общего придется выдрачить сотни, если не тысячи подобный определений. Это стратегическая сложность, про тактические проблемы типа фильтрации информации (это когда википидоры пишут сами не зная о чем пишут) и говорить не будем. Чтобы пройти этот путь нужно быть немного поехавшим фанатиком.
Ну как бы да, но в чем проблема то?
> Это стратегическая сложность, про тактические проблемы типа фильтрации информации (это когда википидоры пишут сами не зная о чем пишут) и говорить не будем.
Хорошие книги читайте. Ну и сейчас еще неплохие курсы появились, можно и их.
>Чтобы пройти этот путь нужно быть немного поехавшим фанатиком.
Читаю tapl и переучиваю английский что бы потом без проблем прочитать hott, лол.
>Ну как бы да, но в чем проблема то?
Да ни в чем, так-то. Было бы желание и на Луну можно слетать.
> Хорошие книги читайте.
Когда не надо «хуяк-хуяк и релиз» можно и почитать
Чтение книг способствует успешному усвоению полученного опыта, но не заменяет его. Вопрос "что тут сложного?" задают исключительно те, кому еще не пришлось применять на практике полученные знания.
Это, кстати, довольно прикольный момент. Когда ко мне на собеседование приходят корзинки из перезвоним-треда, я задаю им вопрос: на сколько баллов они оценивают свои знания. Поскольку ищу я в последнее время в основном макак, то ничего сложного не спрашиваю, но после допроса задаю этот же вопрос еще раз. В ответ обычно доносится жалкое бурчание и вздохи. Вот так и здесь, разве что на чистую воду вывести сложнее да и на хуй не уперлось
Учитывая контингент местной публики, не удивлюсь, если тут половина мамкиных экспертов и критиков - такие вот книжные кукаретики. Почитают на вики про язык, запомнят умные слова и вперед.
> Чтобы пройти этот путь нужно быть немного поехавшим фанатиком.
>> Читаю tapl и переучиваю английский что бы потом без проблем прочитать hott, лол.
hott - это уже не немного, а сильно поехавший фанатик, что-то на уровне золотого или андрюши. Но, к сожалению ли или к счастью, скорее всего это не так и ты просто красуешься.
>В ответ обычно доносится жалкое бурчание и вздохи.
Тут надо всего лишь обладать иррациональной внутренней уверенностью в себе.
Ну, может быть. Но я не вижу в hott чего то этакого, просто может быть это одна из вершин программирования, касающаяся конкретно типов. Эти полуматематические черви не учитывают много чего важного для конкретно программирования, поэтому это явно не самый самый потолок.
>надо всего лишь обладать иррациональной внутренней уверенностью в себе
NIET. Попытки держать лицо под звуки шоколадной капели выглядят еще смешнее.
Ты таки не чтец глазами что ли?
>иррациональной внутренней уверенностью
Или не встречал никогда подобное? -)
>идея язык-под-задачу - это полный бред
Здесь челик неплохо написал про язык-под-задачу : http://nponeccop.livejournal.com/488373.html Хотя на ситуацию можно и по другому смотреть: есть не сделанный проект, есть его заказчики и архитекторы. Появляется понимание что его лучше делать на определенном стеке технологий и под него набирается команда. Все равно не програмисты выбирают язык.
Хотя иногда язык сменяют если уже есть готовый продукт, его можно улучшить переходом на новую платформу и есть деньги и время на эксперименты, или если язык не подразумевает смену платформы (с джавы на скалу спрыгнуть легче, чем на C# или хаскель, например).
>А потому что до большинства не дойдет
Для большинства всегда будет подходить, условно говоря, модель thread-per-request просто по причине низкой нагрузки на приложения. Для тех же, кому производительность важна, не важно сколько ядер - 2 или 20, будут использовать все что есть по максимуму.
>закона Амдала, который математически опровергает саму возможность линейного масштабирования
Этот закон налагает ограничение на возможность распараллеливания алгоритмов, а не на масштабирование обслуживания запросов.
>Сидит токой, чиловек, и интерпритирует программу
Как бы это странно не звучало, да, человек в определенном смысле интерпретирует программы в голове. Особенно императивные.
>Смысл творения тех же четырех - не в том, что нужно везде хуярить фасады с синглтонами, а в том, что нужно в своем коде, решающим совершенно конкретную прикладную задачу, учиться выделять общие подходы.
Кстати да, после прочтения GoF мне стало легче понимать как устроены системы построенные на наследовании.
>сколько мамкиных функциональщиков закукарекало
Я как раз функциональщик, btw.
-кун
>таки не чтец глазами
Таки да, только сейчас понял, что ты про первоначальную оценку.
>Как бы это странно не звучало, да, человек в определенном смысле интерпретирует программы в голове. Особенно императивные.
Человек, "интерпретирует" программу, в смысле составляет представление о том, что она делает.
Однако, все таки, программа пишется для компьютера. Для человека программы пишутся по другому, и к программированию комптуеров это отношения не имееть.
>программа пишется для компьютера
Вообще ни разу, ни в одном из смыслов, лол.
Программы на человеческом языке пишут, после этого программистам надо интерпретировать это в любой язык, понятный компьютеру. Как только сделают интерпретатор с сразу человеческого на машинный - прощай человечество, слава роботам!
О, исчисление объектов и типизированный ассемблер это возможно как раз то что нужно, лол.
Дебил терминальный.
Нет, ты. Результат работы программы нужен кому? Человеку. Вносит изменения и дополнения в программу кто? Человек. При чем тут вообще компьютер? Ах да, он должен выполнить программу, ну так на то у человека есть компиляторы с интерпретаторами, чтобы перевести программу, понятную человеку, в последовательность нулей и единиц, понятную компьютеру. Жир уже вытекает из монитора
Ты походу гуманитарий терминальной стадии.
Человеку нужен результат выполнения программы.
Но не сама программа.
Пишет программу человек.
Но для компьютера, исполняет программу компьютер.
Человеку понятен и ассемблер, в этом отличие человека, от машины. Человек может понимать огромное количество разнообразных концепций и абстракций. Машина - нет.
Поэтому "понятность человеку" не есть критерий.
Язык программирования, это формальный язык, то есть, мат аппарат.
Исходя из вышесказанного, язык этот должен быть построен так, чтобы максимально выразительно отражать то, что машина должна делать.
Слишком много абстракций, и человек перестанет понимать, что именно он командует машине сделать.
Слишком мало - просто неэффективно.
>Поэтому "понятность человеку" не есть критерий.
Ты писал хоть раз в жизни программу, длиннее чем 200 строк?
>Ты писал хоть раз в жизни программу, длиннее чем 200 строк?
Что понятнее.
Erlang
Java
Go
или
Lua
?
Ответ - то, с чем ты лучше знаком.
Размер же программы, это проблема сопровождения, а не понимания.
Тут в 99.999% случаев используется разбивка на модули.
Машине похуй на модули, ей без модулей понятней. Пиши на чистых машинных кодах - машине вообще будет заебись. Поднимаем понятность машине за счет понятности человеку.
Ты какой-то юродивый.
Ну кривляйся дальше.
Зато я ебал твою мамашу.
>Слишком много абстракций, и человек перестанет понимать, что именно он командует машине сделать.
Поэтому абстракции принято разделять на уровни таким образом, чтобы хотя бы два из них нормально помещались в тренированной голове в отдельно взятый момент времени. Это позволяет создавать и поддерживать системы неограниченной сложности.
А ты продолжай писать свою лабу на машинных кодах, дурачок. Не забудь еще раз обругать меня гуманитарием, можешь еще школьником до кучи, а то эффект будет неполным.
> If it looks like a duck and walks like a duck, it must be government waste.
>Поэтому абстракции принято разделять на уровни таким образом, чтобы хотя бы два из них нормально помещались в тренированной голове в отдельно взятый момент времени.
Интересно было бы глянуть исследование на эту тему.
Откуда ты почерпнул про "хотя-бы два уровня"?
Почему не 3, почему не 1? Как тренированность ГОловы определять?
И почему именно два уровня абстракций позволяет создавать системы неограниченной сложности?
>А ты продолжай писать свою лабу на машинных кодах, дурачок. Не забудь еще раз обругать меня гуманитарием, можешь еще школьником до кучи, а то эффект будет неполным.
Извини, ошибся.
Ты видимо шизик. Или первокурсник? Пишешь свою лабу на джаве?
> Пишет программу человек.
> Но для компьютера, исполняет программу компьютер.
И для еще одного человека. Который будет вносить в эту программу изменения. Это всегда так, даже если пишешь один и в стол. Через полгода, когда надо будет внести изменения, ты как раз и обнаружишь себя другим человеком, Столяров.
> Язык программирования, это формальный язык, то есть, мат аппарат.
В этом и есть твое заблуждение и твоих оппонентов, которые говорят, что машина не нужна. Природа компьютерной программы дуальна, а вы тянете одеяло каждый на себя, кидаясь какашками.
Программа - это формальный язык, но загвоздка в том, что этот язык нужно делать понятным какому-то большому количеству людей (в ущерб формальности), в противном случае с тобой никто не будет писать программы на этом языке. Поэтому программа - еще и человеческий язык. Характерные крайние случаи (не самые максимально крайние) этой дуальности - жс и хачкель, жс максимально понятен и легок для входа, но не очень-то он формальный, и программы и компоненты на нем не очень-то надежные. Хачкель гораздо более формален, но из-за этого имеет маленькую экосистему, потому как нужно быть очень умным, чтобы на нем писать.
>Поэтому абстракции принято разделять на уровни
Да тут как получится, эти уровни не всегда помагают, особенно когда хуево разделено. Один поймет другой не поймет.
Про статик ты не слышал, да?
>не всегда помагают
>помагают
С точки зрения малолетнего дебила - несомненно.
каталог-кун пишет:
современное ООП:
толпы быдла бьются головой об стену не видя двери
для них выпиливают люк.
http://codepad.org/iL5gifH5
современное ООП:
толпы быдла бьются головой об стену не видя двери
для них выпиливают люк.
http://codepad.org/iL5gifH5
Я вот тут подумал, а почему вы не ломаете ноги тем кто пишет что код не для людей, а для компьютера? Они же зародыши говнокодеров.
>а почему вы не ломаете ноги
А почему не руки?
Со сломанными ногами все еще можно говнокодить и даже больше
Ну мы же не звери. Надо дать шанс исправиться. А потом руки да, если после ног не дошло.
>Ну мы же не звери.
За себя говори.
>И для еще одного человека. Который будет вносить в эту программу изменения.
Да.
>Природа компьютерной программы дуальна
Да.
>но загвоздка в том, что этот язык нужно делать понятным какому-то большому количеству людей (в ущерб формальности), в противном случае с тобой никто не будет писать программы на этом языке.
Это уже твое заблуждение.
Интегральное исчисление понятно большому количеству людей без ущерба формальности.
Формальность и понятность, вещи не противоположные.
Наоборот!
Формальный язык может понять кто угодно. Тем формальный от неформального и отличается.
>жс максимально понятен и легок для входа, но не очень-то он формальный
Ты под формальностью подразумеваешь что-то свое, не общепринятое.
>и твоих оппонентов
Ну пусть будут оппонентами.
>Хачкель гораздо более формален, но из-за этого имеет маленькую экосистему, потому как нужно быть очень умным, чтобы на нем писать.
Нет, сложность хаскелла в том что нужно прглотить 10-15 новых концепций которые не усваиваются за день-два.
А так то он простой.
Эти монады, функторы, аппликативные функторы и моноиды всего лишь красивые названия над вполне будничными вещами.
Одна и них например выполняет действие с каждым элементом структуры.Типа +5 к каждому элементу массива или дерева.
Другая может производить действие с двумя структурами типа попарного сложения элементов двух списков. Было два списка 1,2,3; стал один 2,4,6. Ну это в случае если было применено сложение.
Еще какая то по моему применяет обычную функцию к типу IO your_type. И возвращает снова IO output_type. Т.е. разворачивает полученные на входе данные которые должны быть обернуты в IO, применяет функцию которую можно применять только к не IO типу, потом снова заворачивает и отдает. IO это input output если не путаю. А вместо IO может быть что то другое и оно тоже будет работатьтак же.
Их 4 вроде, но я забыл 4ую. Если в неделю хорошо изучать по одной незнакомой концепции то можно в нормальные сроки уложиться.
>делать понятным какому-то большому количеству людей (в ущерб формальности)
Пожалуй, это хит треда. В прошлом треде хитом был яростный баттхёрт выгоревшего джявиста, а здесь у нас урок теории формальных языков от гуманитария.
Блять, не может язык быть более или менее формальным, как тяночка не может быть немного беременной. Он либо формальный, либо нет, и абсолютно все языки программирования, включая вышеупомянутый JS - формальные. Нет и не может быть никакой "степени формальности", которая отличала бы JS от, скажем, ассемблера, и уж тем более влияла бы на надежность программ на нём.
Блять, почему эту хуету написал другой человек, а стыдно мне?..
>почему вы не ломаете ноги тем кто пишет что код не для людей, а для компьютера
Их слишком много, это энергетически невыгодно. Хвала богам, мы имеем возможность влиять на кадровую политику компаний, в которых работаем. Благодаря нам таким деятелям НЕ ПЕРЕЗВАНИВАЮТ, ололо.
> Хвала богам, мы имеем возможность влиять на кадровую политику компаний, в которых работаем.
Проигранно.
>Проигранно
"Проиграно" пишется с одной "н", мальчик. Тебе тоже не перзвонили? Скажи мне спасибо, это я постарался нет, конечно же. Такие, как ты, не попадают даже на порог приличных компаний, азаза..
Здоровым людям просьба не читать (хотя их тут нет, мы-то знаем).
> Язык ... Он либо формальный, либо нет
Любой язык - формальный, иначе это не язык. Нужно уточнить, формальность - понятие относительное, а транслятор языка cпособен включать, но не ограничиваться обработкой метоинформации (контекста), нечеткой логикой при построении смыслового ast-дерева, игнорированием ошибок и т.п. логикой утяжеляющей мат. аппарат. транслятора.
Из чего следует - бывают формальные языки, которые сложно интерпритировать. Т.к. сложность противоречит величайшему принципу KISS, то в CS они не популярны, мы оперируем сравнительно примитивными языкам. Но в чяловеческой жизни, ничего не мешает осмысливать 'агугугушу' карапузиков, менее формальной от этого она не становится, хотя данный язык понятен не более чем для одного-пятерых людей во всем мире.
А если язык неформальный - то это и не язык, подобное средство коммуникации ненужна.
p.s. Не знаю зачем я это напейсал, в попу вас всех, шизиков. не_тот_самый_анончик
> "Проиграно" пишется с одной "н", мальчик.
А "Проигранно" пишется с двумя. Чего сказать-то хочешь?
Уроки-то сделал?
Нет детей.
Не нужно тут этих коминг аутов, девственник.
metod1 - указатель, надо так: (*... .metod1)(lksjd)
>Любой язык - формальный, иначе это не язык.
Ещё один. Формальный язык - чисто математическое понятие. Мы не разговариваем на формальных языках (хотя можно построить при помощи формального языка МОДЕЛЬ языка естественного, весьма ограниченную). Язык твоей мамки, сладострастно облизывающий мой анус, тоже далек от формальности.
>формальность - понятие относительное
Относительно чего оно "относительное", дебил гуманитарный?
>бывают формальные языки, которые сложно интерпритировать.
Это никак не влияет на их формальность, она по-прежнему строго в наличии.
>Не знаю зачем я это напейсал
Я тоже не знаю. Чтобы опозориться, выставив напоказ свою некомпетентность, может быть?..
>Формальный язык - чисто математическое понятие.
Что не мешает определять его как функцию конечного автомата.
> Мы не разговариваем на формальных языках
А вот тут не согласен, мы разговариваем на формальных языках, роль конечного автомата выполняет транслятор встроенный в подсознание в самом детстве.
> хотя можно построить при помощи формального языка МОДЕЛЬ языка естественного, весьма ограниченную
А это уже речь о попытках построить транслятор естественного языка в рамках SC, я согласен в том, что подобные трансляторы костыльны. Причины озвучил постом выше. Читай внимательно.
> Относительно чего оно "относительное", дебил гуманитарный?
Относительно конечного автомата, набор правил формально правильный для одного транслятора, может не подходить другому. Вот ты, например, читать не умеешь. Пример, где-то внизу поста будет. Но вообще да, не конца эту мысль сформулировал.
> Это никак не влияет на их формальность, она по-прежнему строго в наличии.
А трава зеленая. Сказать то что хотел? Это не делает естественный язык неформальными.
> Я тоже не знаю. Чтобы опозориться, выставив напоказ свою некомпетентность, может быть?..
Увы опозорился, только ты. Тебе сказали - пишет другой человек, а ты кукарекать начал, про хуя выше, мне он не интересен, от слова совсем. Да и ты тоже, лучше не пиши, если не можешь (а ты неможешь) привести доказательство неформальности естественного языка, ну или пример когда функция конечного автомата неопределена, клоун.
>как функцию конечного автомата
Лол.
>А вот тут не согласен, мы разговариваем на формальных языках
Мы с тобой - точно нет. Ты со своей мамкой - возможно.
>набор правил формально правильный для одного транслятора, может не подходить другому
Вот это да, да ты просто Эйнштейн ебаный. Такая-то теория относительности формальных языков, ёпта.
>доказательство неформальности естественного языка
Бремя доказательства лежит на утверждающем. Подскажу: тебе вполне достаточно привести пример формальной грамматики, описывающей любой естественный язык тактично умолчу о том, что у любого естественного языка нет даже четких границ, он постоянно расширяется и смешивается с другими, порождая всякие пиджины и прочие интересные явления.
>пример когда функция конечного автомата неопределена
Любой контекстно-зависимый язык, простейший пример - Паскаль. Ты внезапно не сможешь отличить синтаксически корректную программу на Паскале от синтаксически некорректной при помощи конечного автомата, так как синтаксис требует объявления переменных перед использованием.
>клоун
Продолжацй, пожалуйста. Давно такого позорища не наблюдал. Конечные автоматы у него формальные языки задают, вообще охуеть. Дропай свой вузик, пока не поздно, если тебя там такому учат.
>20-ти летней давности
50-летней минимум
> Бремя доказательства лежит на утверждающем.
Ну так ты и утверждаешь что он неформальный, вперёд доказывай!
> тактично умолчу о том, что у любого естественного языка нет даже четких границ, он постоянно расширяется и смешивается с другими, порождая всякие пиджины и прочие интересные явления.
Ну зачем, зачем мистер Андерсон, ты пишешь свои сообщения, даже не читая мои. Ты только потверждаешь то, что интерпретаторы встроенные в человека работают лучше чем компьютерные. Или может хочешь сказать, что подсознание не интерпретирует язык? Может это магия позволяет тебе понять текст который ты видишь в первый раз в жизни? В чем смысл, этих утверждений? Информационный шум да и только. Мама тебе книжку по демагогии вместо учебника по литературе купила? Зря.
> Ты внезапно не сможешь отличить синтаксически корректную программу на Паскале от синтаксически некорректной при помощи конечного автомата, так как синтаксис требует объявления переменных перед использованием.
Только, если у тебя свой Паскаль, тот в который не завезли обработчик ошибок. Так что это неудачный пример, ситуация штатная для недетерминированного автомата, я уж не говорю, что ты дал не то, о чем я просил, но и ладно.
> Конечные автоматы у него формальные языки задают, вообще охуеть
Это не мое определение тащем-то, почитай википедию для начала
https://ru.wikipedia.org/wiki/%D0%A4%D0%BE%D1%80%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA
Потом погугли сурс определения, где языки через автоматы описывают. Заодно и нам расскажешь.
---
Вообщем, пока учи теорию, вечером приду и может поговорим.
> 1.
> 2.
У программиста есть 4 ветки кача: менеджер, архитектор, съёб в аналитику, хороший программист. И что-то я не вижу много хороших программистов.
> 3.
Рычи и двигай клавой. Всем своим видом показывай, что ты готов писать код.
> 4.
Зависит от платформы. На какой-нибудь IBM RPG или oracle, ооп не спрашивают, он там не нужен. Решают знания sql.
>роль конечного автомата выполняет транслятор встроенный в подсознание в самом детстве
> >синтаксис требует объявления переменных перед использованием.
>Только, если у тебя свой Паскаль, тот в который не завезли обработчик ошибок.
Это такой редкостный дебил, или просто толстоватый тролль?
>Вообщем, пока учи теорию, вечером приду и может поговорим.
Забавно, когда человек, не знающий теории, советует кому-то учить теорию.
>Это такой редкостный дебил, или просто толстоватый тролль?
Больше похоже на первый вариант.
>Любой язык - формальный, иначе это не язык. Нужно уточнить, формальность - понятие относительное
>А вот тут не согласен, мы разговариваем на формальных языках, роль конечного автомата выполняет транслятор встроенный в подсознание в самом детстве.
Слишком примитивно.
Комон.
Тут же не одни школьники в конце то концов.
>Тут же не одни школьники в конце то концов.
Евгений Ваганыч, пройдите пожалуйста на хуй.
Почему же все забывают о конкатенативной парадигме? https://evincarofautumn.blogspot.com/2012/02/why-concatenative-programming-matters.html - тут попытка сделать некоторую теорию. Конкатенативное программирование позволяет мыслить как императивно, так и декларативно; позволяет добиться некоторого баланса между ними и имеет много других преимуществ.
Повежливее плизики, а то я подумаю что вы (ты Сёма) троллите меня.
Предложение привести доказательство о том, что естественные языки не могут быть формальными (доказательство, а не вскукареки о сложности) все ещё актуально. Ну же, хоть один!
>троллите меня.
Тебя уже жизнь затроллила.
Разберись для начала с определением формальных языков, потом можно будет о чем-нибудь с тобой говорить.
>Естественные языки формальные яскозал!
>Докажите что я неправ, иначе слили!
ясн)
Уебок, ты же сам жопой прочитал статью в Википузии, на которую ссылаешься, и еще щеки тут надуваешь. Из того, что формальный язык может быть задан через определение конечного автомата (что верно) ни разу не следует, что любой формальный язык можно задать таким образом. Тебе даже пример привели.
Я рассматриваю формальный язык как продукт конечного автомата, но т.к. ты не удосужился воспользоваться моим советом относительно википедии, но изволь тыкнуть тебе им в лицо. На этом вопрос считаю закрытым.
Доказано эмпирическим путем. Ты понимаешь русский язык - значит твой внутренний интерпретатор успешно транслирует знаковую систему.
Человеческий мозг не конечный автомат.
>значит
С точки зрения умственно неполноценного программистишки - несомненно.
Итого: ты не знаешь определений ни формального языка, ни конечного автомата, и пытаешься кого-то тыкать в википедию. Беги читай любой учебник по теории вычислений, как закончишь - возвращайся, буду тебя дальше носом тыкать в твою писанину.
Так что в естественных языках неформального? Метаинформация? Нечеткая логика?
Знаете, вы похожи на монахов, что устраивают гонения на Галилео, только за то что тот говорит: «Земля круглая». Ну сорян, что ломаю ваши стереотипы.
>Знаете, вы похожи на монахов, что устраивают гонения на Галилео
Вот тут перетолстил.
Земля геоид вообще-то.
Галилей не за то был гоним.
Вот такие как вы Ньютона и сожгли.
Противно находится на одном форуме с таким зашоренным быдлом как вы.
Язык не подчинен законам логики и противоречив по своей природе: в нём заложены нестабильность значений, двусмысленность, постоянные семантические изменения, большой объём этимологии, идиоматики и т. д.
Не корми плиз
>Не корми
Почему?
Слишком жирная и ленивая троллятина.
>жирная и ленивая
Как что-то плохое, наоборот люблю таких :3
Ну, да, естественные языки не без проблем. Но есть искусственные для людей типа Ыфкуиля того же.
Увы, учитывая уровень собеседников, приходится упрощать - эти люди (ладно один таки осилил) даже не в состоянии открыть википедию.
> Галилей не за то был гоним
> Процесс Галилея — инквизиционный процесс над 70-летним физиком и астрономом Галилео Галилеем, состоявшийся в 1633 году в Риме. Галилей был обвинён в публичной поддержке запрещённой гелиоцентрической системы мира Николая Коперника, которую католическая церковь ранее осудила как еретическое учение (1616). В результате процесса, несмотря на согласие отречься от коперниканства и покаяться, Галилей был приговорён к пожизненному заключению в тюрьме, которое вскоре было заменено на домашний арест и пожизненный надзор инквизиции.
Процесс Галилея впоследствии стал символом противостояния науки и религии — или, в более широком смысле, свободомыслия и догматического (политического или религиозного) учения, претендующего на абсолютную духовную монополию[1]; ссылка на этот процесс часто используется как аргумент в полемике на подобные темы.
Да, а за что?
> Язык не подчинен законам логики и противоречив по своей природе: в нём заложены нестабильность значений
Естественный язык - средство коммуникации, если ЕЯ не подчинен законам логики, то такой язык не может служить средством коммуникации, вот и всё. То, что ЕЯ являются контекстно-зависимым (нестабильность значений) не является неразрешимой проблемой; посмотри на гугл-транслейт - обучается семимильными шагами - у этой сети даже получается в контекст, или его угадывание. А не получается, то можно переспросить, переобучить или добавить костыль, верно?
Нестабильность значений, бтв, никак не мешает строить системы основанные на доверии. Вся утиная типизация - это доверие, и ничего живут люди и интерфейсами не пользуются.
> двусмысленность, постоянные семантические изменения, большой объём этимологии, идиоматики и т. д.
Это техническая проблема: в голове у человека хранится какое-то большое, но конечное число образов. Принципиально ограничений на оцифровку этих образов - их нет. Ну не помешается достаточно мощности для quickdraw в компьютерах размером с твой череп, ну умеет он пока только рисовать/распознавать картинки - ну и что? Завтра научится распознавать колеса, потом будет хуячить детализацию вплоть до рисунка шин. Послезавтра тебя выкинут с работы - и возьмут специалиста по нейронным сетям (которого тоже выкинут, но чуть погодя) - этот будет обучать соотв. программы быстрее, чем ты пишешь код. И с тем же результатом. Или ты хочешь сказать, что нейронная сеть не конечный автомат? Нету никаких принципиальных ограничений на обучение машин ЕЯ, потому что эти языки формализованны.
У этих стадия отрицания, поверить не могут, в то, что сложно реализуемое не равно нереализуемому.
Шизики одни кругом, да и только…
>то такой язык не может служить средством коммуникации, вот и всё
>вот и всё
>ЯСКОЗАЛ
Внезапно, должно соблюдаться
> с(f(x)) = x
где
x - оригинальное сообщение
f - компилятор ЕЯ
c - декомпилятор ЕЯ
Иначе, смысла в существовании ЕЯ, где нельзя восстановить оригинальное сообщение - его нет. А значит, логика есть.
Я с тебя потек.
А как такой ОГРОМНЫЙ проект, как 3d движок Id Tech 3 (который использовался в quake 3 и многих других играх) умудрились написать на чистом Си? Получается можно жить и без OOD даже в таких масштабных проектах? Или же на Cи можно извратиться и фигачить в ООП стиле?
Фишка не в ООП как таковом, а в высокой инженерной культуре. Но в целом и Си оперирует теми же самыми структурами и функциями, которые их обрабатывают.
Какой сегфолт крестодебила
Из полудюжины менеджеров с которыми я работал не был программистом ровно один, точнее одна. И то она ВМиК закончила.
>Или же на Cи можно извратиться и фигачить в ООП стиле?
Так и делают. Любой достаточно крупный проект на сях содержит в себе навелосипедированную реализацию ООП.
Из программистов получаются, как правило, крайне дерьмовые менеджеры. Исключение составляет тот случай, когда человек таки смог заставить себя перестать писать код, думать о коде и вообще думать как программист, и сосредоточился польностью на управлении. Но таких случаев мало. А то что у тебя там много знакомых перекатилось в менеджмент из кодерков - это ничего не значит, быть дерьмовым менеджером может каждый, хоть уборщик. Становиться менеджером через программиста - это как удалять гланды через жопу, такое извращение процветает разве что в бадишопах, для нормальных компани - это скорее исключение.
>что нужно сознательно жрать говно
Вот это глупости, на самом деле. Прогнешься раз, будешь жрать говно всю жизнь. Компромиссы и полумеры и ведут к тому, что в итоге ты жрешь говно. Как на скале, где в итоге 99% кода - обычная жабалапша. Вот тебе и компромиссы.
мимо пишу на окамле за дошираки
Да господи, какие там велосипеды? Объекты есть, ссылки на функции есть, наследование руками - хули еще надо-то?
Что такое ООП?
>ситуация штатная для недетерминированного автомата
>ты хочешь сказать, что нейронная сеть не конечный автомат
Полон тред неучей, на самое смешное никто даже внимания не обратил. Спасибо тебе, безымянный даунито (для местной зелени это уже слишком тонко, такое может написать лишь подлинный воинствующий профан), давно так не ржал.
За то что Папа на него обиделся. А там уже придирались за то что только можно.
То есть одно только определение ООП занимает целую книжку? Короче никак не получится?
Я нашёл её в сети, там вся GoF и до кучи остального, написана сотрудниками DEC и чуть ли не авторами одного из Unix'ов тех лет.
Написано Лукой Карделли, автором standard ml и реализации параметрического полиморфизма в крестах. Все, что нужно знать об ООП, но без маркетингового булшита, чистый формализм.
Одной строкой, как вы выяснили, никто не понимает. Надо разжёвывать каждое слово.
Лука Кардели, кстати, на своём примере отлично показал, что ООП - гумманитарный пиздёж, а применение к нему формальных методов - это натягивание гандона на глобус.
>чистый формализм.
Охуенная формализация. Композицию уже определили?
Результатом этой "формализации" стал Эфель (который, рамзумеется, не взлетел), в котором создатели ничего умнее, чем хуярить ассерты до и после каждого вызова не придумали, а всё лучшее что в нём есть, было взято из ФП.
>стал Эфель
И объектная система окамла - самая годная из объектных систем (ну мб после CLOS)
Ебанный петух, даже сайт не может сделать нормальный, а еще чето гавкает про дизайн языков и фреймворков. Тупой долбоеб получает от силы 50к рублей в месяц, "программирую" на 1С и мечтает о том что создаст свою ОС.
Тупой кусок говна.
Ты так говоришь будто у Кнута или господина ПЖ хорошие сайты. Им вся эта веб-параша до пениса и они гордятся этим.
> В прошлом треде хитом был яростный баттхёрт выгоревшего джявиста, а здесь у нас урок теории формальных языков от гуманитария.
А ты бы не относился так предвзято к гуманитариям, игемон.
Существование "степеней формальности" зависит от того, как посмотреть на все это дело. Формальное - нечто имеющее форму, которая, в случае языков программирования, определяется разными формальными правилами (БНФами, семантиками и т.п.). Так вот правила могут хорошо определять форму, а может случиться так, что спецификация - набор правил полно описывающий язык - по факту не так уж и полна или вообще содержит в явном виде указания на то, что вот тут у нас Undefined Behaviour. Тут наверное можно припомнить Геделя с его депресухой, но я этого делать не буду, чтобы излишне не ветвить дискуссию.
В третьих, существует вероятность, что спецификация, даже самая полная, будет непонята, неправильно истолкована, причем вероятность эта зависит не только от понимающих (наследственных дебилов), но и обуславливается свойствами самой спецификации (например объемную использовать сложнее).
Все это и приводит к тому, что формальное в теории по факту является формальным лишь отчасти.
> Формальный язык может понять кто угодно. Тем формальный от неформального и отличается.
Неформальный тоже, нужно только время чтобы императивно поковыряться в неформальном и вывести для себя правила, по которым оно работает. В формальном еще метатеорию знать надо, иначе получится духовный семинарист, читающий ландавшица.
> Ты под формальностью подразумеваешь что-то свое, не общепринятое.
Обычное для меня дело :( Может правильнее будет так: жс использовать легко, но и неправильно использовать тоже легко, хачкелем пользоваться сложнее, потому что он предпринимает дополнительные подпрыгивания, дабы не дать неправильно себя использовать + барьер в 10-15 новых концепций.
Взрыв мозга просто. Я тут кстати наткнулся еще даже на языке с какой-то алгеброй Клейна взятой за основу: https://en.wikipedia.org/wiki/Orc_(programming_language)
Кнут профессионально занимался программированием до возникновения веб-сайтов - в отличие от г-на Столярова.
Собственно, тот факт, что он даже Оберон не осилил (а все упоротые паскалисты в нулевых на него перешли), все говорит о нем.
А кто мешает писать ФП языках? Чем больше людей будут писать на ФП языках, тем больше будет появляться вакансий. Вакансий мало потому что бизнесы боятся дефицита сотрудников. Ежели даже в ООП языках дефицит грамотных людей, то тем более в ФП. Бизнесы выбирают стабильные инструменты. Попробуй найди десяток хаскелистов. Проще взять какой нибудь жабаскрипт.
Крайняя хуевость и искусственность ФП-языков мешает
>хуевость и искусственность ФП-языков
Давай поподробнее.
Хозяин.гуляет(Собаку)
или
Собака.гуляется(Хозяином)
Поясните, как проблема называется и как правильно делать?
нюфаня
или
Собака.гуляется(Хозяином)
Поясните, как проблема называется и как правильно делать?
нюфаня
>Поясните, как проблема называется
ООП
>и как правильно делать?
ФабрикаГулятелейСобак.Создать( XMLЗагрузчик.ЗагрузитьКонфигурацию() ).Гулять( ФабрикаСобак.Создать( "Собаки.Стандартная собака" ), ФабрикаХозяинов.Создать( "Хозяины.Стандартный хозяин" ) )
>А ты бы не относился так предвзято к гуманитариям, игемон.
В работе с языками без гуманитароблядства никуда да и вообще без него никуда, ибо научный поиск неотделим от поиска эстетического, согласен, но...
>зависит от того, как посмотреть на все это
Ты слишком налегаешь на просмотр банальных вещей под разными углами. Это не попытка отучить тебя думать, это попытка объяснить, что неуместное мудрствование бывает вредным хотя это же двач, все тут ради этого и собрались. Ты не сможешь доказать даже сраной теоремы Пифагора, если будешь все время задумываться о существовании нелинейных пространств. Мозг - это инструмент. Ты же не хочешь, чтобы тебе хирург аппендицит вырезал швейцарским складным ножиком заместо скальпеля? Вот и мозг нужно делать скальпелем, когда надо. А ты вместо этого растопыриваешь штопор и пилочку для ногтей, вольно толкуя терминологию, вот как здесь:
>существует вероятность, что спецификация, даже самая полная, будет непонята, неправильно истолкована
Ты говоришь правильные, казалось бы, вещи, но они не имеют отношения к тому, формален язык или нет. Таким образом, ты обмазываешь простые вещи дополнительными понятиями до тех пор, пока они не перестанут быть простыми. Это отлично работает в литературе, но не в математике.
А мое "казалось бы" относилось к тому, что ты в результате своих умственных выкрутасов нечаянно смешал толкование спецификации человеком и разбор формального языка машиной. Это вовсе не одно и то же, и в случае разбора программы никакой вероятности того, то она будет истолкована неверно, не существует. Любая неоднозначность видна в грамматике явно, и мы можем написать такую грамматику, которая гарантированно не будет содержать неоднозначностей. И в отличие от человека, который сдохнет, читая многотомные талмуды спецификации, машине похуй, насколько велика и сложна программа; от этого не будет зависесть, насколько верно она истолкует грамматику.
Видишь, как просто ошибиться, если в процессе размышлений витать в облаках. А ведь ты на своих ошибках строишь дальнейшие рассуждения.
Мне кажется, ты лет на 5 в кому впал и только сейчас вышел. Никто так не пишет уже.
>ФабрикаГулятелейСобак
слишком конкретно, оставить IФабрикаГулятелей и зарегать в контейнере
>ФабрикаСобак
слишком конкретно, унаследовать от IФабрикаГуляемых и зарегать в контейнере
потом положить оба в контейнер, добавить контейнеру два ресолва:
RegisterType<IГулятель>(c => c.Resolve<IФабрикаГулятелей>().Создать())
RegisterType<IГуляемый>(c => c.Resolve<IФабрикаГуляемых>().Создать())
Потом сделать интерфейс IПрогулка с методом Прогуляться(). От него унаследовать class Выгуливание, в конструкторе инжектить IГулятель и IГуляемый. Класс тоже зарегестрировать в контейнере как имплементацию IПрогулки. После в мейне резолвишь IПрогулку и вызываешь у неё метод Прогуляться().
гугли мультиметод
>искусственность ФП-языков
Точно, понаплодили говна всякого пластмассового и жрут. То ли дело ООП-языки - натуральные, со своего огорода, без пестицидов. С дымком, ёпта.
Смеюсь как сумасшедший.
Пиши еще.
>Попробуй найди десяток хаскелистов.
Сейчас как раз с этим проблем нет. Предложение гораздо выше спроса.
Вот ты смеешься, а я такую хуйню на работе пишу.
>Сейчас как раз с этим проблем нет. Предложение гораздо выше спроса.
Откуда знаешь, нанимал? Работодатели другого мнения. То и дело жалуются на дефицит достойных прогеров. И это касается всяких там похапэ с жабаскриптами. Так откуда возмутся хаскелисты?
Если не ошибаюсь тинькоф-банк заипался искать скалистов, и там зареклись никогда не писать новые проекты на функциональных языках.
Отсутствие состояния - искусственное ограничение, которое не нужно. От него пляшет куча другой хуйни типа монад и рекурсии там, где она нахуй не нужна.
>Если не ошибаюсь тинькоф-банк заипался искать скалистов
Вангую лист А4 с требованиями, вроде мехмата, докторской степени и т.д., набрали бы Жабамакак и за полгода переучили их.
>набрали бы Жабамакак и за полгода переучили их
Жабамакак невозмоно научить даже ООП, о чем ты?..
>Отсутствие состояния - искусственное ограничение, которое не нужно
Почему, это?
Потому что иди нахуй.
Годно обосновал. Всегда так делай.
> в самом языке вообще не должно быть синтаксического сахара, должны быть средства для его создания в библиотеках; библиотеки как раз и должны быть его источником, а равно и источником большинства свойств, которые вы хотите видеть в языке.
Он в 2007 решил изобрести лисп?
Даже с таким подходом непонятно чем это поможет. Все начнут обмазываться библиотеками/фреймворками аля сахарком.
>А кто мешает писать ФП языках?
Бери и пиши, лол. Только вангую уже к следующему проекту забьешь хуй и вернешься к жаве.
Практика - критерий истины. Кому-то явное отсутствие состояния облегчило жизнь? Не как выбор иммутабельных структур как архитектурного решения, а на уровне языка? Никому. Это не new/delete в С++, случайно поменять состояние довольно сложно. А в ФП на этом построено все.
>случайно поменять состояние довольно сложно
Что, вам еще лабы с параллелизмом не задавали?
смотря откуда посмотреть
взять тот же реакт и сравнить с ангуларом (1,второй особо не трогал) - в реакте все действительно выглядит проще, хоть и кода много
Mutex и мониторы для лохов?
Да.
>Mutex и мониторы для лохов
Под нагрузкой - да, кстати.
Лол, в реальных задачах оверхед функционалщины все равно будет больше, даже если потоки будут на уровне ядра.
Скажи это эриксону с его телефонией на эрланге.
>оверхед функционалщины все равно будет больше
Вот этот меня опередил. На Highload++ несколько лет назад был отличный докладов на эту тему, кстати, от каких-то видеобродкастеров, ща не вспомню уже точно, кто.
>Mutex и мониторы для лохов?
Да. Читай про Amdahl's law, чем меньше у тебя синхронизации между потоками, тем лучше. Персистентные структуры данных и свободный порядок редукции помогают с параллелизмом, иммутабельность помогает не накосячить при этом.
Собственно от ебли с семафорами почти все уже пришли к персистентным структурам данных, подобию map/reduce, атомарным операциям, эффектам и минимуму синхронизаций.
Ну а оверхед функционалщины все равно будет много меньше оверхеда от диспетчиризации в ооп благодаря ссылочной прозрачности.
>минимуму синхронизаций
Чтобы было минимум синхронизации, никакая функциональщина ненужна.
Ненужно усложнять то, что не требует усложнения.
Сложность ради сложности порочна.
>Персистентные структуры данных и свободный порядок редукции помогают с параллелизмом, иммутабельность помогает не накосячить при этом.
Ну и пусть себе помогают.
Зачем явное состояние запрещать?
Этот все верно говорит.
Дрочь ради дроча, и поедание кактусов, не есть путь для вменяемого человека.
Это касается как ФП так и ООП.
Реакт если мне не изменяет память, написан на js. Это язык, в котором даже слово const появилось не так давно. А теперь перечитай мой пост. Одно дело использовать реактивное программирование, map/reduce/filter, комбинаторы парсеров и прочие решения, пришедшие из ФП, а другое - использовать ФП-языки, в которых работают ТОЛЬКО решения из ФП.
Ну хорошо, пришел ты к map/reduce (который, вообще говоря, не ФП, а dataflow подход и персистентность как таковая там не требуется, очень часто in-place map отработает эффективнее и потокобезопасно, но в ФП ты не можешь это контролировать); объясни теперь, нахуя городить огород с попытками оградить редьюсер от изменения мира путем хитрожопой системы типов, когда случайно сделать это очень тяжело?
То есть все страхи основаны на том, что возможно, в твоем редьюсере будет некая функция, у которой подфункция подфункции недокументированно меняет глобальный стейт, и это очень страшно, ведь в многопоточной среде случится какая-нибудь хуйня. Но это не настолько часто встречающийся баг, чтобы это вообще реально парило. Реально парит это математиков, которым мутабельность как кость в горле. Им нужны ФП-языки. А остальным нет.
>ородить огород с попытками оградить редьюсер от изменения мира путем хитрожопой системы типов, когда случайно сделать это очень тяжело?
В фп тяжело, в ООП ты можешь иметь список связных объектов, неявно изменяющих друг друга, ты можешь иметь объект, зависящий от состояния извне.
>Чтобы было минимум синхронизации, никакая функциональщина ненужна.
На уровне лаба1 может и не нужна. На уровне десятков млн. строк кода ты просто не уследишь за всеми состояниями и их изменением.
Потому в крестах хорошим тоном считается ставить const везде, где можно, а где нельзя - копировать объект. В фп это сделано за тебя: любой объект иммутабельный, а при необходимости изменения он копируется.
> Зачем явное состояние запрещать?
Что такое явное состояние? В мире нет состояния, он прекрасно описывается декларативно (физикой, химией и проч.). Даже железо описывается декларативно в VHDL. Состояние - костыль, придуманный в угоду машине. Читать статью Бахуса (автора фортрана) про фп из 70-х.
Что касается
>Практика - критерий истины.
То более глупого высказывания придумать нельзя (особенно учитывая, что говорит студент без опыта). Если ты всю жизнь гвозди лбом забивал и работало (иногда), это не значит, что данный метод лучший.
> нахуя городить огород с попытками оградить редьюсер от изменения мира путем хитрожопой системы типов, когда случайно сделать это очень тяжело?
Объясняю (для самых маленьких)
>свободный порядок редукции помогают с параллелизмом
Вне функциональной парадигмы функция, передаваемая reduce, может иметь побочные эффекты, в частности зависеть от предыдущих аргументов. В таком случае редукции слева направо
, справа налево и параллельно дадут разный результат.
В фп порядок редукции не имеет значения, а вместо функции с состоянием придется сделать какой-нибудь map.
Собственно, в многопоточном окружении императивщина приносит очень много боли именно из-за состояния: порядок вычислений стэйтментов сложно определить (привет, ебля с барьерами в крестах). В фп редукция выражений явно дает понять, что и в каком порядке можно вычислять, не дает выстрилить себе в ногу, что в условиях проекта серьезнее лаба1 является огромным преимуществом.
>очень часто in-place map отработает эффективнее и потокобезопасно
Ну вот ты делаешь редьюс по списку, а другой поток из списка пытается читать. Что делать будешь, обернешь список мьютексами? Так это тебе такой удар по производительности даст. С ссылочной прозрачностью таких проблем нет, в императивном окружении эти проблемы встают в полный рост, и начинается ебля с барьерами и
синхронизацией.
Объясняю (для самых маленьких)
>свободный порядок редукции помогают с параллелизмом
Вне функциональной парадигмы функция, передаваемая reduce, может иметь побочные эффекты, в частности зависеть от предыдущих аргументов. В таком случае редукции слева направо
, справа налево и параллельно дадут разный результат.
В фп порядок редукции не имеет значения, а вместо функции с состоянием придется сделать какой-нибудь map.
Собственно, в многопоточном окружении императивщина приносит очень много боли именно из-за состояния: порядок вычислений стэйтментов сложно определить (привет, ебля с барьерами в крестах). В фп редукция выражений явно дает понять, что и в каком порядке можно вычислять, не дает выстрилить себе в ногу, что в условиях проекта серьезнее лаба1 является огромным преимуществом.
>очень часто in-place map отработает эффективнее и потокобезопасно
Ну вот ты делаешь редьюс по списку, а другой поток из списка пытается читать. Что делать будешь, обернешь список мьютексами? Так это тебе такой удар по производительности даст. С ссылочной прозрачностью таких проблем нет, в императивном окружении эти проблемы встают в полный рост, и начинается ебля с барьерами и
синхронизацией.
хацкельпетушня как всегда
>В мире нет состояния
таблетки прими
>в многопоточном окружении
ненужно
А вот и разработчики лаба1 подкатили.
Ни понял не одного слова из этого треда.
Кокой еще оопэ-шмоопэ? О чем вы вообще?
мимо 150к+ Programmist 1C.
Кокой еще оопэ-шмоопэ? О чем вы вообще?
мимо 150к+ Programmist 1C.
Там у тебя Залупа Ивановна с третьего этажа что-то нажала и все исчезло, пиздуй чини, сантехник.
При наследовании, например в с#, создается объект предка или прям добавляются поля и методы предка?
Да.
хули ты дакаешь
>В мире нет состояния, он прекрасно описывается декларативно
Oh boy oh boy!
Here we GO!
No, thanks, but no, go fuck yourself.
>В фп тяжело, в ООП ты можешь иметь список связных объектов, неявно изменяющих друг друга, ты можешь иметь объект, зависящий от состояния извне.
А можешь и не иметь. Это не хуйня типа double delete или даже забытый -1, случайно поменять состояние, если в голове у тебя уже есть иммутабельная архитектура, невозможно. Поэтому получается противоречие
1. ФП-языки рассчитаны на не очень умных программистов, которые могут внезапно забыть о собственной архитектуре. Ну то есть писал такой редьюсер, который должен работать распределенно, и, хуяк - полез на диск за чем-то.
2. ФП-языки рассчитаны на очень умных программистов, ведь контроль за состоянием на уровне типов языка - это большой семантический оверхед.
Разрешается это противоречие простым образом - иммутабельные структуры данных и решения типа реактивного программирования нужны, а ФП с монадами и стрелками - нет. А языки остаются аутистам, у которых есть заморочки по поводу несуществующих потенциальных проблем.
> Даже железо описывается декларативно в VHDL. Состояние - костыль, придуманный в угоду машине.
Ты сам-то VHDL видел? Там есть переменные https://stackoverflow.com/questions/15485749/vhdl-variable-vs-signal
Пиздец какой-то, состояние появляется ровно в тот момент, когда в твоем железе появляется триггер. А без триггеров ты ничего сложнее простых логических схем не построишь. И машинные языки упрощают ситуацию благодаря фоннейнмановской архитектуре - вместо кучи разного рода параллельно выполняющихся независимых кусков, есть один поток команд. И сделано это не угоду машине, а в угоду людям, которые мыслят точно так же - императивно.
>То более глупого высказывания придумать нельзя (особенно учитывая, что говорит студент без опыта).
Мне 28
>И сделано это не угоду машине, а в угоду людям, которые мыслят точно так же - императивно.
Все не так. Существует 2 основных модели вычисления алгоритмов - Машина Тьюринга и Лямбда-исчисление. Они равносильны, но отличаются по модели.
Машина Тьюринга имеет состояние, вычисление происходит с помощью перехода в другое состояние. В Лямбда-исчислении вычисление выглядит как математическая функция, которая не может иметь состояние.
Каждый ребенок с малого учится математике, где никаких состояний нет. Так с чего вдруг императивное мышление понятнее человеку, а фукнциональные языки основанные на лямбда исчислении и близкие к математике неудобны?
Приведи пример императивного мышления в жизни?
>Каждый ребенок с малого учится математике, где никаких состояний нет.
Лолчто?
Ты забыл как решаются уравнения, расписывая изменения глобального состояния? Или для тебя переменные в скоупе - не состояние?
> Приведи пример императивного мышления в жизни?
В школе на физику надо было ходить, мань.
В школе на физику надо было ходить, мань.
>Каждый ребенок с малого учится математике, где никаких состояний нет.
Вот это аутизм. Каждый ребенок учится решать задачки уровня "у Вани было 5 яблок, он 3 отдал Маше, сколько яблок у Вани?".
Затем идет алгебра - символьные преобразования. Детей обучают рецептам типа "если отнять x слева и справа от знака равно, то уравнение будет эквивалентным".
Затем только геометрия, которая ближе всего к настоящей математике и там да, по сути идет распространение ограничений.
>Приведи пример императивного мышления в жизни?
http://www.vnukovo.ru/transport/bus/
https://dt.mos.ru/projects/moscow-parking-space/pay.php
http://recn.ru/kak-raspilit-brevno-na-doski-svoimi-rukami
Люди эволюционно приспособлены к командной работе, при которой они с помощью языка объясняют товарищам, что они хотят - без этого ты не поймаешь медведя и не построишь египетскую пирамиду.
Программист представляет себя на месте машины, что бы он сделал и куда что запихнул, точно так же, как если бы он объяснял кому-то, как пилить бревна. По этой причине, собственно, многопоточный код сложнее - там приходится представлять себя на месте не одного субъекта, а нескольких.
А ФП для реального мира устроено как, имеется вроде как язык без состояний, на нее наворачиваются монады IO и ST, чтобы эмулировать состояние, и дальше пишется старый добрый императивный код, потому что люди привыкли писать императивный код.
В итоге что мы имеем, в одном случае мы имеем машину Тьюринга per se, а в другом, лямбда-исчисление, которое эмулирует машину Тьюринга. В итоге один гемор:
1. Вместо простого и понятного аппликативного порядка (сказал Васяну считать - он посчитал), ты получаешь ленивый (сказал Пете, что если нужно посчитать, пусть обращается к Васяну, когда ему удобно, и хуй знает что у них там будут за взаимоотношения), и дальше получаешь охуительные баги.
2. Вместо цепочки действий получаешь колбасу из обещаний действий. Что дает тебе огромный сементический оверхед.
И т. д. Удобно это только математикам, которым нужно не программировать, а теоремы о программировании.
>В школе на физику надо было ходить, мань.
Сходи в магазин, выполни то и то, - все эти алгоритмы декларативны. Никто из людей не раскладывает в уме как нужно идти в магазин. Когда говорят выполнить заказ, все понимают что это значит. Все это декларативные функции.
Утрись, вась.
>Детей обучают рецептам типа "если отнять x слева и справа от знака равно, то уравнение будет эквивалентным".
Эталонный посетитель зк. Скоро у вас еще анализ начнется, классе в 10, тогда приходи.
> все эти алгоритмы декларативны.
Ага, особенно корпускулярно-волновой дуализм, когда в зависимости от состояния объекта работают разные формулы, даун.
>Ага, особенно корпускулярно-волновой дуализм, когда в зависимости от состояния объекта работают разные формулы, даун.
Ты это серьезно сейчас сказал? Про два состояния и разные формулы? Ты, часом, не на го пишешь?
>Лолчто?
>Ты забыл как решаются уравнения, расписывая изменения глобального состояния? Или для тебя переменные в скоупе - не состояние?
Редукция - https://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%B4%D1%83%D0%BA%D1%86%D0%B8%D1%8F_(%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B0)
Любое математическое вычисление есть последовательность редукций, без перехода состояний. Уравнения не исключение.
Не корми корпоскулярный дуализм.
> разные формулы
Напейхал тебе за щеку кванты и волновые свойства, проверяй.
Не зря у матейматиков (да и видно у тебя тоже) 1 апреля - профессиональный праздник.
Нет - распили бревна - это императивщина, просто на высоком уровне. Это тоже самое, что у тебя есть функция, которая внутри себя вызывает еще сотню.
А декларативно - бревна распилены.
Фактически просто изменение сотояния у объекта, без отдачи ему команды.
Ты словно пишешь
квадрат красный
квадрат зеленый
квадрат желтый
а в итоге у тебя квадрат мигает разными цветами
а вот если бы ты писал, сделать квадрат краснм, потом зеленым, потом желтым. СДЕЛАТЬ. то это было бы как раз императивно. Ровно как в твоем примере с магазином, где ты используешь КОМАНДУ сходить.
html - декларативный язык. ты там не отдаешь команд, ты описываешь декларативно элементы. Словно список покупок. А уже исполнитель (браузер, или куьер заехавший в магаизн) сам решает как отрисовать эти элементы, или что сделать с этим списком покупок - купить их, или подтереться.
>Люди эволюционно приспособлены к командной работе, при которой они с помощью языка объясняют товарищам, что они хотят - без этого ты не поймаешь медведя и не построишь египетскую пирамиду.
Все команды от человека к человеку представляют собой декларативные функции - построить пирамиду, выполнить кирпичную кладку, пристрелить медведя, etc. Все люди мыслят так, никто каждый раз не объясняет что он хочет получить, он называет команду, декларативную функцию.
>построить пирамиду, выполнить кирпичную кладку, пристрелить медведя
это императивищина
>построенная пирамида, выполненная кирпичная кладка, пристреленный медведь
вот декларативщина
>кванты и волновые свойства
То чувство, когда школьник цитирует википедию без понимания вопроса.
>распили бревна - это императивщина
У тебя мозг протух, либо ты не различаешь декларативное мышление от императивного. Распили бревна - это функция отвечает на вопрос что сделать, а не как сделать. Значит декларативна.
>>построить пирамиду, выполнить кирпичную кладку, пристрелить медведя
>это императивищина
>>построенная пирамида, выполненная кирпичная кладка, пристреленный медведь
>вот декларативщина
Ты безнадежен. Понимаешь разницу между - "Что сделать" и "Как сделать"?
Кромешных дебилов полон говнотред.
>Декларативное программирование — это парадигма программирования, в которой задаётся спецификация решения задачи, то есть описывается, что представляет собой проблема и ожидаемый результат
твое - распили бревна, не описывает ЖЕЛАЕМЫЙ РЕЗУЛЬТАТ, который обязана описывать декларативность.
Удачи.
Ты тоже дебил, кстати.
Так ведь это ты не понимаешь разницы, между о том, что нужно что-то ДЕЛАТЬ, и что-то ПОЛУЧИТЬ.
Каша в голове тут лишь у тебя.
А ты даже до дебила не дорос.
Иди нахуй, имбецил.
>твое - распили бревна, не описывает ЖЕЛАЕМЫЙ РЕЗУЛЬТАТ, который обязана описывать декларативность.
>
>Удачи.
Баран, распиленные бревна разве не результат распиловки?
Взаимно.
С такими аргументами предлагаю пройти нахуй.
И, на затравачку, предлагаю рассказать сколько будет "дохуя" в декларативной парадигме.
>затравачку
Ох уж эти деревенские.
>Так ведь это ты не понимаешь разницы, между о том, что нужно что-то ДЕЛАТЬ, и что-то ПОЛУЧИТЬ.
>
>Каша в голове тут лишь у тебя.
Сходи в магазин за хлебом - результат купленный хлеб. Сходить в магазин за хлебом - опять же отвечает на вопрос "что сделать?".
команда - распили бревна - не декларирует распиленые бревна, баран. она приказывает ПИЛИТЬ БРЕВВНА, а скаким труднстями при распике их ты встретишься, и получатся ли у тебя распиленные бревна, ты не говоришь.
Вы просто не видети разницу, между -КОПАЙ ТРАНШЕЮ, и ТУТ ВОТ ТРАНШЕЯ ДЛИНОЙ СТО МЕТРОВ.
В армии не служили же, да?
Ды вы тут, в общем-то, все поехавший.
>видети
>все поехавший.
>В армии не служили же, да?
То что ты, быдло безмозглое, служило - очень заметно, да.
>скаким труднстями при распике
>команда - распили бревна - не декларирует распиленые бревна, баран. она приказывает ПИЛИТЬ БРЕВВНА, а скаким труднстями при распике их ты встретишься, и получатся ли у тебя распиленные бревна, ты не говоришь.
Вася, ты еще и языка не знаешь. Распилить означает распилить все, получить конечный результат. А просто пилить, означает пилить вечно, то есть без конечного результата.
>Вы просто не видети разницу, между -КОПАЙ ТРАНШЕЮ, и ТУТ ВОТ ТРАНШЕЯ ДЛИНОЙ СТО МЕТРОВ.
Не путай копай и выкопать, ходи и сходить тоже самое. Сходить в магазин означает купить что-то и принести, а не уйти навечно.
>В армии не служили же, да?
Служили. Хороший аргумент, в армии вообще нет логики, так что это показывает уровень твоего мышления.
>Сходить в магазин означает купить что-то и принест
Проиграно.
Императивщики порвались, лол.
Всю жизнь был закостинелым процедурщиком-императивщиком. ООП узал только для сдачи лаб во времена студенчества. В последнее время тучи над мое головой сгустились и я решил сменить специализацию. Порешал тестовых задачек и охуел от того насколько уместно бывает ООП. Теперь думаю даже GoF читнуть.
Трустори.
Трустори.
>закостинелым
>над мое головой
Ясно.
А теперь попробуй Хаскел и увидишь насколько просто и лаконично лямбда-исчисление. Нет никакого Бойлерплейт-кода, все сконцентрировано на решении задачи, а не решении проблемы языка.
>Эталонный посетитель зк. Скоро у вас еще анализ начнется, классе в 10, тогда приходи.
От этого не изменится тот факт, что детей начинают обучать математике путем объяснения рецептов преобразования символов. Среди функциональщиков же бытует миф, что первоклассникам сразу же матан объясняют, поэтому и программировать нужно учить через обучение матану. Хотя это все чушь. Программировать через матан нужно только математиков. Типичная ситуация для 70-х годов прошлого века, когда компьютеры были большими, а доступ к ним был только у тех, кто знал математику. А сейчас это не так, интересующиеся дети с 12 лет программируют и задают вопросы, нужна ли программисту математика.
>Все команды от человека к человеку представляют собой декларативные функции - построить пирамиду, выполнить кирпичную кладку, пристрелить медведя, etc.
Все языки, включая человеческие и языки программирования, являются набором деклараций. Тогда о чем речь вообще, асм - декларативный язык (он говорит процессору - проксорить регистр, и нас не ебет, как он там его поксорит, нам важен результат), и брейнфак, спорить не о чем. Только твоя демагогия делает инвалидным собственно предмет спора.
Все перечисленные мной вещи в процессе работы изменяют стейт окружающего мира.
А то, что тебя не ебет, как именно бревна будут распилены и с какими сложностями и как именно стейт окружающего мира будет изменен, называется инкапсуляцией. Что есть дикий зашквар с точки зрения ФП.
>Все перечисленные мной вещи в процессе работы изменяют стейт окружающего мира.
Вся математика декларативна. Вычислить корень числа - декларативная процедура, редукция, в ней не хранится никакого состояния, просто вычисляем и записываем результат. Только в императивной парадигме корень из числа представлен как переход состояний, это не человеческое мышление, это мышление тупой машины.
Последовательность редукций над несколькими функциями - результат декларативной программы. Состояние для этого хранить не нужно.
Человек не мыслить императивно. Это неудобно, нужно постоянно хранить каждый шаг. Императивно мыслит машина на архитектуре Фон Неймана.
Ты выдаешь желаемое за действительное.
Использую как лямбды так и классы.
С++
>на архитектуре Фон Неймана.
И даже на гарвардской!
Та самая архитектура тут непричём
>как именно бревна будут распилены
Ты когда составляешь планы на день, тоже записываешь каждый шаг в виде императивного алгоритма? Не думаю. Ты пишешь последовательность процедур, декларативных.
Так что не пизди, что мыслишь императивно.
>Вся математика декларативна.
И что? Ты спросил "Приведи пример императивного мышления в жизни?", а не в математике, которая вообще оперирует нематериальными объектами.
>Вычислить корень числа - декларативная процедура
Это императивная процедура. Вот набор символов sqrt(2) - это декларация, которая говорит о том, что существует x такое, что x*x=2. При этом никто не просит вычислять это самое sqrt(2). А "вычислить корень" - это императивный алгоритм.
>Ты пишешь последовательность процедур, декларативных.
Я пишу последовательность императивных процедур, каждая из которых при желании может быть расписана в виде более подробности последовательных процедур. Ты занимаешься демагогией, называя это
def main():
print "hello world"
декларативным кодом только потому, что я не записываю каждый шаг того, что необходимо сделать, чтобы вывести строку на экран.
>>Вычислить корень числа - декларативная процедура
>Это императивная процедура.
Все ясно. Ты либо тролль, либо дегенерат. Не можешь отличить императивность от декларативности.
>>Ты пишешь последовательность процедур, декларативных.
>Я пишу последовательность императивных процедур
Не пизди вася. Распорядок дня человек пишет в виде декларативных процедур. Императивные инструкции пишут только как инструкции по выполнению чего-то, например инструкция по пользованию техникой, или инструкция для рабочего.
Пиздишь ты вася, вот распорядок дня призывника.
Распорядок дня военнослужащих по призыву
Время Понедельник
06.50 Подъем заместителей командиров взводов
07.00-07.10 Подъем личного состава
07.10-08.00 Утренняя физическая зарядка
08.00-08.30 Утренний туалет, заправка постелей
etc...
Взято с сайта МО РФ.
Все это декларативные процедуры, они не описывают последовательные инструкции как в императивных алгоритмах, они задают декларации. Человеку так удобно мыслить.
А теперь пошел нах.
>Все ясно. Ты либо тролль, либо дегенерат.
А ты злой школьник, который пытается заниматься демагогией, а как только это не получается, начинает агриться.
Напоминаю, как шел диалог. Ты меня попросил дать тебе пример императивности из реальной жизни. Я тебе дал 3 штуки. Ты начал заявлять о декларативности моих примеров. Когда тебе несколько человек начали объяснять, что это не так, ты не нашел ничего умнее, как найти свой пример.
Декларативных примеров я тебе тоже дать могу. УК РФ, например. Но что это меняет в моих словах о том, что людям как социальным тварям проще мыслить императивно?
>А ты злой школьник
Кхе-кхе. Императивный алгоритм отвечает а вопрос "Как?". Великовозрастная сопля даже этого не может понять.
>пытается заниматься демагогией, а как только это не получается, начинает агриться
Мудила назвавший меня школьником рассуждает за аргументированность. Может ты и доказать можешь что я школьник? А я вот могу доказать, что ты дегенерат.
>Ты меня попросил дать тебе пример императивности из реальной жизни. Я тебе дал 3 штуки.
Фуфло а не примеры. Иди учи матчасть. Не забудь расписать пошаговый алгоритм, а то твой отсталый ум по другому не сможет.
>эти два дебила
Докажите уже друг другу во все дыры и пиздуйте нахуй.
>Может ты и доказать можешь что я школьник? А я вот могу доказать, что ты дегенерат.
Ты первый меня школьником назвал вот тут - .
И то и другое является примерами ad hominem и поэтому к делу отношения не имеет. Даже если я дегенерат (чего ты доказать не можешь), это никакого отношения к моей аргументации не имеет. У тебя просто аргументация закончилась и осталась голая демагогия, с приемами типа "ad hominem", "ненастоящий шотландец" и другими. Нечего сказать - давай агриться и сраться. Ну молодец, лол.
А так, ты конечно не школьник, ты просто инфантильный хуй, в обществе ничего из себя не представляющий, но компенсирующий свою никчемность нигилизмом. ФП тебе дает возможность почувствовать себя илиткой, в итоге вместо реальных достижений (например, освоения tensorflow и получения работы за много американских денег), приходится писать везде, какое оопэ отстой.
>Ты первый меня школьником назвал
Мальчик, сколько тебе лет?
По существу есть что сказать за ООП? Типа какое оно распиздатое и все такое. Начнем с того, что в гавеном ООП половина кода если не больше это бойлерплейт. Надеюсь не надо объяснять что это значит. О чем это говорит? Обилие бойлерплейт-кода призвано решать проблемы самого ООП. Это обычные костыли. Без костылей ООП не едет.
В ФП весь код решает задачу, так же как в математике. ФП ищет наиболее короткий и простой путь решения, опять же как в математике. Так нахер нужно ООП? Есть аргументы.
>ФП ищет наиболее короткий и простой путь решения
Вроде организации циклов посредством рекурсии, ага.
>Вроде организации циклов посредством рекурсии, ага.
Рекурсия не сложная, обычное повторение функции многократно. В рекурсии все прозрачно.
ПЕРЕКОТ
ПЕРЕКОТ
ПЕРЕКОТ
ПЕРЕКОТ
ПЕРЕКОТ
>Рекурсия не сложная
Чтобы понять рекурсию, нужно понять рекурсию.
Она то не сложная, да только нужна только в некоторых случаях, типа обхода деревьев. В остальных случаях циклы лучше.
ООП - лажа, набор ебучих догматов построенных вокруг перфоманс хака 20-ти летней давности, а ты ждешь от набора догм внутренней непротиворечивости уровня зрелой целостной теории.
OOD, Буч, GOF, POOD, SOLID - это лажа все, братан.
Догматы, весьма открытые для интерпретации, "паттерны", "проектирование" -- ПИЗДЕЖ
Думал миллионы мух не могут ошибаться?
Не волнуйся - все просто - они не выбирают инструментарий... Еще раз - почти все программисты не выбирают инструментарий, его выбирают те кто программистов нанимает - занавес.
Ты думал Enterprise Patterns, единая платформа и вот это вот все продавались как технологическое решение? Хуй на.
Всем корпорациям единые стандарты и пул стандартизированных и сертифицированных дятлов для написания оперденей.
Фраза "правильное ООП" - маркер гандона, который считает, что те блоги которые он читает - самые охуенные, и возвышают его над окружающей чернью.
Посмотри на историю терок про OOD, GoF, TDD, BDD, SOLID - везде догматы, хуевые примитивные примеры и поливание говном несогласных. Цифр, исследований, предметной полемики с оппонентами - нет как таковых.
Старый тред: