Что такое ооп в твоем понимании?

>>770268 (OP)
Да, если в языке есть нормальная система типов, то ООП ни к чему.

>>770268 (OP)
Альтернатива?

> Убедите меня, что ООП не полное говно без задач.
Зачем? Оно потому и умерло, что без задач.

>>770268 (OP)
Да, ООП говно. Достаточно посмотреть как идет развитие каких-нибудь проектов, которые писали хотя бы 5-10 лет на крестах. Там пиздец, мрак и ужас. 99% времени тратится на ковыряние в старом говнокоде из спагетти-многоэтажек. Но боюсь, что это проблема не самого ООП, а больших систем в целом. Написать говна можно и на хаскелле и на агде.

>>770288
>>ООП
>>умерло
Не умерло, а переродилось в современных мультипарадигменных языках.

>>770292
Вините программистов.

>>770295
Переродилось до такой степени, что типажи в расте по сути своей ничем не отличаются от классов типов в хаскеле? В новые языки наследование или совсем не завозят, или настоятельно рекомендуют его не использовать.

>>770302
А чем типажи в пидоРасте отличаются от множественного наследования в крестах ?

>>770268 (OP)
Альтернатива

>>770305
Хотя бы тем, что не имеют экземпляров и вообще не являются типами, поддерживают как параметрический полиморфизм, так и ad-hoc, не страдают алмазными проблемами, ну и так далее. Ты можешь, конечно привести какое-нибудь обмазанное шаблонами виртуальное наследование виртуальных классов, но это же не ООП, это С++.

>>770268 (OP)
Основная беда в наследовании, которое действительно только вредит, и в излишней инкапсуляции, которая полезна, но с ООП слишком чрезмерно используется.

Есть ли перевод этого поста?
http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end

>>770268 (OP)
Альтернатива?

Доставьте боевых картинок, где унижают Джаву и ООП в пользу Си.

>>770335
Не в наследовании а в множественном наследовании.

>>770268 (OP)
GoF почитаешь, тогда поговорим.

>>770292
Таки да. Линух потому и жив, что его писали на Си. Писали бы на плюсах - утонул бы в говне и ушел бы в забвение десяток лет назад.

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

Как начать жить без наследования?

>>770420
А kobjects (kernel objects) там сдуру существуют? Си-не Си, а где ООП было нужно, там оно естественно появилось.

>>770477
Интерфейсы в виде структур с указателями на функции это еще не ООП.

>>770472
Достаточно стоить код так, чтобы его части легко друг с другом соединялись. Благо, современные языки предоставляют множество возможностей для этого.

>>770472
Ампутируй органы наследования.

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

>>770479
И что же это тогда?

>>770484
Просто полиморфизм. Без ООП.

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

>>770268 (OP)
Всевозможные симуляторы, включая компьютерные игры, неплохо реализуются с использованием ООП. Тот же NS-3 без ООП сложно представить. NS-2 был говнищем ебаным.

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

>>770558
На чем сам пишешь?

>>770565
На лиспе

>>770565
На том что лучшим образом подходит для задачи, с учетом целевых приоритетов и ограничений.

>>770573
Иногда на Лиспе.
На нем очень удобно быстро закостылить прототип какой-то подсистемы, которую непонятно как лучше всего делать. Потом иногда можно переписать на чем-то другом, в зависимости от задачи, иногда можно и так оставить.

>>770268 (OP)
Очередной борщехлеб, изучивший на мамкиной шее математику, возмущается тому, что программируют не такие элитные люди как он, и им почему то хватает полутора абстракций, которые у борщехлеба, в отличие от нормальных людей, почему-то не укладываются в голове и на работу его соответственно не берут. Все что борщехлеб не в состоянии освоить объявляется им ООП, а те кто не берут его на работу - тупыми взрослыми

>>770585
>03:56
Борзехлеб борзехлеба видит издалека

>>770613
https://wiki.theory.org/YourLanguageSucks#Ruby_sucks_because

Хочешь увидеть нормальную реализацию ООП в динамических языках - смотри на CLOS.

Четыре слова: инкапсуляция, полиморфизм, абстракция, наследование.
Если тебе, оп, так не нравится то, на чём ты кодишь - у тебя всегда есть ассемблер или вообще прямые машинные коды.
Берёшь и пилишь свой язык таким, какой ты его видишь. Что ещё нужно?

>>770631
>считает ассемблер единственной альтернативой ООП-раши
>костылюция, костылеморфизм, костыляция, костылирование
Лол студентота(или ты уже джун?), ты такая няшная)))

>>770620
>CLOS
Его кто-то использует? Хотя это же скобкомирок, всегда умиляли скобкоёбы которые пишут все тот же грязный, сайдэффектный имеративный код, но только со смайликами, и считает себя илитой.

>>770631
Один из столпов ООП ты забыл, еще один (наследование) - это только инструмент для реализации в ООП другого - полиморфизма.

>Берёшь и пилишь свой язык
>Не слышал ни об одном языке, который не использует кривых ООП-костылей кроме ассемблера.

>>770633
Не считаю. Говорю же, пусть берёт машинные коды и пилит то, что считакт нужным.
Ассемблер привёл лишь как ближайший к машинному коду, который сейчас знаю.
> костыли
Велосипеды.

>>770633
И да, я не няшный. Я жирный быдло-кодер. т-т

>>770626
No true Scottsman fallacy.

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

>>770663
Возможно прозвучит глупо, но где про это можно почитать конкретнее? Мимокрокодил.

>>770663
Ебать манямирок.
Даже Кармак, адепт си, со временем дошёл до плюсов, и он же высказывался что писать даже рендер (самая нагруженная часть) без перегрузки операторов и прочего – боль.

>>770667
В исходниках UE4 или Cryengine например ссут на ебло господину выше.

>>770268 (OP)
Зачем тебя убеждать в ложном утверждении?

Eiffel - самая каноничъная реализация ООП на сегодняшний день. И смотри, что из этого вышло: http://lavironsoftware.blogspot.ru/2012/04/eiffel-studio-review.html .

>>770496
В играх вроде в основном компонентный подход, а не "чистое" ооп.

>>770673
>Ебать манямирок
https://youtu.be/rX0ItVEVjHc?t=1h23m48s
Из плюсов исползуют очень мало фич, на самом деле. Очень простой код, мало абстракций, соответственно, под каждую игру много перелопачивается. Если ты не пишешь жирное middleware вроде UE4, конечно. Там раздолье абстракций.
>даже рендер (самая нагруженная часть) без перегрузки операторов и прочего – боль
Весь рендер на видюхе сейчас. На ЦПУ только шедулер, который в комманд буфер шейдеры складывает, а в шейдерах никаких перегрузок операторов делать не надо, там для векторов все встроено.

>>770667
https://macton.smugmug.com/Other/2008-07-15-by-Eye-Fi/n-xmKDH/i-BrHWXdJ
https://www.youtube.com/watch?v=rX0ItVEVjHc
https://www.google.ru/?q=data+oriented+design

>>770673
>даже рендер (самая нагруженная часть) без перегрузки операторов и прочего – боль
А нахуя вообще там перегрузка операторов? Кто-то умножает источники света на анимированные модели? Зачем?

>>770727
>Очень простой код, мало абстракций
Хм, подожди-ка.

Движок может поддерживать, например, рендер в D39, D3D11 и OGL. Как это реализовать без абстракций? Написание всяких конструкций вида if(m_mode = MODE_D3D11) убивает на корню всю оптимизацию, ибо будут происходить регулярные ошибки branch predictor'а. А когда есть какой-нибудь AbstractRenderer, от которого наследуется 3 разных класса, то всё идеально. С виртуальными функциями проблем не будет - т.к. функции разных рендереров не перемешаны, а разбиты по файлам, то промахов кэша происходить не будет.

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

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

Вот код: http://pastebin.com/cZ0YymnV

Так вот, эффект в том, что в Debug-сборке виртуальная версия значительно медленнее, но в Release-сборке она несколько быстрее(тестировал на i7-6700K). К слову, на стареньком i5-760 виртуальная версия почему-то всегда быстрее( примерно 45с против 80с в debug и 3.0с против 3.2с в release, точных цифр особо не помню). Почему так?

>>770765
> Написание всяких конструкций вида if(m_mode = MODE_D3D11) убивает на корню всю оптимизацию, ибо будут происходить регулярные ошибки branch predictor'а. А когда есть какой-нибудь AbstractRenderer, от которого наследуется 3 разных класса, то всё идеально. С виртуальными функциями проблем не будет

Те же яйца, только в профиль

Unconditional branch, fixed target

Infinite loop
goto statement
break or continue statement
End of the 'then' clause of an if/else statement (to jump past the else clause)
Non-virtual function call

Unconditional branch, variable target

Returning from a function
Virtual function call
Function pointer call
switch statement (if compiled into a jump table)

Conditional branch, fixed target

if statement
switch statement (if compiled into a series of if/else statements)
Loop condition tests
The && and || operators
The ternary ?: operator

Conditional branch, variable target

Less likely to show up under normal conditions, but the compiler may synthesize one as an optimization, combining two of the above cases. For example, on x86, the compiler may optimize code like if (condition) { obj->VirtualFunctionCall(); } into a conditional indirect jump like jne *%eax if it appears at the end of a function due to tail call optimization.

>>770765

Изучай

http://www.codeproject.com/Articles/7150/Member-Function-Pointers-and-the-Fastest-Possible

https://hbfs.wordpress.com/2008/12/30/the-true-cost-of-calls/

>>770268 (OP)
Игровой 3D движок. Хуй ты его без ООП напишешь.

>>770765
>И опять же, как это реализовывать без абстраций?
Там DoD во все поля. Организация данных примерно как в БД (с нарушением нормализации, где производительность требует). То есть объект "робот" размазан по куче таблиц - скелеты, анимации, материалы с прозрачностью, без, и т.д. При рендере/апдейте, соответственно, ты не работаешь с абстрактными объектами через виртуальные функции, а прогоняешь таблицы через функции - отфильтровать сферические коллайдеры из таблицы со сферами, заполнив таблицу для более точно коллижена, например.

>>770772
>Unconditional branch, variable target
>Conditional branch, fixed target
Суть-то как раз в том, что в первом случае не нужен branch predictor(в ассемблере преобразовывается в конструкцию вида call dword ptr[0xbabe], а по указателю уже подставляется адрес нужной функции). Во втором уже не обойтись без него.

В итоге в первом случае оверхед - просто дополнительный переход по адресу. При хорошем кэше это вообще ни на что не влияет. Во втором случае - вероятность ошибки предсказателя. А это остановка конвейера и всё, пиздец. Тактов 7-8 очень легко потерять. Если это будет вызываться в цикле, то оверхед будет очень заметен.

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

>>770785
Ты знаешь о существовании branch prediction, но не знаешь о branch target prediction, почему так? Дочитываешь до середины, потом засыпаешь?

>>770727
>плюсов исползуют очень мало фич
А ты что ожидаешь? Что проект на плюсах обязательно вымазан наследованием в 800 предков, с шаблонной магией и виртуальной хуитой?

>>770468
Можно вообще обойтись без наследования (в Visual Basic 6 его не было, например). Любое наследование легко заменяется композицией объектов. Основа ООП (по Алану Кэю) - объекты и сообщения, которые они отправляют друг другу и обрабатывают. А "три принципа" придумал Страуструп, и они довольно сомнительны (инкапсуляция есть в любом языке с заданием области видимости вплоть до ассемблера, а для полиморфизма достаточно разрешить overload для функций).

>>770787
Ну и где процедурные/функциональные движки с йоба графоном? Вот Кармак скажем долго выебывался, а однако Doom 3 пришлось ему писать на крестах.

>>770788
Просто обо всём этом я где-то полтора года назад узнал из книжки Game Engine Architecture, где всякие промахи кэша и предсказатели переходов были рассмотрены довольно поверхностно.

>>770796
Криворукие игроделы ничего кроме сишечки не знают, щито поделать

>>770796
>Ну и где процедурные/функциональные движки с йоба графоном?
Почти везде в ААА. Сишечка в функциональном стиле - чистые функции, иммьютебл стейт все дела.Кармак почти в каждом выступлении последнее время рассказывает про прелести функционального программирования.

>>770796
>функциональные
Уважающий себя борщехлеб не будет марать руки об игори, очевидно же. Игори для детей.

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

Функциональный стиль и мьютабл-иммьютабл друг другу ортогональны, и immutable быстрым не будет никогда. Даже упоротые хаскелеры когда им надо БЫСТРО, берутся за IORef, STRef и MVar, ловко выкручиваясь тем что mutable references на immutable values это ВНЕЗАПНО не mutable variables.

>>770840
>и immutable быстрым не будет никогда
Например, пересоздавать на каждом кадре стейт игры заново, гораздо быстрее и проще, чем апдейтить мутабельный стейт.

>>770843
> пересоздавать на каждом кадре стейт игры заново
Дельты же хранить можно. При сете создается дельта которая держит ссылку на предыдущую версию.

>>770844
Нафига? Весь стейт - несколько мегабайт, максимум. Хранишь два-три кадра, при создании нового кадра копируешь предыдущий с обновлением.

>>770840
>>770814
Блядь! Я только что осознал! Рендеринг - это НА 100% функциональный стиль. Пиздеееец, я столько времени его использовал и даже не думал об этом.

Смотрите сами:
Шейдер - чистая функция. Если подать туда одинаковые буферы, одинаковые константы и одинаковые текстурвы, то и результат будет одинаков.
Более того! Всякие SetVertexShader - это функции высшего порядка.
ВСЕ объекты для контроля рендеринга - различные ID3D11RasterizerState иммутабельны.
В случае с D3D12 всё ещё круче - практически ВСЕ настройки, включающие в себя шейдеры, режим отрисовки, тип топологии примитивов и т.д., ВСЁ ЭТО упаковано в иммутабельный ID3D12PipelineState. При рендериге просто вызывается функция SetPipelineState для контроля этого! И она чистая!

Охуеть. В рендеринге СТОЛЬКО функциональщины. Я даже не знаю теперь, как к этому относиться.

>>770851
Хорошо относиться. Перестать дрочить на ООП и почитать http://okmij.org/ftp/cpp-digest/

>>770851
Охуеть открытие. Рендеринг функциональный, потому что GPU суперпараллельный, это любому должно быть очевидно.

>>770814
> Почти везде в ААА.
Примеры? Ну кроме недописанного шутера на хаскеле (да и тот по графону ближе к Quake 2). Кармак пиздеть может что угодно, вот когда очередной id Tech будет не на крестах, я ему поверю.

>>770851
Там не только шейдеры. Игровой движок это целая ОС в миниатюре. Грамотно построить архитектуру, и чтобы еще быстро работало, можно только на ООП (C++, Delphi, D или тому подобном) .

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

>>771023
>Грамотно построить архитектуру, и чтобы еще быстро работало, можно только на ООП
Нет.
Но утверждение "грамотно построить архитектуру, и чтоб еще быстро работало, и чтоб еще обязательно на С++, который только и знают криворукие игроделы, и сделать это все с помощью криворуких игроделов, которые не могут ни во что кроме ООП, можно только с помощью ООП"

>>771027
*будет правдой.

>>771027
https://en.wikipedia.org/wiki/Id_Tech_5
https://en.wikipedia.org/wiki/Unreal_Engine
https://en.wikipedia.org/wiki/CryEngine
https://en.wikipedia.org/wiki/Source_(game_engine)
https://en.wikipedia.org/wiki/Unity_(game_engine)

Все основные движки на крестах, так-то.

>>771027
> криворукие игроделы
Ну пусть борщехлеб продемонстрирует, как правильно писать.

>>771032
> и чтоб еще обязательно на С++, который только и знают криворукие игроделы, и сделать это все с помощью криворуких игроделов, которые не могут ни во что кроме ООП
Я и говорю.

>>771036
Так криворукие игроделы хоть делают и выпускают рабочий продукт, в отличие от мамкиных борщехлёбов, визжащих о превосходстве фп.

>>771023
>шутера на хаскеле
Пишут не на хаскеле, а на сишечке в функциональном стиле, без ООП.

>>771051
>на сишечке в функциональном стиле
Как на сисечке можно сделать функции высшего порядка? Путем черной магии в виде исполнения ссылки на фунцкию?

>>771032
UT, CryEngine - middleware, движок с редакторами. Остальное, считай, легаси из 90-х, написанное писишными программистами, которые консоль и голое железо в глаза не видели. К тому же там не сказано, в каком стиле у них С++.

>>771052
Под "функциональным стилем" имелись ввиду чистые функции и в основном иммьютабл стейт, отстутствие ООП.

>>771055
Больше на процедурность с иммутабильностью смахивает. Какое же это ФП без функций высшего порядка.

>>771052
http://okmij.org/ftp/cpp-digest/

>>771056
Больше всего похоже на SQL и работу с БД по стилю.

>>771049
Делает и выпускает много чего много кто.
В игродельной индустрии - там же замкнутый порочный круг. Берут только бородатых сишечников, потому что ну епта у нас же все на сишечке, они в свою очередь нихера кроме сишечки и ООП не знают и знать не хотят.
В других индустриях ФП успешно используется, в том числе и там где высоки требования к производительности, в том числе и с использованием языков Си и С++.

>>771059
SQL это декларативное функциональное программирование, чего тут удивительного.

>>771061
>В других индустриях ФП успешно используется, в том числе и там где высоки требования к производительности,
Например?

>>770409
Design Patterns in Dynamic Languages Норвига почитаешь, тогда и поговорим.

>>771063
https://wiki.haskell.org/Haskell_in_industry

>>771062
Ну я и говорю, что не все ФП выглядит как хаскел. Функциональные практики in the wild ближе к SQL чем к ML.

>>771068
На самом деле нет. У тебя по ссылке откровенное наглое вранье. Вот разоблачение:
http://flyingfrogblog.blogspot.ru/2010/05/why-is-haskell-used-so-little-in.html

>>771068
Куча нонеймов и фейсбук, интел и с ан анд т и пр. где на всю корпорацию 1 внутренняя утилита на хаскелле, ахуеть теперь.

Конкретные примеры давай. Риалтайм рендер уровня source 2 хотя бы.

>>771063
Бигдата, например, всякие Кложи-Скалы.

>>771087
И там тоже пишут основную часть на питоне/р, а все числодробилки на сях, хотя перформанс в этой области никому не всрался.

>>771078
Ну охуеть можно. ABN Amro ему нонейм. Alcatel-Lucent ему нонейм. Bank of America Merril Lynch ему нонейм.
Это я еще до буквы B не дошел.

А контора из пяти бородатых сишечников, кидающих треугольнички в GPU - доооо, это сирьооозная ендустрия.

>>771076
Я сразу говорил что речь не про Haskell, а про ФП. В перечисленных лавках, и во многих других, часто пишут на разных языках, в том числе и на Си и на С++. Но вот набирают туда людей прицельно со знанием Хаскеля. Потому что они умеют в ФП, что и нужно. А в ООП и так любая макака умеет, хрена ли там уметь. И человек умеющий в ФП, напишет и на С++ приличный ФП код, когда надо на С++.
А вот наборот получается хуево. Поэтому и слышно со стороны криворуких игроделов только нинууужна

>>771099
На питоне/р прототипируют алгоритмы, а в продакшене вся инфрастрктура на JVM.

>>771106
Продакшны разные бывают.
Cloudflare, например, на Lua.

>>771100
Человек умеющий в фп скорее нагреет процессор.

А бородатые сишники тем не менее написали явно поболее пары внутренних утилит. не знаю на счёт самого компилятора, на рантайм у хачкеля, ВНЕЗАПНО БЛЯДЬ, сишный

>>771106
Ты похоже не в курсе что за означает "бигдата". Это не хуйлоад, сам ознакомься с значением термина.

>>771115
Ну так а чего на рантайме останавливаться, давай до внутренностей процессоров и порчих железок дойдем, в которые криворукие игроделы с охуенно важным видом кидают треугольнички. А там ВНЕЗАПНО, из того самого списка

> Bluespec, Inc. Waltham, Massachusetts

> Developing a modern integrated circuit (ASIC or FPGA) is an enormously expensive process involving specification, modeling (to choose and fix the architecture), design (to describe what will become silicon) and verification (to ensure that it meets the specs), all before actually committing anything to silicon (where the cost of a failure can be tens of millions of dollars). Bluespec, Inc. is a three year-old company that provides language facilities, methodologies, and tools for this purpose, within the framework of the IEEE standard languages SystemVerilog and SystemC, but borrowing ideas heavily from Term Rewriting Systems and functional programming languages like Haskell. In this talk, after a brief technical overview to set the context, we will describe our tactics and strategies, and the challenges we face, in introducing declarative programming ideas into this field, both externally (convincing customers about the value of these ideas) and internally (using Haskell for our tool implementation).

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

>>771123
>using Haskell for our tool implementation
Ты понимаешь что сейчас сам себе в рот поссал?

>>771100
>Но вот набирают туда людей прицельно со знанием Хаскеля
Прицельно набирают спецов с нужным опытом. Хаскелиты без знания предметной области никому не всрались.
>человек умеющий в ФП, напишет и на С++ приличный ФП код
Очень спорно. ФП в основном в академиях используется, а академический год обычно не очень хорош.
>А вот наборот получается хуево
Потому что никому не нужно

>>771123
>After a bit of digging, I was horrified to discover that almost all of the "success stories" listed on the Haskell in Industry page were fakes. Anygma may ship a product in the future but do not intend to write it in Haskell. Ansemond had a product and are actually a real software company but (according to their blog) there was "no Haskell" in their product. Antiope didn't list any products at all, let alone ones written in Haskell. Bluespec were advertising their product but their customer testimonials were from "Elvis Lives", "Chicken Man", "Painful Eliminations", "Mr. Bigglesworth" and two people from the founders' University. The prominent member of the Haskell community from Credit Suisse told us that his employer was seriously invested in Haskell with over a hundred developers and that he was personally responsible for much of their Haskell development but this turned out to be another deception: Credit Suisse have over a hundred developers using other languages, he had been a large proportion of a tiny number of Haskell developers and Haskell never caught on at Credit Suisse (they are now merely maintaining legacy Haskell code).

>>771152
Компания ПРОДАЕТ тулзы для создания чипов, игродел!
Ты себе представляешь сложность этой поебени?
Или ты думаешь что скорость там никого не ебет?
Знаешь сколько времени занимает в каком-нибудь бытовом-народном Квартусе чекинг или генерация RTL? А это время - это живые деньги, если ты думаешь что для производителей чипов - то есть покупателей этих тулзов все это не имеет значения.

>>771156
>Нинуужна
Кто бы мог чего другого от криворуких игроделов ожидать.

>>771162
>Или ты думаешь что скорость там никого не ебет?
Не, не ебёт. Ни скорость, ни нагрузка.

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

>>770409
>Dynamic Languages
Зачем ты этот хлам сюда принес. Убирайся вместе с ним.

>>771064
>>771304

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

>>771312
Haskell неудачный вариант для обучения. Язык сложный, возможностей мало. Сейчас каждая макака учит Haskell, а потом не знает что делать с ним. Лучше попробуй Haskell. Язык легкий и понятный даже школьнику. Если никогда не занимался программированием, то начинать лучше всего с Haskell - после него другие языки учатся быстрее.
По книгам, что бы подготовится. Если есть хоть немного знаний программирования, читай это: http://www.ozon.ru/context/detail/id/30425643/ Если совсем новичок, пойдет эта книга: http://www.ozon.ru/context/detail/id/28346038/ Ну и куча онлайн-учебников. Вот, например: https://anton-k.github.io/ru-haskell-book/book/home.html Хороший учебник, всё расписано подробно. Сам по нему учился. Рекомендую.

>>771312
А еще в жопу все ябутся.

>>771312
https://www.ohaskell.guide/
А вообще в хаскеле конечно не хватает очередного неразобравшегося в ООП, вот прям ждут тебя, на стену лезут.

>>771592
Не посоветуешь чего почитать, чтобы в ООП разобраться полностью? Просто в большинстве книг по языкам он идёт как что-то побочное и даётся отрывками. Желательно с примерами на питоне.

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

>>771606
> в ООП разобраться полностью
> Желательно с примерами на питоне.
В голосину.

Choose your destiny:
C++ | C# | Java

>>771622
То есть на питоне ООП нинужен?
> Choose your destiny:
Ну прям сорта. Пусть будут плюсы, в них я чутка умею.

>>770268 (OP)
ООП - гоано без задач. По пунктам:
1. ООП - это экзистенциальная типизация. Но 90% программ пишутся и без экзистенциальных типов, а если они нужны, их и подрубить можно.
2. ООП - это сабтайпинг. Сабтайпинг в 99% задач не нужен, в оставшихся 0.5% он эмулируется тайпклассами (причем тайпклассы строго больше ООП, поскольку они могут в мультидиспатчинг, а ООП - нет) и еще в 0.5% extensible records-ми (причем extensible records строго больше ООП, потому что они могут structural equality, а ООП - нет).
2.5. ООП - это RTTI. RTTI не нужен, даже лень объяснять почему. Впрочем, если нужен, в нормальных языках он есть, по желанию.
3. ООП - это namespace resolver. Вот тут оно неплохО. Но есть модули, линзы, record field disambiguation наконец, короче, разрешение пространств имён в ООП реально неплохо сделано, но есть альтернативы, позволяющие делать всё то же самое, не привнося в программу минусов ООП.

Но это всё лирика. На самом деле всё зависит от программиста. И как их различить? Предложу простой критерий:
A - программист говорит, что ООП не нужно.
Б - программист говорит, что ООП нужно.
В - программист знает, чем рекурсия отличается от корекурсии.
Г - программист не знает, чем рекурсия отличается от корекурсии.
Д -программист не знает, что такое рекурсия.

Ответы:
АВ - нормальный программист
БВ - фрик
АГ - быдлокодер
БГ - быдлокодер
Д - не програмист
AБ - мастер взаимоисключающих параграфов, фрик и быдлокодер.

>>771635
>модули
В OCaml есть, в Haskell - хуй.

>record field disambiguation
Сделали только неделю назад

>>771651
Паттерн-матчинг это инструмент для диспетчеризации и, если есть сложные структуры — средство декомпозиции сложных структур (в частном случае — кортежей). Отношение к функциональному программированию он имеет, но весьма опосредованное. Есть языки с паттерн матчингом не являющиеся функциональными (Prolog) и функциональные языки без паттерн матчинга (Scheme).
В Haskell это инструмент очень низкоуровневый, если у вас в функциях огромные свитчи, то вы явно что-то неправильно делаете.

>>771651
>ООП как раз в этом плане и хорошо тем, что гетерогенный список (который нужен в разы чаще, чем множественная диспетчеризация) пишется просто и приятно
Ну конечно, особенно если завести искуственного общего предка "некий Объект" - заипись, компилятор не ругается, все прекрасно. Что толку от такой "типизации" никакой - да и хрен с ним.

Haskell - экзистенциальные типы и HList (http://okmij.org/ftp/Haskell/HList-ext.pdf, https://hackage.haskell.org/package/HList-0.4.2.0), в Scala тоже все есть.

>>771674
>HList lets the user formulate statically checkable constraints
А ты как хотел?

>>771671
>В хаскелле98
Можно еще Алгол60 вспомнить. Или первую версию Си, там даже struct не было.

>>771671
>В ООП ты делаешь IDrawable, ISerialazble, далее создаешь IDrawableSeriazableEbotable (это основной проеб ООП), и делаешь array<IDrawableSeriazableEbotable>, все. Проеб тут возникает в том, что если у тебя нет возможности реализовать интерфейс Ebotable для круга, допустим, у тебя возникнет pure virutal function call, а система типов тебя никак не проверит
Но хочу я не этого.
Я хочу сделать список, и явно указать что в нем могут содержаться только сущности типов, которые можно рисовать И сериализовывать. Просто перечислить эти необходимые свойства, а никаких еботических их гибридов не делать, потому что это костыль. И чтобы компилятор ругался когда какой-то джуниор в этот список пытался положить что-то, что либо не seriаlizable, либо не drawable.

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

Хуйня какая-то у нас получилась к 2016 году.
Смотри, в чем была изначальная претензия к ООП-дизайну? В том что он принуждает к эссенциализму, то есть структурировать сущности по тому чем они являются. Ущербность самой такой постановки вопроса и скудность термина "является" мы можем увидеть на примере птеродактиля и летучей мыши - они чем являются, и в какую стало быть иерархию их помещать - в какую не помести, все неудобно. С точки зрения летучести вроде надо к птицам, а с точки зрения, например, яиц и теплокровности - мало того что в другую, так еще и не в одну, а в разные. И выбирай по какому принципу тебе важней классифицировать, но не ошибись, потому что выбрать для удобной работы можно либо летучесть, либо теплокровность, либо яйцекладкость, и только один раз.
А ведь хочется вот здесь единообразно поработать со всеми летучими, а вот тут, столь же единообразно, уже со всеми теплокровными. То есть работать не с онтологией, прибитой гвоздями, а с ортогональными проекциями.
Придумали множественное наследование, но получилось опять не слишком заебись, из-за наследования имплементаций и традиционного для ООП state в каждом объекте, который традиционно еще и mutable - получалась каша, баги и боль.
Потом придумали отрывать имплементацию и множественно наследовать и (или) миксинить только интерфейсы. Получилось уже лучше, но все равно криво, потому что каждый раз создавать абстрактный класс, только для того чтоб перечислить в нем нужные мне в этом месте свойства - это какая-то хуита.

>>770785
>call dword ptr[0xbabe]
А что лежит в переменной по этому адресу - хуй его знает.
>Тактов 7-8 очень легко потерять
Dude, было бы это 7-8 тактов - всем было бы на это наплевать. Простой кэш-мисс - это 200+ тактов, остановка конвеера - и того больше.
Вот и приходится людям извращаться, придумывая своё ооп поверх крестов (Анальный Акробат Андрюша делал презентацию по этому поводу на цппкон14, по-моему, можешь в ютубе поискать - что-то там про кресты и производительность).
Алсо, даже ассемблерщики более пятнадцати лет назад дошли до нормального ооп, а крестобляди всё разлагаются www.wasm.ru/article/71
>>770840
>Кармак
>ничего оосбенного за всю карьеру не написав
Смешная шутка. Он написал дум, который работал на компьютерах, которые на тот момент не могли выдавать подобную графику в реалтайме. Он написал первую полностью трёхмерную игру, движок которой так или иначе является предком половины современных движков. Он первый начал опенсорсить свои движки. Он с дремучих времён участвовал в развитии опенгля (вместе со всякими нвидиями). По большому счёту, именно благодаря ему ты имеешь 3д ускоритель в пекарне. Алсо, первой игрой, использующей шейдеры, была quake 3, если я не ошибаюсь.
>>770843
Это только кажется с теоретической точки зрения. На самом деле, ты не один раз пересоздаёшь весь стейт, а по чуть-чуть его меняешь, поэтому у тебя будет огромная куча {xyu with dlina = new_dlina xyu.dlina} на кадр.

>>771698
>По большому счёту, именно благодаря ему
Да, дедушка умный, куда б мы без него.

> свет лучше чем в 2007-ом году можно сделать и делают, только не Кармак. Кармак, напоминаю, в 2011ом году выпустил игру на лайтмапах (то есть с той же технологией освещения, которую он использовал в Quake 1). Он очень умный, наверное, но не любит спешить со своими революционными алгоритмами
>http://live13.livejournal.com/423196.html?thread=1148700#t1148700

>>771698
>Очередной гениальный замысел Кармака
>Кто не знает, так работала его мегатекстура, только даже она была чуть умнее - делала feedback pass сначала и находила все страницы в сцене, но все равно это был страшный тормоз. Останавливать GPU и грузить страницу по первому fault - будет тормознее на порядки.
>большая проблема начиная с PS3 - программисты не знают и знать не хотят как работает железо не смотря на 100500 презентаций, которые для них делают. Упираются рогом и ваяют хренотень как им хочется, а хочется странного очень часто. Например, хочется continuous submit на PS4. Плевать, что тормозит не по-децки, так у них же еще там баг на баге сидит и багом погоняет. Что, конечно, неудивительно, потому что человек, который знает достаточно, чтобы его написать правильно, это делать не будет потому что этих знаний более чем достаточно, чтобы понять почему это не нужно делать
>http://kunaifusu.livejournal.com/566139.html

>>771704
Кармак, который (хуй с ним) десять лет двигал прогресс в области компьютерной интерактивной реалтайм графики, или какой-то нонейм хуй? Какой тяжёлый вопрос.
>communities
>fprog
А, теперь всё встало на свои места.
>вот, Моська, знать, она сильна, коль лает на слона
Ок, пошли по пунктам.
>Кармак, напоминаю, в 2011ом году выпустил игру на лайтмапах (то есть с той же технологией освещения, которую он использовал в Quake 1).
Ну, во-первых, в оригинальном квейке, по-моему, не лайтмапы. Но хуй с ними. Почему лайтмапы? Да потому, что выглядят охуенно. А нормальное освещение с таким же качеством тяжеловато было сделать. Потому что, всегда быстрее не считать.
>Кармак так никому и не смог внятно объяснить, что с ее помощью можно сделать такого, чего нельзя гораздо быстрее сделать без нее
Дизайнеры уровней и хуйдожники, я слышал, от неё радугой кончают. Но ещё можно вспомнить, что Кармак обосрался во второй кваке с трёхмерными взрывами. Почему? А это проблема всех первопроходцев. Сначала ты делаешь криво, потому что опыта нет, потом уже люди (ты сам), которым не нужно искать новую дорогу, кладут асфальт.

>>771708
>это проблема всех первопроходцев
Кармак у нас первопроходец.
Ебущий свою мегатекстуру с лайтмапами уже второй десяток, не сумевший сделать ни одной консольной игры, торгующий лицом (это сложно, потому что лицо-то как раз закрыто Шлемом Виртуальной Реальности - тут никто кроме Кармака не справится) в шарашках, продающих наступление эры VR под свист воздуха в надуваемом ими мыльном пузыре?

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

>>771711
>Сделай 2 копии кода, и тебя все заинлайнится и будет чики-пуки
Потом оно перестанет помещаться в instruction cache и будут только пуки, а все чики уйдут к конкурентам

>>771711
>двойного перехода указатель на объект->адрес VMT->смещение по VMT страшнее. Это, кстати, основная причина принципиальных тормозов языков типа Java.
В языках типа Java есть JIT, который, особенно при ярко выраженном наличии hot path - что бывает довольно часто - это дело оптимизнет. Но в бенчмарках этого не покажут, потому что с дефолтными настройками оптимизнет оно только через десяток тысяч итераций по этому месту, а бенчмаркальщики слишком тупы чтобы об этом знать и настройки настроить, так что до JIT в бенчмарках обычно дело не доходит совсем.

>>771671
> data Yoba = Circ r1 | Rect x1 y1 | Eboat
Про тайпклассы не слышал, не?

>>> Судя по требованию двух USB 3.0 весь трэкинг делается на CPU из сырого стрима с датчиков/камер. Это неудивительно, компьют они использовать не могут (иначе Нвидия и Вин7 и 8 в пролете), а DSP в хэдсете - а) нужно уметь и б) сделает хэдсет еще дороже

>>Блджд, шестиосевой аксель-инклинометр с калманом на борту стоит 40 центов. 40 центов, Карл! Оптовикам дают СДК к микрухе, которая позволяет задействовать нутряной ДСП для детекции жестов-хуестов и прочей хрени.

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

>>771732
Понимать может только Кармак, потому что он Кармак, понятно.

>>771723
Ты самый умный просто, долбоёб.
Иди почитай как перформанс жявы на каком нибудь benchmarksgame измеряется, потом пизди.

>>771737
Дык жабадебилы все время орут про бенчмарки, а вот попробуй любое жавопобедилие запустить и оно будет адово тормозить. Еще и ОЗУ жрать, да, но еще и тормозить. А еще это говно тормозит. Адово. Но зато бенчмарки.

>>771748
>данные акселерометра занимают так мало (килобайты полосы)
Вопрос - и нахрена ж ей джва USB 3.0 (и еще один - для контроллера, но мы не о нем)?

> Из всех "изобретений" Джона Кармака, тесселляция - единственное, что используется кем-то кроме несчастных покупателей id Tech. Наверное потому, что Кармак только хвалился тесселляцией, но так ее и не сделал
> http://kunaifusu.livejournal.com/534869.html

>>771698
>Он написал первую полностью трёхмерную игру
Нет, он на BSP в 3D сдулся, и побежал за помощью к Абрашу. С окулусом, кстати, такая же фигня. Без Абраша он долго не просидел, выписал себе помогать.

>>771787
Ну Миша, кстати, тоже люит пиздеть, какие вокруг лохи, а сам в 2011 году выпускает игру с графоном уровня 2003. Да и судя по mobygames, остальной послужной список у него не оче.

>>771793
Я к тому, что "написал первую трехмерную игру" - это довольно громко сказано.

>>771792
>Абрашу
К тому который книжку написал? Хорошая была книжка.

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

>>771811
С того что надули из него Великого Игро Девелопера, и какую бы хуйню он не нес, только и слышно про него.

>>771801
Это все любят, но его на каждой ярмарке хоть не показывают и бложек не обсуждают на каждом перекрестке

>>771817
Да и полезное что-то можно от него иногда узнать http://live13.livejournal.com/462582.html?thread=1403894#t1403894

А от Кармака только "покупай, торопись" и великие идеи о мегатекстурах будущего.

>>771831
Полезное - то что на книжку эту можно времени не тратить, не говоря уж про забивание мозгов

>>771832
"Бесполезна для ААА под консоли" не значит бесполезна вообще для геймдева.

>>771820
>А от Кармака только
Наоборот, у Кармака гораздо более интересные твитор и пейсбук. Без поливания всех говном, пещерного расизма и гомофобии.

>>771836
Ну я же не говорю что читать надо некритично, без понимания того зачем чувак пишет и какие у него в LA фрустрации, особенно глядя на Кармака.
Но именно эта едкая negativity (тем более что ее можно спокойно пропускать мимо ушей) и сопутствующий ей взгляд на какие-то вещи, события и персоны, дает возможность не только посмотреть на некоторые вещи с более других сторон чем это принято и несется из всех репродукторов, но и, что часто даже продуктивней, о чем-то самостоятельно задуматься.
Тот же GoF book намного более полезен и хорош (если, где, кому и когда он вообще может быть полезен и хорош) когда ты понимаешь откуда оно взялось, зачем, причем тут Смаллток, и кем, почему, и в качестве чего это было сделано в Симуле, и почему Алан Кей похож с одной стороны на Кармака, а с другой - на автора Хагакурэ, который тоже немного опоздал родиться и немного переусердствовал в развитии концепций того, прекрасного прошлого времени, над которыми в то, прекрасное старое время все причастные максимум пожали бы плечами.

>>771841
Что в этом треде делают леваки?

>>771850
У kunaifusu это просто через край переходит.

>>771856
Человек, измученный нарзаном.
Я когда с индусами работал, тоже порой головой об стол бился. Не столько от качества кода, сколько от attitude.
Это в Воронеже хорошо к ним относиться, когда их нет в радиусе 1000 км

>>771868
Да, это со многими так. Читаешь какого-нибудь умного (вроде бы) парня про просторы большого театра в области lockless алгоритмов, и ВНЕЗАПНО он как начнет про социальную справедливость, раскулачивание Уолл-Стрит и угнетенных (Демократами, но это никогда в сообщение не помещается по загадочным причинам) миноритис Чикагщины - хоть отписывайся.
Тэги же придумали специально для этого, но никто не пользуется.

>>771723
Давай, расскажи мне как он это оптимзирует. Что он такого делает, что двойного cache miss не происходит.

>>771881

гугли inlining of megamorphic function calls in hot inner loops

>>770268 (OP)
Я придерживаюсь СТРУКТУРИРОВАННОГО ПРОГРАММИРОВАНИЯ (СП). Мое личное изобретение.

>>771896
Никакие инлайны и девиртуализация не спасут при организации памяти в жвм с неебическими индиректами и адовым оверхедом по 500% из-за боксинга неба и аллаха.

>>771902
Поясняю. Во главе идеи - один суперобъект, назовем проектом.

Весь код это его функции и методы.

Программа запускается через метод Object.run (), который может содержать различные методы инициализации (например Object.preload (), Object.init ()).

Создание объектов происходит так, например кнопки:
>Object.create.button (..) // метод в качестве аргументов принимает параметры, положение, текст, текстуру и прочее

Все объекты автоматически получают цифровое порядковое id и ссылки на них можно найти в Object.id<objects_id>. Чтобы найти объекты не по id, а по внутреннему тегу или свойству, используется метод Object.get.object (..) - указываем что нужно найти, например пару { name: 'menu' }

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

>>771904
Java неплохо оптимизируется в тех местах где надо и тогда когда надо
http://mechanical-sympathy.blogspot.ru/2012/10/compact-off-heap-structurestuples-in.html

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

>>771912
>Java неплохо оптимизируется в тех местах
Это ебаный ад off-heap пердолинга. Проще на крестах переписать.
>которые составляют обычно 98.74% при этом не нужно
Потому что эти 98% - блоат из бесполезных ФабрикАбстрактныхФабрик, которые как-то оптимизировать можно только выкинув их совсем.

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

>>771937
Вот поэтому оптимизацией жабы заниматься абсолютно бессмысленно. Как и пытаться писать на ней что-то кроме жирного интерпрайза.

>>771939
Совсем наоборот, именно ее-то оптимизацией заниматься осмысленно.
Оптимизируя 1% критичного к производительности кода, ты получаешь 90% прироста общей производительности, весь остальной код пишут дешевые джава-макаки - это очень хороший результата в подавляющем количестве случаев.
За бортом остаются буквально считанные задачи - жесткий реалтайм, часть эмбедовки, консольные игродвижки.

>>771946
Проблема в том, что в джавакоде обычно нет 1% критической части. Потери размазаны по всему коду равномерно. А затраты на написание быстрого кода ОЧЕНЬ высоки, поскольку джава как язык не поощряет работу с примитивными типами и off-heap.

>>771951
>в джавакоде обычно нет 1% критической части. Потери размазаны по всему коду равномерно
Может быть где-то такое и бывает, но мне сходу сложно себе представить такое, процент критического кода, конечно, варьируется и 1% бывает не всегда (хотя и удивительно часто), но до 5% обычно укладывается.

>>771957
>much more FP friendly
Ты правда считаешь, что это означает, что все станут на хаскеле писать? GPU-программирование FP-friendly с самого начала, но все языки там - варианты си.

>>771964
Чистые ФП языки это маразм. Просто добавят в попсовые языки ФП парадигму. Java 8, например.

>>771965
>Java 8, например.
Ахуеть, там же лямбды и мап-редюч-И так далее в стандартной библиотеке! Ахуеть, фп язык!
Плюсы у тебя, наверно, на уровне с хачкеллем стоят?

>>771992
Так это только начало. Там еще стримы добавили, композишн, maybe-типы и все такое. А в 9ке обещают модули, настоящие.
Но там еще надо дохуя вычистить, исключения, для начала.
Ну ладно, жаба жабой, а вот в кресты ФП парадигму норм добавится.

>>771314
ВНЕЗАПНО

>>771993
Вот у анона озарение, например >>770851

>>771965
>>771995
Модули это конечно хорошо. Только и с лямбда фишечками C#, Java и подобные им "гибридные" языки останутся глубоко императивными. Все это натягивание ФП на ОПП, причем совершено не с той стороны, выглядит бредово. Принцип "снаружи ООП, а внутри методов — ФП". Какой ФП? Внутри каких методов? ФП как раз должен быть снаружи, а внутри хоть ассемблер.

Какие есть плюсы у ФП на примере хаскеля?
1) Более-менее полноценная поддержка для комбинирования комбинаторов.
2) Возможность рассуждать об этих комбинаторах как о математических объектах (с оговорками).

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

В любом же "гибридном" языке вы получаете отказ от контроля за эффектами (потому что так не бывает когда здесь контролируем, здесь не контролируем, это получается нигде не контролируем) — а это сразу значит что с рассуждениями о коде, нормальной ленивостью и оптимизациями можно распрощаться, а значит и с полноценным комбинированием комбинаторов. Даже если у нас остается у нас только более-менее полноценная система типов, то мы попадаем в мертвую зону между хаскелем и так называемыми "гибридами", забитую мертвыми ML-ями и дышащим на ладан окамлом. Это вечные девяностые — прогресс отсюда никуда не двинуть.
Тем не менее, от гибридов и языки мертвой зоны выгодно отличаются полноценными системами типов и модулей, которыми гибриды жертвуют ради использования библиотек и рантаймов популярных мейнстримовых языков, но — по всей видимости — этого недостаточно.

Обычное ООП, мейнстримовое, с сабтайпингом, а не марсианское-структурное, какое возможно в хаскеле и некоторых "негибридных" мл-ях, наносит такой удар по системе типов, что о хоть сколько нибудь полноценной поддержке ФП говорить уже не приходится. "Гибриды" любят декларировать "мультипарадигменность", но ФП там, как колбаса при коммунизме: чего не спроси — отвечают, что потребности нет

>>771964
А чего б на нем и не писать? Если роль того что крутится на CPU все больше сводится к control plane, простаивающей при этом 90% времени в виду явно избыточной для ее задач мощности современных процессоров. Все остальное (data plane) едет в GPU с SSD само, и считается там, и показывается прямо оттуда.

>>772029
>А чего б на нем и не писать?
С того, что все будет адово тормозить из-за боксинга и аллокаций. Или придется писать в стиле мало отличающемся от нынешнего.

>>772029
Я чот представил как будут работать требовательные к процессору игрушки (стратегии, игры с физикой), или насколько придётся отупить и без того ебланский ИИ в стрелялочках

Кек

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

>>772049
Вот именно – скорость кода хачкелля упирается в оптимизатор, в отличие от си.

Да и GC с увеличением кол-ва потоков увеличит оверхед, что довольно сомнительная затея.

>>772058
Качество оптимизатора Си упирается в Си.
И вот с этим ничего не поделать, и никаких прорывов впереди не ожидается - неоткуда. Алиасинг и некоторые другие проблемы вытекают прямиком из самого языка Си.
Уровень хаскельного оптимизатора совсем другой, и то что он может наоптимизировать благодаря возможности рассуждать о хаскельном коде на совсем другом уровне - и сейчас уже очень неплохо, и есть куда пилить. При этом уровень сложений в человеко-часах в современные сишные оптимизаторы и GHC отличается в какие-то дикие порядки раз.

>>772060
>Vulkan

>>772064
Что Vulkan?

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

>>772062
>Уровень хаскельного оптимизатора совсем другой
Наверное поэтому у наивного qsort на хаскеле реальная асимптотика больше n^2 из-за постоянных переаллокаций и копирования.

>>772062
Вот тут за чудо параллельность и производительность хаскеля поясняют:
http://flyingfrogblog.blogspot.ru/2016/05/disadvantages-of-purely-functional.html
>There is no efficient purely functional unsorted dictionary or set
>There is no purely functional weak hash table
>There are no purely functional concurrent collections
>Most graph algorithms look worse and run much slower when written in an FP style.
>All existing implementations of functional programming languages, both pure and impure, happen to allocate far too much by design
>Purely functional programming is theoretically good for parallelism but bad for performance in practice, which is the sole purpose of parallelism

>>772081
>The author of the post is a longtime troll.
>https://www.reddit.com/r/haskell/comments/4ogle3/post_about_the_disadvantages_of_functional/

>>772106
>мышка сломалась, кликнуть не смог
>>https://www.reddit.com/r/haskell/comments/4ogle3/post_about_the_disadvantages_of_functional/

>>772066

>>771957

>>772106
Не ad hominem, но важные уточнения контекста, для верной поправки на bias при чтении этой "критики"
> Thing is, Harrop runs a business using F# and is a known troll against anything competing with F#. His MO is to focus on minutiae and make them sound like bigger deals than they actually are. Then when asked about a limitation of F# typically responds "well you'll never need that in the real world anyway". (See his responses to e.g. http://stackoverflow.com/questions/21170493/when-are-higher-kinded-types-useful/21445106 trolling every single answer)

> https://news.ycombinator.com/item?id=11841248

>>772125
Шрифты плохо настроены?

> That said, the claim that there are no purely functional versions of certain data structures and algorithms that have the same complexity as mutable versions is true. Although its better to say that there are certain data structures / algos for which immutable versions don't keep the same performance profile.

> But that doesn't mean haskell much less FP is fundamentally flawed for those algos and structures -- it just means you use the mutable versions of them. And FP in general and haskell in particular have no problem with mutation -- in haskell you just get to be more granular and controlled with it through explicit management of effects

>>772075
Если я правильно понял о чем ты, "наивный qsort" в хаскеле это никакой не qsort, а другой алгоритм, использующий похожую идею.
>>772081
Не буду защищать хаскель, не пишу на нем и никогда не делал бенчмарков связанных с ним, но этот челик по всей видимости путает иммутабельность и ФП.

>>772132
Он не путает, у него четкая бизнес-цель.
Хэши сильно оптимизнули, кстати, после именно этой попытки Харропа доебаться до мышей.

>>772140
Ну гратц его тогда. Но из-за него же вот такие >>772143 необразованные долбоёбы лезут.

>>772143
Мы очень внимательно слушаем, в чем же именно ты нашел хуиту в этих его словах?

>>772177
Хэши в хаскеле оптимизировали, а бизнес этого чувака по F#-внедрежу, ЧСХ, сдох.
Win-Win!

>>772214
Ты сейчас его сравниваешь с сишечкой, где код хорошо описывается выражением "нам дали ведро болтов и гаек, сейчас мы легко всего в 100000 строк построим из этого синхрофазотрон ни разу не уронив себе на ногу отбойный молоток, который мы построим отдельно всего в 25000 строк" или с каким-то идеальным языком, названия которого по причине скромности не приводишь?

Раз такой пири говно льётся друг на друга рекой, попрошу толковых ораторов свыше помочь Java-даунумне.

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

Поправьте, знатоки. Реквестирую от вас roadway, только не в стиле "Ищешь сегодня книжку ..."

>>772241
Про джаву? Вот:
https://www.cs.virginia.edu/kim/publicity/pldi09tutorials/memory-efficient-java-tutorial.pdf

>>772244
Нет, в целом об устройстве ПК, принципах работы ОС, и игро-индустрия.

>>772241
> дискретная математика
Не нужна. Неплохо для умения в реляционные СУБД иметь общее представление о first order logic, и только. Нужно будет графы зачем-нибудь пораскрашивать - в справочнике алгоритм посмотришь.

> компьютерная схемотехника
Общее понимание того как устроен процессор - на уровне "есть кэши уровней 1-N, шины обмена с памятью, и более тормозная периферия, причем latency и bandwith это разные вещи"

> что-то по устройству операционных систем
Общие понятие - вот ядро, вот сисколы, вот скедулер, вот процессы, вот os-level треды, вот между ними IPC.

> и низкоуровневый язык
10 ассемблерных инструкций чтобы иногда понять не хуиты ли понаделал вот тут мне компилятор

Все остальное - разбираешься по надобности

>>772261
Пусть и суперкратко, но годно. Заскринил, будет хотя бы от чего оттолкнуться

>>772224
Так ты не путай свои стилистические идиосинкразии уровня "мда, неэлегантно у вас здесь, сударь, выходит, неэлегантно-с" с "у хаскеля проблемы с mutable state".

>>771896
Это мимо.

>>772274
И нахуя мне это говно, если я веб-программист?

>>772290
>веб
>программист

>>772274
>А потом получаем непонимание того как происходит переполнение при арифметических операциях, откуда берутся неточности при работе с флоатами и как писать/читать/менять сложные логические условия.
Человеку, который это не понимает, никакая дискретка не поможет.

>>772274
> непонимание того как происходит переполнение при арифметических операциях
Тебе дай, ты бы его циклические группы для этого учить заставил. Столкнется с этим сам - прочитает за вечер что это такое и что с этим делать.

> откуда берутся неточности при работе с флоатами
То же самое. Большинство программистов вообще ни разу в жизни с этим не сталкивались, и большинство из этого большинства - и не столкнутся.

> как писать/читать/менять сложные логические условия
Он же джавщик - значит взять Drools и поебаться с ним на выходных. Когда и если возникнет надобность. После выходных поймет что не совсем понимает как эта хуйня работает - возьмет книжку, почитает.

В процессе решения конкретной задачи все на порядок лучше осваивается и выучивается чем этот стандартный bottom-up подход "докажем пока все теоремы из первого тома, а зачем мы это делали вы узнаете на пятом курсе"

>>772290
Даже веб-программисту надо знать законы де Моргана и понимать, почему вдруг оказалось, что 30%*70% != 21%.

>>772290
Переполнения и флоаты - чтоб считать.

писать/читать/менять сложные логические условия - чтоб, например, валидатор был нормальный, а не лапша из 50 if-ов, причем на каждую формочку своя, совпадающая с остальными на 90%

>>772297
Ему бы про транзакции хотя бы самые основы понять, 21% это хоть сразу вылезет и нащальника надает

>>772300
>писать/читать/менять сложные логические условия - чтоб, например, валидатор был нормальный, а не лапша из 50 if-ов, причем на каждую формочку своя, совпадающая с остальными на 90%
Мне за это заплатят больше? Нет? Ну и иди нахуй со своим задротским говном, мне и без него неплохо живётся.

>>772297
Ну-ка расскажи, почему 30%*70% != 21%.

>>772290
Тогда нахуй ты вы этот тред вообще защёл? Ухади.

>>772300
Ебать ты хуйню написал. Челик без знания дискретной математики по твоему не способен написать что-то, отличное от 50-и ифов?

>>772297
>>772306
И почему же не 21%? Объясните, а то я такой тупой, даже дискретку не знаю.

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

>большинство из этого большинства - и не столкнутся.
Потому что руководство не доверит им работу на которой с такими проблемами можно столкнуться.

>Он же джавщик - значит взять Drools и поебаться с ним на выходных. Когда и если возникнет надобность.
Когда он напишет что-то вроде !(!A || !B) у него ничего нигде на защемит, и необходимости что-либо читать он не осознает.

>>772315
>>772328
Нахуя? Вы с этим не столкнётесь. А если столкнётесь, то возьмёте книжку и за вечер всё выясните.

>>771671
>Это не я делаю, это тот, у которого "90% программ пишутся и без экзистенциальных типов" так делает.
Откуда этот фантазёр знает как я делаю?
>В ООП гетерогенные списки везде
В ООП нет гетерогенных списков, обмудок, единственный ОО-язык который их позволяет делать - это Скала.

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

Я тут за математику сел плотно. Алгебра + Лин.Алгебра + Тригонометрия. Плюс комбинаторика.

Что посоветуешь по дискретной математике? Что ещё добавить?

>>771661
>и функциональные языки без паттерн матчинга (Scheme)
На основании чего ты считаешь схему функциональным языком? Да и паттерн матчинга нет только в стандарте, в котором есть средства для его реализации (коих немеряно).

>>772468
А на основании чего ты её таковой не считаешь? В твоем представлении ФП = ML-like?

>>772485
ФП = функциональная чистота.

>>772468
>коих немеряно
Чего-чего немеряно? Реализаций сопоставления с образцом на схеме? Их, полноценных, едва ли на пальцы одной руки хватит.

>>772491
Да хуле ты к словам цепляешься, епты бля. Главное, что они есть. А вообще, почти в каждой имплементации есть своя реализация, в chicken есть, в guile есть. Ну и каждый уважающий себя скобкоеб писал свою, я, например, писал

>>772489
Схема достаточно чиста. Но а если уж совсем занудничать, то может оказаться, что в мире нет ни одного функционально чистого языка.
А вот отсутствие АТД и сопоставления с образцом в схеме делает её менее ФП в моём представлении.
>>772513
Писал-то каждый, но пригодных для применения из них - единицы.

>>772311
Тебя за это не заставят до 12 в офисе сидеть.

>>772549
Меня и так не заставят

>>770300
>На ООП хорошо ложатся некоторые задачи, например всякие там ГУЙовины

О, дружище, "ООП хорошо для GUI" - это примерно такой же спид, как и "ООП хорошо для всего" - когда программисты обожглись об ООП, но проблемы гуйни глубже формошлёпства не исследовали, поэтому решили "ну ладно, ООП для %моей_предметной_области% - говно, но ведь КНОПКА - это же объект!!1". Ты ведь понимаешь, о чем я, а уёбок? Повторю другими словами на всякий случай: когда ты был маленьким и глупым и нихуя не шарил в своей предметной области, ты думал, что "всё есть (некий абстрактный) объект (про который я нихуя не знаю)" и что ООП идеально этот факт моделирует. Потом ты немного подрос и поумнел, и выделил в своей области множество взаимосвязей и закономерностей. И она наполнилась морфизмами, функторами, отражениями, естественными преобразованиями, пределами, копределами, сопряжениями и прочими знаниями, для моделирования которых убогое ООП ну никак не подходит. А гуй для тебя так и остался той областью, в которой ты нихуя не шаришь. Так вот, уёбок, не надо экстраполировать свою самоуверенность на все отрасли человеческой деятельности. Если ты охуенный спец по обработке сигналов, это еще не значит, что ты охуенный спец по чистке туалетов или лепке крудов. И если ты не видишь в лепке крудов никаких закономерностей, это еще не значит, что их там нет, и что любой виджет есть объект и не более того. Закономерностей там более чем дохуя. Я вот с ходу могу сказать, что гуйню лучше моделировать стрелками, чем объектами, а истинный спец по гуи тебе наверняка категорий пять навернёт, охватывающих визуализацию, валидацию, интернационализацию и локализацию, лейаут, помощь людям с ограниченными возможностями и хуй знает, что там еще может быть.. Поэтому пиши про то, что знаешь, а про гуй пусть лучше спецы по гуи напишут, от них то мы и узнаем, столь ли там хорошо ООП, или приходится еще каким-нибудь xml-ем в жопу поябываться.

>>770268 (OP)
>ООП сложно, оно не нужно, я не осилил

Класс - это тупо программный модуль, изолированный средствами языка. Ты можешь писать на сях изолированные модули, можешь на плюсах в виде классов. Реальное ООП как в смартталке (или как его) не реализовали ибо там помоему упорото совсем.

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

ВСЕ, никакие блять наследования и полиморфизмы и использование повторного кода, а тупо возможно разбиение макак одной задачи на группы и увеличить скорость разработки - рынок решил (а не программисты, как они свято верят в это)

>>770268 (OP)
Блядь, всегда проигрываю с того, когда прилетают сюда обладатели функциональщины головного мозга(хотя сам ФП котирую) и начинаются кукареки с линзами, бананами, гиломорфизмами, классами типов и пр. При этом всегда уходят в крайности: ООП маздай, пыхопидоры сосут, крестоблядь не человек. Вот только, вероятно, у большинства здешних "мамкиных хаскелистов" проектов больше 20к строк кода и не было, а гитхаб акк так и не наполнен проектами на божественном ML/Haskell/Agda(если вообще наполнен).

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

Ты прав, скорее всего будет именно так.
Но накачивать ньюба всем около-CS матаном под завязку - тоже не выход. Без реальной задачи и потребности ее решить (а не "сдать курсовик" и подобное) КПД будет меньше чем у паровоза.
Люди делятся на тех кто хочет сделать по-человечески и да нахер оно мне надо, и так платят (>>772311). С первыми вариант "почитать книжку on demand" работает, со вторыми не работает ничего, хоть в Стэнфорд его отправь. Традиционный ВУЗоподход в результате бессмысленно мучает первых и никак не влияет на вторых.

>>772633
> программисты обожглись об ООП, но проблемы гуйни глубже формошлёпства не исследовали
Те кто исследовал ЧСХ придумали functional reactive programming а никакое не ООП.
> лейаут
Отлично ложится на комбинаторы.
https://www.youtube.com/watch?v=fRdU5yHsAA4
Заодно ответ на >>772676

ООП хорошо подходило для сочетания двух условий - "у нас есть задачи дискретно-событийного моделирования" и "у нас есть Algol60 и больше нихуя". К Алголу60 оказалось очень легко прикрутить несколько полезных (для той задачи) хаков, которые (на тех компьютерах) еще и были дешевы в смысле скорости. Сначала они хотели сделать препроцессор (что логично - Страуструп через много лет тоже начал с этого и собирался этим и ограничиться), но им понадобились и некоторые другие расширения Алгола и ограничиться препроцессором не удалось.

И все эти "Концепции ООП" появлялись именно таким способом: вот интересный (и дешевый в реализации) эффект — как мы можем его использовать? Началось все с того, что понадобилось придумать новый (быстрый) способ передачи параметров в процедуры. Стандартные алголовские способы: по значению и по имени были медленными по разным причинам. Тогда Хоар изобрел ссылки и null. Раз уж структурная эквивалентность оказалось сложной в реализации, сравнивать стали адреса, по которым "объекты" располагаются — появилось identity. Обратили внимание на то, что блок памяти B, структурированный в начале так же, как и блок A можно обрабатывать процедурами, написанными для работы с A — появился "префиксинг" (даже синтаксически объявление класса родителя было префиксным), под который потом подвели идеологию и назвали "наследованием" (ну и понятно, почему сначала никаких "множественных наследований" не было — что такое "множественный префиксинг"?). К рекордам добавили процедуры, диспетчеризующиеся по одному аргументу. Почему именно по одному? Потому что по n > 1 — сложно в реализации.

Прекрасно решили свои задачи дискретно-событийного моделирования, на тех компьютерах что у них были, и успокоились. Но пришел Алан Кей и все испортил. Кей и прочие смолтокеры захотели сделать не такой вот "натянутый" на структурное программирование ООП, а идеологически чистый и непротиворечивый. Для этого они подвели базу под все эти технические срезания углов. Получилась чистая реализация идей, придуманных для быстроты и простоты реализации, только медленная и сложная. Они не смогли все это заставить вертеться с приемлемой скоростью до 90-х годов, когда стало уже поздно. Чтоб ввести Симула-лайк ООП в мейнстрим понадобилось только (временно) отказаться от сборщика мусора. Однако, вся философия и методология ООП, паттерны и юнит-тесты и т.д., придуманные смолтокерами не пропали, а были адаптированы мейнстримом.

Смолток — это не "изначальное древнее ООП", а возрождение умирающего старого и реформация неправильного ООП, загнувшееся, правда, раньше нем неправильное, пока по настоящему древнее ООП все продолжало умирать. Ну и, понятно, философия ООП, которая превратила все картины, загораживающие дырки на обоях, в "краеугольные камни" концепции и "имманентные особенности человеческого мЫшленья"

>>771716
> то же самое что автомат для стрижки - который тоже неплохо работает, если у клиента голова квадратная

Но иногда это самый правильный подход - оквадратить головы.

> But we should not be too quick to cast aside our OO tools. For an internal business tool, we can be the American Psychiatric Association - forcing users to agree on a single unambiguous classifaction, to draw lines in the sand that are arbitrary (“5 months of grief is normal, 6 months is depression”) but nonetheless very useful. In some organizations I’ve found that the very process of codifying the rules - forcing business users to agree once and for all on whether the tripartite division of a Hong Kong contract is the same thing as the bipartite split of a three-part London contract or a different kind of thing - is, if anything, more useful than the working software we produce. Done well, the resulting software can be more authoritative, more discoverable, perhaps even more correct than the loose-schemaed functional equivalent.
> http://m50d.github.io/2014/12/08/object-oriented-essentialism.html

>>772391
>единственный ОО-язык который их позволяет делать - это Скала
Потому что это единственный язык с неигрушечной типизацией ООП.
Цену за это пришлось заплатить такую, что хуйзнает, надо ли все это было делать.
В общем-то нет языка, который может "запарить" мозг сильнее, чем скала. Скала имеет мозговыносящую систему типов, не имеющую аналогов в том смысле, что нет другого языка, в котором ООП было бы адекватно статически типизировано. Это крайне сложная и амбициозная задача, буквально все остальные создатели ООЯ на каком-то этапе плюнули и решили: "Статическая типизация — это сложно, лучше будем динамически кастить". Правда, весь этот околодинамический цирк с конями в скале остался "для совместимости" (и дополнительного выноса мозга)

На ОО Objective-C и Swift пишутся программы для лучшей ОС, которую используют программисты в достойнейших компаниях – macOS. А если работодатель не купил вам аймак или макбук – значит, он жид ебаный.
По поводу Obj-C – ладно, плохой аргумент, просто какой язык использовался Эпплом с 1983 года, такой и остался, с небольшими изменениями.
Но Swift разработан с учётом всех best practices. И всё равно имеет ОО парадигму.

>>772530
>Схема достаточно чиста.
Что значит "достаточно" чиста? Если одна и та же функция может выдать разный результат при одинаковых аргументах, то ни о какой функциональной чистоте и речи быть не может. А еще call/cc, где континуация не то, что не возвращает ничего (что уже противоречит принципам фп), она не возвращается в принципе.
>АТД
Какое там адт, когда типов, в принципе, нет.

>>772794
>Swift разработан с учётом всех best practices
Как же, как же, помним, помним.
iPhone был тоже "разработан с учетом всех best practices". До какой версии в нем не было даже copy и paste? НИНУЖНА ведь.
iPad тоже был "разработан с учетом всех best practices". Сколько лет у него не было номрального стилуса? НИНУЖНА ведь.
Вот и в этом уёбище все то же самое. Огрызкопрограммистам ничего не нужно, у них есть iTunes, AppleTV и XCode.

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

>>772799
>Сколько лет у него не было номрального стилуса
Вот что действительно не нужно. Удачи им с их стилусами по 100$, который при этом отсосёт с заглотом у проф. стилусов для рисования за ту же цену.
>Вот и в этом уёбище все то же самое.
Да нет, это ты уебан просто, не сравнивай свифт с го.
Алсо, он у эпла как оарп у майкрософта – компания его спонсирует, но ничем анально не ограждает.

>>772804
>оарп
Шарп

>>772804
Стилус - не для рисования, уебан ты эдакий.
Это на огрызках с ним больше ничего нельзя кроме рисования сделать, потому что десятилетия НИНУЖНА привели к тому у огрызка вместо поддержки стилуса в приложениях, SDK и API, пронизывающих всю экосистему (https://blogs.windows.com/buildingapps/2016/04/06/create-ideate-and-collaborate-build-apps-powered-by-windows-ink/) нет НИХУЯ кроме "можно нарисовать котика! yay!"

>>772804
>не сравнивай свифт с го
Я и не сравнивал, но ты сам проговорился.

>>772808
Стилус в таком устройстве – бесполезная хуйня ради хуйни, как и на телефонах.
>Я и не сравнивал, но ты сам проговорился.
Я-то в чём оговорился, поехавший мамкин нищеброд-борщехлёб? Это модерновый язык, в котором куча фич, в том числе и из функциональщины, без "нинужна" как в го.

>>772810
>куча фич, в том числе и из функциональщины
Огромная-преогромная. Даже до лютой императивщины Java 8 как до Луны, не говоря уж о C#.

>бесполезная хуйня
Ясно, понятно. Не видел, не пробовал, не знаешь.
НИНУЖНА

>>772800
Не, я хуйню сказал, "ничего" в схеме это тоже объект. Но акцент был вот на этом:
>она не возвращается в принципе

>>772814
>объект
Значение.
fix, не спал сутки

>>772813
>Даже до лютой императивщины Java 8 как до Луны, не говоря уж о C#.
Щас бы написать хуйню не видев кода на свифте...
>НИНУЖНА
Ну и нахуя же он мне на системе, разработанной для тыканья пальцем? Можешь дальше свои окошки в оконном режиме на шиндовз планшетах двигать им, оч полезно.

>>772813
Ах да, ты же скинул видосик где им пишут заметочки и рисуют! Ахуеть полезность!

>>772819
Ясно, понятно. Не видел, не пробовал, не знаешь.
НИНУЖНА

>>772798
>А еще call/cc

Которое НИНУЖНА

>Это вполне реализуемо в языках с полноценным call-with-current-continuation, то есть код функции будет одинаковым для T, для AnyMonad<T>
>https://rsdn.ru/forum/philosophy/5428281.1

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

На десктопной ос в планшете ясен хуй что без него всё печально, чо уж. Не можем разработать ПО - разработаем палочку с блютусом.

>>772808
Стандартный аргумент когда больше нечего противопоставить:
- Смотри, а я на голове стоять умею!

>>772825
А чо, кто-то кроме огрызка выпускает нормальные планшеты, а не хуйню на яве без планшетных приложений/хуйню с десктопной ОС, которая либо ебаный кирпич похуже любого ноутбука (но не может его заменить при этом) либо приложений нет вообще (НИНУЖНА!), и хоть один конкурент у огрызковых планшетов по соотношению батарейка/эргономичность есть?

Нету => конкуренция говно без задач.

>>772766
>только медленная и сложная
Чистое ООП вообще очень сложно сделать быстрым. В чистом ООП уровня смолтока или джавы без примитивов, все функции должны быть виртуальными, все объекты должны создаваться в куче и менеджится сборщиком, работа с объектами только через ссылки. Естественно, такой язык быстрым быть не может, поскольку на железо не ложится никак.

>>772820
Стилус на экранах меньше 20 дюймов - бесполезная игрушка. У стилуса точность меньше, поэтому приходится писать заметки буквами в два-три раза больше чем на бумаге. При рисовании приходится непрерывно зумить и скроллить, постоянно мешаешь себе пальцами. Как баловство и для быстрых набросков подходит, для более-менее серьезной работы - нет. Хочешь рисовать на экране - копи деньги на большой синтик, или привыкай к обычному вакому.

>>772834
>уровня смолтока или джавы
>уровня квантовой физики или школьной арифметики
>уровня круизного лайнера или утлой лодочки

>>772842
Да хоть уровня скалы и жабоскрипта, общие недостатки-то одни и те же у всех ООП языков.

>>772865
Поэтому его моментально выкинули на помойку с появлением джавы.

>>772867
Если бы вместо джавы IBM, Sun и все-все-все решили бы дать миру INTERCAL, ничего бы не изменилось, писали бы все на INTERCAL как миленькие, точно так же как на Java.
Язык в успехе Java никакой роли не играет, как и в успехе Javascript, например.

>>772878
У хаскеля нет проблем с mutable state. Могу еще раз повторить.

>>772894
С системой типой, тотальностью, выводом типов, зависимыми типами, template haskell страшненький. Да много с чем.

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

Меня просто вымораживает ситуация вокруг haskell.
С одной стороны барьера сидят "хаскелисты", осилившие только скрипты писать да конфиг xmonad настроить, фанатично приравнивающие haskell к ghc, не слышавшие о большинстве type экстешонов их любимого компилятора, не понимающие в чём проблемы с RankNTypes, почему и зачем в Clean были введены афинные типы, а в MLKit — регионы.
Но самое смешное, — их противники. Представьте себе любителя эзотерических язычков, орущего о том, что хаскель переусложнённый, а самое главное — о непопулярности оного. Забавно наблюдать подобные заявления от фанатика схемы или, например, Go. Но любое упоминание хаскеля у них вызывает какой-то нерациональный слепой приступ ярости и душевной боли.

>>772894
Всё довольно просто. В ghc (и вообще классических компиляторах haskell) монада IO является особой, несмотря на то, что формально type IO = State RealWorld. Использовать RealWorld вне этой монады не стоит, — ведь ничто не мешает накастовать на него \a -> (a, a), а потом засунуть один из экземпляров абы куда и там его "потерять", то есть доступ к RealWorld в haskell равносилен нечистоте языка (и вообще жутко неэффективно, ибо оптимизации ghc расчитаны на работу с монадой IO (основной аргумент против введения линейных или хотя бы афинных типов как раз то, что большой кусок ghc должен быть переписан)).
Чтобы решить эту проблемы придумали афинные и линейные типы, — первые позволяют использовать значение этого типа не более одного раза, а вторые — ровно один раз. По факту RealWorld должен быть линейным, но в Clean его сделали афинным, — терять его всё равно нельзя, ибо если потеряешь, то не сойдётся тип main'а.
Тут важно заметить, что использование оных не отменяет возможности (да и банальной потребности в удобном интерфейсе) использовать монаду IO, только теперь она будет иметь вид State !RealWorld, где ! — обозначение линейности/уникальности.

>>772908
копипаста http://juick.com/Elemir/2246125

>>772903
Скорее по сравнению с сишкой/явой хакель прозвучит так:
>чтобы моя яхта плыла, мне нужно вывести типы и зачекать, доказав ей её же правильность, но плывёт она не быстрее черепахи – нужно боксить каждую молекулу воды и преобразовывать руками каждый тип молекулы воды, отличающийся от H2O - добавки соли, например. И самое главное – это всё нужно делать массовым копированием воды чистыми функциями.

>>772913
И телевизор на такой яхте, без IO, кстати, работать точно не будет.

>>772916
Зачем же без IO?

>>772917
Так иначе она уже не чистая, как же главный канон фп?

>>772919
Так и хаскель не чистый, на нем императивно писать можно не хуже чем на джавочке

>>772920
Может у тебя ещё всё мутабельное? Не нужно брать одну молекулу воды, и возвращать модифицированную копию?

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

>>772922
Если не нужно - не нужно. Если нужно - то нужно.
Хаскель позволяет делать и так и так.
При этом четко очертить и разграничить одно и так от другого и так как тебе надо, проверять это и не заставлять все это проверять тебя - вся прелесть именно в этом

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

> Система типов-то у хаскеля как раз нормальная
Компромиссная. С чаще всего работающим выводом типов.

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

> одна из самых полных и новых книжек по realizability in category theory. Тут есть практически все важные модели и результаты в области описания рекурсивной математики категориально-порядковым языком. Порог вхождения, правда, высокий, — автор предполагает, что читатель неплохо разбирается как в теории категорий, так и в теории порядка.

> http://www.staff.science.uu.nl/~steke104/proefschrift2.pdf

> Если хочется сначала вникнуть в эту область, то рекомендую начать с монографии Oosten'а "Realizability — An introduction to its categorical side". Тут есть основы и превосходно освещается привычная для рекурсивной математики категория Eff (По сути категория марковского конструктивизма)

>>772942
Я не знаю какие тезисы можно привести в ответ на утверждение о том что людей не волнует корректность их программ, они не хотели бы облегчить себе управление сложностью, помнят весь свой код наизусть (а чужого им не надо), и подобные им.
Мне кажется что адекватный человек таких утверждений делать не станет, а как что-то объяснить человеку неадекватному - я в этом не специалист, этому люди долго учатся, им потом специальные халаты выдают с дипломом.

>>772942
>Scala
>становится популярной
Scala практически загнулась уже.

>>772927
>они и так в курсе, что проиходит в их коде
Вот это неверный тезис. Большинство багов в программах, потому что программисты не понимают, что на самом деле происходит в их коде.

>>772894
У хаскиля везде всё заебись. Нет кода - нет проблем.

>>772798
>Если одна и та же функция может выдать разный результат при одинаковых аргументах, то ни о какой функциональной чистоте и речи быть не может.
Тогда у нас нет чистых ФЯП.
>А еще call/cc, где континуация не то, что не возвращает ничего (что уже противоречит принципам фп), она не возвращается в принципе.
Продолжение и не может ничего вернуть, учи мат.часть
callCC :: ((a -> ContT r m b) -> ContT r m a) -> ContT r m a

>>772814
>>она не возвращается в принципе
man CPS

>>772633
Ололо! Какая смсачная ФРУСТРАЦИЯ!
Продолжайте, нам очень интересно.

>>772961
В сишных программах не бывает багов.
Во-первых, сишники всегда знают что происходит в их коде.
Во-вторых, сишные программы настолько быстры, что баги просто не успевают происходить.

>>772987
ахахах, а ну тогда ЯСНА
прикольно зашутил братуха))

> Functional Programming Can Work for Games
> Why I set out to prove that functional programming could work for games, and what it might mean for modern game dev
> https://medium.com/@bryanedds/functional-game-programming-can-work-95ed0df14f77

https://twitter.com/hanpari/status/743889393124057090

> The results of the 2016 Stack Overflow Developer Survey are in! F# came out as the single most highly paid tech worldwide and is amongst the third top paying techs in the US

> https://fsharp.tv/gazettes/f-the-most-highly-paid-tech-worldwide-in-2016/

https://twitter.com/dsyme/status/741289272809033728/photo/1

>>772804
>не сравнивай свифт с го.
Го не нужен. На свифте уже пишут бэк. Kitura, vapor, Perfect

> F# in the real world
> In this talk we discussed a number of real world use cases of F# at Gamesys
> http://www.slideshare.net/theburningmonk/f-in-the-real-world-ndc/4-1MILLION_USERSACTIVEDAILY

>>773047
Фигня. Кванты писали и будут писать на крестах

>>773064
Вчерашний день. Кванты пишут DSL для аналитиков, чтоб те сами 90% писали.

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

Всё это можно было делать и в модульном программировании.

Вообще ООП говно, потому что его даже нельзя формализовать. А значит это просто гуманитарное словоблудие и нинужно.

/тред

> subhuman
> fleas = 14
axaxaxaxxax

>>773099
>его даже нельзя формализовать
Обоснуй свой вскукарек.

>>772927
Зависимые типы далеко не только про «давайте чекать на тайплевеле вообще все», а проблема хаскеля не в изоляции IO, а в том, что он использует монады вместо эффектов для этого.

>>773110
Ну Лука Карделли пытался, но нихуя не получилось же. Даже определение композиции не осилил. А все потому что ООП - обычная такая надстройка под процедурщиной, которая по строгости и уровню формализации является чем-то средним между философским трактатом и юридическим договором. Гуманитарная дрисня в общем. Для даунов.

Поэтому ты либо инженер и пишешь команды на асме, либо прикладной логик-алгебраист и пишешь на Coq и LambdaProlog. Остальная пиздобратия - обычные гуманитарные офисные питухи.

>>773128
>над

>>773125
Олег уже работает над этим.
Но эффекты тоже всех проблем не решают.

>>773128
>либо инженер и пишешь команды на асме, либо прикладной логик-алгебраист и пишешь на Coq и LambdaProlog
Не вижу здесь никакого либо.
Высокоуровневую логику - на языках высокого уровня, необходимые для требуемого быстродействия части - на языках низкого уровня, если нужен небольшой (или большой) rule engine - либо берешь готовый, устраивающий тебя, либо быстренько пишешь на коленке небольшой Prolog - ну, идея понятна.

>>773159
Это сказал Бисмарк еще в 5 веке до нашей эры

>>773165
Это сказал Рем при основании Рима хуй знает сколько веков назад до н.э.

>>773171
Но Рема замочили еще в 1934 году

>>773176
Он вирус скачал и у него брат умер, ты с Ромулом попутал.

>>771178
YO!

>>773159
Дауны не могут в формулу Бине.

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

>>773444
Ну, щас-то хаскель в индустрии массово применяют. Вакансий больше, чем на джаву.

>>773481
В той статье аргументы малость протухли. Например, в хаскель завезли stack, а опенсорц стал нормой.

>>773481
Мартыханских вакансий конечно больше на джаве, но если говорить про что-нибудь нормальное, то там будет Хаскель.

>>773128
>Ну Лука Карделли пытался
О, анон, ты походу его читал. Собираюсь тоже почитать. Интересно хоть?

>>772766
>Олег Заимкин.
У него есть блог?

>>770420
> Линух потому и жив, что его писали на Си
У линукса очень маленькая сложность как у системы. Там, упрощённо говоря, есть некоторая центральная часть типа управления памятью и проч. + куча драйверов. Добавь 100 драйверов или выкини, изменится только суммарное число строк, но не сложность архитектуры.

>>773128
Почему это не получилось? Очень даже получилось. Только у него говно получилось, длинное и бесполезное.

>>770795
>Можно вообще обойтись без наследования
Можно обойтись без наследования, классов, исключений, функций и много всего другого.
Можно обойтись без ног, рук, одной почки и одного лёгкого. Без глаз, ушей и языка. Только вот жизнь станет немного скудной.

>>770394
>Не в наследовании а в множественном наследовании.
Не применяй там, где не надо, вот и всё.

>>770268 (OP)
> Убедите меня, что ООП не полное говно без задач.
Убеди меня, что ты не хуй.