Это копия, сохраненная 26 июля 2016 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Да, если в языке есть нормальная система типов, то ООП ни к чему.
Альтернатива?
> Убедите меня, что ООП не полное говно без задач.
Зачем? Оно потому и умерло, что без задач.
Да, ООП говно. Достаточно посмотреть как идет развитие каких-нибудь проектов, которые писали хотя бы 5-10 лет на крестах. Там пиздец, мрак и ужас. 99% времени тратится на ковыряние в старом говнокоде из спагетти-многоэтажек. Но боюсь, что это проблема не самого ООП, а больших систем в целом. Написать говна можно и на хаскелле и на агде.
Вините программистов.
А вообще ООП говно, потому что только его не хватает, приходится обмазываться компонентным подходом и всем таким.
Переродилось до такой степени, что типажи в расте по сути своей ничем не отличаются от классов типов в хаскеле? В новые языки наследование или совсем не завозят, или настоятельно рекомендуют его не использовать.
А чем типажи в пидоРасте отличаются от множественного наследования в крестах ?
Альтернатива
Хотя бы тем, что не имеют экземпляров и вообще не являются типами, поддерживают как параметрический полиморфизм, так и ad-hoc, не страдают алмазными проблемами, ну и так далее. Ты можешь, конечно привести какое-нибудь обмазанное шаблонами виртуальное наследование виртуальных классов, но это же не ООП, это С++.
Основная беда в наследовании, которое действительно только вредит, и в излишней инкапсуляции, которая полезна, но с ООП слишком чрезмерно используется.
http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end
Альтернатива?
GoF почитаешь, тогда поговорим.
Таки да. Линух потому и жив, что его писали на Си. Писали бы на плюсах - утонул бы в говне и ушел бы в забвение десяток лет назад.
>Не в наследовании а в множественном наследовании
В любом наследовании. Беда наследования в том, что оно пытается сущности представить в виде иерархии, что возможно только в очень редких случаях. Это понятно каждому, кто пытался отсортировать файлы на диске. Множественно наследование как раз костыль, с помощью которого от древовидной структуры пытались уйти.
А kobjects (kernel objects) там сдуру существуют? Си-не Си, а где ООП было нужно, там оно естественно появилось.
Достаточно стоить код так, чтобы его части легко друг с другом соединялись. Благо, современные языки предоставляют множество возможностей для этого.
Ампутируй органы наследования.
>чтобы его части легко друг с другом соединялись
Проблема в том, что они легко соединяются только в момент написания. А через полгода, например, уже далеко не легко.
Просто полиморфизм. Без ООП.
Ну, допилить до состыковки проще, чем перепиливать иерархию наследования. Особенно, если предусмотрена какая-либо гибкость.
Впрочем, твой вопрос формулируется проще: «как строить архитектуру приложения так, чтобы через полгода не пришлось всё выкинуть и начать заново?».
Всевозможные симуляторы, включая компьютерные игры, неплохо реализуются с использованием ООП. Тот же NS-3 без ООП сложно представить. NS-2 был говнищем ебаным.
Чаще всего используется для костыльной эмуляции простейшего полиморфизма, потому что в типичном ОО-языке никаких других средств для этого не предусмотрено.
С модульностью то же самое.
На том что лучшим образом подходит для задачи, с учетом целевых приоритетов и ограничений.
Иногда на Лиспе.
На нем очень удобно быстро закостылить прототип какой-то подсистемы, которую непонятно как лучше всего делать. Потом иногда можно переписать на чем-то другом, в зависимости от задачи, иногда можно и так оставить.
Очередной борщехлеб, изучивший на мамкиной шее математику, возмущается тому, что программируют не такие элитные люди как он, и им почему то хватает полутора абстракций, которые у борщехлеба, в отличие от нормальных людей, почему-то не укладываются в голове и на работу его соответственно не берут. Все что борщехлеб не в состоянии освоить объявляется им ООП, а те кто не берут его на работу - тупыми взрослыми
https://wiki.theory.org/YourLanguageSucks#Ruby_sucks_because
Хочешь увидеть нормальную реализацию ООП в динамических языках - смотри на CLOS.
А кто сказал, что должна быть древовидная иерархия?
У меня наследование используется только, если мне надо получить набстройку над определенным типом.
Если тебе, оп, так не нравится то, на чём ты кодишь - у тебя всегда есть ассемблер или вообще прямые машинные коды.
Берёшь и пилишь свой язык таким, какой ты его видишь. Что ещё нужно?
>считает ассемблер единственной альтернативой ООП-раши
>костылюция, костылеморфизм, костыляция, костылирование
Лол студентота(или ты уже джун?), ты такая няшная)))
>CLOS
Его кто-то использует? Хотя это же скобкомирок, всегда умиляли скобкоёбы которые пишут все тот же грязный, сайдэффектный имеративный код, но только со смайликами, и считает себя илитой.
Один из столпов ООП ты забыл, еще один (наследование) - это только инструмент для реализации в ООП другого - полиморфизма.
>Берёшь и пилишь свой язык
>Не слышал ни об одном языке, который не использует кривых ООП-костылей кроме ассемблера.
Не считаю. Говорю же, пусть берёт машинные коды и пилит то, что считакт нужным.
Ассемблер привёл лишь как ближайший к машинному коду, который сейчас знаю.
> костыли
Велосипеды.
No true Scottsman fallacy.
>неплохо реализуются с использованием ООП
ААА практически на чистой сишке пишутся, без использования крестовых фич.
Зачем тебя убеждать в ложном утверждении?
Eiffel - самая каноничъная реализация ООП на сегодняшний день. И смотри, что из этого вышло: http://lavironsoftware.blogspot.ru/2012/04/eiffel-studio-review.html .
В играх вроде в основном компонентный подход, а не "чистое" ооп.
>Ебать манямирок
https://youtu.be/rX0ItVEVjHc?t=1h23m48s
Из плюсов исползуют очень мало фич, на самом деле. Очень простой код, мало абстракций, соответственно, под каждую игру много перелопачивается. Если ты не пишешь жирное middleware вроде UE4, конечно. Там раздолье абстракций.
>даже рендер (самая нагруженная часть) без перегрузки операторов и прочего – боль
Весь рендер на видюхе сейчас. На ЦПУ только шедулер, который в комманд буфер шейдеры складывает, а в шейдерах никаких перегрузок операторов делать не надо, там для векторов все встроено.
>даже рендер (самая нагруженная часть) без перегрузки операторов и прочего – боль
А нахуя вообще там перегрузка операторов? Кто-то умножает источники света на анимированные модели? Зачем?
>>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, точных цифр особо не помню). Почему так?
> Написание всяких конструкций вида 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.
> Написание всяких конструкций вида 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.
Игровой 3D движок. Хуй ты его без ООП напишешь.
>И опять же, как это реализовывать без абстраций?
Там DoD во все поля. Организация данных примерно как в БД (с нарушением нормализации, где производительность требует). То есть объект "робот" размазан по куче таблиц - скелеты, анимации, материалы с прозрачностью, без, и т.д. При рендере/апдейте, соответственно, ты не работаешь с абстрактными объектами через виртуальные функции, а прогоняешь таблицы через функции - отфильтровать сферические коллайдеры из таблицы со сферами, заполнив таблицу для более точно коллижена, например.
>Unconditional branch, variable target
>Conditional branch, fixed target
Суть-то как раз в том, что в первом случае не нужен branch predictor(в ассемблере преобразовывается в конструкцию вида call dword ptr[0xbabe], а по указателю уже подставляется адрес нужной функции). Во втором уже не обойтись без него.
В итоге в первом случае оверхед - просто дополнительный переход по адресу. При хорошем кэше это вообще ни на что не влияет. Во втором случае - вероятность ошибки предсказателя. А это остановка конвейера и всё, пиздец. Тактов 7-8 очень легко потерять. Если это будет вызываться в цикле, то оверхед будет очень заметен.
Не знать о существовании иных техник для управления сложностью кроме кривых костылей ООП в 2016 году.
Ты знаешь о существовании branch prediction, но не знаешь о branch target prediction, почему так? Дочитываешь до середины, потом засыпаешь?
>плюсов исползуют очень мало фич
А ты что ожидаешь? Что проект на плюсах обязательно вымазан наследованием в 800 предков, с шаблонной магией и виртуальной хуитой?
Можно вообще обойтись без наследования (в Visual Basic 6 его не было, например). Любое наследование легко заменяется композицией объектов. Основа ООП (по Алану Кэю) - объекты и сообщения, которые они отправляют друг другу и обрабатывают. А "три принципа" придумал Страуструп, и они довольно сомнительны (инкапсуляция есть в любом языке с заданием области видимости вплоть до ассемблера, а для полиморфизма достаточно разрешить overload для функций).
Ну и где процедурные/функциональные движки с йоба графоном? Вот Кармак скажем долго выебывался, а однако Doom 3 пришлось ему писать на крестах.
Просто обо всём этом я где-то полтора года назад узнал из книжки Game Engine Architecture, где всякие промахи кэша и предсказатели переходов были рассмотрены довольно поверхностно.
Криворукие игроделы ничего кроме сишечки не знают, щито поделать
>Ну и где процедурные/функциональные движки с йоба графоном?
Почти везде в ААА. Сишечка в функциональном стиле - чистые функции, иммьютебл стейт все дела.Кармак почти в каждом выступлении последнее время рассказывает про прелести функционального программирования.
>функциональные
Уважающий себя борщехлеб не будет марать руки об игори, очевидно же. Игори для детей.
Кармак пиздит дохуя, еблоторговец раскрученный, сам ничего оосбенного за всю карьеру не написав.
Функциональный стиль и мьютабл-иммьютабл друг другу ортогональны, и immutable быстрым не будет никогда. Даже упоротые хаскелеры когда им надо БЫСТРО, берутся за IORef, STRef и MVar, ловко выкручиваясь тем что mutable references на immutable values это ВНЕЗАПНО не mutable variables.
>и immutable быстрым не будет никогда
Например, пересоздавать на каждом кадре стейт игры заново, гораздо быстрее и проще, чем апдейтить мутабельный стейт.
> пересоздавать на каждом кадре стейт игры заново
Дельты же хранить можно. При сете создается дельта которая держит ссылку на предыдущую версию.
Нафига? Весь стейт - несколько мегабайт, максимум. Хранишь два-три кадра, при создании нового кадра копируешь предыдущий с обновлением.
>>770814
Блядь! Я только что осознал! Рендеринг - это НА 100% функциональный стиль. Пиздеееец, я столько времени его использовал и даже не думал об этом.
Смотрите сами:
Шейдер - чистая функция. Если подать туда одинаковые буферы, одинаковые константы и одинаковые текстурвы, то и результат будет одинаков.
Более того! Всякие SetVertexShader - это функции высшего порядка.
ВСЕ объекты для контроля рендеринга - различные ID3D11RasterizerState иммутабельны.
В случае с D3D12 всё ещё круче - практически ВСЕ настройки, включающие в себя шейдеры, режим отрисовки, тип топологии примитивов и т.д., ВСЁ ЭТО упаковано в иммутабельный ID3D12PipelineState. При рендериге просто вызывается функция SetPipelineState для контроля этого! И она чистая!
Охуеть. В рендеринге СТОЛЬКО функциональщины. Я даже не знаю теперь, как к этому относиться.
Охуеть открытие. Рендеринг функциональный, потому что GPU суперпараллельный, это любому должно быть очевидно.
> Почти везде в ААА.
Примеры? Ну кроме недописанного шутера на хаскеле (да и тот по графону ближе к Quake 2). Кармак пиздеть может что угодно, вот когда очередной id Tech будет не на крестах, я ему поверю.
>>770851
Там не только шейдеры. Игровой движок это целая ОС в миниатюре. Грамотно построить архитектуру, и чтобы еще быстро работало, можно только на ООП (C++, Delphi, D или тому подобном) .
> Игори для детей.
Дык, ясное дело, что Кармаки и Ньюэллы они инфантилы, вот сидящий на шее у мамки борщехлеб совсем другое дело.
>Грамотно построить архитектуру, и чтобы еще быстро работало, можно только на ООП
Нет.
Но утверждение "грамотно построить архитектуру, и чтоб еще быстро работало, и чтоб еще обязательно на С++, который только и знают криворукие игроделы, и сделать это все с помощью криворуких игроделов, которые не могут ни во что кроме ООП, можно только с помощью ООП"
*будет правдой.
> и чтоб еще обязательно на С++, который только и знают криворукие игроделы, и сделать это все с помощью криворуких игроделов, которые не могут ни во что кроме ООП
Я и говорю.
Так криворукие игроделы хоть делают и выпускают рабочий продукт, в отличие от мамкиных борщехлёбов, визжащих о превосходстве фп.
>на сишечке в функциональном стиле
Как на сисечке можно сделать функции высшего порядка? Путем черной магии в виде исполнения ссылки на фунцкию?
UT, CryEngine - middleware, движок с редакторами. Остальное, считай, легаси из 90-х, написанное писишными программистами, которые консоль и голое железо в глаза не видели. К тому же там не сказано, в каком стиле у них С++.
Под "функциональным стилем" имелись ввиду чистые функции и в основном иммьютабл стейт, отстутствие ООП.
Больше на процедурность с иммутабильностью смахивает. Какое же это ФП без функций высшего порядка.
Делает и выпускает много чего много кто.
В игродельной индустрии - там же замкнутый порочный круг. Берут только бородатых сишечников, потому что ну епта у нас же все на сишечке, они в свою очередь нихера кроме сишечки и ООП не знают и знать не хотят.
В других индустриях ФП успешно используется, в том числе и там где высоки требования к производительности, в том числе и с использованием языков Си и С++.
SQL это декларативное функциональное программирование, чего тут удивительного.
>В других индустриях ФП успешно используется, в том числе и там где высоки требования к производительности,
Например?
Ну я и говорю, что не все ФП выглядит как хаскел. Функциональные практики in the wild ближе к SQL чем к ML.
На самом деле нет. У тебя по ссылке откровенное наглое вранье. Вот разоблачение:
http://flyingfrogblog.blogspot.ru/2010/05/why-is-haskell-used-so-little-in.html
Куча нонеймов и фейсбук, интел и с ан анд т и пр. где на всю корпорацию 1 внутренняя утилита на хаскелле, ахуеть теперь.
Конкретные примеры давай. Риалтайм рендер уровня source 2 хотя бы.
И там тоже пишут основную часть на питоне/р, а все числодробилки на сях, хотя перформанс в этой области никому не всрался.
Ну охуеть можно. ABN Amro ему нонейм. Alcatel-Lucent ему нонейм. Bank of America Merril Lynch ему нонейм.
Это я еще до буквы B не дошел.
А контора из пяти бородатых сишечников, кидающих треугольнички в GPU - доооо, это сирьооозная ендустрия.
>>771076
Я сразу говорил что речь не про Haskell, а про ФП. В перечисленных лавках, и во многих других, часто пишут на разных языках, в том числе и на Си и на С++. Но вот набирают туда людей прицельно со знанием Хаскеля. Потому что они умеют в ФП, что и нужно. А в ООП и так любая макака умеет, хрена ли там уметь. И человек умеющий в ФП, напишет и на С++ приличный ФП код, когда надо на С++.
А вот наборот получается хуево. Поэтому и слышно со стороны криворуких игроделов только нинууужна
На питоне/р прототипируют алгоритмы, а в продакшене вся инфрастрктура на JVM.
Человек умеющий в фп скорее нагреет процессор.
А бородатые сишники тем не менее написали явно поболее пары внутренних утилит. не знаю на счёт самого компилятора, на рантайм у хачкеля, ВНЕЗАПНО БЛЯДЬ, сишный
Ты похоже не в курсе что за означает "бигдата". Это не хуйлоад, сам ознакомься с значением термина.
Ну так а чего на рантайме останавливаться, давай до внутренностей процессоров и порчих железок дойдем, в которые криворукие игроделы с охуенно важным видом кидают треугольнички. А там ВНЕЗАПНО, из того самого списка
> 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).
Но это все хуйня, конечно, треугольнички потом внутрь этого всего кидать - задача важнее. Это тебе любой таджик с лопатой объяснит что каток, грейдер и асфальтоукладчик сделать - это чепуха, главное лопатой щебень для них раскидывать.
>Но вот набирают туда людей прицельно со знанием Хаскеля
Прицельно набирают спецов с нужным опытом. Хаскелиты без знания предметной области никому не всрались.
>человек умеющий в ФП, напишет и на С++ приличный ФП код
Очень спорно. ФП в основном в академиях используется, а академический год обычно не очень хорош.
>А вот наборот получается хуево
Потому что никому не нужно
>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).
Компания ПРОДАЕТ тулзы для создания чипов, игродел!
Ты себе представляешь сложность этой поебени?
Или ты думаешь что скорость там никого не ебет?
Знаешь сколько времени занимает в каком-нибудь бытовом-народном Квартусе чекинг или генерация RTL? А это время - это живые деньги, если ты думаешь что для производителей чипов - то есть покупателей этих тулзов все это не имеет значения.
>>771156
>Нинуужна
Кто бы мог чего другого от криворуких игроделов ожидать.
>Кто бы мог чего другого от криворуких игроделов ожидать
Криворукие игроделы выпускают продукт, который продается, пряморукие борщехлебы выпускают воздух с запахом нечищеных зубов.
как там в хаскеле? дефицит кадров?
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 Хороший учебник, всё расписано подробно. Сам по нему учился. Рекомендую.
А еще в жопу все ябутся.
https://www.ohaskell.guide/
А вообще в хаскеле конечно не хватает очередного неразобравшегося в ООП, вот прям ждут тебя, на стену лезут.
Не посоветуешь чего почитать, чтобы в ООП разобраться полностью? Просто в большинстве книг по языкам он идёт как что-то побочное и даётся отрывками. Желательно с примерами на питоне.
Почему не разобравшегося? Я в нем отлично разобрался, просто работы на ООП языках нет ибо сейчас каждый школьник учит какой-нибудь питон. пхп, жиес, кресты или жаву и далее по пасте.
> в ООП разобраться полностью
> Желательно с примерами на питоне.
В голосину.
Choose your destiny:
C++ | C# | Java
То есть на питоне ООП нинужен?
> Choose your destiny:
Ну прям сорта. Пусть будут плюсы, в них я чутка умею.
ООП - гоано без задач. По пунктам:
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Б - мастер взаимоисключающих параграфов, фрик и быдлокодер.
>модули
В OCaml есть, в Haskell - хуй.
>record field disambiguation
Сделали только неделю назад
>>771651
Паттерн-матчинг это инструмент для диспетчеризации и, если есть сложные структуры — средство декомпозиции сложных структур (в частном случае — кортежей). Отношение к функциональному программированию он имеет, но весьма опосредованное. Есть языки с паттерн матчингом не являющиеся функциональными (Prolog) и функциональные языки без паттерн матчинга (Scheme).
В Haskell это инструмент очень низкоуровневый, если у вас в функциях огромные свитчи, то вы явно что-то неправильно делаете.
>ООП как раз в этом плане и хорошо тем, что гетерогенный список (который нужен в разы чаще, чем множественная диспетчеризация) пишется просто и приятно
Ну конечно, особенно если завести искуственного общего предка "некий Объект" - заипись, компилятор не ругается, все прекрасно. Что толку от такой "типизации" никакой - да и хрен с ним.
Haskell - экзистенциальные типы и HList (http://okmij.org/ftp/Haskell/HList-ext.pdf, https://hackage.haskell.org/package/HList-0.4.2.0), в Scala тоже все есть.
>В ООП ты делаешь IDrawable, ISerialazble, далее создаешь IDrawableSeriazableEbotable (это основной проеб ООП), и делаешь array<IDrawableSeriazableEbotable>, все. Проеб тут возникает в том, что если у тебя нет возможности реализовать интерфейс Ebotable для круга, допустим, у тебя возникнет pure virutal function call, а система типов тебя никак не проверит
Но хочу я не этого.
Я хочу сделать список, и явно указать что в нем могут содержаться только сущности типов, которые можно рисовать И сериализовывать. Просто перечислить эти необходимые свойства, а никаких еботических их гибридов не делать, потому что это костыль. И чтобы компилятор ругался когда какой-то джуниор в этот список пытался положить что-то, что либо не seriаlizable, либо не drawable.
>и явно указать
Еще лучше, конечно, еще и явно не указывать. Пусть компилятор сам посмотрит что я с элементами этого списка делаю, и ругается если где-то в коде вынув из списка элемент его пытаются нарисовать, а при добавлении в список рисовабельность не проверяется.
Смотри, в чем была изначальная претензия к ООП-дизайну? В том что он принуждает к эссенциализму, то есть структурировать сущности по тому чем они являются. Ущербность самой такой постановки вопроса и скудность термина "является" мы можем увидеть на примере птеродактиля и летучей мыши - они чем являются, и в какую стало быть иерархию их помещать - в какую не помести, все неудобно. С точки зрения летучести вроде надо к птицам, а с точки зрения, например, яиц и теплокровности - мало того что в другую, так еще и не в одну, а в разные. И выбирай по какому принципу тебе важней классифицировать, но не ошибись, потому что выбрать для удобной работы можно либо летучесть, либо теплокровность, либо яйцекладкость, и только один раз.
А ведь хочется вот здесь единообразно поработать со всеми летучими, а вот тут, столь же единообразно, уже со всеми теплокровными. То есть работать не с онтологией, прибитой гвоздями, а с ортогональными проекциями.
Придумали множественное наследование, но получилось опять не слишком заебись, из-за наследования имплементаций и традиционного для ООП state в каждом объекте, который традиционно еще и mutable - получалась каша, баги и боль.
Потом придумали отрывать имплементацию и множественно наследовать и (или) миксинить только интерфейсы. Получилось уже лучше, но все равно криво, потому что каждый раз создавать абстрактный класс, только для того чтоб перечислить в нем нужные мне в этом месте свойства - это какая-то хуита.
>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} на кадр.
>По большому счёту, именно благодаря ему
Да, дедушка умный, куда б мы без него.
> свет лучше чем в 2007-ом году можно сделать и делают, только не Кармак. Кармак, напоминаю, в 2011ом году выпустил игру на лайтмапах (то есть с той же технологией освещения, которую он использовал в Quake 1). Он очень умный, наверное, но не любит спешить со своими революционными алгоритмами
>http://live13.livejournal.com/423196.html?thread=1148700#t1148700
>Очередной гениальный замысел Кармака
>Кто не знает, так работала его мегатекстура, только даже она была чуть умнее - делала feedback pass сначала и находила все страницы в сцене, но все равно это был страшный тормоз. Останавливать GPU и грузить страницу по первому fault - будет тормознее на порядки.
>большая проблема начиная с PS3 - программисты не знают и знать не хотят как работает железо не смотря на 100500 презентаций, которые для них делают. Упираются рогом и ваяют хренотень как им хочется, а хочется странного очень часто. Например, хочется continuous submit на PS4. Плевать, что тормозит не по-децки, так у них же еще там баг на баге сидит и багом погоняет. Что, конечно, неудивительно, потому что человек, который знает достаточно, чтобы его написать правильно, это делать не будет потому что этих знаний более чем достаточно, чтобы понять почему это не нужно делать
Кармак, который (хуй с ним) десять лет двигал прогресс в области компьютерной интерактивной реалтайм графики, или какой-то нонейм хуй? Какой тяжёлый вопрос.
>communities
>fprog
А, теперь всё встало на свои места.
>вот, Моська, знать, она сильна, коль лает на слона
Ок, пошли по пунктам.
>Кармак, напоминаю, в 2011ом году выпустил игру на лайтмапах (то есть с той же технологией освещения, которую он использовал в Quake 1).
Ну, во-первых, в оригинальном квейке, по-моему, не лайтмапы. Но хуй с ними. Почему лайтмапы? Да потому, что выглядят охуенно. А нормальное освещение с таким же качеством тяжеловато было сделать. Потому что, всегда быстрее не считать.
>Кармак так никому и не смог внятно объяснить, что с ее помощью можно сделать такого, чего нельзя гораздо быстрее сделать без нее
Дизайнеры уровней и хуйдожники, я слышал, от неё радугой кончают. Но ещё можно вспомнить, что Кармак обосрался во второй кваке с трёхмерными взрывами. Почему? А это проблема всех первопроходцев. Сначала ты делаешь криво, потому что опыта нет, потом уже люди (ты сам), которым не нужно искать новую дорогу, кладут асфальт.
>это проблема всех первопроходцев
Кармак у нас первопроходец.
Ебущий свою мегатекстуру с лайтмапами уже второй десяток, не сумевший сделать ни одной консольной игры, торгующий лицом (это сложно, потому что лицо-то как раз закрыто Шлемом Виртуальной Реальности - тут никто кроме Кармака не справится) в шарашках, продающих наступление эры VR под свист воздуха в надуваемом ими мыльном пузыре?
>Современное ООП, с довольно плоской иерархиев
Ну это то же самое что автомат для стрижки - который тоже неплохо работает, если у клиента голова квадратная, и еще и строго утвержденного размера.
Понятно что если вся требуемая в задаче иерархия это кружочек и квадратик, то все заебись.
Плохо то что такие задачи за пределами собеседований с джуниорами в полуподвальных лухософтах встречаются редко.
>Сделай 2 копии кода, и тебя все заинлайнится и будет чики-пуки
Потом оно перестанет помещаться в instruction cache и будут только пуки, а все чики уйдут к конкурентам
>двойного перехода указатель на объект->адрес VMT->смещение по VMT страшнее. Это, кстати, основная причина принципиальных тормозов языков типа Java.
В языках типа Java есть JIT, который, особенно при ярко выраженном наличии hot path - что бывает довольно часто - это дело оптимизнет. Но в бенчмарках этого не покажут, потому что с дефолтными настройками оптимизнет оно только через десяток тысяч итераций по этому месту, а бенчмаркальщики слишком тупы чтобы об этом знать и настройки настроить, так что до JIT в бенчмарках обычно дело не доходит совсем.
>>> Судя по требованию двух USB 3.0 весь трэкинг делается на CPU из сырого стрима с датчиков/камер. Это неудивительно, компьют они использовать не могут (иначе Нвидия и Вин7 и 8 в пролете), а DSP в хэдсете - а) нужно уметь и б) сделает хэдсет еще дороже
>>Блджд, шестиосевой аксель-инклинометр с калманом на борту стоит 40 центов. 40 центов, Карл! Оптовикам дают СДК к микрухе, которая позволяет задействовать нутряной ДСП для детекции жестов-хуестов и прочей хрени.
> Не стоит забывать, что CTO у них Кармак, который в железе ничего никогда не понимал.
Понимать может только Кармак, потому что он Кармак, понятно.
Ты самый умный просто, долбоёб.
Иди почитай как перформанс жявы на каком нибудь benchmarksgame измеряется, потом пизди.
>я 2000го года рождения и не знаю, что было до рейджа, поэтому этого не было
>сейчас Кармак обсирается (то есть, на самом деле - нет, но я считаю, что он обсирается), поэтому все его прошлые заслуги аннулируются и больше ничего не значат
>а ещё вот вам посты от хуй_вообще_знает_кого_чью_компетентность_никак_не_проверить, которые подверждают мою точку зрения (на самом деле, это не моя точка зрения, я просто прочёл эти посты и ПРОЗРЕЛ)
>я лучше знаю, а вы все тупые семёны
Здорово.
Дык жабадебилы все время орут про бенчмарки, а вот попробуй любое жавопобедилие запустить и оно будет адово тормозить. Еще и ОЗУ жрать, да, но еще и тормозить. А еще это говно тормозит. Адово. Но зато бенчмарки.
>данные акселерометра занимают так мало (килобайты полосы)
Вопрос - и нахрена ж ей джва USB 3.0 (и еще один - для контроллера, но мы не о нем)?
> Из всех "изобретений" Джона Кармака, тесселляция - единственное, что используется кем-то кроме несчастных покупателей id Tech. Наверное потому, что Кармак только хвалился тесселляцией, но так ее и не сделал
>Он написал первую полностью трёхмерную игру
Нет, он на BSP в 3D сдулся, и побежал за помощью к Абрашу. С окулусом, кстати, такая же фигня. Без Абраша он долго не просидел, выписал себе помогать.
Ну Миша, кстати, тоже люит пиздеть, какие вокруг лохи, а сам в 2011 году выпускает игру с графоном уровня 2003. Да и судя по mobygames, остальной послужной список у него не оче.
Я к тому, что "написал первую трехмерную игру" - это довольно громко сказано.
>Но личность Кармака трудно недооценить
Просто Кармака преподносят как гения программирования 3Д, хотя его достижения в этой области далеко в прошлом, учитывая темпы развития.
С того что надули из него Великого Игро Девелопера, и какую бы хуйню он не нес, только и слышно про него.
Это все любят, но его на каждой ярмарке хоть не показывают и бложек не обсуждают на каждом перекрестке
Да и полезное что-то можно от него иногда узнать http://live13.livejournal.com/462582.html?thread=1403894#t1403894
А от Кармака только "покупай, торопись" и великие идеи о мегатекстурах будущего.
Полезное - то что на книжку эту можно времени не тратить, не говоря уж про забивание мозгов
"Бесполезна для ААА под консоли" не значит бесполезна вообще для геймдева.
>А от Кармака только
Наоборот, у Кармака гораздо более интересные твитор и пейсбук. Без поливания всех говном, пещерного расизма и гомофобии.
Ну я же не говорю что читать надо некритично, без понимания того зачем чувак пишет и какие у него в LA фрустрации, особенно глядя на Кармака.
Но именно эта едкая negativity (тем более что ее можно спокойно пропускать мимо ушей) и сопутствующий ей взгляд на какие-то вещи, события и персоны, дает возможность не только посмотреть на некоторые вещи с более других сторон чем это принято и несется из всех репродукторов, но и, что часто даже продуктивней, о чем-то самостоятельно задуматься.
Тот же GoF book намного более полезен и хорош (если, где, кому и когда он вообще может быть полезен и хорош) когда ты понимаешь откуда оно взялось, зачем, причем тут Смаллток, и кем, почему, и в качестве чего это было сделано в Симуле, и почему Алан Кей похож с одной стороны на Кармака, а с другой - на автора Хагакурэ, который тоже немного опоздал родиться и немного переусердствовал в развитии концепций того, прекрасного прошлого времени, над которыми в то, прекрасное старое время все причастные максимум пожали бы плечами.
Человек, измученный нарзаном.
Я когда с индусами работал, тоже порой головой об стол бился. Не столько от качества кода, сколько от attitude.
Это в Воронеже хорошо к ним относиться, когда их нет в радиусе 1000 км
Да, это со многими так. Читаешь какого-нибудь умного (вроде бы) парня про просторы большого театра в области lockless алгоритмов, и ВНЕЗАПНО он как начнет про социальную справедливость, раскулачивание Уолл-Стрит и угнетенных (Демократами, но это никогда в сообщение не помещается по загадочным причинам) миноритис Чикагщины - хоть отписывайся.
Тэги же придумали специально для этого, но никто не пользуется.
Давай, расскажи мне как он это оптимзирует. Что он такого делает, что двойного cache miss не происходит.
Я придерживаюсь СТРУКТУРИРОВАННОГО ПРОГРАММИРОВАНИЯ (СП). Мое личное изобретение.
Никакие инлайны и девиртуализация не спасут при организации памяти в жвм с неебическими индиректами и адовым оверхедом по 500% из-за боксинга неба и аллаха.
Поясняю. Во главе идеи - один суперобъект, назовем проектом.
Весь код это его функции и методы.
Программа запускается через метод Object.run (), который может содержать различные методы инициализации (например Object.preload (), Object.init ()).
Создание объектов происходит так, например кнопки:
>Object.create.button (..) // метод в качестве аргументов принимает параметры, положение, текст, текстуру и прочее
Все объекты автоматически получают цифровое порядковое id и ссылки на них можно найти в Object.id<objects_id>. Чтобы найти объекты не по id, а по внутреннему тегу или свойству, используется метод Object.get.object (..) - указываем что нужно найти, например пару { name: 'menu' }
Конечно даже в сотне постов не описать всех деталей, но если вы обладаете зачатками интеллекта, то даже эти пару абзацев способны дать почву для создания полной картины.
Java неплохо оптимизируется в тех местах где надо и тогда когда надо
http://mechanical-sympathy.blogspot.ru/2012/10/compact-off-heap-structurestuples-in.html
Пердолиться с указателями во всех остальных частях программы, которые составляют обычно 98.74%, при этом не нужно.
>Java неплохо оптимизируется в тех местах
Это ебаный ад off-heap пердолинга. Проще на крестах переписать.
>которые составляют обычно 98.74% при этом не нужно
Потому что эти 98% - блоат из бесполезных ФабрикАбстрактныхФабрик, которые как-то оптимизировать можно только выкинув их совсем.
Даже предположив что ты действительно мог бы все это переписать, есть еще и другие факторы - например, время, бюджет и уровень персонала.
Те фабрики фабрик, которые ты будешь переписывать пока Солнце не упадет на Землю, можно поручить менее квалифицированному персоналу, и это будет не только быстрее, но в том числе и значительно дешевле.
Вот поэтому оптимизацией жабы заниматься абсолютно бессмысленно. Как и пытаться писать на ней что-то кроме жирного интерпрайза.
Совсем наоборот, именно ее-то оптимизацией заниматься осмысленно.
Оптимизируя 1% критичного к производительности кода, ты получаешь 90% прироста общей производительности, весь остальной код пишут дешевые джава-макаки - это очень хороший результата в подавляющем количестве случаев.
За бортом остаются буквально считанные задачи - жесткий реалтайм, часть эмбедовки, консольные игродвижки.
Проблема в том, что в джавакоде обычно нет 1% критической части. Потери размазаны по всему коду равномерно. А затраты на написание быстрого кода ОЧЕНЬ высоки, поскольку джава как язык не поощряет работу с примитивными типами и off-heap.
> Although Vulkan is very low level its design caters much nicer to the properties of (purely) functional languages. I expect higher level abstraction for Vulkan to appear soon
> Also SPIR-V adds the possibility to create shaders and compute kernels through DSL or even through a runtime just-in-time SPIR-V generator. All in all Vulkan is much more FP friendly than OpenGL
>в джавакоде обычно нет 1% критической части. Потери размазаны по всему коду равномерно
Может быть где-то такое и бывает, но мне сходу сложно себе представить такое, процент критического кода, конечно, варьируется и 1% бывает не всегда (хотя и удивительно часто), но до 5% обычно укладывается.
>much more FP friendly
Ты правда считаешь, что это означает, что все станут на хаскеле писать? GPU-программирование FP-friendly с самого начала, но все языки там - варианты си.
Чистые ФП языки это маразм. Просто добавят в попсовые языки ФП парадигму. Java 8, например.
>Java 8, например.
Ахуеть, там же лямбды и мап-редюч-И так далее в стандартной библиотеке! Ахуеть, фп язык!
Плюсы у тебя, наверно, на уровне с хачкеллем стоят?
Так это только начало. Там еще стримы добавили, композишн, maybe-типы и все такое. А в 9ке обещают модули, настоящие.
Но там еще надо дохуя вычистить, исключения, для начала.
Ну ладно, жаба жабой, а вот в кресты ФП парадигму норм добавится.
ВНЕЗАПНО
>>771995
Модули это конечно хорошо. Только и с лямбда фишечками C#, Java и подобные им "гибридные" языки останутся глубоко императивными. Все это натягивание ФП на ОПП, причем совершено не с той стороны, выглядит бредово. Принцип "снаружи ООП, а внутри методов — ФП". Какой ФП? Внутри каких методов? ФП как раз должен быть снаружи, а внутри хоть ассемблер.
Какие есть плюсы у ФП на примере хаскеля?
1) Более-менее полноценная поддержка для комбинирования комбинаторов.
2) Возможность рассуждать об этих комбинаторах как о математических объектах (с оговорками).
Для этого нужна более-менее нормальная система типов, полноценная поддержка ленивости, специальные оптимизации, и контроль за эффектами как сам по себе, так и для нормальной работы ленивости и оптимизатора. Неплохо было бы еще и завершимость проверять, чего в хаскеле нет и в этом смысле (как и в аспекте системы типов) он язык компромиссный и недоделанный. Собственно, на этом направлении и идет дальнейшее развитие как самого хаскеля, так и связанное с появлением родственных языков вроде омеги, агды и идриса. В этих языках могут отказаться от ленивости по умолчанию, но не от контроля за эффектами.
В любом же "гибридном" языке вы получаете отказ от контроля за эффектами (потому что так не бывает когда здесь контролируем, здесь не контролируем, это получается нигде не контролируем) — а это сразу значит что с рассуждениями о коде, нормальной ленивостью и оптимизациями можно распрощаться, а значит и с полноценным комбинированием комбинаторов. Даже если у нас остается у нас только более-менее полноценная система типов, то мы попадаем в мертвую зону между хаскелем и так называемыми "гибридами", забитую мертвыми ML-ями и дышащим на ладан окамлом. Это вечные девяностые — прогресс отсюда никуда не двинуть.
Тем не менее, от гибридов и языки мертвой зоны выгодно отличаются полноценными системами типов и модулей, которыми гибриды жертвуют ради использования библиотек и рантаймов популярных мейнстримовых языков, но — по всей видимости — этого недостаточно.
Обычное ООП, мейнстримовое, с сабтайпингом, а не марсианское-структурное, какое возможно в хаскеле и некоторых "негибридных" мл-ях, наносит такой удар по системе типов, что о хоть сколько нибудь полноценной поддержке ФП говорить уже не приходится. "Гибриды" любят декларировать "мультипарадигменность", но ФП там, как колбаса при коммунизме: чего не спроси — отвечают, что потребности нет
>>771995
Модули это конечно хорошо. Только и с лямбда фишечками C#, Java и подобные им "гибридные" языки останутся глубоко императивными. Все это натягивание ФП на ОПП, причем совершено не с той стороны, выглядит бредово. Принцип "снаружи ООП, а внутри методов — ФП". Какой ФП? Внутри каких методов? ФП как раз должен быть снаружи, а внутри хоть ассемблер.
Какие есть плюсы у ФП на примере хаскеля?
1) Более-менее полноценная поддержка для комбинирования комбинаторов.
2) Возможность рассуждать об этих комбинаторах как о математических объектах (с оговорками).
Для этого нужна более-менее нормальная система типов, полноценная поддержка ленивости, специальные оптимизации, и контроль за эффектами как сам по себе, так и для нормальной работы ленивости и оптимизатора. Неплохо было бы еще и завершимость проверять, чего в хаскеле нет и в этом смысле (как и в аспекте системы типов) он язык компромиссный и недоделанный. Собственно, на этом направлении и идет дальнейшее развитие как самого хаскеля, так и связанное с появлением родственных языков вроде омеги, агды и идриса. В этих языках могут отказаться от ленивости по умолчанию, но не от контроля за эффектами.
В любом же "гибридном" языке вы получаете отказ от контроля за эффектами (потому что так не бывает когда здесь контролируем, здесь не контролируем, это получается нигде не контролируем) — а это сразу значит что с рассуждениями о коде, нормальной ленивостью и оптимизациями можно распрощаться, а значит и с полноценным комбинированием комбинаторов. Даже если у нас остается у нас только более-менее полноценная система типов, то мы попадаем в мертвую зону между хаскелем и так называемыми "гибридами", забитую мертвыми ML-ями и дышащим на ладан окамлом. Это вечные девяностые — прогресс отсюда никуда не двинуть.
Тем не менее, от гибридов и языки мертвой зоны выгодно отличаются полноценными системами типов и модулей, которыми гибриды жертвуют ради использования библиотек и рантаймов популярных мейнстримовых языков, но — по всей видимости — этого недостаточно.
Обычное ООП, мейнстримовое, с сабтайпингом, а не марсианское-структурное, какое возможно в хаскеле и некоторых "негибридных" мл-ях, наносит такой удар по системе типов, что о хоть сколько нибудь полноценной поддержке ФП говорить уже не приходится. "Гибриды" любят декларировать "мультипарадигменность", но ФП там, как колбаса при коммунизме: чего не спроси — отвечают, что потребности нет
А чего б на нем и не писать? Если роль того что крутится на CPU все больше сводится к control plane, простаивающей при этом 90% времени в виду явно избыточной для ее задач мощности современных процессоров. Все остальное (data plane) едет в GPU с SSD само, и считается там, и показывается прямо оттуда.
>А чего б на нем и не писать?
С того, что все будет адово тормозить из-за боксинга и аллокаций. Или придется писать в стиле мало отличающемся от нынешнего.
Я чот представил как будут работать требовательные к процессору игрушки (стратегии, игры с физикой), или насколько придётся отупить и без того ебланский ИИ в стрелялочках
Кек
Алгоритмы физики и ИИ в любом случае придется в будущем переписывать под массивно-параллельность, потому что скорость ядер CPU увеличиваться больше не планирует, только их количество.
Да и оптимизатор хаскеля на месте не стоит, и движется во многом именно в сторону распараллеливания - и руки у него сишечкой не связаны в этом.
Вот именно – скорость кода хачкелля упирается в оптимизатор, в отличие от си.
Да и GC с увеличением кол-ва потоков увеличит оверхед, что довольно сомнительная затея.
Качество оптимизатора Си упирается в Си.
И вот с этим ничего не поделать, и никаких прорывов впереди не ожидается - неоткуда. Алиасинг и некоторые другие проблемы вытекают прямиком из самого языка Си.
Уровень хаскельного оптимизатора совсем другой, и то что он может наоптимизировать благодаря возможности рассуждать о хаскельном коде на совсем другом уровне - и сейчас уже очень неплохо, и есть куда пилить. При этом уровень сложений в человеко-часах в современные сишные оптимизаторы и GHC отличается в какие-то дикие порядки раз.
Алиасинг забарывается одним модификатором переменной и хотя бы каплей внимательности.
Вась, успокойся уже.
>Уровень хаскельного оптимизатора совсем другой
Наверное поэтому у наивного qsort на хаскеле реальная асимптотика больше n^2 из-за постоянных переаллокаций и копирования.
Вот тут за чудо параллельность и производительность хаскеля поясняют:
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
>The author of the post is a longtime troll.
>https://www.reddit.com/r/haskell/comments/4ogle3/post_about_the_disadvantages_of_functional/
>мышка сломалась, кликнуть не смог
>>https://www.reddit.com/r/haskell/comments/4ogle3/post_about_the_disadvantages_of_functional/
Не 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)
Шрифты плохо настроены?
> 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
Если я правильно понял о чем ты, "наивный qsort" в хаскеле это никакой не qsort, а другой алгоритм, использующий похожую идею.
>>772081
Не буду защищать хаскель, не пишу на нем и никогда не делал бенчмарков связанных с ним, но этот челик по всей видимости путает иммутабельность и ФП.
Он не путает, у него четкая бизнес-цель.
Хэши сильно оптимизнули, кстати, после именно этой попытки Харропа доебаться до мышей.
Ты сейчас его сравниваешь с сишечкой, где код хорошо описывается выражением "нам дали ведро болтов и гаек, сейчас мы легко всего в 100000 строк построим из этого синхрофазотрон ни разу не уронив себе на ногу отбойный молоток, который мы построим отдельно всего в 25000 строк" или с каким-то идеальным языком, названия которого по причине скромности не приводишь?
Хотелось бы знать и понимать то, о чем говорили ораторы свыше. Как я вижу, для этого нужны: дискретная математика, компьютерная схемотехника, что-то по устройству операционных систем и низкоуровневый язык(очевидная няшная?)
Поправьте, знатоки. Реквестирую от вас roadway, только не в стиле "Ищешь сегодня книжку ..."
Про джаву? Вот:
https://www.cs.virginia.edu/kim/publicity/pldi09tutorials/memory-efficient-java-tutorial.pdf
Нет, в целом об устройстве ПК, принципах работы ОС, и игро-индустрия.
> дискретная математика
Не нужна. Неплохо для умения в реляционные СУБД иметь общее представление о first order logic, и только. Нужно будет графы зачем-нибудь пораскрашивать - в справочнике алгоритм посмотришь.
> компьютерная схемотехника
Общее понимание того как устроен процессор - на уровне "есть кэши уровней 1-N, шины обмена с памятью, и более тормозная периферия, причем latency и bandwith это разные вещи"
> что-то по устройству операционных систем
Общие понятие - вот ядро, вот сисколы, вот скедулер, вот процессы, вот os-level треды, вот между ними IPC.
> и низкоуровневый язык
10 ассемблерных инструкций чтобы иногда понять не хуиты ли понаделал вот тут мне компилятор
Все остальное - разбираешься по надобности
Пусть и суперкратко, но годно. Заскринил, будет хотя бы от чего оттолкнуться
Так ты не путай свои стилистические идиосинкразии уровня "мда, неэлегантно у вас здесь, сударь, выходит, неэлегантно-с" с "у хаскеля проблемы с mutable state".
>дискретная математика не нужна.
А потом получаем непонимание того как происходит переполнение при арифметических операциях, откуда берутся неточности при работе с флоатами и как писать/читать/менять сложные логические условия.
Это мимо.
>А потом получаем непонимание того как происходит переполнение при арифметических операциях, откуда берутся неточности при работе с флоатами и как писать/читать/менять сложные логические условия.
Человеку, который это не понимает, никакая дискретка не поможет.
> непонимание того как происходит переполнение при арифметических операциях
Тебе дай, ты бы его циклические группы для этого учить заставил. Столкнется с этим сам - прочитает за вечер что это такое и что с этим делать.
> откуда берутся неточности при работе с флоатами
То же самое. Большинство программистов вообще ни разу в жизни с этим не сталкивались, и большинство из этого большинства - и не столкнутся.
> как писать/читать/менять сложные логические условия
Он же джавщик - значит взять Drools и поебаться с ним на выходных. Когда и если возникнет надобность. После выходных поймет что не совсем понимает как эта хуйня работает - возьмет книжку, почитает.
В процессе решения конкретной задачи все на порядок лучше осваивается и выучивается чем этот стандартный bottom-up подход "докажем пока все теоремы из первого тома, а зачем мы это делали вы узнаете на пятом курсе"
Даже веб-программисту надо знать законы де Моргана и понимать, почему вдруг оказалось, что 30%*70% != 21%.
Переполнения и флоаты - чтоб считать.
писать/читать/менять сложные логические условия - чтоб, например, валидатор был нормальный, а не лапша из 50 if-ов, причем на каждую формочку своя, совпадающая с остальными на 90%
Ему бы про транзакции хотя бы самые основы понять, 21% это хоть сразу вылезет и нащальника надает
>писать/читать/менять сложные логические условия - чтоб, например, валидатор был нормальный, а не лапша из 50 if-ов, причем на каждую формочку своя, совпадающая с остальными на 90%
Мне за это заплатят больше? Нет? Ну и иди нахуй со своим задротским говном, мне и без него неплохо живётся.
>Столкнется с этим сам - прочитает за вечер
>возьмет книжку, почитает.
Боюсь он просто не будет представлять размеры пробела в своих знаниях и какую книжку ему надо прочитать. Поэтому всё ограничится прогулкой по стековерфлоу и перебором вариантов или задалбыванием опытного коллеги.
>большинство из этого большинства - и не столкнутся.
Потому что руководство не доверит им работу на которой с такими проблемами можно столкнуться.
>Он же джавщик - значит взять Drools и поебаться с ним на выходных. Когда и если возникнет надобность.
Когда он напишет что-то вроде !(!A || !B) у него ничего нигде на защемит, и необходимости что-либо читать он не осознает.
>Это не я делаю, это тот, у которого "90% программ пишутся и без экзистенциальных типов" так делает.
Откуда этот фантазёр знает как я делаю?
>В ООП гетерогенные списки везде
В ООП нет гетерогенных списков, обмудок, единственный ОО-язык который их позволяет делать - это Скала.
Так поясни мне, пожалуйста, как не быть тупым. Напиши роад-мэп, чтобы я знал.
Я тут за математику сел плотно. Алгебра + Лин.Алгебра + Тригонометрия. Плюс комбинаторика.
Что посоветуешь по дискретной математике? Что ещё добавить?
>и функциональные языки без паттерн матчинга (Scheme)
На основании чего ты считаешь схему функциональным языком? Да и паттерн матчинга нет только в стандарте, в котором есть средства для его реализации (коих немеряно).
А на основании чего ты её таковой не считаешь? В твоем представлении ФП = ML-like?
>коих немеряно
Чего-чего немеряно? Реализаций сопоставления с образцом на схеме? Их, полноценных, едва ли на пальцы одной руки хватит.
Да хуле ты к словам цепляешься, епты бля. Главное, что они есть. А вообще, почти в каждой имплементации есть своя реализация, в chicken есть, в guile есть. Ну и каждый уважающий себя скобкоеб писал свою, я, например, писал
Схема достаточно чиста. Но а если уж совсем занудничать, то может оказаться, что в мире нет ни одного функционально чистого языка.
А вот отсутствие АТД и сопоставления с образцом в схеме делает её менее ФП в моём представлении.
>>772513
Писал-то каждый, но пригодных для применения из них - единицы.
Меня и так не заставят
>На ООП хорошо ложатся некоторые задачи, например всякие там ГУЙовины
О, дружище, "ООП хорошо для GUI" - это примерно такой же спид, как и "ООП хорошо для всего" - когда программисты обожглись об ООП, но проблемы гуйни глубже формошлёпства не исследовали, поэтому решили "ну ладно, ООП для %моей_предметной_области% - говно, но ведь КНОПКА - это же объект!!1". Ты ведь понимаешь, о чем я, а уёбок? Повторю другими словами на всякий случай: когда ты был маленьким и глупым и нихуя не шарил в своей предметной области, ты думал, что "всё есть (некий абстрактный) объект (про который я нихуя не знаю)" и что ООП идеально этот факт моделирует. Потом ты немного подрос и поумнел, и выделил в своей области множество взаимосвязей и закономерностей. И она наполнилась морфизмами, функторами, отражениями, естественными преобразованиями, пределами, копределами, сопряжениями и прочими знаниями, для моделирования которых убогое ООП ну никак не подходит. А гуй для тебя так и остался той областью, в которой ты нихуя не шаришь. Так вот, уёбок, не надо экстраполировать свою самоуверенность на все отрасли человеческой деятельности. Если ты охуенный спец по обработке сигналов, это еще не значит, что ты охуенный спец по чистке туалетов или лепке крудов. И если ты не видишь в лепке крудов никаких закономерностей, это еще не значит, что их там нет, и что любой виджет есть объект и не более того. Закономерностей там более чем дохуя. Я вот с ходу могу сказать, что гуйню лучше моделировать стрелками, чем объектами, а истинный спец по гуи тебе наверняка категорий пять навернёт, охватывающих визуализацию, валидацию, интернационализацию и локализацию, лейаут, помощь людям с ограниченными возможностями и хуй знает, что там еще может быть.. Поэтому пиши про то, что знаешь, а про гуй пусть лучше спецы по гуи напишут, от них то мы и узнаем, столь ли там хорошо ООП, или приходится еще каким-нибудь xml-ем в жопу поябываться.
>ООП сложно, оно не нужно, я не осилил
Класс - это тупо программный модуль, изолированный средствами языка. Ты можешь писать на сях изолированные модули, можешь на плюсах в виде классов. Реальное ООП как в смартталке (или как его) не реализовали ибо там помоему упорото совсем.
ООП живо, потому что можно одну группу макак отделить от другой, а между ними повесить интерфейсы и макаки не будут мешать друг другу работая в рамках контракта интерфейса.
ВСЕ, никакие блять наследования и полиморфизмы и использование повторного кода, а тупо возможно разбиение макак одной задачи на группы и увеличить скорость разработки - рынок решил (а не программисты, как они свято верят в это)
Блядь, всегда проигрываю с того, когда прилетают сюда обладатели функциональщины головного мозга(хотя сам ФП котирую) и начинаются кукареки с линзами, бананами, гиломорфизмами, классами типов и пр. При этом всегда уходят в крайности: ООП маздай, пыхопидоры сосут, крестоблядь не человек. Вот только, вероятно, у большинства здешних "мамкиных хаскелистов" проектов больше 20к строк кода и не было, а гитхаб акк так и не наполнен проектами на божественном ML/Haskell/Agda(если вообще наполнен).
>он просто не будет представлять размеры пробела в своих знаниях и какую книжку ему надо прочитать. Поэтому всё ограничится прогулкой по стековерфлоу
Ты прав, скорее всего будет именно так.
Но накачивать ньюба всем около-CS матаном под завязку - тоже не выход. Без реальной задачи и потребности ее решить (а не "сдать курсовик" и подобное) КПД будет меньше чем у паровоза.
Люди делятся на тех кто хочет сделать по-человечески и да нахер оно мне надо, и так платят (>>772311). С первыми вариант "почитать книжку on demand" работает, со вторыми не работает ничего, хоть в Стэнфорд его отправь. Традиционный ВУЗоподход в результате бессмысленно мучает первых и никак не влияет на вторых.
> программисты обожглись об ООП, но проблемы гуйни глубже формошлёпства не исследовали
Те кто исследовал ЧСХ придумали functional reactive programming а никакое не ООП.
> лейаут
Отлично ложится на комбинаторы.
https://www.youtube.com/watch?v=fRdU5yHsAA4
Заодно ответ на >>772676
ООП хорошо подходило для сочетания двух условий - "у нас есть задачи дискретно-событийного моделирования" и "у нас есть Algol60 и больше нихуя". К Алголу60 оказалось очень легко прикрутить несколько полезных (для той задачи) хаков, которые (на тех компьютерах) еще и были дешевы в смысле скорости. Сначала они хотели сделать препроцессор (что логично - Страуструп через много лет тоже начал с этого и собирался этим и ограничиться), но им понадобились и некоторые другие расширения Алгола и ограничиться препроцессором не удалось.
И все эти "Концепции ООП" появлялись именно таким способом: вот интересный (и дешевый в реализации) эффект — как мы можем его использовать? Началось все с того, что понадобилось придумать новый (быстрый) способ передачи параметров в процедуры. Стандартные алголовские способы: по значению и по имени были медленными по разным причинам. Тогда Хоар изобрел ссылки и null. Раз уж структурная эквивалентность оказалось сложной в реализации, сравнивать стали адреса, по которым "объекты" располагаются — появилось identity. Обратили внимание на то, что блок памяти B, структурированный в начале так же, как и блок A можно обрабатывать процедурами, написанными для работы с A — появился "префиксинг" (даже синтаксически объявление класса родителя было префиксным), под который потом подвели идеологию и назвали "наследованием" (ну и понятно, почему сначала никаких "множественных наследований" не было — что такое "множественный префиксинг"?). К рекордам добавили процедуры, диспетчеризующиеся по одному аргументу. Почему именно по одному? Потому что по n > 1 — сложно в реализации.
Прекрасно решили свои задачи дискретно-событийного моделирования, на тех компьютерах что у них были, и успокоились. Но пришел Алан Кей и все испортил. Кей и прочие смолтокеры захотели сделать не такой вот "натянутый" на структурное программирование ООП, а идеологически чистый и непротиворечивый. Для этого они подвели базу под все эти технические срезания углов. Получилась чистая реализация идей, придуманных для быстроты и простоты реализации, только медленная и сложная. Они не смогли все это заставить вертеться с приемлемой скоростью до 90-х годов, когда стало уже поздно. Чтоб ввести Симула-лайк ООП в мейнстрим понадобилось только (временно) отказаться от сборщика мусора. Однако, вся философия и методология ООП, паттерны и юнит-тесты и т.д., придуманные смолтокерами не пропали, а были адаптированы мейнстримом.
Смолток — это не "изначальное древнее ООП", а возрождение умирающего старого и реформация неправильного ООП, загнувшееся, правда, раньше нем неправильное, пока по настоящему древнее ООП все продолжало умирать. Ну и, понятно, философия ООП, которая превратила все картины, загораживающие дырки на обоях, в "краеугольные камни" концепции и "имманентные особенности человеческого мЫшленья"
> программисты обожглись об ООП, но проблемы гуйни глубже формошлёпства не исследовали
Те кто исследовал ЧСХ придумали functional reactive programming а никакое не ООП.
> лейаут
Отлично ложится на комбинаторы.
https://www.youtube.com/watch?v=fRdU5yHsAA4
Заодно ответ на >>772676
ООП хорошо подходило для сочетания двух условий - "у нас есть задачи дискретно-событийного моделирования" и "у нас есть Algol60 и больше нихуя". К Алголу60 оказалось очень легко прикрутить несколько полезных (для той задачи) хаков, которые (на тех компьютерах) еще и были дешевы в смысле скорости. Сначала они хотели сделать препроцессор (что логично - Страуструп через много лет тоже начал с этого и собирался этим и ограничиться), но им понадобились и некоторые другие расширения Алгола и ограничиться препроцессором не удалось.
И все эти "Концепции ООП" появлялись именно таким способом: вот интересный (и дешевый в реализации) эффект — как мы можем его использовать? Началось все с того, что понадобилось придумать новый (быстрый) способ передачи параметров в процедуры. Стандартные алголовские способы: по значению и по имени были медленными по разным причинам. Тогда Хоар изобрел ссылки и null. Раз уж структурная эквивалентность оказалось сложной в реализации, сравнивать стали адреса, по которым "объекты" располагаются — появилось identity. Обратили внимание на то, что блок памяти B, структурированный в начале так же, как и блок A можно обрабатывать процедурами, написанными для работы с A — появился "префиксинг" (даже синтаксически объявление класса родителя было префиксным), под который потом подвели идеологию и назвали "наследованием" (ну и понятно, почему сначала никаких "множественных наследований" не было — что такое "множественный префиксинг"?). К рекордам добавили процедуры, диспетчеризующиеся по одному аргументу. Почему именно по одному? Потому что по n > 1 — сложно в реализации.
Прекрасно решили свои задачи дискретно-событийного моделирования, на тех компьютерах что у них были, и успокоились. Но пришел Алан Кей и все испортил. Кей и прочие смолтокеры захотели сделать не такой вот "натянутый" на структурное программирование ООП, а идеологически чистый и непротиворечивый. Для этого они подвели базу под все эти технические срезания углов. Получилась чистая реализация идей, придуманных для быстроты и простоты реализации, только медленная и сложная. Они не смогли все это заставить вертеться с приемлемой скоростью до 90-х годов, когда стало уже поздно. Чтоб ввести Симула-лайк ООП в мейнстрим понадобилось только (временно) отказаться от сборщика мусора. Однако, вся философия и методология ООП, паттерны и юнит-тесты и т.д., придуманные смолтокерами не пропали, а были адаптированы мейнстримом.
Смолток — это не "изначальное древнее ООП", а возрождение умирающего старого и реформация неправильного ООП, загнувшееся, правда, раньше нем неправильное, пока по настоящему древнее ООП все продолжало умирать. Ну и, понятно, философия ООП, которая превратила все картины, загораживающие дырки на обоях, в "краеугольные камни" концепции и "имманентные особенности человеческого мЫшленья"
> то же самое что автомат для стрижки - который тоже неплохо работает, если у клиента голова квадратная
Но иногда это самый правильный подход - оквадратить головы.
> 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
>единственный ОО-язык который их позволяет делать - это Скала
Потому что это единственный язык с неигрушечной типизацией ООП.
Цену за это пришлось заплатить такую, что хуйзнает, надо ли все это было делать.
В общем-то нет языка, который может "запарить" мозг сильнее, чем скала. Скала имеет мозговыносящую систему типов, не имеющую аналогов в том смысле, что нет другого языка, в котором ООП было бы адекватно статически типизировано. Это крайне сложная и амбициозная задача, буквально все остальные создатели ООЯ на каком-то этапе плюнули и решили: "Статическая типизация — это сложно, лучше будем динамически кастить". Правда, весь этот околодинамический цирк с конями в скале остался "для совместимости" (и дополнительного выноса мозга)
По поводу Obj-C – ладно, плохой аргумент, просто какой язык использовался Эпплом с 1983 года, такой и остался, с небольшими изменениями.
Но Swift разработан с учётом всех best practices. И всё равно имеет ОО парадигму.
>Схема достаточно чиста.
Что значит "достаточно" чиста? Если одна и та же функция может выдать разный результат при одинаковых аргументах, то ни о какой функциональной чистоте и речи быть не может. А еще call/cc, где континуация не то, что не возвращает ничего (что уже противоречит принципам фп), она не возвращается в принципе.
>АТД
Какое там адт, когда типов, в принципе, нет.
>Swift разработан с учётом всех best practices
Как же, как же, помним, помним.
iPhone был тоже "разработан с учетом всех best practices". До какой версии в нем не было даже copy и paste? НИНУЖНА ведь.
iPad тоже был "разработан с учетом всех best practices". Сколько лет у него не было номрального стилуса? НИНУЖНА ведь.
Вот и в этом уёбище все то же самое. Огрызкопрограммистам ничего не нужно, у них есть iTunes, AppleTV и XCode.
>континуация не то, что не возвращает ничего (что уже противоречит принципам фп),
Ведь если возвращать несуществующий костыльный фейк "состояние вселенной", все магическим образом меняется.
>Сколько лет у него не было номрального стилуса
Вот что действительно не нужно. Удачи им с их стилусами по 100$, который при этом отсосёт с заглотом у проф. стилусов для рисования за ту же цену.
>Вот и в этом уёбище все то же самое.
Да нет, это ты уебан просто, не сравнивай свифт с го.
Алсо, он у эпла как оарп у майкрософта – компания его спонсирует, но ничем анально не ограждает.
Стилус - не для рисования, уебан ты эдакий.
Это на огрызках с ним больше ничего нельзя кроме рисования сделать, потому что десятилетия НИНУЖНА привели к тому у огрызка вместо поддержки стилуса в приложениях, SDK и API, пронизывающих всю экосистему (https://blogs.windows.com/buildingapps/2016/04/06/create-ideate-and-collaborate-build-apps-powered-by-windows-ink/) нет НИХУЯ кроме "можно нарисовать котика! yay!"
Стилус в таком устройстве – бесполезная хуйня ради хуйни, как и на телефонах.
>Я и не сравнивал, но ты сам проговорился.
Я-то в чём оговорился, поехавший мамкин нищеброд-борщехлёб? Это модерновый язык, в котором куча фич, в том числе и из функциональщины, без "нинужна" как в го.
>куча фич, в том числе и из функциональщины
Огромная-преогромная. Даже до лютой императивщины Java 8 как до Луны, не говоря уж о C#.
>бесполезная хуйня
Ясно, понятно. Не видел, не пробовал, не знаешь.
НИНУЖНА
Не, я хуйню сказал, "ничего" в схеме это тоже объект. Но акцент был вот на этом:
>она не возвращается в принципе
>Даже до лютой императивщины Java 8 как до Луны, не говоря уж о C#.
Щас бы написать хуйню не видев кода на свифте...
>НИНУЖНА
Ну и нахуя же он мне на системе, разработанной для тыканья пальцем? Можешь дальше свои окошки в оконном режиме на шиндовз планшетах двигать им, оч полезно.
Ах да, ты же скинул видосик где им пишут заметочки и рисуют! Ахуеть полезность!
>А еще call/cc
Которое НИНУЖНА
>Это вполне реализуемо в языках с полноценным call-with-current-continuation, то есть код функции будет одинаковым для T, для AnyMonad<T>
>маааам, мне впаривают хуйню ради хуйни!
>ну дык не ведись, хуле ты.
>но ведь я хачу быдь нитаким как все с айпадами... и у меня нет денег...
На десктопной ос в планшете ясен хуй что без него всё печально, чо уж. Не можем разработать ПО - разработаем палочку с блютусом.
>маааам, я хочу эту хуйню только от огрызкааа
>но ведь огрызки это сделают только к 2030
>мааам, это будет ИННОВАЦИЯ
Стандартный аргумент когда больше нечего противопоставить:
- Смотри, а я на голове стоять умею!
А чо, кто-то кроме огрызка выпускает нормальные планшеты, а не хуйню на яве без планшетных приложений/хуйню с десктопной ОС, которая либо ебаный кирпич похуже любого ноутбука (но не может его заменить при этом) либо приложений нет вообще (НИНУЖНА!), и хоть один конкурент у огрызковых планшетов по соотношению батарейка/эргономичность есть?
Нету => конкуренция говно без задач.
Для огрызкоманов стоять на голове это не то что им нужно, я не спорю. Им нужны более активные, более вовлекающие формы.
https://en.wikipedia.org/wiki/HumancentiPad
>только медленная и сложная
Чистое ООП вообще очень сложно сделать быстрым. В чистом ООП уровня смолтока или джавы без примитивов, все функции должны быть виртуальными, все объекты должны создаваться в куче и менеджится сборщиком, работа с объектами только через ссылки. Естественно, такой язык быстрым быть не может, поскольку на железо не ложится никак.
Стилус на экранах меньше 20 дюймов - бесполезная игрушка. У стилуса точность меньше, поэтому приходится писать заметки буквами в два-три раза больше чем на бумаге. При рисовании приходится непрерывно зумить и скроллить, постоянно мешаешь себе пальцами. Как баловство и для быстрых набросков подходит, для более-менее серьезной работы - нет. Хочешь рисовать на экране - копи деньги на большой синтик, или привыкай к обычному вакому.
>уровня смолтока или джавы
>уровня квантовой физики или школьной арифметики
>уровня круизного лайнера или утлой лодочки
Да хоть уровня скалы и жабоскрипта, общие недостатки-то одни и те же у всех ООП языков.
Но только в Smalltalk можно наслаждаться ими в чистом виде, на полную катушку, только ими, без отвратительных мешающих достоинств.
Если бы вместо джавы IBM, Sun и все-все-все решили бы дать миру INTERCAL, ничего бы не изменилось, писали бы все на INTERCAL как миленькие, точно так же как на Java.
Язык в успехе Java никакой роли не играет, как и в успехе Javascript, например.
У хаскеля нет проблем с mutable state. Могу еще раз повторить.
С системой типой, тотальностью, выводом типов, зависимыми типами, template haskell страшненький. Да много с чем.
Но по сравнению с какой-нибудь джавой или сишечкой это проблемы типа "на моей океанской яхте не работает телевизор на лестнице"
С одной стороны барьера сидят "хаскелисты", осилившие только скрипты писать да конфиг xmonad настроить, фанатично приравнивающие haskell к ghc, не слышавшие о большинстве type экстешонов их любимого компилятора, не понимающие в чём проблемы с RankNTypes, почему и зачем в Clean были введены афинные типы, а в MLKit — регионы.
Но самое смешное, — их противники. Представьте себе любителя эзотерических язычков, орущего о том, что хаскель переусложнённый, а самое главное — о непопулярности оного. Забавно наблюдать подобные заявления от фанатика схемы или, например, Go. Но любое упоминание хаскеля у них вызывает какой-то нерациональный слепой приступ ярости и душевной боли.
Всё довольно просто. В ghc (и вообще классических компиляторах haskell) монада IO является особой, несмотря на то, что формально type IO = State RealWorld. Использовать RealWorld вне этой монады не стоит, — ведь ничто не мешает накастовать на него \a -> (a, a), а потом засунуть один из экземпляров абы куда и там его "потерять", то есть доступ к RealWorld в haskell равносилен нечистоте языка (и вообще жутко неэффективно, ибо оптимизации ghc расчитаны на работу с монадой IO (основной аргумент против введения линейных или хотя бы афинных типов как раз то, что большой кусок ghc должен быть переписан)).
Чтобы решить эту проблемы придумали афинные и линейные типы, — первые позволяют использовать значение этого типа не более одного раза, а вторые — ровно один раз. По факту RealWorld должен быть линейным, но в Clean его сделали афинным, — терять его всё равно нельзя, ибо если потеряешь, то не сойдётся тип main'а.
Тут важно заметить, что использование оных не отменяет возможности (да и банальной потребности в удобном интерфейсе) использовать монаду IO, только теперь она будет иметь вид State !RealWorld, где ! — обозначение линейности/уникальности.
Скорее по сравнению с сишкой/явой хакель прозвучит так:
>чтобы моя яхта плыла, мне нужно вывести типы и зачекать, доказав ей её же правильность, но плывёт она не быстрее черепахи – нужно боксить каждую молекулу воды и преобразовывать руками каждый тип молекулы воды, отличающийся от H2O - добавки соли, например. И самое главное – это всё нужно делать массовым копированием воды чистыми функциями.
Так и хаскель не чистый, на нем императивно писать можно не хуже чем на джавочке
Может у тебя ещё всё мутабельное? Не нужно брать одну молекулу воды, и возвращать модифицированную копию?
Смотри чтоб камнями твои браться по шариату после такого не забили, неверный.
Если не нужно - не нужно. Если нужно - то нужно.
Хаскель позволяет делать и так и так.
При этом четко очертить и разграничить одно и так от другого и так как тебе надо, проверять это и не заставлять все это проверять тебя - вся прелесть именно в этом
>Ты перечисляешь борщеговно для аутистов
Этой фразой ты хотел продемонстрировать свое аристократическое нежелание попадать в какие-либо архивы, если я верно тебя понял? Тебя давно волнует вопрос архивов? Хочешь поговорить об этом?
> Система типов-то у хаскеля как раз нормальная
Компромиссная. С чаще всего работающим выводом типов.
> трекинг побочных эффектов им нахуй не сдался, они и так в курсе, что проиходит в их коде.
Весьма неожиданное утверждение. Многим людям, конечно, вообще нахуй не сдалось что происходит в их коде, и происходит ли оно вообще, и всегда ли оно происходит, или только по четным числам и только при юго-западном ветре не выше 5 метров в секунду. Этих людей обычно пытается периодически побить нащальника, потом их увольняют и они идут копать канавы. Это немного печально, но причем здесь хаскель?
> одна из самых полных и новых книжек по realizability in category theory. Тут есть практически все важные модели и результаты в области описания рекурсивной математики категориально-порядковым языком. Порог вхождения, правда, высокий, — автор предполагает, что читатель неплохо разбирается как в теории категорий, так и в теории порядка.
> http://www.staff.science.uu.nl/~steke104/proefschrift2.pdf
> Если хочется сначала вникнуть в эту область, то рекомендую начать с монографии Oosten'а "Realizability — An introduction to its categorical side". Тут есть основы и превосходно освещается привычная для рекурсивной математики категория Eff (По сути категория марковского конструктивизма)
Я не знаю какие тезисы можно привести в ответ на утверждение о том что людей не волнует корректность их программ, они не хотели бы облегчить себе управление сложностью, помнят весь свой код наизусть (а чужого им не надо), и подобные им.
Мне кажется что адекватный человек таких утверждений делать не станет, а как что-то объяснить человеку неадекватному - я в этом не специалист, этому люди долго учатся, им потом специальные халаты выдают с дипломом.
http://www.leafpetersen.com/leaf/publications/ifl2013/haskell-gap.pdf
>они и так в курсе, что проиходит в их коде
Вот это неверный тезис. Большинство багов в программах, потому что программисты не понимают, что на самом деле происходит в их коде.
У хаскиля везде всё заебись. Нет кода - нет проблем.
>Если одна и та же функция может выдать разный результат при одинаковых аргументах, то ни о какой функциональной чистоте и речи быть не может.
Тогда у нас нет чистых ФЯП.
>А еще call/cc, где континуация не то, что не возвращает ничего (что уже противоречит принципам фп), она не возвращается в принципе.
Продолжение и не может ничего вернуть, учи мат.часть
callCC :: ((a -> ContT r m b) -> ContT r m a) -> ContT r m a
В сишных программах не бывает багов.
Во-первых, сишники всегда знают что происходит в их коде.
Во-вторых, сишные программы настолько быстры, что баги просто не успевают происходить.
> 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
> 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/
> 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
Вчерашний день. Кванты пишут DSL для аналитиков, чтоб те сами 90% писали.
>ООП живо, потому что можно одну группу макак отделить от другой, а между ними повесить интерфейсы и макаки не будут мешать друг другу работая в рамках контракта интерфейса.
Всё это можно было делать и в модульном программировании.
/тред
> subhuman
> fleas = 14
axaxaxaxxax
Зависимые типы далеко не только про «давайте чекать на тайплевеле вообще все», а проблема хаскеля не в изоляции IO, а в том, что он использует монады вместо эффектов для этого.
Ну Лука Карделли пытался, но нихуя не получилось же. Даже определение композиции не осилил. А все потому что ООП - обычная такая надстройка под процедурщиной, которая по строгости и уровню формализации является чем-то средним между философским трактатом и юридическим договором. Гуманитарная дрисня в общем. Для даунов.
Поэтому ты либо инженер и пишешь команды на асме, либо прикладной логик-алгебраист и пишешь на Coq и LambdaProlog. Остальная пиздобратия - обычные гуманитарные офисные питухи.
>либо инженер и пишешь команды на асме, либо прикладной логик-алгебраист и пишешь на Coq и LambdaProlog
Не вижу здесь никакого либо.
Высокоуровневую логику - на языках высокого уровня, необходимые для требуемого быстродействия части - на языках низкого уровня, если нужен небольшой (или большой) rule engine - либо берешь готовый, устраивающий тебя, либо быстренько пишешь на коленке небольшой Prolog - ну, идея понятна.
Он вирус скачал и у него брат умер, ты с Ромулом попутал.
YO!
Дауны не могут в формулу Бине.
То, что ты обосрался в самом начале поста, позволило мне сэкономить время и недочитывать остальной бред.
Ну, щас-то хаскель в индустрии массово применяют. Вакансий больше, чем на джаву.
В той статье аргументы малость протухли. Например, в хаскель завезли stack, а опенсорц стал нормой.
Мартыханских вакансий конечно больше на джаве, но если говорить про что-нибудь нормальное, то там будет Хаскель.
>Ну Лука Карделли пытался
О, анон, ты походу его читал. Собираюсь тоже почитать. Интересно хоть?
> Линух потому и жив, что его писали на Си
У линукса очень маленькая сложность как у системы. Там, упрощённо говоря, есть некоторая центральная часть типа управления памятью и проч. + куча драйверов. Добавь 100 драйверов или выкини, изменится только суммарное число строк, но не сложность архитектуры.
Почему это не получилось? Очень даже получилось. Только у него говно получилось, длинное и бесполезное.
>Можно вообще обойтись без наследования
Можно обойтись без наследования, классов, исключений, функций и много всего другого.
Можно обойтись без ног, рук, одной почки и одного лёгкого. Без глаз, ушей и языка. Только вот жизнь станет немного скудной.
Сейчас бы поутешать самого себя.
Ситуация примерно такая: в джаве отношение мартыханских вакансий к нормальным - 10/1, в хаскеле 1/10, при этом нормальных вакансий на джаве в 100 раз больше чем на хаскеле. Я не к тому что хаскель хуже джавы или что-то в этом роде, просто такова реальность.
>Наиболее быстро - шаблонами. В таком коде нет ничего такого, чтобы выполнять проверку или переход по указателю на функцию каждый раз. Сделай 2 копии кода, и тебя все заинлайнится и будет чики-пуки
Понимаешь, тогда будет либо отдельные launch_d3d11.exe и launch_ogl.exe. Либо всякие
if(m_mode == MODE_D3D11)
{
D3D11Render();
}.
В первом случае хуйня какая-то. Во втором случае тот же самый оверхед на branch predictor. У меня, правда, возникали идеи - а если он и правда работает статистически, то, может, после прохода 1000 раз по варианту MODE_D3D11 он всегда будет выбирать его? Но я не хочу серьёзно полагаться на такую низкоуровневую вещь, как реализация предсказателя переходов на конкретном процессоре.
>Cache miss во время двойного перехода указатель на объект->адрес VMT->смещение по VMT страшнее
Хм. А разве он не может подгрузить в кэш все функции, которые тебе нужны? Он же видит, например, что функции по D3D11 используются много, а OGL в данной сессии не использовались вообще. Или кэш не такой умный? Или это опять же зависит от реализации, как в предыдущем примере?
>Кстати, признак школьника-долбоеба - слово ААА в лексиконе. Это примерно так же, когда говорят хайлоад в вебе, но хуже, потому что на игры в принципе одни школьники дрочат
Ну во-первых, мне просто нравится работа с графикой. Именно с программной стороны. Всякие сложные алгоритмы, эффекты - это пиздец как интересно.
А во-вторых, я и не использовал этого слова.
>оверхед на branch predictor
Начиная с Haswell брэнч предиктор на свитчах уже не промахивается практически.
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 Хороший учебник, всё расписано подробно. Сам по нему учился. Рекомендую.
А где вообще можно увидеть тесты на эту тему? Или вручную закупать процессоры разных лет и самостоятельно проверять?
http://agner.org/optimize/
http://igoro.com/archive/fast-and-slow-if-statements-branch-prediction-in-modern-processors/comment-page-1/#comment-178540
Если тебе надо на полчаса потестировать, зачем покупать, в эпоху облачных технологий.
Короче, начал пилить проект, подразумевающий дохуя разнородных структур, мутабельный стейт, сорт оф наследование (или сабтайпинг, я хз), модульность, короче, все, для чего придумывалась волшебная таблетка ооп. Взял питон, ну а что, ПРОСТО пишешь и все работает, как я по наивности предполагал. Первые 4к SLOC все и правда шло хорошо, я открывал для себя на практике паттерны ооп, вроде multiple dispatch и синглтонов, да еще с такими-то метаклассами, почти как в CLOS/MOP, сказка прям. Но в какой-то момент была достигнута сингулярность и начался какой-то адовый пиздец, растущий по экспоненциальной зависимости. Конечно, вскрылись фундаментальные ошибки в архитектуре, но дело даже не в этом, а в том, что я просто перестал понимать всю ту лапшу, в которую превратился мой код. Да, я писал поначалу методы, максимум, в 10 (или сколько там по PEP-008) строк, но рано или поздно их приходилось подпирать костылями, плюс мутабельность, когда нихуя не ясно, когда оно там мутирует, а иногда вообще не понять, где мутатор, а где мутант. Причем, я не думаю, что если бы в гвидобейсике была система типов, было бы легче, была бы та же костыльная лапша, только более вербозная. Когда я поймал себя на том, что опустился до глобальных переменных и magic numbers, весь питонокод был отправлен в ад.
Для второй попытки я выбрал Scheme. Изначально самый ванильный R5RS, который из ракеты. Принципиально отказался от мутабельности и сайд эффектов, кроме ио, и, перешагнув через себя, от call/cc (пытался в функциональное ооп на континуациях, но это хуита, все-таки), кроме обработки ошибок. Вместо питоновских объектов - обычные ассоциативные списки, вместо методов - функции, принимающие "объект" и возвращающие модифицированную копию (меня не волновало потребление памяти и скорость), плюс макросы для более удобного последовательного применения этих функций. 4к строк питонокода уместились на схеме в 1к. Примерно тогда же, я осознал, что от общего стейта не сбежать никак, пробовал варианты с multiple return values, но оказалось неудобно, прибегать к set! не хотелось, короче, да, анон, ты прав, я понял, что пытаюсь изобрести монады.
И таки написал реализации >>= и return, ну и макрос для do нотации. Да, это оказалось той самой волшебной таблеткой, сделавшей мой день. Я, наконец-то, смог сконцентрироваться на решении проблемы с помощью языка программирования, а не на борьбе с ним. Только вот (да-да, господа хаскеллисты, это жалкое подобие монад в языке без типов, etc, но все же), мне кажется, или это и есть то же ооп, сделанное через жопу реализованное функционально? То есть, на словах это вещи разные: с одной стороны, мутабельная хуйня в виде black box, с другой - описание последовательности вычислений с имплицитным стейтом. Вот только без стейта обойтись все равно никак, а если представить, что последовательность процедур в императивной параше и есть последовательность вычислений, то выходит, что монады это, буквально, та же хуйня, только с лишним слоем абстракции?
Короче, начал пилить проект, подразумевающий дохуя разнородных структур, мутабельный стейт, сорт оф наследование (или сабтайпинг, я хз), модульность, короче, все, для чего придумывалась волшебная таблетка ооп. Взял питон, ну а что, ПРОСТО пишешь и все работает, как я по наивности предполагал. Первые 4к SLOC все и правда шло хорошо, я открывал для себя на практике паттерны ооп, вроде multiple dispatch и синглтонов, да еще с такими-то метаклассами, почти как в CLOS/MOP, сказка прям. Но в какой-то момент была достигнута сингулярность и начался какой-то адовый пиздец, растущий по экспоненциальной зависимости. Конечно, вскрылись фундаментальные ошибки в архитектуре, но дело даже не в этом, а в том, что я просто перестал понимать всю ту лапшу, в которую превратился мой код. Да, я писал поначалу методы, максимум, в 10 (или сколько там по PEP-008) строк, но рано или поздно их приходилось подпирать костылями, плюс мутабельность, когда нихуя не ясно, когда оно там мутирует, а иногда вообще не понять, где мутатор, а где мутант. Причем, я не думаю, что если бы в гвидобейсике была система типов, было бы легче, была бы та же костыльная лапша, только более вербозная. Когда я поймал себя на том, что опустился до глобальных переменных и magic numbers, весь питонокод был отправлен в ад.
Для второй попытки я выбрал Scheme. Изначально самый ванильный R5RS, который из ракеты. Принципиально отказался от мутабельности и сайд эффектов, кроме ио, и, перешагнув через себя, от call/cc (пытался в функциональное ооп на континуациях, но это хуита, все-таки), кроме обработки ошибок. Вместо питоновских объектов - обычные ассоциативные списки, вместо методов - функции, принимающие "объект" и возвращающие модифицированную копию (меня не волновало потребление памяти и скорость), плюс макросы для более удобного последовательного применения этих функций. 4к строк питонокода уместились на схеме в 1к. Примерно тогда же, я осознал, что от общего стейта не сбежать никак, пробовал варианты с multiple return values, но оказалось неудобно, прибегать к set! не хотелось, короче, да, анон, ты прав, я понял, что пытаюсь изобрести монады.
И таки написал реализации >>= и return, ну и макрос для do нотации. Да, это оказалось той самой волшебной таблеткой, сделавшей мой день. Я, наконец-то, смог сконцентрироваться на решении проблемы с помощью языка программирования, а не на борьбе с ним. Только вот (да-да, господа хаскеллисты, это жалкое подобие монад в языке без типов, etc, но все же), мне кажется, или это и есть то же ооп, сделанное через жопу реализованное функционально? То есть, на словах это вещи разные: с одной стороны, мутабельная хуйня в виде black box, с другой - описание последовательности вычислений с имплицитным стейтом. Вот только без стейта обойтись все равно никак, а если представить, что последовательность процедур в императивной параше и есть последовательность вычислений, то выходит, что монады это, буквально, та же хуйня, только с лишним слоем абстракции?
Без стейта не надо обходиться.
Хаскельное удобство не в том чтоб не было стейта, или не было мутаций, или не было IO, или не было сайд-эффектов. Оно только в том чтобы все эти эффекты были эксплицитно обозначены, легко отделялись друг от друга и от кода без эффектов, и с этим всем было удобно работать.
В Racket ты мог бы на полную мощности использовать контракты и typed racket, со своими плюсами и своими минусами для тех же целей.
ООП в Хаскель есть, свое, марсиански-структурное, и на изобретения из Симулы похоже не очень.
>это жалкое подобие монад в языке без типов
Попизди мне тут. Монада - не цель, а средство. В языке с call-cc ты можешь использовать функцию в монадическом коде а не писать отдельную и ехал лифт через лифт, а map через mapM
>Вот только без стейта обойтись все равно никак, а если представить, что последовательность процедур в императивной параше и есть последовательность вычислений, то выходит, что монады это, буквально, та же хуйня, только с лишним слоем абстракции?
Именно так. В фортране ты эмулируешь стек, в сишке кастишь void*, в С++ ебешься с владением, в старой жабе мучаешься без лямбд, а в хаскелле ты явно пердолишься со стейтом. Это неудобство, но иногда это неудобство бывает оправданным (иначе эти языки бы не существовали). Например, в академической среде.
Твоя ошибка в том, что ты, соснув с питоном, не начал изучать причины своего отсоса (мы обсуждали в соседнем треде, в динамическом языке нужно 100% покрытия "тестами типизации", чтобы оно хоть как-то работало), а решил, что это язык виноват.
Не "пердолишься", а аккуратно и эксплицитно работаешь с ним.
> В фортране ты эмулируешь стек
В Алголе запилили нормальный уже.
> причины своего отсоса (мы обсуждали в соседнем треде, в динамическом языке нужно 100% покрытия "тестами типизации", чтобы оно хоть как-то работало)
В первую очередь все решают вопросы архитектуры. Разбиение на модули, выбор абстракций, интерфейсов между ними, организация кода. 100% покрытия тестами не требуется во многих случаях.
> а решил, что это язык виноват.
Он не решил что язык виноват. Он сообщает что на собственном опыте убедился вот в чем - в том что если (как он в первой же фразе и объявил) архитектурить не умеешь - в данном случае потому что опыта нет - то язык может тебя в разной степени заставить это делать (пусть и не самым оптимальным образом, но хоть как-нибудь), а может не заставлять.
В разных случаях требуется разное, соотношение затрат времени и сил разное, требования разные, квалификация у всех разная. Мудрый человек не сильно напрягаясь напишет понятный, надежный, легко модифицируемый и быстрый код на любом языке, использовав те проеимущества языка что ему нужны в конкретном случае.
>Без стейта не надо обходиться.
Никто и не говорит, что надо.
>>775337
man irony
>>775341
>Твоя ошибка в том, что ты, соснув с питоном, не начал изучать причины своего отсоса (мы обсуждали в соседнем треде, в динамическом языке нужно 100% покрытия "тестами типизации", чтобы оно хоть как-то работало), а решил, что это язык виноват.
Питон был взят для прототипирования, просто вначале хорошо пошло, думал на нем и доделаю.
>>775343
>Он не решил что язык виноват. Он сообщает что на собственном опыте убедился вот в чем - в том что если (как он в первой же фразе и объявил) архитектурить не умеешь - в данном случае потому что опыта нет - то язык может тебя в разной степени заставить это делать (пусть и не самым оптимальным образом, но хоть как-нибудь), а может не заставлять.
В точку. Ну и еще про небходимость правильного выбора инструмента (я считаю, питон для тех случаев, когда баша или перла немного не хватает, ну или для рапид прототайпинга).
>Не "пердолишься", а аккуратно и эксплицитно работаешь с ним.
>эксплицитно
https://www.youtube.com/watch?v=5tkMi72w8j0
>Он не решил что язык виноват
Он взял мейнстримный язык, наговнокодил, и потом взял экзотику. Т.е. вместо того, чтобы понять, что с собой не так, хает питон. Еще пара таких итераций и очередное золотце готово.
Хорошо - "явным образом" будет достаточно для тебя понятно?
Чтобы "понять что с ним не так" требуется гораздо больше времени чем взять язык, который ему в данном случае бил по рукам и тем самым помог не говнокодить.
Он решил поделиться своим опытом.
>>775359
>питон для тех случаев, когда баша или перла немного не хватает
Это ошибка во многих случаях. Во многих - нет.
Мир разнообразен.
Кто-то берет питон написать небольшую утилиту, кто-то пишет на нем миллионы строк, по-разному бывает.
То что динамические языки дают больше свободы - эти еще нужно уметь правильно воспользоваться. А не себе во вред.
Хуя ты пиздабол. Налепил слов на *ция, как будто это придаст смысл и большую значимость твоему высеру. Пиздец, и с таким апломбом ещё... Как будто бы только что статью в энциклопедию написал.
>Чтобы "понять что с ним не так" требуется гораздо больше времени чем взять язык, который ему в данном случае бил по рукам и тем самым помог не говнокодить.
Он выкинул код и написал его заново. Конечно велик шанс, что вторая попытка будет чуть лучше прошлой.
Совсем невелик.
Хотя я очень удивлен таким лихим его напором и освоением схемы и хаскеля в кратчайшее время, может быть он и дизайну и архитектуре так же лихо учится, вундеркинд.
Очень велик, когда изначальный подход - это
>вроде multiple dispatch и синглтонов, да еще с такими-то метаклассами, почти как в CLOS/MOP, сказка прям
Не, я хаскель не осваивал. Считаю, что еще не дорос. Про монадки знал в общих чертах. А у схемы весь стандарт на 50 страниц, осваивать нечего.
>>775376
>язык, который ему в данном случае бил по рукам и тем самым помог не говнокодить.
При желании и на ванильном r5rs можно запилить python-like oop и говнокодить в нем, а еще srfi есть какие-то, вроде, с подобием ооп. Тут я сам себя по рукам бил, схему взял из-за макросов, наличия ровно нихуя в стандартной библиотеке, да и вообще люблю лишп. Вместо нее мог быть тот же питон, это вообще не важно, тут про ооп vs монадки, а не языкосрач
Ты прав, так и есть, вкусив всех прелестей ооп, я выбрал другой подход и получилось чуть лучше.
>Чтобы "понять что с ним не так" требуется гораздо больше времени чем взять язык, который ему в данном случае бил по рукам и тем самым помог не говнокодить.
Для чистоты эксперимента надо чтобы он ещё раз написал этот проект на питоне. Вполне возможно успех со схемой вызван тем, что грабли были уже изучены при прототипировании.
>Для чистоты эксперимента надо чтобы он ещё раз написал этот проект на питоне.
Читай:
>>775426
>схему взял из-за макросов, наличия ровно нихуя в стандартной библиотеке, да и вообще люблю лишп. Вместо нее мог быть тот же питон, это вообще не важно
Будет абсолютно то же самое на питоне с монадами.
В итоге - чтобы понять как надо было это делать с самого начала потребовалось сделать два прототипа на выброс.
https://news.ycombinator.com/item?id=11939851
Для чистоты эксперимента хорошо бы посмотреть на код. Пока все эти слова доверия не вызывают. Я вижу только личинку лиспера, т.е. говно нации.
А как иначе?
>>775468
>личинку лиспера, т.е. говно нации
Один лиспер = целая нация?
Да, схема - не лисп. Только синтаксис похож.
>А как иначе?
Иначе - это когда прототипов на выброс делать не требуется, а дизайнится, и пишется один раз - и сразу работает.
Для этого нужен опыт.
Малолетние долбоебы называет это waterfall и утверждают что такого не бывает, а нужно соблюдать аджайл, слушать радио Радонеж и переписывать все заново каждые две недели.
> дизайнится, и пишется один раз - и сразу работает
такая хуита бывает только в госзаказах
вотерфол это когда заказчик не видит результат пол года, потом получает парашу что вы слепили и посылает вас нахуй, потому что все не так
это любимый способ разработки в военке и НИИ, где все должно быть параллельно и перпендикулярно, а на продукт всем похуй, главное отчеты и работа вместо результата, ведь продукт делается не чтоб зарабатывать бапки, а чтоб горжусь великай родиной
>потому что все не так
Для того чтобы было все так существуют Технические Задания, Эскизные Проекты, Рабочие Проекты, и Технические Проекты, не говоря о документации.
Говорил я не об этом, кстати. Но так ты не видел нихуя кроме стэндап-митингов, заменяющих проектирование, то тебе кажется что по-другому и не бывает.
>Технические Задания, Эскизные Проекты, Рабочие Проекты, и Технические Проекты, не говоря о документации
Вся эта хуйня существует только в вотерфол мирке, который умер в нормальных странах ещё в 80е, кроме госпараши разумеется
>документации
Это присутствует в любом проекте, не важно от методологии, но это не решает описанной выше проблемы.
Я и не говорил что документация сама по себе волшебным магическим образом решает проблемы.
Проблемы решаются головой. Ей же осмысливается опыт, выводы из опыта применяются к новым проектам - потому что решения и задачи в погромировании на 95% типовые и одни и те же. Особенно если общие их черты научиться видеть.
Голову ни одна методология, хотя бы и с самыми скрамными и солидными аджайлами, не заменяет.
Тем более что туда где аджайлы, стендапы и скрамное мракобесие, нормальный, уважающий себя человек чаще всего просто не пойдет.
ad hoс, конечно же
Ты даже задачу не можешь сформулировать.
Сколько капч тебе надо распознавать - одну в час или миллион в секунду?
Когда эта капча сменится другой - окей ли выкинуть распознавалку и начать все сначала или лучше потратить X времени сразу на нормальную?
И еще десяток подобных вопросов.
Потрать час-два времени, подумай над ними хорошенько, расставь приоритеты.
Станешь уже на 30-50% ближе к правильным решениям.
Задача - обнаруживать новые WEBM как можно ближе к реалтайму делая запросы только с одного айпишника.
Тредов и досок много, поэтому придётся делать несколько запросов в секунду.
Ты не понял.
Это был не вопрос к тебе сформулировать для меня задачу более точно.
Это был добрый методологический совет как тебе начать включать голову и хотя бы начать улучшать качество решения твоих задач.
Судя по твоему ответу, тебе это не помогло. Задача сформулирована так же говенно как и в прошлый раз - вопросов к ней с таким дополнением стало только больше.
Может быть ты не умеешь понимать прочитанное - это называется функциональная неграмотность.
Это ты не понял. Я показал конкретный пример того как так случается, что чёткой постановки задачи нет.
У меня есть только широкая формулировка большой задачи, из которой никак не вывести детали реализации. Когда нет дяди в галстуке который бы принёс на блюдечке спецификацию. Только ты один на один с дикой природой. Архитектор, ПМ и кодер в одном лице. Твоя задача сделать жизнеспособный продукт или объяснить почему это невозможно.
Ты сам должен провести инвестигейшн, выяснить какая у двача и у клаудфлейра политика бана за частые запросы и частое неправильное распознавание капчи. Проверить что лучше - использовать API или парсить треды. Если парсить треды, то какую версию - десктопную или мобильную.
А потом ещё найти где хостинг подешевле. И тут интересное ещё не заканчивается. Сканер двача это только часть проекта. Вебмки я в итоге собираюсь выкачивать и процессить, и для этого нужен достаточно мощный сервер. Есть хостинги подешевле, где в полиси запрещается использовать все ядра в режиме 24/7, а есть полноценные vds, но стоят они заметно дороже. Чтобы сказать какой сервер мне нужен (и сколько ядер на нём) мне надо знать как меняется количество вебмок на дваче в течении недели, каковы пики и средняя нагрузка, и какой среди вебмок процент повторов в долгосрочной перспективе. С этими данными я смогу сказать а по карману ли мне вообще этот проект или это всё воздушные замки.
Но вот загвоздка - чтобы собрать эти данные нужна прога, которая сканит двач и находит вебмки.
Если проект реализовать с моим бюджетом невозможно, то я хочу узнать об этом как можно раньше. Поэтому я пишу прототип, и другого варианта не вижу.
Проектирование делается после рисёрча, а его зачастую невозможно провести без прототипа.
Конечно всё проще если ты упитанный розовощёкий офисный кретин, которому начальник присылает спецификацию. Но эта простота обусловлена тем, что во-первых за тебя подумал аналитики, ПМ и тимлид, а во-вторых не исключено, что высшее руководство рассматривает весь твой проект как прототип, и если не взлетит он, то будут извлечены уроки и запилят новый.
Это ты не понял. Я показал конкретный пример того как так случается, что чёткой постановки задачи нет.
У меня есть только широкая формулировка большой задачи, из которой никак не вывести детали реализации. Когда нет дяди в галстуке который бы принёс на блюдечке спецификацию. Только ты один на один с дикой природой. Архитектор, ПМ и кодер в одном лице. Твоя задача сделать жизнеспособный продукт или объяснить почему это невозможно.
Ты сам должен провести инвестигейшн, выяснить какая у двача и у клаудфлейра политика бана за частые запросы и частое неправильное распознавание капчи. Проверить что лучше - использовать API или парсить треды. Если парсить треды, то какую версию - десктопную или мобильную.
А потом ещё найти где хостинг подешевле. И тут интересное ещё не заканчивается. Сканер двача это только часть проекта. Вебмки я в итоге собираюсь выкачивать и процессить, и для этого нужен достаточно мощный сервер. Есть хостинги подешевле, где в полиси запрещается использовать все ядра в режиме 24/7, а есть полноценные vds, но стоят они заметно дороже. Чтобы сказать какой сервер мне нужен (и сколько ядер на нём) мне надо знать как меняется количество вебмок на дваче в течении недели, каковы пики и средняя нагрузка, и какой среди вебмок процент повторов в долгосрочной перспективе. С этими данными я смогу сказать а по карману ли мне вообще этот проект или это всё воздушные замки.
Но вот загвоздка - чтобы собрать эти данные нужна прога, которая сканит двач и находит вебмки.
Если проект реализовать с моим бюджетом невозможно, то я хочу узнать об этом как можно раньше. Поэтому я пишу прототип, и другого варианта не вижу.
Проектирование делается после рисёрча, а его зачастую невозможно провести без прототипа.
Конечно всё проще если ты упитанный розовощёкий офисный кретин, которому начальник присылает спецификацию. Но эта простота обусловлена тем, что во-первых за тебя подумал аналитики, ПМ и тимлид, а во-вторых не исключено, что высшее руководство рассматривает весь твой проект как прототип, и если не взлетит он, то будут извлечены уроки и запилят новый.
Ты описываешь какой-то оверкилл. Особенно включая экономические факторы. В жизни, а не школьных учебниках, устроено все попроще. С таким подходом к проектированию и разработке как у тебя, быстро в трех соснах заблудишься. Попробуй набить шишек в реальных проектах, вместо теоретизирования.
>такая хуита бывает только в госзаказах
Не бывает. Вот как выглядит разработка прибора:
1. Эскизный проект - теоретики ебашат выкладки, что это возможно. Каждый отдел пишет ТЗ по тому, что он знает
2. Технический проект. Уже более подробное описание.
3. Лабораторное изделие - альфа-версия, так сказать. Изделия ебашится вдоль и поперек, модифицируется прямо паяльником на месте.
4. Стендовое изделие - несколько бета-версий.
5. Штатные изделия - все гонится потоком.
На каждом этапе заказчик принимает все и подписывает.
>это любимый способ разработки в военке и НИИ
А ты как хочешь? Каждый день новый прибор за несколько миллионов клепать, чтобы протестить багфикс? Или чтобы заказчик "ой, а нам энергопотребление нужно в 5 раз меньше, и цвет зелененький можно" пиздел на середине разработки? Ты ебанько с промытыми порашей мозгами.
>Задача - обнаруживать новые WEBM как можно ближе к реалтайму делая запросы только с одного айпишника.
Это не задача.
>обнаруживать новые WEBM как можно ближе к реалтайму
Вот это - задача.
И решать ее разгадыванием капчи - дурацкий способ. Способы нужно перебирать таким образом:
1. Готовое решение - может решение уже сделано. Всегда нужно начинать с анализа конкурентов.
2. Социальное решение - может проще написать Абу и дать ему долю в обмен на API. Это просто нереальный этап для программистишки.
3. Типовое решение. То, что делается всегда в таком случае. Например, набор из 10К прокси.
4. Йоба-решения, требующие R&D.
А далее, если ты опустился до этого варианта, тебе нужно собственно R&D, которое является отдельной работой по своим законам. Именно тут делают ad-hoc прототипы из говна и палок, доказывающие работоспособность каждой из частей.
>Но вот загвоздка - чтобы собрать эти данные нужна прога, которая сканит двач и находит вебмки.
Чтобы узнать политику бана, тебе достаточно curl. Но еще лучше - спросить. Потому что грузить сервер однообразными запросами - занятие мудацкое изначально.
>Поэтому я пишу прототип, и другого варианта не вижу.
>Проектирование делается после рисёрча, а его зачастую невозможно провести без прототипа.
Это ad-hoc прототипы маленьких чстей системы, которых в процессе проектирования делается куча по полчаса на каждый.
Это НЕ версии всей системы целиком "на выброс", о которых и шла речь изначально.
Так аджайл-сектанты ведь на полном серьезе утверждают что заранее вообще ничего знать невозможно!
Ни какое у прибора должно быть энергопотребление, ни какой зелененький цвет. Потому что неподвластно это уму человеческому, и проектирование - тайна великая есмь, из глубины веков, забытое искусство ацтеков.
А такие вещи как анализ требований и спецификации - слова неприличные, в аджайл-манямирке не употребляемые.
http://www.markjowen.com/2014/09/01/is-agile-a-cult/
Было это взято из авральной модели затыкания дыр.
> Before the Agile fad made it a permanent process, “Scrum” was a term sometimes used for what corporations might also call a “Code Red” or a “War Room emergency”. If there was an unexpected, rapidly-evolving problem, you’d call together your best people and form a cross-cutting team.
> This team would have no clear manager, so you’d elect a leader (like a “Scrum Master”) and give him authority. You’d want him not to be an official “people manager” (since he needs to be as impartial as possible). Since the crisis is short-term, individuals’ career goals can be put on hold. It’s considered a “sprint” because people are expected to work as fast as they can to solve the problem, and because they’ll be allowed to go back to their regular work once it’s over. Also, in this kind of emergency, you need to make it clear that no one is being evaluated individually. The focus is on the mission and the mission only.
> https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/
Логичный вывод мудрых аджайл-консультантов - давайте же сделаем всю работу постоянным авральным затыканием дыр.
> It’s time for this culture of terminal juniority, low autonomy, and aggressive management to die. These aren’t just bad ideas. They’re more dangerous than that, because there’s a generation of software engineers who are absorbing them without knowing any better. There are far too many young programmers being doomed to mediocrity by the idea that business-driven engineering and “user stories” are how things have always been done.
Аджайл нормален, когда ребилд всей системы не стоит ничего и занимает 10 минут. В промышленности такое бывает редко, в айти - часто, но не прямо сказать, чтобы всегда. То есть по сути когда вся разработка - это и есть проектирование, аджайл нормален.
В любом случае странно дрочить что на водопад, что на аджайл, это разные методы со своими достоинствами и недостатками.
>Логичный вывод мудрых аджайл-консультантов - давайте же сделаем всю работу постоянным авральным затыканием дыр.
Ну это капитализм - вытянуть из работника ресурсы по-максимуму, не беря при этом на себя ответственность за кривое ТЗ. При водопаде если клиент подписал этап, то все, пизда, контрактор может ссылаться на эту подпись, даже если там явно невыгодное решение, а устроить это довольно просто, ведь заказчик не может знать так много о разработке, как исполнитель.
>culture of terminal juniority
Годно выразил.
На русский точно даже и не переведешь.
Страна вечного детства блджад.
Полного и окончательного детства.
Этого двачую. Программач превратился в сборище вечно ноющих идиотов, которым всё не так. Хорошо, что подобных макак не пускают к управлению.
Объекты с множеством конструкторов и 1 функцией exec - самая лучшая абстракция, которая неплохо себя документирует. Всегда так делаю.
>Для абстракций лучше всего подходит ООП.
Потому что ничего другого ты не видел и не знаешь.
>Кривые абстракции - дефект программиста, а не ООП.
Но источник некривых программистов, которым не помешает даже ООП, пока не обнаружен.
>Наследование в ООП не является обязательным к использованию
А так как других способов реализации полиморфизма в ОПП нет, то полиморфизм не нужен, заебись.
>Но источник некривых программистов, которым не помешает даже ООП, пока не обнаружен.
Смотрите, Прямой заехал!
>А так как других способов реализации полиморфизма в ОПП нет, то полиморфизм не нужен, заебись.
Ты че? Ебанутый? Че ты там делаешь?
Лучшая абстракция - U-комбинатор.
>других способов реализации полиморфизма
Во-первых, наследование никак не связано с полиморфизмом. Во-вторых, полиморфизм это костыль для ЯП со статической типизацией.
Наследование - это кривой костыль, которым полиморфизм реализуется в ООП-парадигме, потому что других не завезли.
Но нет же, ООП плохой, негодный. Пушкин с Толстым хуйню написали, надо переписать на ассемблере.
Ты говно с мочой путаешь. Наследование это повторное использование кода. Полиморфизм к нему никаким боком.
Тебе уже в говновики даже написали
> Подтипизация (subtyping), или полиморфизм подтипов (subtype polymorphism), означает, что поведение параметрически полиморфной функции ограничивается множеством типов, связанных в иерархию «супертип — подтип»
ООД - это штука, которая говорит: раз мы можем держать сложность под контролем, не надо ей озабачиваться во время проектирования, а надо тупо плодить объекты на каждый чих. И создает сложность гораздо быстрее, чем ООП в состоянии ее контролировать.
То крестоебы писали, у них родовая травма.
Наследование изначально не для полиморфизма, а для повторного использования кода.
>надо тупо плодить объекты на каждый чих
а вот за это я бы арматурой по рукам бил, за каждую лишнюю сущность
Согласен, слово "изначально" было лишнее.
Но продолжаю настаивать, что полиморфизм через наследование - это костыль
Нахуя метод exec, если можно перегрузить оператор вызова.
Так глупо, что даже толсто. Поведение функций зависит только от аргументов и влияет лишь на возвращаемое значение, поэтому зачастую по одной только сигнатуре можно понять, что она делает.
Например:
head :: [a] -> a
или посложнее:
compose :: (b -> c) -> (a -> b) -> a -> c
maybe :: b -> (a -> b) -> Maybe a -> b
У объектов же есть есть ещё подводная часть айсберга - его внутреннее состояние и связи с другими объектами, у которых оно тоже есть, а это уже очень трудно поддается документированию.
>Поведение функций зависит только от аргументов и влияет лишь на возвращаемое значение
Неправильно. И объекты, и функции, могут как обладать внутренним состоянием, так и не обладать. Причем даже не обладая внутренним состоянием, они могут иметь квази-внутреннее состояние (путем возврата модифицированной копии). Здесь никакой разницы нет.
>поэтому зачастую по одной только сигнатуре можно понять, что она делает.
Ну давай, расскажи мне, что делает [Float] -> IO [Float].
> полиморфизм через наследование - это костыль
А такое возможно вообще? Пример справедливый для этой части Вселенной, пожалуйста.
Ты ООП изобрел. Пишешь просто похоже на каком нибудь урезанном форке си
У тебя получилась in-memory база данных без SQL.
Если у тебя язык без GC то непонятно кто будет освобождать память. Если с GC то советую для реестра объектов использовать weak references.
И вообще давай там без фанатизма, глобальные переменные ругают не зря.
>зачастую по одной только сигнатуре можно понять, что она делает
Это ещё один функци-анальный миф:
val sendto : file_descr -> bytes -> int -> int -> msg_flag list -> sockaddr -> int
Видишь эти два int -> int? Расскажи-ка мне, что это и зачем.
> что это
Это говно, не делай так.
Haskell дал им type и newtype, но нет, не хочу давать нормальные имена типам, хочу жрать только базовые... и далее по пасте.
Я понимаю, что в мейнстриме все хуево даже с базовыми вещами вроде именования типов (хотя тайпдеф даже в сишечке есть), ну в хачкеле-то зачем продолжать жрать это говно? Там свое есть.
>У объектов же есть есть ещё подводная часть айсберга - его внутреннее состояние и связи с другими объектами, у которых оно тоже есть, а это уже очень трудно поддается документированию
This.
> Objects can model hidden state, not just abstract state. In this way, not all of an object may be observable based on the I/O relation provided by the object's sequential interfaces. It's not that an abstraction hides whether something uses state. It is that the abstraction allows hidden state. See Brock-Ackerman Anomaly for a good discussion of this, since it is important to take into account when objects with hidden state interact. In OO programming, especially with inheritance, this is extremely common and non-robust communication protocols have fancy nicknames like "Fragile Base Class"
Они от этого пропадут или что? Или можно подписать "абстрактно-могадическая рекурсивная фабрика интов" чтобы было всё просто и понятно?
Во-первых, они от этого станут понятными.
Во-вторых, они начнут выполнять свою основную задачу - специализацию (после валидации) данных, попавших из одной части программы в другую, чтобы не проверять их корректность в каждой функции на входе.
Не надо, проще говоря, использовать String для фамилии пользователя, и не потому что стрингов в хаскеле больше чем расширений GHC, и все они еще хуже совместимы между собой. А потому что проверив эту фамилию на то что она фамилия (буквы там русские-английские, пробелов нет с цифрами), надо пометить ее тем что она уже проверена и это действительно фамилия - проще всего сделать это одноврменно в конструкторе типа LastName. И в сигнатуре функции будет не String, из которого ничего непонятно, а LastName, из которого все понятно.
В перле для этого был taint mode, который решал эту задачу не через жопу а просто и удобно - но во многом потому перл больше и не с нами, слишком уж все было в нем просто и удобно.
Во-первых, читаемо.
Во-вторых, когда плохой код можно легко визуально отличить от хорошего - это довольно удобно. На Python или Java, например, это сделать на порядок сложнее.
Плохой код и хороший код можно написать на любом языке, странно что ты этого не знаешь.
Самому сделать не?
> Я вот с ходу могу сказать, что гуйню лучше моделировать стрелками, чем объектами
Кукарекнул петух.
> а про гуй пусть лучше спецы по гуи напишут, от них то мы и узнаем
Так и автор копипасты петух, а не спец по гую. А вот спецы из Эппла выбрали именно ООП для моделирования сложного GUI на Mac OS X.
>спецы из Эппла выбрали именно ООП
Это спецы из NeXT выбрали. "Спецы" из Apple тогда пешком под стол ходили.
Выбрали неудачно, поэтому NeXT загнулся.
Но ничего другого с собой принести Жобсу не было когда опять в огрызку позвали.
Можно было с нуля разработать. В любом случае, самый крутой GUI всегда (с первого Мака) делали в Apple, а поделки борщехлебов на стрелках и монадах недалеко ушли от Tk. Полупрозрачность? Резиновая верстка? Создание своих компонент? Аппаратное ускорение и 3D эффекты? Нет, не слышали.
Самый крутой GUI сейчас вообще на вебе делают.
Самый крутой гуй никакого отношения к ООП не имеет и называется FRP.
Тащем - то те полтора пользователя этого гуя блевали в сторонку от этого поделия.
Проблемы которые решает FRP ортогональны проблематике хорошего UI. Поэтому сравнение со сложившимися практиками интересно только разработчикам. Вопросы надежности и корректности, как и удобство разработки, пользователям по барабану.
Уёбище, научись пробелы ставить между дефисом, пол часа пытался прочитать первое предложение.
Тащем-то, ты — хуесос.
ООП в GUI все только усложняет.
Я тут вообще мимо проходил, просто ты тупое уёбище портящее ощущение от чтения сосачика.
Не смотрел, но полагаю 0. Учить мартыханов программировать на Хаскелле смысла не имеет, а нормальный Хаскеллист может поехать в Лондон или в Сингапур, зачем ему обязательно стоять в московских пробках по пути в бирюлёво?
>на каждый чих заводишь отдельный стрим?
Почему бы и нет? Хотя можно гораздо проще - без FRP и классического списка событий. Тупо глобальный gui.update(), который иерархически прогоняет список накопившихся событий по компонентам. То есть Form1 при вызове update прогоняет его вместе с рисовательным ресурсом через все дочерние виджеты. Нет FRP-наркомании, нет onClick ебанатства. Для простой логики можно все разруливать на уровне формы, в одной жирной функции. Для сложных виджетов делать подписку на onEvent. Что-то вроде immediate gui, но без обязательного перестроения на каждый апдейт.
Ну и правильно. Идея строгого разделения рисования-логики кнопочек-логики приложения - отрыжка 90-х. Гораздо удобнее все чохом лепить, с абстракциями где необходимо.
Где же ты был тогда, герой архитектуры? Столько бы сотен тысяч человеко-часов спас, научил бы индустрию
> чохом лепить, с абстракциями где необходимо.
А ну да, в 90х же твоя мамка только в первый класс пошла
ООП это просто красивый способ зашить стейт-монаду в синтаксис так, чтобы этим было удобно пользоваться.
Нет никаких монад. Проснись, ты говоришь на петушином новоязе.
Каждый объект O соответствует стейт монаде со стейтом состоящим из записи R со всеми полями объекта O.
Нестатические методы - это функции типов
method : ..args.. -> State R result
чтобы как-то организовать мышление в случаях,
когда программы большие, и не запутаться
Дело в том, что у человека ограниченная возможность
"обозреть" множество деталей, а потому любые
методы, расширяющие видимое, охватываемое поле
понимания, приводят к "лучшему программированию"
Но беда в том, что ООП превратилось в монстра,
который не помогает как птице, 'увидеть задачу
с высоты', но ОБСЛУЖИВАЕТ САМ СЕБЯ - б'ольшая
часть умственных усилий тратится на то, чтобы
создавать и помнить детали самих ООП patterns
В этом смысле, это как бюрократия: министерство
с/хозяйства на 70% занято поддержанием внутренних
процессов, которые создает само, и лишь на остаток
как-то соотносится с действительностью.
Доказательством тому служат на порядок более
пухлые и раза в 1.5-2 более долгие при выполнении
программы ООП, по сравнению с программами на
процедурных языках (и тем более на функциональных)
Да откуда ж вы лезете-то в таком количестве.
>>772766
>философия ООП, которая превратила все картины, загораживающие дырки на обоях, в "краеугольные камни" концепции и "имманентные особенности человеческого мЫшленья"
Это поэма?
> философия ООП, которая превратила все картины, загораживающие дырки на обоях, в "краеугольные камни" концепции и "имманентные особенности человеческого мЫшленья"
Да похуй в каком виде это реализовать: через параметризованные модули, через какие-нибудь "контексты", через классы/объекты, через стейт монады. Главное, что это должно быть реализовано в языке, причём так, чтобы этим можно было удобно пользоваться на каждом шагу, потому что оно нужно на каждом шагу.
Жиза на оп-пике
Это ясно уже по первым строкам написанного и по манере общения. Анончик спрашивает, что сказать то хотел?
>Объект - плохая абстракция, потому как не является композабельной
Монады тоже не композабельны в общем случае, напомню.
Лень читать тред. Напомни, анон, есть ли у борщехлебов что-нибудь подобное божественному Qt?
С монадами, стрелками и эффектами есть куда разиваться.
http://okmij.org/ftp/Haskell/extensible/index.html
С объектами - тупик.
Только это не нужно как и он сам.
Тебе хватило одной минуты и сорока семи секунд чтобы ознакомиться с совершенно новой для тебя, и сложной технологией, и успеть задать хорошо обдуманный, конструктивный вопрос.
Да ты блджад Феномен.
Не нужно учить весь лисп, чтобы понять, что это говно без задач.
Любая достаточно сложная программа на Си или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp.
Филип Гринспен
…в том числе и сам Common Lisp.
Роберт Моррис
> 2016
> потешный ком костылей на гигабайт для формочек
Напомни, анон, есть ли у байтослесарей что-нибудь подобное божественному Apache Spark?
> Hadoop
> речь про Spark
> only about 1.75GB
> сравнивает с локалхостом
> нинужна!
Лол блять, до чего же тупое животное.
Структура кода и её свойства оверрейтед. Важно что код делает, с точностью до изоморфизма.
А сделать красивое и удобное апи поверх содержательного кода можно бесконечным количеством способов,
и на мейнстримном ООП в том числе.
Лично я мечтаю о юзабельном языке, на котором нельзя написать две разные программы, делающие одно и то же.
> языке, на котором нельзя написать две разные программы, делающие одно и то же.
Урезанный ассемблер, без альтернативных инструкций и джампов.
> Comparing, say, Kx systems Q/KDB (80s technology which still sells for upwards of $100k a CPU, and is worth every penny) to Hive or Redis is an exercise in high comedy. Q does what Hive does. It does what Redis does. It does both, several other impressive things modern “big data” types haven’t thought of yet, and it does them better, using only a few pages of tight C code, and a few more pages of tight K code.
> https://scottlocklin.wordpress.com/2013/07/28/ruins-of-forgotten-empires-apl-languages/
>Лично я мечтаю о юзабельном языке, на котором нельзя написать две разные программы, делающие одно и то же.
Такой язык не будет Тьюринг-полным.
Если бы было иначе, то ты такой
[CODE]println ('aaaaaa'..'zzzzzz').find {
def md5 = java.security.MessageDigest.getInstance('MD5')
md5.update('qwerty'.bytes)
return md5.digest() == 'd8578edf8458ce6fbc5bb76a58c5ca4'.bytes
}[/CODE]
а компилятор тебе в ответ:
неправильно, надо писать
[CODE]println 'qwerty'[/CODE]
Был тут когда-то курс по окамлу. Для него пацаны написали автоматический проверяльщик заданий, который генерировал правильные значения на лету и сравнивал их с теми, которые выдаёт твой код. Сравнивал, конечно, через "=" (а как ещё-то?). И были в том курсе задачки с флоатами. И всё, вроде бы, нормально, потому что полученные одним и тем же путём флоаты, на одном и том же компьютере всегда будут иметь одно и то же значение. Вот только есть одна маленькая проблемка - если ты, например, сохранил число в переменную, а не подставил само выражение, то это уже другой путь. В общем, первую задачу я решил за ~15 минут, после чего ещё часа полтора пытался угадать, как они написали эталонную программу. Остальные задачи я не решил (точнее, решил, но в зачёте было 0, по понятным причинам). А теперь представь, что тебе это надо делать для каждой программы, иначе она не будет конпеляться. Ты же первый назовёшь этот язык говном и больше никогда к нему не притронешься.
>нельзя написать две разные программы, делающие одно и то же
Ничего хорошего из этой затеи не выйдет. Насколько я понял, лямбда-исчисление с одним типом подходит, но если ты добавляешь натуральные числа, то ничего не выйдет в общем случае, а в частном случае тебе придется подробно указать максимум информации о функции в ее типе, чтобы что-то можно было доказывать.
Лучше уж просто хранить в распределенной базе данных хеш от AST функции и ее значений, как пацаны что Unison делают собираются.
Такое же бесполезное говно как и ООП, кстати, и тот же хайп вокруг него. История идёт по кругу.
Это копия, сохраненная 26 июля 2016 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.