Этого треда уже нет.
Это копия, сохраненная 26 июля 2016 года.

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

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
151 Кб, 1948x858
Убедите меня, что ООП не полное говно без задач. #770268 В конец треда | Веб
Убедите меня, что ООП не полное говно без задач. С примерами, никаких "кококо куд кудах а вот у меня в голове сферическая задача в вакууме которая без ООП не решается"
#2 #770270
Что такое ооп в твоем понимании?
#3 #770274
>>770268 (OP)
Да, если в языке есть нормальная система типов, то ООП ни к чему.
sage #4 #770287
>>770268 (OP)
Альтернатива?
#5 #770288

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


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

>>ООП


>>умерло


Не умерло, а переродилось в современных мультипарадигменных языках.
>>770302
#8 #770298
>>770292
Вините программистов.
35 Кб, 595x479
#9 #770300
На ООП хорошо ложатся некоторые задачи, например всякие там ГУЙовины и все такое.

А вообще ООП говно, потому что только его не хватает, приходится обмазываться компонентным подходом и всем таким.
>>772633
#10 #770302
>>770295
Переродилось до такой степени, что типажи в расте по сути своей ничем не отличаются от классов типов в хаскеле? В новые языки наследование или совсем не завозят, или настоятельно рекомендуют его не использовать.
>>770305
#11 #770305
>>770302
А чем типажи в пидоРасте отличаются от множественного наследования в крестах ?
>>770328
sage #12 #770314
>>770268 (OP)
Альтернатива
#13 #770328
>>770305
Хотя бы тем, что не имеют экземпляров и вообще не являются типами, поддерживают как параметрический полиморфизм, так и ad-hoc, не страдают алмазными проблемами, ну и так далее. Ты можешь, конечно привести какое-нибудь обмазанное шаблонами виртуальное наследование виртуальных классов, но это же не ООП, это С++.
#14 #770335
>>770268 (OP)
Основная беда в наследовании, которое действительно только вредит, и в излишней инкапсуляции, которая полезна, но с ООП слишком чрезмерно используется.
>>770394
#15 #770336
>>770375
sage #16 #770343
>>770268 (OP)
Альтернатива?
#18 #770379
Доставьте боевых картинок, где унижают Джаву и ООП в пользу Си.
>>770395
#19 #770394
>>770335
Не в наследовании а в множественном наследовании.
>>770468>>773901
74 Кб, 512x504
#20 #770395
#21 #770409
>>770268 (OP)
GoF почитаешь, тогда поговорим.
>>771064>>771304
#22 #770420
>>770292
Таки да. Линух потому и жив, что его писали на Си. Писали бы на плюсах - утонул бы в говне и ушел бы в забвение десяток лет назад.
>>770477>>773897
#23 #770468
>>770394

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


В любом наследовании. Беда наследования в том, что оно пытается сущности представить в виде иерархии, что возможно только в очень редких случаях. Это понятно каждому, кто пытался отсортировать файлы на диске. Множественно наследование как раз костыль, с помощью которого от древовидной структуры пытались уйти.
>>770626>>770795
#24 #770472
Как начать жить без наследования?
>>770480>>770481
#25 #770477
>>770420
А kobjects (kernel objects) там сдуру существуют? Си-не Си, а где ООП было нужно, там оно естественно появилось.
>>770479
#26 #770479
>>770477
Интерфейсы в виде структур с указателями на функции это еще не ООП.
>>770484
#27 #770480
>>770472
Достаточно стоить код так, чтобы его части легко друг с другом соединялись. Благо, современные языки предоставляют множество возможностей для этого.
>>770483
#28 #770481
>>770472
Ампутируй органы наследования.
#29 #770483
>>770480

>чтобы его части легко друг с другом соединялись


Проблема в том, что они легко соединяются только в момент написания. А через полгода, например, уже далеко не легко.
>>770494
#30 #770484
>>770479
И что же это тогда?
>>770491
#31 #770491
>>770484
Просто полиморфизм. Без ООП.
#32 #770494
>>770483
Ну, допилить до состыковки проще, чем перепиливать иерархию наследования. Особенно, если предусмотрена какая-либо гибкость.
Впрочем, твой вопрос формулируется проще: «как строить архитектуру приложения так, чтобы через полгода не пришлось всё выкинуть и начать заново?».
#33 #770496
>>770268 (OP)
Всевозможные симуляторы, включая компьютерные игры, неплохо реализуются с использованием ООП. Тот же NS-3 без ООП сложно представить. NS-2 был говнищем ебаным.
>>770663>>770675
#34 #770558
ООП - полное говно, что тут обсуждать?
Чаще всего используется для костыльной эмуляции простейшего полиморфизма, потому что в типичном ОО-языке никаких других средств для этого не предусмотрено.
С модульностью то же самое.
>>770565
#35 #770565
>>770558
На чем сам пишешь?
>>770573>>770574
#36 #770573
>>770565
На лиспе
>>770575
#37 #770574
>>770565
На том что лучшим образом подходит для задачи, с учетом целевых приоритетов и ограничений.
#38 #770575
>>770573
Иногда на Лиспе.
На нем очень удобно быстро закостылить прототип какой-то подсистемы, которую непонятно как лучше всего делать. Потом иногда можно переписать на чем-то другом, в зависимости от задачи, иногда можно и так оставить.
#39 #770585
>>770268 (OP)
Очередной борщехлеб, изучивший на мамкиной шее математику, возмущается тому, что программируют не такие элитные люди как он, и им почему то хватает полутора абстракций, которые у борщехлеба, в отличие от нормальных людей, почему-то не укладываются в голове и на работу его соответственно не берут. Все что борщехлеб не в состоянии освоить объявляется им ООП, а те кто не берут его на работу - тупыми взрослыми
>>770588
#40 #770588
>>770585

>03:56


Борзехлеб борзехлеба видит издалека
#41 #770620
>>770613
https://wiki.theory.org/YourLanguageSucks#Ruby_sucks_because

Хочешь увидеть нормальную реализацию ООП в динамических языках - смотри на CLOS.
>>770635
67 Кб, 603x407
#42 #770626
>>770468
А кто сказал, что должна быть древовидная иерархия?

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

>считает ассемблер единственной альтернативой ООП-раши


>костылюция, костылеморфизм, костыляция, костылирование


Лол студентота(или ты уже джун?), ты такая няшная)))
>>770649>>770652
#45 #770635
>>770620

>CLOS


Его кто-то использует? Хотя это же скобкомирок, всегда умиляли скобкоёбы которые пишут все тот же грязный, сайдэффектный имеративный код, но только со смайликами, и считает себя илитой.
#46 #770637
>>770631
Один из столпов ООП ты забыл, еще один (наследование) - это только инструмент для реализации в ООП другого - полиморфизма.

>Берёшь и пилишь свой язык


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

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

> костыли


Велосипеды.
#48 #770652
>>770633
И да, я не няшный. Я жирный быдло-кодер. т-т
#49 #770660
>>770626
No true Scottsman fallacy.
#50 #770663
>>770496

>неплохо реализуются с использованием ООП


ААА практически на чистой сишке пишутся, без использования крестовых фич.
>>770667>>770673
#51 #770667
>>770663
Возможно прозвучит глупо, но где про это можно почитать конкретнее? Мимокрокодил.
#52 #770673
>>770663
Ебать манямирок.
Даже Кармак, адепт си, со временем дошёл до плюсов, и он же высказывался что писать даже рендер (самая нагруженная часть) без перегрузки операторов и прочего – боль.

>>770667
В исходниках UE4 или Cryengine например ссут на ебло господину выше.
>>770727>>770765
#53 #770674
>>770268 (OP)
Зачем тебя убеждать в ложном утверждении?

Eiffel - самая каноничъная реализация ООП на сегодняшний день. И смотри, что из этого вышло: http://lavironsoftware.blogspot.ru/2012/04/eiffel-studio-review.html .
#54 #770675
>>770496
В играх вроде в основном компонентный подход, а не "чистое" ооп.
22 Кб, 260x331
#55 #770680
#56 #770727
>>770673

>Ебать манямирок


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

>даже рендер (самая нагруженная часть) без перегрузки операторов и прочего – боль


Весь рендер на видюхе сейчас. На ЦПУ только шедулер, который в комманд буфер шейдеры складывает, а в шейдерах никаких перегрузок операторов делать не надо, там для векторов все встроено.
>>770765>>770789
7 Кб, 980x515
6 Кб, 979x513
#58 #770765
>>770673

>даже рендер (самая нагруженная часть) без перегрузки операторов и прочего – боль


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

>>770727

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


Хм, подожди-ка.

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

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

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

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

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

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



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

Unconditional branch, fixed target

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

Unconditional branch, variable target

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

Conditional branch, fixed target

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

Conditional branch, variable target

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

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



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

Unconditional branch, fixed target

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

Unconditional branch, variable target

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

Conditional branch, fixed target

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

Conditional branch, variable target

Less likely to show up under normal conditions, but the compiler may synthesize one as an optimization, combining two of the above cases. For example, on x86, the compiler may optimize code like if (condition) { obj->VirtualFunctionCall(); } into a conditional indirect jump like jne *%eax if it appears at the end of a function due to tail call optimization.
>>770785
#61 #770782
>>770268 (OP)
Игровой 3D движок. Хуй ты его без ООП напишешь.
>>770787
#62 #770784
>>770765

>И опять же, как это реализовывать без абстраций?


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

>Unconditional branch, variable target


>Conditional branch, fixed target


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

В итоге в первом случае оверхед - просто дополнительный переход по адресу. При хорошем кэше это вообще ни на что не влияет. Во втором случае - вероятность ошибки предсказателя. А это остановка конвейера и всё, пиздец. Тактов 7-8 очень легко потерять. Если это будет вызываться в цикле, то оверхед будет очень заметен.
>>770788>>771698
#64 #770787
>>770782
Не знать о существовании иных техник для управления сложностью кроме кривых костылей ООП в 2016 году.
>>770796
#65 #770788
>>770785
Ты знаешь о существовании branch prediction, но не знаешь о branch target prediction, почему так? Дочитываешь до середины, потом засыпаешь?
>>770805
#66 #770789
>>770727

>плюсов исползуют очень мало фич


А ты что ожидаешь? Что проект на плюсах обязательно вымазан наследованием в 800 предков, с шаблонной магией и виртуальной хуитой?
#67 #770795
>>770468
Можно вообще обойтись без наследования (в Visual Basic 6 его не было, например). Любое наследование легко заменяется композицией объектов. Основа ООП (по Алану Кэю) - объекты и сообщения, которые они отправляют друг другу и обрабатывают. А "три принципа" придумал Страуструп, и они довольно сомнительны (инкапсуляция есть в любом языке с заданием области видимости вплоть до ассемблера, а для полиморфизма достаточно разрешить overload для функций).
>>773900
#68 #770796
>>770787
Ну и где процедурные/функциональные движки с йоба графоном? Вот Кармак скажем долго выебывался, а однако Doom 3 пришлось ему писать на крестах.
#69 #770805
>>770788
Просто обо всём этом я где-то полтора года назад узнал из книжки Game Engine Architecture, где всякие промахи кэша и предсказатели переходов были рассмотрены довольно поверхностно.
#70 #770808
>>770796
Криворукие игроделы ничего кроме сишечки не знают, щито поделать
#71 #770814
>>770796

>Ну и где процедурные/функциональные движки с йоба графоном?


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

>функциональные


Уважающий себя борщехлеб не будет марать руки об игори, очевидно же. Игори для детей.
>>771026
#73 #770840
>>770814
Кармак пиздит дохуя, еблоторговец раскрученный, сам ничего оосбенного за всю карьеру не написав.

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

>и immutable быстрым не будет никогда


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

> пересоздавать на каждом кадре стейт игры заново


Дельты же хранить можно. При сете создается дельта которая держит ссылку на предыдущую версию.
>>770850
#76 #770850
>>770844
Нафига? Весь стейт - несколько мегабайт, максимум. Хранишь два-три кадра, при создании нового кадра копируешь предыдущий с обновлением.
#77 #770851
>>770840
>>770814
Блядь! Я только что осознал! Рендеринг - это НА 100% функциональный стиль. Пиздеееец, я столько времени его использовал и даже не думал об этом.

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

Охуеть. В рендеринге СТОЛЬКО функциональщины. Я даже не знаю теперь, как к этому относиться.
#78 #770859
>>770851
Хорошо относиться. Перестать дрочить на ООП и почитать http://okmij.org/ftp/cpp-digest/
#79 #770860
>>770851
Охуеть открытие. Рендеринг функциональный, потому что GPU суперпараллельный, это любому должно быть очевидно.
#80 #771023
>>770814

> Почти везде в ААА.


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

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

> Игори для детей.


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

>Грамотно построить архитектуру, и чтобы еще быстро работало, можно только на ООП


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

> криворукие игроделы


Ну пусть борщехлеб продемонстрирует, как правильно писать.
#86 #771036
>>771032

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


Я и говорю.
>>771049
#87 #771049
>>771036
Так криворукие игроделы хоть делают и выпускают рабочий продукт, в отличие от мамкиных борщехлёбов, визжащих о превосходстве фп.
>>771061>>773159
#88 #771051
>>771023

>шутера на хаскеле


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

>на сишечке в функциональном стиле


Как на сисечке можно сделать функции высшего порядка? Путем черной магии в виде исполнения ссылки на фунцкию?
>>771055>>771057
#90 #771054
>>771032
UT, CryEngine - middleware, движок с редакторами. Остальное, считай, легаси из 90-х, написанное писишными программистами, которые консоль и голое железо в глаза не видели. К тому же там не сказано, в каком стиле у них С++.
#91 #771055
>>771052
Под "функциональным стилем" имелись ввиду чистые функции и в основном иммьютабл стейт, отстутствие ООП.
>>771056
#92 #771056
>>771055
Больше на процедурность с иммутабильностью смахивает. Какое же это ФП без функций высшего порядка.
>>771059
#94 #771059
>>771056
Больше всего похоже на SQL и работу с БД по стилю.
>>771062
#95 #771061
>>771049
Делает и выпускает много чего много кто.
В игродельной индустрии - там же замкнутый порочный круг. Берут только бородатых сишечников, потому что ну епта у нас же все на сишечке, они в свою очередь нихера кроме сишечки и ООП не знают и знать не хотят.
В других индустриях ФП успешно используется, в том числе и там где высоки требования к производительности, в том числе и с использованием языков Си и С++.
>>771063
#96 #771062
>>771059
SQL это декларативное функциональное программирование, чего тут удивительного.
>>771074
#97 #771063
>>771061

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


Например?
>>771068>>771087
#98 #771064
>>770409
Design Patterns in Dynamic Languages Норвига почитаешь, тогда и поговорим.
>>771305
206 Кб, 1000x1200
#99 #771066
>>770268 (OP)

>Subhuman

#101 #771074
>>771062
Ну я и говорю, что не все ФП выглядит как хаскел. Функциональные практики in the wild ближе к SQL чем к ML.
#102 #771076
>>771068
На самом деле нет. У тебя по ссылке откровенное наглое вранье. Вот разоблачение:
http://flyingfrogblog.blogspot.ru/2010/05/why-is-haskell-used-so-little-in.html
>>771100>>773444
#103 #771078
>>771068
Куча нонеймов и фейсбук, интел и с ан анд т и пр. где на всю корпорацию 1 внутренняя утилита на хаскелле, ахуеть теперь.

Конкретные примеры давай. Риалтайм рендер уровня source 2 хотя бы.
>>771100
#104 #771087
>>771063
Бигдата, например, всякие Кложи-Скалы.
>>771099
#105 #771099
>>771087
И там тоже пишут основную часть на питоне/р, а все числодробилки на сях, хотя перформанс в этой области никому не всрался.
>>771106
#106 #771100
>>771078
Ну охуеть можно. ABN Amro ему нонейм. Alcatel-Lucent ему нонейм. Bank of America Merril Lynch ему нонейм.
Это я еще до буквы B не дошел.

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

>>771076
Я сразу говорил что речь не про Haskell, а про ФП. В перечисленных лавках, и во многих других, часто пишут на разных языках, в том числе и на Си и на С++. Но вот набирают туда людей прицельно со знанием Хаскеля. Потому что они умеют в ФП, что и нужно. А в ООП и так любая макака умеет, хрена ли там уметь. И человек умеющий в ФП, напишет и на С++ приличный ФП код, когда надо на С++.
А вот наборот получается хуево. Поэтому и слышно со стороны криворуких игроделов только нинууужна
>>771115>>771156
#107 #771106
>>771099
На питоне/р прототипируют алгоритмы, а в продакшене вся инфрастрктура на JVM.
>>771114>>771117
#108 #771114
>>771106
Продакшны разные бывают.
Cloudflare, например, на Lua.
#109 #771115
>>771100
Человек умеющий в фп скорее нагреет процессор.

А бородатые сишники тем не менее написали явно поболее пары внутренних утилит. не знаю на счёт самого компилятора, на рантайм у хачкеля, ВНЕЗАПНО БЛЯДЬ, сишный
>>771123
#110 #771117
>>771106
Ты похоже не в курсе что за означает "бигдата". Это не хуйлоад, сам ознакомься с значением термина.
#111 #771123
>>771115
Ну так а чего на рантайме останавливаться, давай до внутренностей процессоров и порчих железок дойдем, в которые криворукие игроделы с охуенно важным видом кидают треугольнички. А там ВНЕЗАПНО, из того самого списка

> Bluespec, Inc. Waltham, Massachusetts



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



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

>using Haskell for our tool implementation


Ты понимаешь что сейчас сам себе в рот поссал?
>>771162
#113 #771156
>>771100

>Но вот набирают туда людей прицельно со знанием Хаскеля


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

>человек умеющий в ФП, напишет и на С++ приличный ФП код


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

>А вот наборот получается хуево


Потому что никому не нужно
>>771162
#114 #771158
>>771123

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

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

>>771156

>Нинуужна


Кто бы мог чего другого от криворуких игроделов ожидать.
>>771174>>771178
#116 #771174
>>771162

>Или ты думаешь что скорость там никого не ебет?


Не, не ебёт. Ни скорость, ни нагрузка.
#117 #771178
>>771162

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


Криворукие игроделы выпускают продукт, который продается, пряморукие борщехлебы выпускают воздух с запахом нечищеных зубов.
>>773199
#118 #771304
>>770409

>Dynamic Languages


Зачем ты этот хлам сюда принес. Убирайся вместе с ним.
>>771305
#119 #771305
#120 #771312
Грят, хаскель - последний писк моды? Я поверхностно пощупал пхп, жиес, жаву, но не смог в них закатиться. И вот думаю, попробовать изучить хаскель.
как там в хаскеле? дефицит кадров?
#121 #771314
>>771312
Haskell неудачный вариант для обучения. Язык сложный, возможностей мало. Сейчас каждая макака учит Haskell, а потом не знает что делать с ним. Лучше попробуй Haskell. Язык легкий и понятный даже школьнику. Если никогда не занимался программированием, то начинать лучше всего с Haskell - после него другие языки учатся быстрее.
По книгам, что бы подготовится. Если есть хоть немного знаний программирования, читай это: http://www.ozon.ru/context/detail/id/30425643/ Если совсем новичок, пойдет эта книга: http://www.ozon.ru/context/detail/id/28346038/ Ну и куча онлайн-учебников. Вот, например: https://anton-k.github.io/ru-haskell-book/book/home.html Хороший учебник, всё расписано подробно. Сам по нему учился. Рекомендую.
>>772005
#122 #771332
>>771312
А еще в жопу все ябутся.
#123 #771592
>>771312
https://www.ohaskell.guide/
А вообще в хаскеле конечно не хватает очередного неразобравшегося в ООП, вот прям ждут тебя, на стену лезут.
>>771606>>771609
#124 #771606
>>771592
Не посоветуешь чего почитать, чтобы в ООП разобраться полностью? Просто в большинстве книг по языкам он идёт как что-то побочное и даётся отрывками. Желательно с примерами на питоне.
>>771622
#125 #771609
>>771592
Почему не разобравшегося? Я в нем отлично разобрался, просто работы на ООП языках нет ибо сейчас каждый школьник учит какой-нибудь питон. пхп, жиес, кресты или жаву и далее по пасте.
#126 #771622
>>771606

> в ООП разобраться полностью


> Желательно с примерами на питоне.


В голосину.

Choose your destiny:
C++ | C# | Java
>>771626
#127 #771626
>>771622
То есть на питоне ООП нинужен?

> Choose your destiny:


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

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

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

>модули


В OCaml есть, в Haskell - хуй.

>record field disambiguation


Сделали только неделю назад

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

>ООП как раз в этом плане и хорошо тем, что гетерогенный список (который нужен в разы чаще, чем множественная диспетчеризация) пишется просто и приятно


Ну конечно, особенно если завести искуственного общего предка "некий Объект" - заипись, компилятор не ругается, все прекрасно. Что толку от такой "типизации" никакой - да и хрен с ним.

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

>HList lets the user formulate statically checkable constraints


А ты как хотел?
#132 #771682
>>771671

>В хаскелле98


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

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


Но хочу я не этого.
Я хочу сделать список, и явно указать что в нем могут содержаться только сущности типов, которые можно рисовать И сериализовывать. Просто перечислить эти необходимые свойства, а никаких еботических их гибридов не делать, потому что это костыль. И чтобы компилятор ругался когда какой-то джуниор в этот список пытался положить что-то, что либо не seriаlizable, либо не drawable.
>>771685
#134 #771685
>>771684

>и явно указать


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

>call dword ptr[0xbabe]


А что лежит в переменной по этому адресу - хуй его знает.

>Тактов 7-8 очень легко потерять


Dude, было бы это 7-8 тактов - всем было бы на это наплевать. Простой кэш-мисс - это 200+ тактов, остановка конвеера - и того больше.
Вот и приходится людям извращаться, придумывая своё ооп поверх крестов (Анальный Акробат Андрюша делал презентацию по этому поводу на цппкон14, по-моему, можешь в ютубе поискать - что-то там про кресты и производительность).
Алсо, даже ассемблерщики более пятнадцати лет назад дошли до нормального ооп, а крестобляди всё разлагаются www.wasm.ru/article/71
>>770840

>Кармак


>ничего оосбенного за всю карьеру не написав


Смешная шутка. Он написал дум, который работал на компьютерах, которые на тот момент не могли выдавать подобную графику в реалтайме. Он написал первую полностью трёхмерную игру, движок которой так или иначе является предком половины современных движков. Он первый начал опенсорсить свои движки. Он с дремучих времён участвовал в развитии опенгля (вместе со всякими нвидиями). По большому счёту, именно благодаря ему ты имеешь 3д ускоритель в пекарне. Алсо, первой игрой, использующей шейдеры, была quake 3, если я не ошибаюсь.
>>770843
Это только кажется с теоретической точки зрения. На самом деле, ты не один раз пересоздаёшь весь стейт, а по чуть-чуть его меняешь, поэтому у тебя будет огромная куча {xyu with dlina = new_dlina xyu.dlina} на кадр.
#137 #771703
>>771698

>По большому счёту, именно благодаря ему


Да, дедушка умный, куда б мы без него.

> свет лучше чем в 2007-ом году можно сделать и делают, только не Кармак. Кармак, напоминаю, в 2011ом году выпустил игру на лайтмапах (то есть с той же технологией освещения, которую он использовал в Quake 1). Он очень умный, наверное, но не любит спешить со своими революционными алгоритмами


>http://live13.livejournal.com/423196.html?thread=1148700#t1148700

#138 #771704
>>771698

>Очередной гениальный замысел Кармака


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


>большая проблема начиная с PS3 - программисты не знают и знать не хотят как работает железо не смотря на 100500 презентаций, которые для них делают. Упираются рогом и ваяют хренотень как им хочется, а хочется странного очень часто. Например, хочется continuous submit на PS4. Плевать, что тормозит не по-децки, так у них же еще там баг на баге сидит и багом погоняет. Что, конечно, неудивительно, потому что человек, который знает достаточно, чтобы его написать правильно, это делать не будет потому что этих знаний более чем достаточно, чтобы понять почему это не нужно делать


>http://kunaifusu.livejournal.com/566139.html

>>771708
#139 #771708
>>771704
Кармак, который (хуй с ним) десять лет двигал прогресс в области компьютерной интерактивной реалтайм графики, или какой-то нонейм хуй? Какой тяжёлый вопрос.

>communities


>fprog


А, теперь всё встало на свои места.

>вот, Моська, знать, она сильна, коль лает на слона


Ок, пошли по пунктам.

>Кармак, напоминаю, в 2011ом году выпустил игру на лайтмапах (то есть с той же технологией освещения, которую он использовал в Quake 1).


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

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


Дизайнеры уровней и хуйдожники, я слышал, от неё радугой кончают. Но ещё можно вспомнить, что Кармак обосрался во второй кваке с трёхмерными взрывами. Почему? А это проблема всех первопроходцев. Сначала ты делаешь криво, потому что опыта нет, потом уже люди (ты сам), которым не нужно искать новую дорогу, кладут асфальт.
>>771715
#140 #771715
>>771708

>это проблема всех первопроходцев


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

>Современное ООП, с довольно плоской иерархиев


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

>Сделай 2 копии кода, и тебя все заинлайнится и будет чики-пуки


Потом оно перестанет помещаться в instruction cache и будут только пуки, а все чики уйдут к конкурентам
#143 #771723
>>771711

>двойного перехода указатель на объект->адрес VMT->смещение по VMT страшнее. Это, кстати, основная причина принципиальных тормозов языков типа Java.


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

> data Yoba = Circ r1 | Rect x1 y1 | Eboat


Про тайпклассы не слышал, не?
#145 #771728

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



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



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

#146 #771734
>>771732
Понимать может только Кармак, потому что он Кармак, понятно.
#147 #771737
>>771723
Ты самый умный просто, долбоёб.
Иди почитай как перформанс жявы на каком нибудь benchmarksgame измеряется, потом пизди.
>>771745
140 Кб, 2400x2083
#148 #771738

>я 2000го года рождения и не знаю, что было до рейджа, поэтому этого не было


>сейчас Кармак обсирается (то есть, на самом деле - нет, но я считаю, что он обсирается), поэтому все его прошлые заслуги аннулируются и больше ничего не значат


>а ещё вот вам посты от хуй_вообще_знает_кого_чью_компетентность_никак_не_проверить, которые подверждают мою точку зрения (на самом деле, это не моя точка зрения, я просто прочёл эти посты и ПРОЗРЕЛ)


>я лучше знаю, а вы все тупые семёны


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

>данные акселерометра занимают так мало (килобайты полосы)


Вопрос - и нахрена ж ей джва USB 3.0 (и еще один - для контроллера, но мы не о нем)?
#151 #771787

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


> http://kunaifusu.livejournal.com/534869.html

>>771801
#152 #771792
>>771698

>Он написал первую полностью трёхмерную игру


Нет, он на BSP в 3D сдулся, и побежал за помощью к Абрашу. С окулусом, кстати, такая же фигня. Без Абраша он долго не просидел, выписал себе помогать.
>>771808
#153 #771801
>>771787
Ну Миша, кстати, тоже люит пиздеть, какие вокруг лохи, а сам в 2011 году выпускает игру с графоном уровня 2003. Да и судя по mobygames, остальной послужной список у него не оче.
>>771817
#154 #771805
>>771793
Я к тому, что "написал первую трехмерную игру" - это довольно громко сказано.
#155 #771808
>>771792

>Абрашу


К тому который книжку написал? Хорошая была книжка.
#156 #771813
>>771811

>Но личность Кармака трудно недооценить


Просто Кармака преподносят как гения программирования 3Д, хотя его достижения в этой области далеко в прошлом, учитывая темпы развития.
#157 #771814
>>771811
С того что надули из него Великого Игро Девелопера, и какую бы хуйню он не нес, только и слышно про него.
#158 #771817
>>771801
Это все любят, но его на каждой ярмарке хоть не показывают и бложек не обсуждают на каждом перекрестке
>>771820
#159 #771820
>>771817
Да и полезное что-то можно от него иногда узнать http://live13.livejournal.com/462582.html?thread=1403894#t1403894

А от Кармака только "покупай, торопись" и великие идеи о мегатекстурах будущего.
>>771841
#160 #771832
>>771831
Полезное - то что на книжку эту можно времени не тратить, не говоря уж про забивание мозгов
>>771840
#161 #771840
>>771832
"Бесполезна для ААА под консоли" не значит бесполезна вообще для геймдева.
#162 #771841
>>771820

>А от Кармака только


Наоборот, у Кармака гораздо более интересные твитор и пейсбук. Без поливания всех говном, пещерного расизма и гомофобии.
>>771850
#163 #771845
>>771836
Ну я же не говорю что читать надо некритично, без понимания того зачем чувак пишет и какие у него в LA фрустрации, особенно глядя на Кармака.
Но именно эта едкая negativity (тем более что ее можно спокойно пропускать мимо ушей) и сопутствующий ей взгляд на какие-то вещи, события и персоны, дает возможность не только посмотреть на некоторые вещи с более других сторон чем это принято и несется из всех репродукторов, но и, что часто даже продуктивней, о чем-то самостоятельно задуматься.
Тот же GoF book намного более полезен и хорош (если, где, кому и когда он вообще может быть полезен и хорош) когда ты понимаешь откуда оно взялось, зачем, причем тут Смаллток, и кем, почему, и в качестве чего это было сделано в Симуле, и почему Алан Кей похож с одной стороны на Кармака, а с другой - на автора Хагакурэ, который тоже немного опоздал родиться и немного переусердствовал в развитии концепций того, прекрасного прошлого времени, над которыми в то, прекрасное старое время все причастные максимум пожали бы плечами.
#164 #771850
>>771841
Что в этом треде делают леваки?
>>771856
#165 #771856
>>771850
У kunaifusu это просто через край переходит.
>>771866
#166 #771866
>>771856
Человек, измученный нарзаном.
Я когда с индусами работал, тоже порой головой об стол бился. Не столько от качества кода, сколько от attitude.
Это в Воронеже хорошо к ним относиться, когда их нет в радиусе 1000 км
#167 #771877
>>771868
Да, это со многими так. Читаешь какого-нибудь умного (вроде бы) парня про просторы большого театра в области lockless алгоритмов, и ВНЕЗАПНО он как начнет про социальную справедливость, раскулачивание Уолл-Стрит и угнетенных (Демократами, но это никогда в сообщение не помещается по загадочным причинам) миноритис Чикагщины - хоть отписывайся.
Тэги же придумали специально для этого, но никто не пользуется.
#168 #771881
>>771723
Давай, расскажи мне как он это оптимзирует. Что он такого делает, что двойного cache miss не происходит.
>>771896
#169 #771896
>>771881

гугли inlining of megamorphic function calls in hot inner loops
>>771904>>772285
#170 #771902
>>770268 (OP)
Я придерживаюсь СТРУКТУРИРОВАННОГО ПРОГРАММИРОВАНИЯ (СП). Мое личное изобретение.
>>771908
#171 #771904
>>771896
Никакие инлайны и девиртуализация не спасут при организации памяти в жвм с неебическими индиректами и адовым оверхедом по 500% из-за боксинга неба и аллаха.
>>771912
#172 #771908
>>771902
Поясняю. Во главе идеи - один суперобъект, назовем проектом.

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

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

Создание объектов происходит так, например кнопки:

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



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

Конечно даже в сотне постов не описать всех деталей, но если вы обладаете зачатками интеллекта, то даже эти пару абзацев способны дать почву для создания полной картины.
>>776572>>776580
#173 #771912
>>771904
Java неплохо оптимизируется в тех местах где надо и тогда когда надо
http://mechanical-sympathy.blogspot.ru/2012/10/compact-off-heap-structurestuples-in.html

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

>Java неплохо оптимизируется в тех местах


Это ебаный ад off-heap пердолинга. Проще на крестах переписать.

>которые составляют обычно 98.74% при этом не нужно


Потому что эти 98% - блоат из бесполезных ФабрикАбстрактныхФабрик, которые как-то оптимизировать можно только выкинув их совсем.
>>771937
#175 #771937
>>771924
Даже предположив что ты действительно мог бы все это переписать, есть еще и другие факторы - например, время, бюджет и уровень персонала.
Те фабрики фабрик, которые ты будешь переписывать пока Солнце не упадет на Землю, можно поручить менее квалифицированному персоналу, и это будет не только быстрее, но в том числе и значительно дешевле.
>>771939
#176 #771939
>>771937
Вот поэтому оптимизацией жабы заниматься абсолютно бессмысленно. Как и пытаться писать на ней что-то кроме жирного интерпрайза.
>>771946
#177 #771946
>>771939
Совсем наоборот, именно ее-то оптимизацией заниматься осмысленно.
Оптимизируя 1% критичного к производительности кода, ты получаешь 90% прироста общей производительности, весь остальной код пишут дешевые джава-макаки - это очень хороший результата в подавляющем количестве случаев.
За бортом остаются буквально считанные задачи - жесткий реалтайм, часть эмбедовки, консольные игродвижки.
>>771951
#178 #771951
>>771946
Проблема в том, что в джавакоде обычно нет 1% критической части. Потери размазаны по всему коду равномерно. А затраты на написание быстрого кода ОЧЕНЬ высоки, поскольку джава как язык не поощряет работу с примитивными типами и off-heap.
>>771958
169 Кб, 550x778
#179 #771957
Время бородатых игроделов-сишников с ООП уходит

> 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

>>771964>>772111
#180 #771958
>>771951

>в джавакоде обычно нет 1% критической части. Потери размазаны по всему коду равномерно


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

>much more FP friendly


Ты правда считаешь, что это означает, что все станут на хаскеле писать? GPU-программирование FP-friendly с самого начала, но все языки там - варианты си.
>>771965>>772029
#182 #771965
>>771964
Чистые ФП языки это маразм. Просто добавят в попсовые языки ФП парадигму. Java 8, например.
>>771992>>772021
#183 #771992
>>771965

>Java 8, например.


Ахуеть, там же лямбды и мап-редюч-И так далее в стандартной библиотеке! Ахуеть, фп язык!
Плюсы у тебя, наверно, на уровне с хачкеллем стоят?
>>771995
#184 #771995
>>771992
Так это только начало. Там еще стримы добавили, композишн, maybe-типы и все такое. А в 9ке обещают модули, настоящие.
Но там еще надо дохуя вычистить, исключения, для начала.
Ну ладно, жаба жабой, а вот в кресты ФП парадигму норм добавится.
>>772021
#185 #772005
>>771314
ВНЕЗАПНО
#186 #772020
>>771993
Вот у анона озарение, например >>770851
#187 #772021
>>771965
>>771995
Модули это конечно хорошо. Только и с лямбда фишечками C#, Java и подобные им "гибридные" языки останутся глубоко императивными. Все это натягивание ФП на ОПП, причем совершено не с той стороны, выглядит бредово. Принцип "снаружи ООП, а внутри методов — ФП". Какой ФП? Внутри каких методов? ФП как раз должен быть снаружи, а внутри хоть ассемблер.

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

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

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

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

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

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

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

Обычное ООП, мейнстримовое, с сабтайпингом, а не марсианское-структурное, какое возможно в хаскеле и некоторых "негибридных" мл-ях, наносит такой удар по системе типов, что о хоть сколько нибудь полноценной поддержке ФП говорить уже не приходится. "Гибриды" любят декларировать "мультипарадигменность", но ФП там, как колбаса при коммунизме: чего не спроси — отвечают, что потребности нет
#188 #772029
>>771964
А чего б на нем и не писать? Если роль того что крутится на CPU все больше сводится к control plane, простаивающей при этом 90% времени в виду явно избыточной для ее задач мощности современных процессоров. Все остальное (data plane) едет в GPU с SSD само, и считается там, и показывается прямо оттуда.
>>772034>>772042
#189 #772034
>>772029

>А чего б на нем и не писать?


С того, что все будет адово тормозить из-за боксинга и аллокаций. Или придется писать в стиле мало отличающемся от нынешнего.
#190 #772042
>>772029
Я чот представил как будут работать требовательные к процессору игрушки (стратегии, игры с физикой), или насколько придётся отупить и без того ебланский ИИ в стрелялочках

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

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

>Vulkan

>>772066
#195 #772066
>>772064
Что Vulkan?
>>772111
#196 #772074
>>772062
Алиасинг забарывается одним модификатором переменной и хотя бы каплей внимательности.
Вась, успокойся уже.
#197 #772075
>>772062

>Уровень хаскельного оптимизатора совсем другой


Наверное поэтому у наивного qsort на хаскеле реальная асимптотика больше n^2 из-за постоянных переаллокаций и копирования.
>>772132
#198 #772081
>>772062
Вот тут за чудо параллельность и производительность хаскеля поясняют:
http://flyingfrogblog.blogspot.ru/2016/05/disadvantages-of-purely-functional.html

>There is no efficient purely functional unsorted dictionary or set


>There is no purely functional weak hash table


>There are no purely functional concurrent collections


>Most graph algorithms look worse and run much slower when written in an FP style.


>All existing implementations of functional programming languages, both pure and impure, happen to allocate far too much by design


>Purely functional programming is theoretically good for parallelism but bad for performance in practice, which is the sole purpose of parallelism

>>772102>>772132
#200 #772110
#201 #772111
#202 #772127
>>772106
Не ad hominem, но важные уточнения контекста, для верной поправки на bias при чтении этой "критики"

> Thing is, Harrop runs a business using F# and is a known troll against anything competing with F#. His MO is to focus on minutiae and make them sound like bigger deals than they actually are. Then when asked about a limitation of F# typically responds "well you'll never need that in the real world anyway". (See his responses to e.g. http://stackoverflow.com/questions/21170493/when-are-higher-kinded-types-useful/21445106 trolling every single answer)



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

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

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



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

#204 #772132
>>772075
Если я правильно понял о чем ты, "наивный qsort" в хаскеле это никакой не qsort, а другой алгоритм, использующий похожую идею.
>>772081
Не буду защищать хаскель, не пишу на нем и никогда не делал бенчмарков связанных с ним, но этот челик по всей видимости путает иммутабельность и ФП.
>>772140
#205 #772140
>>772132
Он не путает, у него четкая бизнес-цель.
Хэши сильно оптимизнули, кстати, после именно этой попытки Харропа доебаться до мышей.
>>772177
#206 #772177
>>772140
Ну гратц его тогда. Но из-за него же вот такие >>772143 необразованные долбоёбы лезут.
>>772203
#207 #772203
>>772143
Мы очень внимательно слушаем, в чем же именно ты нашел хуиту в этих его словах?

>>772177
Хэши в хаскеле оптимизировали, а бизнес этого чувака по F#-внедрежу, ЧСХ, сдох.
Win-Win!
#208 #772222
>>772214
Ты сейчас его сравниваешь с сишечкой, где код хорошо описывается выражением "нам дали ведро болтов и гаек, сейчас мы легко всего в 100000 строк построим из этого синхрофазотрон ни разу не уронив себе на ногу отбойный молоток, который мы построим отдельно всего в 25000 строк" или с каким-то идеальным языком, названия которого по причине скромности не приводишь?
#209 #772241
Раз такой пири говно льётся друг на друга рекой, попрошу толковых ораторов свыше помочь Java-даунумне.

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

Поправьте, знатоки. Реквестирую от вас roadway, только не в стиле "Ищешь сегодня книжку ..."
>>772244>>772261
#211 #772246
>>772244
Нет, в целом об устройстве ПК, принципах работы ОС, и игро-индустрия.
#212 #772261
>>772241

> дискретная математика


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

> компьютерная схемотехника


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

> что-то по устройству операционных систем


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

> и низкоуровневый язык


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

Все остальное - разбираешься по надобности
>>772265>>772274
#213 #772265
>>772261
Пусть и суперкратко, но годно. Заскринил, будет хотя бы от чего оттолкнуться
#214 #772270
>>772224
Так ты не путай свои стилистические идиосинкразии уровня "мда, неэлегантно у вас здесь, сударь, выходит, неэлегантно-с" с "у хаскеля проблемы с mutable state".
101 Кб, 890x670
#215 #772274
>>772261

>дискретная математика не нужна.


А потом получаем непонимание того как происходит переполнение при арифметических операциях, откуда берутся неточности при работе с флоатами и как писать/читать/менять сложные логические условия.
#216 #772285
>>771896
Это мимо.
#217 #772290
>>772274
И нахуя мне это говно, если я веб-программист?
#218 #772291
>>772290

>веб


>программист

#219 #772292
>>772274

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


Человеку, который это не понимает, никакая дискретка не поможет.
#220 #772293
>>772274

> непонимание того как происходит переполнение при арифметических операциях


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

> откуда берутся неточности при работе с флоатами


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

> как писать/читать/менять сложные логические условия


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

В процессе решения конкретной задачи все на порядок лучше осваивается и выучивается чем этот стандартный bottom-up подход "докажем пока все теоремы из первого тома, а зачем мы это делали вы узнаете на пятом курсе"
>>772359
#221 #772297
>>772290
Даже веб-программисту надо знать законы де Моргана и понимать, почему вдруг оказалось, что 30%*70% != 21%.
#222 #772300
>>772290
Переполнения и флоаты - чтоб считать.

писать/читать/менять сложные логические условия - чтоб, например, валидатор был нормальный, а не лапша из 50 if-ов, причем на каждую формочку своя, совпадающая с остальными на 90%
>>772311>>772316
#223 #772306
>>772297
Ему бы про транзакции хотя бы самые основы понять, 21% это хоть сразу вылезет и нащальника надает
>>772328
#224 #772311
>>772300

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


Мне за это заплатят больше? Нет? Ну и иди нахуй со своим задротским говном, мне и без него неплохо живётся.
>>772549>>772763
#225 #772315
>>772297
Ну-ка расскажи, почему 30%*70% != 21%.
>>772370
#226 #772316
>>772290
Тогда нахуй ты вы этот тред вообще защёл? Ухади.

>>772300
Ебать ты хуйню написал. Челик без знания дискретной математики по твоему не способен написать что-то, отличное от 50-и ифов?
#227 #772328
>>772297
>>772306
И почему же не 21%? Объясните, а то я такой тупой, даже дискретку не знаю.
>>772370
#228 #772359
>>772293

>Столкнется с этим сам - прочитает за вечер


>возьмет книжку, почитает.


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

>большинство из этого большинства - и не столкнутся.


Потому что руководство не доверит им работу на которой с такими проблемами можно столкнуться.

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


Когда он напишет что-то вроде !(!A || !B) у него ничего нигде на защемит, и необходимости что-либо читать он не осознает.
>>772438>>772763
#229 #772370
>>772315
>>772328
Нахуя? Вы с этим не столкнётесь. А если столкнётесь, то возьмёте книжку и за вечер всё выясните.
#230 #772391
>>771671

>Это не я делаю, это тот, у которого "90% программ пишутся и без экзистенциальных типов" так делает.


Откуда этот фантазёр знает как я делаю?

>В ООП гетерогенные списки везде


В ООП нет гетерогенных списков, обмудок, единственный ОО-язык который их позволяет делать - это Скала.
>>772775
#231 #772438
>>772359
Так поясни мне, пожалуйста, как не быть тупым. Напиши роад-мэп, чтобы я знал.

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

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

>и функциональные языки без паттерн матчинга (Scheme)


На основании чего ты считаешь схему функциональным языком? Да и паттерн матчинга нет только в стандарте, в котором есть средства для его реализации (коих немеряно).
>>772485>>772491
#233 #772485
>>772468
А на основании чего ты её таковой не считаешь? В твоем представлении ФП = ML-like?
>>772489
#234 #772489
>>772485
ФП = функциональная чистота.
>>772530
#235 #772491
>>772468

>коих немеряно


Чего-чего немеряно? Реализаций сопоставления с образцом на схеме? Их, полноценных, едва ли на пальцы одной руки хватит.
>>772513
#236 #772513
>>772491
Да хуле ты к словам цепляешься, епты бля. Главное, что они есть. А вообще, почти в каждой имплементации есть своя реализация, в chicken есть, в guile есть. Ну и каждый уважающий себя скобкоеб писал свою, я, например, писал
>>772530
#237 #772530
>>772489
Схема достаточно чиста. Но а если уж совсем занудничать, то может оказаться, что в мире нет ни одного функционально чистого языка.
А вот отсутствие АТД и сопоставления с образцом в схеме делает её менее ФП в моём представлении.
>>772513
Писал-то каждый, но пригодных для применения из них - единицы.
>>772798
#238 #772549
>>772311
Тебя за это не заставят до 12 в офисе сидеть.
>>772608
#239 #772608
>>772549
Меня и так не заставят
sage #240 #772633
>>770300

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



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

>ООП сложно, оно не нужно, я не осилил



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

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

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

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



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

> программисты обожглись об ООП, но проблемы гуйни глубже формошлёпства не исследовали


Те кто исследовал ЧСХ придумали functional reactive programming а никакое не ООП.

> лейаут


Отлично ложится на комбинаторы.
https://www.youtube.com/watch?v=fRdU5yHsAA4
Заодно ответ на >>772676

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

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

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

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

> программисты обожглись об ООП, но проблемы гуйни глубже формошлёпства не исследовали


Те кто исследовал ЧСХ придумали functional reactive programming а никакое не ООП.

> лейаут


Отлично ложится на комбинаторы.
https://www.youtube.com/watch?v=fRdU5yHsAA4
Заодно ответ на >>772676

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

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

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

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

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



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

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


> http://m50d.github.io/2014/12/08/object-oriented-essentialism.html

#246 #772775
>>772391

>единственный ОО-язык который их позволяет делать - это Скала


Потому что это единственный язык с неигрушечной типизацией ООП.
Цену за это пришлось заплатить такую, что хуйзнает, надо ли все это было делать.
В общем-то нет языка, который может "запарить" мозг сильнее, чем скала. Скала имеет мозговыносящую систему типов, не имеющую аналогов в том смысле, что нет другого языка, в котором ООП было бы адекватно статически типизировано. Это крайне сложная и амбициозная задача, буквально все остальные создатели ООЯ на каком-то этапе плюнули и решили: "Статическая типизация — это сложно, лучше будем динамически кастить". Правда, весь этот околодинамический цирк с конями в скале остался "для совместимости" (и дополнительного выноса мозга)
#247 #772794
На ОО Objective-C и Swift пишутся программы для лучшей ОС, которую используют программисты в достойнейших компаниях – macOS. А если работодатель не купил вам аймак или макбук – значит, он жид ебаный.
По поводу Obj-C – ладно, плохой аргумент, просто какой язык использовался Эпплом с 1983 года, такой и остался, с небольшими изменениями.
Но Swift разработан с учётом всех best practices. И всё равно имеет ОО парадигму.
>>772799
#248 #772798
>>772530

>Схема достаточно чиста.


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

>АТД


Какое там адт, когда типов, в принципе, нет.
#249 #772799
>>772794

>Swift разработан с учётом всех best practices


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

>континуация не то, что не возвращает ничего (что уже противоречит принципам фп),


Ведь если возвращать несуществующий костыльный фейк "состояние вселенной", все магическим образом меняется.
>>772814
#251 #772804
>>772799

>Сколько лет у него не было номрального стилуса


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

>Вот и в этом уёбище все то же самое.


Да нет, это ты уебан просто, не сравнивай свифт с го.
Алсо, он у эпла как оарп у майкрософта – компания его спонсирует, но ничем анально не ограждает.
#252 #772805
>>772804

>оарп


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

>не сравнивай свифт с го


Я и не сравнивал, но ты сам проговорился.
#255 #772810
>>772808
Стилус в таком устройстве – бесполезная хуйня ради хуйни, как и на телефонах.

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


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

>куча фич, в том числе и из функциональщины


Огромная-преогромная. Даже до лютой императивщины Java 8 как до Луны, не говоря уж о C#.

>бесполезная хуйня


Ясно, понятно. Не видел, не пробовал, не знаешь.
НИНУЖНА
>>772818>>772819
#257 #772814
>>772800
Не, я хуйню сказал, "ничего" в схеме это тоже объект. Но акцент был вот на этом:

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

>>772816>>772968
#258 #772816
>>772814

>объект


Значение.
fix, не спал сутки
#259 #772818
>>772813

>Даже до лютой императивщины Java 8 как до Луны, не говоря уж о C#.


Щас бы написать хуйню не видев кода на свифте...

>НИНУЖНА


Ну и нахуя же он мне на системе, разработанной для тыканья пальцем? Можешь дальше свои окошки в оконном режиме на шиндовз планшетах двигать им, оч полезно.
#260 #772819
>>772813
Ах да, ты же скинул видосик где им пишут заметочки и рисуют! Ахуеть полезность!
>>772820
#261 #772820
>>772819
Ясно, понятно. Не видел, не пробовал, не знаешь.
НИНУЖНА
>>772824>>772836
#262 #772823
>>772798

>А еще call/cc



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

>Это вполне реализуемо в языках с полноценным call-with-current-continuation, то есть код функции будет одинаковым для T, для AnyMonad<T>


>https://rsdn.ru/forum/philosophy/5428281.1

#263 #772824
>>772820

>маааам, мне впаривают хуйню ради хуйни!


>ну дык не ведись, хуле ты.


>но ведь я хачу быдь нитаким как все с айпадами... и у меня нет денег...



На десктопной ос в планшете ясен хуй что без него всё печально, чо уж. Не можем разработать ПО - разработаем палочку с блютусом.
>>772825
127 Кб, 820x482
#264 #772825
>>772824

>маааам, я хочу эту хуйню только от огрызкааа


>но ведь огрызки это сделают только к 2030


>мааам, это будет ИННОВАЦИЯ

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

Нету => конкуренция говно без задач.
1138 Кб, 1920x1200
#267 #772832
>>772826
Для огрызкоманов стоять на голове это не то что им нужно, я не спорю. Им нужны более активные, более вовлекающие формы.
https://en.wikipedia.org/wiki/HumancentiPad
#268 #772834
>>772766

>только медленная и сложная


Чистое ООП вообще очень сложно сделать быстрым. В чистом ООП уровня смолтока или джавы без примитивов, все функции должны быть виртуальными, все объекты должны создаваться в куче и менеджится сборщиком, работа с объектами только через ссылки. Естественно, такой язык быстрым быть не может, поскольку на железо не ложится никак.
>>772842
#269 #772836
>>772820
Стилус на экранах меньше 20 дюймов - бесполезная игрушка. У стилуса точность меньше, поэтому приходится писать заметки буквами в два-три раза больше чем на бумаге. При рисовании приходится непрерывно зумить и скроллить, постоянно мешаешь себе пальцами. Как баловство и для быстрых набросков подходит, для более-менее серьезной работы - нет. Хочешь рисовать на экране - копи деньги на большой синтик, или привыкай к обычному вакому.
#270 #772842
>>772834

>уровня смолтока или джавы


>уровня квантовой физики или школьной арифметики


>уровня круизного лайнера или утлой лодочки

>>772860
#271 #772860
>>772842
Да хоть уровня скалы и жабоскрипта, общие недостатки-то одни и те же у всех ООП языков.
>>772865
30 Кб, 357x400
#272 #772865
>>772860
Но только в Smalltalk можно наслаждаться ими в чистом виде, на полную катушку, только ими, без отвратительных мешающих достоинств.
>>772867
#273 #772867
>>772865
Поэтому его моментально выкинули на помойку с появлением джавы.
>>772870
#274 #772870
>>772867
Если бы вместо джавы IBM, Sun и все-все-все решили бы дать миру INTERCAL, ничего бы не изменилось, писали бы все на INTERCAL как миленькие, точно так же как на Java.
Язык в успехе Java никакой роли не играет, как и в успехе Javascript, например.
#275 #772890
>>772878
У хаскеля нет проблем с mutable state. Могу еще раз повторить.
#276 #772903
>>772894
С системой типой, тотальностью, выводом типов, зависимыми типами, template haskell страшненький. Да много с чем.

Но по сравнению с какой-нибудь джавой или сишечкой это проблемы типа "на моей океанской яхте не работает телевизор на лестнице"
>>772913
#277 #772908
Меня просто вымораживает ситуация вокруг haskell.
С одной стороны барьера сидят "хаскелисты", осилившие только скрипты писать да конфиг xmonad настроить, фанатично приравнивающие haskell к ghc, не слышавшие о большинстве type экстешонов их любимого компилятора, не понимающие в чём проблемы с RankNTypes, почему и зачем в Clean были введены афинные типы, а в MLKit — регионы.
Но самое смешное, — их противники. Представьте себе любителя эзотерических язычков, орущего о том, что хаскель переусложнённый, а самое главное — о непопулярности оного. Забавно наблюдать подобные заявления от фанатика схемы или, например, Go. Но любое упоминание хаскеля у них вызывает какой-то нерациональный слепой приступ ярости и душевной боли.
>>772912
#278 #772909
>>772894
Всё довольно просто. В ghc (и вообще классических компиляторах haskell) монада IO является особой, несмотря на то, что формально type IO = State RealWorld. Использовать RealWorld вне этой монады не стоит, — ведь ничто не мешает накастовать на него \a -> (a, a), а потом засунуть один из экземпляров абы куда и там его "потерять", то есть доступ к RealWorld в haskell равносилен нечистоте языка (и вообще жутко неэффективно, ибо оптимизации ghc расчитаны на работу с монадой IO (основной аргумент против введения линейных или хотя бы афинных типов как раз то, что большой кусок ghc должен быть переписан)).
Чтобы решить эту проблемы придумали афинные и линейные типы, — первые позволяют использовать значение этого типа не более одного раза, а вторые — ровно один раз. По факту RealWorld должен быть линейным, но в Clean его сделали афинным, — терять его всё равно нельзя, ибо если потеряешь, то не сойдётся тип main'а.
Тут важно заметить, что использование оных не отменяет возможности (да и банальной потребности в удобном интерфейсе) использовать монаду IO, только теперь она будет иметь вид State !RealWorld, где ! — обозначение линейности/уникальности.
#279 #772912
#280 #772913
>>772903
Скорее по сравнению с сишкой/явой хакель прозвучит так:

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

>>772916
#281 #772916
>>772913
И телевизор на такой яхте, без IO, кстати, работать точно не будет.
>>772917
#282 #772917
>>772916
Зачем же без IO?
>>772919
#283 #772919
>>772917
Так иначе она уже не чистая, как же главный канон фп?
>>772920
#284 #772920
>>772919
Так и хаскель не чистый, на нем императивно писать можно не хуже чем на джавочке
>>772922
#285 #772922
>>772920
Может у тебя ещё всё мутабельное? Не нужно брать одну молекулу воды, и возвращать модифицированную копию?

Смотри чтоб камнями твои браться по шариату после такого не забили, неверный.
>>772923
#286 #772923
>>772922
Если не нужно - не нужно. Если нужно - то нужно.
Хаскель позволяет делать и так и так.
При этом четко очертить и разграничить одно и так от другого и так как тебе надо, проверять это и не заставлять все это проверять тебя - вся прелесть именно в этом
#287 #772932
>>772927

>Ты перечисляешь борщеговно для аутистов


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

> Система типов-то у хаскеля как раз нормальная


Компромиссная. С чаще всего работающим выводом типов.

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


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

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



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



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

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

>Scala


>становится популярной


Scala практически загнулась уже.
107 Кб, 423x397
#291 #772952
немного старое (2013), но интересное
http://www.leafpetersen.com/leaf/publications/ifl2013/haskell-gap.pdf
#292 #772961
>>772927

>они и так в курсе, что проиходит в их коде


Вот это неверный тезис. Большинство багов в программах, потому что программисты не понимают, что на самом деле происходит в их коде.
>>772987
#293 #772966
>>772894
У хаскиля везде всё заебись. Нет кода - нет проблем.
#294 #772967
>>772798

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


Тогда у нас нет чистых ФЯП.

>А еще call/cc, где континуация не то, что не возвращает ничего (что уже противоречит принципам фп), она не возвращается в принципе.


Продолжение и не может ничего вернуть, учи мат.часть
callCC :: ((a -> ContT r m b) -> ContT r m a) -> ContT r m a
#295 #772968
>>772814

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


man CPS
#296 #772972
>>772633
Ололо! Какая смсачная ФРУСТРАЦИЯ!
Продолжайте, нам очень интересно.
#297 #772987
>>772961
В сишных программах не бывает багов.
Во-первых, сишники всегда знают что происходит в их коде.
Во-вторых, сишные программы настолько быстры, что баги просто не успевают происходить.
>>772993
#298 #772993
>>772987
ахахах, а ну тогда ЯСНА
прикольно зашутил братуха))
#299 #773026

> 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

#301 #773044

> 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/

#303 #773055
>>772804

>не сравнивай свифт с го.


Го не нужен. На свифте уже пишут бэк. Kitura, vapor, Perfect
#304 #773056

> 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

#305 #773064
>>773047
Фигня. Кванты писали и будут писать на крестах
>>773067
#306 #773067
>>773064
Вчерашний день. Кванты пишут DSL для аналитиков, чтоб те сами 90% писали.
#307 #773082
>>772649

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



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

/тред
>>773110
sage #309 #773104

> subhuman


> fleas = 14


axaxaxaxxax
#310 #773110
>>773099

>его даже нельзя формализовать


Обоснуй свой вскукарек.
>>773128
#311 #773125
>>772927
Зависимые типы далеко не только про «давайте чекать на тайплевеле вообще все», а проблема хаскеля не в изоляции IO, а в том, что он использует монады вместо эффектов для этого.
>>773158
#312 #773128
>>773110
Ну Лука Карделли пытался, но нихуя не получилось же. Даже определение композиции не осилил. А все потому что ООП - обычная такая надстройка под процедурщиной, которая по строгости и уровню формализации является чем-то средним между философским трактатом и юридическим договором. Гуманитарная дрисня в общем. Для даунов.

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

>над

#314 #773158
>>773125
Олег уже работает над этим.
Но эффекты тоже всех проблем не решают.
45 Кб, 500x225
#315 #773159
>>773165>>773425
#316 #773162
>>773128

>либо инженер и пишешь команды на асме, либо прикладной логик-алгебраист и пишешь на Coq и LambdaProlog


Не вижу здесь никакого либо.
Высокоуровневую логику - на языках высокого уровня, необходимые для требуемого быстродействия части - на языках низкого уровня, если нужен небольшой (или большой) rule engine - либо берешь готовый, устраивающий тебя, либо быстренько пишешь на коленке небольшой Prolog - ну, идея понятна.
#317 #773165
>>773159
Это сказал Бисмарк еще в 5 веке до нашей эры
>>773171
#318 #773171
>>773165
Это сказал Рем при основании Рима хуй знает сколько веков назад до н.э.
>>773176
#319 #773176
>>773171
Но Рема замочили еще в 1934 году
>>773189
#320 #773189
>>773176
Он вирус скачал и у него брат умер, ты с Ромулом попутал.
#321 #773199
#322 #773425
>>773159
Дауны не могут в формулу Бине.
#323 #773436
>>772882
То, что ты обосрался в самом начале поста, позволило мне сэкономить время и недочитывать остальной бред.
168 Кб, 2560x1024
#324 #773444
>>773481
#325 #773481
>>773444
Ну, щас-то хаскель в индустрии массово применяют. Вакансий больше, чем на джаву.
>>773493>>773507
#326 #773493
>>773481
В той статье аргументы малость протухли. Например, в хаскель завезли stack, а опенсорц стал нормой.
#327 #773507
>>773481
Мартыханских вакансий конечно больше на джаве, но если говорить про что-нибудь нормальное, то там будет Хаскель.
>>773957>>774371
#328 #773843
>>773128

>Ну Лука Карделли пытался


О, анон, ты походу его читал. Собираюсь тоже почитать. Интересно хоть?
#329 #773849
>>772766

>Олег Заимкин.


У него есть блог?
#330 #773897
>>770420

> Линух потому и жив, что его писали на Си


У линукса очень маленькая сложность как у системы. Там, упрощённо говоря, есть некоторая центральная часть типа управления памятью и проч. + куча драйверов. Добавь 100 драйверов или выкини, изменится только суммарное число строк, но не сложность архитектуры.
#331 #773898
>>773128
Почему это не получилось? Очень даже получилось. Только у него говно получилось, длинное и бесполезное.
#332 #773900
>>770795

>Можно вообще обойтись без наследования


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

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


Не применяй там, где не надо, вот и всё.
>>773929
sage #334 #773903
>>770268 (OP)

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


Убеди меня, что ты не хуй.
>>773929
#335 #773929
>>773900
>>773901
>>773903
Фрустрация жабообезьяны лол.
>>773930
sage #336 #773930
>>773929
Чини детектор, я на plain c пишу.
>>773943
#337 #773943
>>773930
Как трансфореры монад делаешь?
>>773944
sage #338 #773944
>>773943
Лифтингом.
>>773946
#339 #773946
>>773944
Сильный программист!
>>773947
61 Кб, 618x418
sage #340 #773947
>>773946

> Сильный программист!


А ТО
>>773950
#341 #773950
>>773947
Сила - это хорошо, но можно ведь и удобней, если ум добавить.

> https://www.reddit.com/r/programming/comments/4mzlvi/10_lesserknown_programming_languages_worth/d42lbie

#342 #773957
>>773507
Сейчас бы поутешать самого себя.
#343 #774371
>>773507
Ситуация примерно такая: в джаве отношение мартыханских вакансий к нормальным - 10/1, в хаскеле 1/10, при этом нормальных вакансий на джаве в 100 раз больше чем на хаскеле. Я не к тому что хаскель хуже джавы или что-то в этом роде, просто такова реальность.
>>775300
#344 #775209
>>771711

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


Понимаешь, тогда будет либо отдельные launch_d3d11.exe и launch_ogl.exe. Либо всякие
if(m_mode == MODE_D3D11)
{
D3D11Render();
}.
В первом случае хуйня какая-то. Во втором случае тот же самый оверхед на branch predictor. У меня, правда, возникали идеи - а если он и правда работает статистически, то, может, после прохода 1000 раз по варианту MODE_D3D11 он всегда будет выбирать его? Но я не хочу серьёзно полагаться на такую низкоуровневую вещь, как реализация предсказателя переходов на конкретном процессоре.

>Cache miss во время двойного перехода указатель на объект->адрес VMT->смещение по VMT страшнее


Хм. А разве он не может подгрузить в кэш все функции, которые тебе нужны? Он же видит, например, что функции по D3D11 используются много, а OGL в данной сессии не использовались вообще. Или кэш не такой умный? Или это опять же зависит от реализации, как в предыдущем примере?

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


Ну во-первых, мне просто нравится работа с графикой. Именно с программной стороны. Всякие сложные алгоритмы, эффекты - это пиздец как интересно.
А во-вторых, я и не использовал этого слова.
>>775233
#345 #775233
>>775209

>оверхед на branch predictor


Начиная с Haswell брэнч предиктор на свитчах уже не промахивается практически.
>>775277
#346 #775248
>>774983
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 Хороший учебник, всё расписано подробно. Сам по нему учился. Рекомендую.
#347 #775277
>>775233
А где вообще можно увидеть тесты на эту тему? Или вручную закупать процессоры разных лет и самостоятельно проверять?
>>775308
#348 #775300
>>774371
Сколько в Москве сейчас открытых вакансий на Хаскелле?
>>775309>>779006
#349 #775308
>>775277
http://agner.org/optimize/

http://igoro.com/archive/fast-and-slow-if-statements-branch-prediction-in-modern-processors/comment-page-1/#comment-178540

Если тебе надо на полчаса потестировать, зачем покупать, в эпоху облачных технологий.
1 Кб, 200x131
#350 #775309
>>776657
#351 #775329
Сап, программач. Сразу скажу, что я не программист, не борщехлеб и даже не макака, так что я не шарю за все эти экзистенциальные типы, гетерогенные списки и прочее, прошу отнестись с пониманием, ибо мне кажется, что моя кулстори релевантна треду, в какой-то степени.
Короче, начал пилить проект, подразумевающий дохуя разнородных структур, мутабельный стейт, сорт оф наследование (или сабтайпинг, я хз), модульность, короче, все, для чего придумывалась волшебная таблетка ооп. Взял питон, ну а что, ПРОСТО пишешь и все работает, как я по наивности предполагал. Первые 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, с другой - описание последовательности вычислений с имплицитным стейтом. Вот только без стейта обойтись все равно никак, а если представить, что последовательность процедур в императивной параше и есть последовательность вычислений, то выходит, что монады это, буквально, та же хуйня, только с лишним слоем абстракции?
#351 #775329
Сап, программач. Сразу скажу, что я не программист, не борщехлеб и даже не макака, так что я не шарю за все эти экзистенциальные типы, гетерогенные списки и прочее, прошу отнестись с пониманием, ибо мне кажется, что моя кулстори релевантна треду, в какой-то степени.
Короче, начал пилить проект, подразумевающий дохуя разнородных структур, мутабельный стейт, сорт оф наследование (или сабтайпинг, я хз), модульность, короче, все, для чего придумывалась волшебная таблетка ооп. Взял питон, ну а что, ПРОСТО пишешь и все работает, как я по наивности предполагал. Первые 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, с другой - описание последовательности вычислений с имплицитным стейтом. Вот только без стейта обойтись все равно никак, а если представить, что последовательность процедур в императивной параше и есть последовательность вычислений, то выходит, что монады это, буквально, та же хуйня, только с лишним слоем абстракции?
#352 #775332
>>775329
Без стейта не надо обходиться.
Хаскельное удобство не в том чтоб не было стейта, или не было мутаций, или не было IO, или не было сайд-эффектов. Оно только в том чтобы все эти эффекты были эксплицитно обозначены, легко отделялись друг от друга и от кода без эффектов, и с этим всем было удобно работать.
В Racket ты мог бы на полную мощности использовать контракты и typed racket, со своими плюсами и своими минусами для тех же целей.

ООП в Хаскель есть, свое, марсиански-структурное, и на изобретения из Симулы похоже не очень.
>>775359
#353 #775337
>>775329

>это жалкое подобие монад в языке без типов


Попизди мне тут. Монада - не цель, а средство. В языке с call-cc ты можешь использовать функцию в монадическом коде а не писать отдельную и ехал лифт через лифт, а map через mapM
>>775359
#354 #775341
>>775329

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


Именно так. В фортране ты эмулируешь стек, в сишке кастишь void*, в С++ ебешься с владением, в старой жабе мучаешься без лямбд, а в хаскелле ты явно пердолишься со стейтом. Это неудобство, но иногда это неудобство бывает оправданным (иначе эти языки бы не существовали). Например, в академической среде.
Твоя ошибка в том, что ты, соснув с питоном, не начал изучать причины своего отсоса (мы обсуждали в соседнем треде, в динамическом языке нужно 100% покрытия "тестами типизации", чтобы оно хоть как-то работало), а решил, что это язык виноват.
>>775343>>775359
#355 #775343
>>775341
Не "пердолишься", а аккуратно и эксплицитно работаешь с ним.

> В фортране ты эмулируешь стек


В Алголе запилили нормальный уже.

> причины своего отсоса (мы обсуждали в соседнем треде, в динамическом языке нужно 100% покрытия "тестами типизации", чтобы оно хоть как-то работало)


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

> а решил, что это язык виноват.


Он не решил что язык виноват. Он сообщает что на собственном опыте убедился вот в чем - в том что если (как он в первой же фразе и объявил) архитектурить не умеешь - в данном случае потому что опыта нет - то язык может тебя в разной степени заставить это делать (пусть и не самым оптимальным образом, но хоть как-нибудь), а может не заставлять.
В разных случаях требуется разное, соотношение затрат времени и сил разное, требования разные, квалификация у всех разная. Мудрый человек не сильно напрягаясь напишет понятный, надежный, легко модифицируемый и быстрый код на любом языке, использовав те проеимущества языка что ему нужны в конкретном случае.
>>775359>>775361
#356 #775359
>>775332

>Без стейта не надо обходиться.


Никто и не говорит, что надо.
>>775337
man irony
>>775341

>Твоя ошибка в том, что ты, соснув с питоном, не начал изучать причины своего отсоса (мы обсуждали в соседнем треде, в динамическом языке нужно 100% покрытия "тестами типизации", чтобы оно хоть как-то работало), а решил, что это язык виноват.


Питон был взят для прототипирования, просто вначале хорошо пошло, думал на нем и доделаю.
>>775343

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


В точку. Ну и еще про небходимость правильного выбора инструмента (я считаю, питон для тех случаев, когда баша или перла немного не хватает, ну или для рапид прототайпинга).
>>775376
#357 #775361
>>775343

>Не "пердолишься", а аккуратно и эксплицитно работаешь с ним.


>эксплицитно


https://www.youtube.com/watch?v=5tkMi72w8j0

>Он не решил что язык виноват


Он взял мейнстримный язык, наговнокодил, и потом взял экзотику. Т.е. вместо того, чтобы понять, что с собой не так, хает питон. Еще пара таких итераций и очередное золотце готово.
>>775376
#358 #775376
>>775361
Хорошо - "явным образом" будет достаточно для тебя понятно?
Чтобы "понять что с ним не так" требуется гораздо больше времени чем взять язык, который ему в данном случае бил по рукам и тем самым помог не говнокодить.
Он решил поделиться своим опытом.

>>775359

>питон для тех случаев, когда баша или перла немного не хватает


Это ошибка во многих случаях. Во многих - нет.
Мир разнообразен.
Кто-то берет питон написать небольшую утилиту, кто-то пишет на нем миллионы строк, по-разному бывает.
То что динамические языки дают больше свободы - эти еще нужно уметь правильно воспользоваться. А не себе во вред.
#359 #775380
>>772633
Хуя ты пиздабол. Налепил слов на *ция, как будто это придаст смысл и большую значимость твоему высеру. Пиздец, и с таким апломбом ещё... Как будто бы только что статью в энциклопедию написал.
>>775384
#360 #775381
>>773128
С хуя ли не получилось? Кончай кукарекать.
>>775384
#361 #775384
>>775380
>>775381
Каникулы, прекрасные каникулы.
#362 #775385
>>775376

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


Он выкинул код и написал его заново. Конечно велик шанс, что вторая попытка будет чуть лучше прошлой.
>>775386>>775434
#363 #775386
>>775385
Совсем невелик.
Хотя я очень удивлен таким лихим его напором и освоением схемы и хаскеля в кратчайшее время, может быть он и дизайну и архитектуре так же лихо учится, вундеркинд.
>>775387>>775426
#364 #775387
>>775386
Очень велик, когда изначальный подход - это

>вроде multiple dispatch и синглтонов, да еще с такими-то метаклассами, почти как в CLOS/MOP, сказка прям

#365 #775426
>>775386
Не, я хаскель не осваивал. Считаю, что еще не дорос. Про монадки знал в общих чертах. А у схемы весь стандарт на 50 страниц, осваивать нечего.
>>775376

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


При желании и на ванильном r5rs можно запилить python-like oop и говнокодить в нем, а еще srfi есть какие-то, вроде, с подобием ооп. Тут я сам себя по рукам бил, схему взял из-за макросов, наличия ровно нихуя в стандартной библиотеке, да и вообще люблю лишп. Вместо нее мог быть тот же питон, это вообще не важно, тут про ооп vs монадки, а не языкосрач
>>775447
#366 #775434
>>775385
Ты прав, так и есть, вкусив всех прелестей ооп, я выбрал другой подход и получилось чуть лучше.
#367 #775444
>>775376

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


Для чистоты эксперимента надо чтобы он ещё раз написал этот проект на питоне. Вполне возможно успех со схемой вызван тем, что грабли были уже изучены при прототипировании.
>>775447>>775468
#368 #775447
>>775444

>Для чистоты эксперимента надо чтобы он ещё раз написал этот проект на питоне.


Читай:
>>775426

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


Будет абсолютно то же самое на питоне с монадами.
>>775451
#369 #775451
>>775447
В итоге - чтобы понять как надо было это делать с самого начала потребовалось сделать два прототипа на выброс.
>>775491
#370 #775456
Alan Kay - главный зачинатель ОО-культа, сегодня отвечает на вопросы публики

https://news.ycombinator.com/item?id=11939851
#371 #775468
>>775444
Для чистоты эксперимента хорошо бы посмотреть на код. Пока все эти слова доверия не вызывают. Я вижу только личинку лиспера, т.е. говно нации.
>>775491
#372 #775491
>>775451
А как иначе?
>>775468

>личинку лиспера, т.е. говно нации


Один лиспер = целая нация?
Да, схема - не лисп. Только синтаксис похож.
>>775535
#373 #775535
>>775491

>А как иначе?


Иначе - это когда прототипов на выброс делать не требуется, а дизайнится, и пишется один раз - и сразу работает.
Для этого нужен опыт.
Малолетние долбоебы называет это waterfall и утверждают что такого не бывает, а нужно соблюдать аджайл, слушать радио Радонеж и переписывать все заново каждые две недели.
>>775541>>775571
#374 #775541
>>775535

> дизайнится, и пишется один раз - и сразу работает


такая хуита бывает только в госзаказах

вотерфол это когда заказчик не видит результат пол года, потом получает парашу что вы слепили и посылает вас нахуй, потому что все не так
это любимый способ разработки в военке и НИИ, где все должно быть параллельно и перпендикулярно, а на продукт всем похуй, главное отчеты и работа вместо результата, ведь продукт делается не чтоб зарабатывать бапки, а чтоб горжусь великай родиной
>>775548>>775764
#375 #775548
>>775541

>потому что все не так


Для того чтобы было все так существуют Технические Задания, Эскизные Проекты, Рабочие Проекты, и Технические Проекты, не говоря о документации.

Говорил я не об этом, кстати. Но так ты не видел нихуя кроме стэндап-митингов, заменяющих проектирование, то тебе кажется что по-другому и не бывает.
>>775550>>775553
#376 #775550
>>775548

>Технические Задания, Эскизные Проекты, Рабочие Проекты, и Технические Проекты, не говоря о документации


Вся эта хуйня существует только в вотерфол мирке, который умер в нормальных странах ещё в 80е, кроме госпараши разумеется
>>775584
#377 #775553
>>775548

>документации


Это присутствует в любом проекте, не важно от методологии, но это не решает описанной выше проблемы.
>>775634
#378 #775571
>>775535

>Для этого нужен опыт.


Ага.
#379 #775584
>>775550
Какой же ты даун.
мимокрокодил
#380 #775634
>>775553
Я и не говорил что документация сама по себе волшебным магическим образом решает проблемы.
Проблемы решаются головой. Ей же осмысливается опыт, выводы из опыта применяются к новым проектам - потому что решения и задачи в погромировании на 95% типовые и одни и те же. Особенно если общие их черты научиться видеть.
Голову ни одна методология, хотя бы и с самыми скрамными и солидными аджайлами, не заменяет.
Тем более что туда где аджайлы, стендапы и скрамное мракобесие, нормальный, уважающий себя человек чаще всего просто не пойдет.
>>775662>>775667
#381 #775662
>>775634
Ну вот допустим я хочу написать распознавалку новой, хуёвой капчи двача.
>>775667
#382 #775667
>>775634
>>775662
...
Я подозреваю, что для этого не обязательно использовать весь арсенал методов OCR и machine learning, а можно обойтись сопоставлением с маской, или какими-то другими ad hock хаками. Но я не уверен в этом.
Как мне без прототипа в голове определить возможно это или нет?
>>775668>>775676
#383 #775668
>>775667
ad hoс, конечно же
#384 #775676
>>775667
Ты даже задачу не можешь сформулировать.
Сколько капч тебе надо распознавать - одну в час или миллион в секунду?
Когда эта капча сменится другой - окей ли выкинуть распознавалку и начать все сначала или лучше потратить X времени сразу на нормальную?
И еще десяток подобных вопросов.
Потрать час-два времени, подумай над ними хорошенько, расставь приоритеты.
Станешь уже на 30-50% ближе к правильным решениям.
>>775687
#385 #775687
>>775676
Задача - обнаруживать новые WEBM как можно ближе к реалтайму делая запросы только с одного айпишника.
#386 #775688
>>775687
Тредов и досок много, поэтому придётся делать несколько запросов в секунду.
#387 #775691
>>775687
Ты не понял.
Это был не вопрос к тебе сформулировать для меня задачу более точно.
Это был добрый методологический совет как тебе начать включать голову и хотя бы начать улучшать качество решения твоих задач.
Судя по твоему ответу, тебе это не помогло. Задача сформулирована так же говенно как и в прошлый раз - вопросов к ней с таким дополнением стало только больше.
Может быть ты не умеешь понимать прочитанное - это называется функциональная неграмотность.
>>775703
#388 #775703
>>775691
Это ты не понял. Я показал конкретный пример того как так случается, что чёткой постановки задачи нет.
У меня есть только широкая формулировка большой задачи, из которой никак не вывести детали реализации. Когда нет дяди в галстуке который бы принёс на блюдечке спецификацию. Только ты один на один с дикой природой. Архитектор, ПМ и кодер в одном лице. Твоя задача сделать жизнеспособный продукт или объяснить почему это невозможно.
Ты сам должен провести инвестигейшн, выяснить какая у двача и у клаудфлейра политика бана за частые запросы и частое неправильное распознавание капчи. Проверить что лучше - использовать API или парсить треды. Если парсить треды, то какую версию - десктопную или мобильную.
А потом ещё найти где хостинг подешевле. И тут интересное ещё не заканчивается. Сканер двача это только часть проекта. Вебмки я в итоге собираюсь выкачивать и процессить, и для этого нужен достаточно мощный сервер. Есть хостинги подешевле, где в полиси запрещается использовать все ядра в режиме 24/7, а есть полноценные vds, но стоят они заметно дороже. Чтобы сказать какой сервер мне нужен (и сколько ядер на нём) мне надо знать как меняется количество вебмок на дваче в течении недели, каковы пики и средняя нагрузка, и какой среди вебмок процент повторов в долгосрочной перспективе. С этими данными я смогу сказать а по карману ли мне вообще этот проект или это всё воздушные замки.
Но вот загвоздка - чтобы собрать эти данные нужна прога, которая сканит двач и находит вебмки.
Если проект реализовать с моим бюджетом невозможно, то я хочу узнать об этом как можно раньше. Поэтому я пишу прототип, и другого варианта не вижу.
Проектирование делается после рисёрча, а его зачастую невозможно провести без прототипа.
Конечно всё проще если ты упитанный розовощёкий офисный кретин, которому начальник присылает спецификацию. Но эта простота обусловлена тем, что во-первых за тебя подумал аналитики, ПМ и тимлид, а во-вторых не исключено, что высшее руководство рассматривает весь твой проект как прототип, и если не взлетит он, то будут извлечены уроки и запилят новый.
#388 #775703
>>775691
Это ты не понял. Я показал конкретный пример того как так случается, что чёткой постановки задачи нет.
У меня есть только широкая формулировка большой задачи, из которой никак не вывести детали реализации. Когда нет дяди в галстуке который бы принёс на блюдечке спецификацию. Только ты один на один с дикой природой. Архитектор, ПМ и кодер в одном лице. Твоя задача сделать жизнеспособный продукт или объяснить почему это невозможно.
Ты сам должен провести инвестигейшн, выяснить какая у двача и у клаудфлейра политика бана за частые запросы и частое неправильное распознавание капчи. Проверить что лучше - использовать API или парсить треды. Если парсить треды, то какую версию - десктопную или мобильную.
А потом ещё найти где хостинг подешевле. И тут интересное ещё не заканчивается. Сканер двача это только часть проекта. Вебмки я в итоге собираюсь выкачивать и процессить, и для этого нужен достаточно мощный сервер. Есть хостинги подешевле, где в полиси запрещается использовать все ядра в режиме 24/7, а есть полноценные vds, но стоят они заметно дороже. Чтобы сказать какой сервер мне нужен (и сколько ядер на нём) мне надо знать как меняется количество вебмок на дваче в течении недели, каковы пики и средняя нагрузка, и какой среди вебмок процент повторов в долгосрочной перспективе. С этими данными я смогу сказать а по карману ли мне вообще этот проект или это всё воздушные замки.
Но вот загвоздка - чтобы собрать эти данные нужна прога, которая сканит двач и находит вебмки.
Если проект реализовать с моим бюджетом невозможно, то я хочу узнать об этом как можно раньше. Поэтому я пишу прототип, и другого варианта не вижу.
Проектирование делается после рисёрча, а его зачастую невозможно провести без прототипа.
Конечно всё проще если ты упитанный розовощёкий офисный кретин, которому начальник присылает спецификацию. Но эта простота обусловлена тем, что во-первых за тебя подумал аналитики, ПМ и тимлид, а во-вторых не исключено, что высшее руководство рассматривает весь твой проект как прототип, и если не взлетит он, то будут извлечены уроки и запилят новый.
>>775742>>775784
#389 #775742
>>775703
Ты описываешь какой-то оверкилл. Особенно включая экономические факторы. В жизни, а не школьных учебниках, устроено все попроще. С таким подходом к проектированию и разработке как у тебя, быстро в трех соснах заблудишься. Попробуй набить шишек в реальных проектах, вместо теоретизирования.
#390 #775743
Ну что, программистишки. Давай челлендж на написание разгадывалки капчи с хуями.
#391 #775764
>>775541

>такая хуита бывает только в госзаказах


Не бывает. Вот как выглядит разработка прибора:
1. Эскизный проект - теоретики ебашат выкладки, что это возможно. Каждый отдел пишет ТЗ по тому, что он знает
2. Технический проект. Уже более подробное описание.
3. Лабораторное изделие - альфа-версия, так сказать. Изделия ебашится вдоль и поперек, модифицируется прямо паяльником на месте.
4. Стендовое изделие - несколько бета-версий.
5. Штатные изделия - все гонится потоком.

На каждом этапе заказчик принимает все и подписывает.

>это любимый способ разработки в военке и НИИ


А ты как хочешь? Каждый день новый прибор за несколько миллионов клепать, чтобы протестить багфикс? Или чтобы заказчик "ой, а нам энергопотребление нужно в 5 раз меньше, и цвет зелененький можно" пиздел на середине разработки? Ты ебанько с промытыми порашей мозгами.
>>775799
#392 #775778
>>775687

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


Это не задача.

>обнаруживать новые WEBM как можно ближе к реалтайму


Вот это - задача.
И решать ее разгадыванием капчи - дурацкий способ. Способы нужно перебирать таким образом:

1. Готовое решение - может решение уже сделано. Всегда нужно начинать с анализа конкурентов.
2. Социальное решение - может проще написать Абу и дать ему долю в обмен на API. Это просто нереальный этап для программистишки.
3. Типовое решение. То, что делается всегда в таком случае. Например, набор из 10К прокси.
4. Йоба-решения, требующие R&D.

А далее, если ты опустился до этого варианта, тебе нужно собственно R&D, которое является отдельной работой по своим законам. Именно тут делают ad-hoc прототипы из говна и палок, доказывающие работоспособность каждой из частей.

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


Чтобы узнать политику бана, тебе достаточно curl. Но еще лучше - спросить. Потому что грузить сервер однообразными запросами - занятие мудацкое изначально.
>>776019
#393 #775784
>>775703

>Поэтому я пишу прототип, и другого варианта не вижу.


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


Это ad-hoc прототипы маленьких чстей системы, которых в процессе проектирования делается куча по полчаса на каждый.
Это НЕ версии всей системы целиком "на выброс", о которых и шла речь изначально.
22 Кб, 600x208
#394 #775799
>>775764
Так аджайл-сектанты ведь на полном серьезе утверждают что заранее вообще ничего знать невозможно!
Ни какое у прибора должно быть энергопотребление, ни какой зелененький цвет. Потому что неподвластно это уму человеческому, и проектирование - тайна великая есмь, из глубины веков, забытое искусство ацтеков.
А такие вещи как анализ требований и спецификации - слова неприличные, в аджайл-манямирке не употребляемые.

http://www.markjowen.com/2014/09/01/is-agile-a-cult/
>>775813
#395 #775800
Интересно посмотреть откуда были взяты аджайл-модели и какое в них было здравое зерно - пока не пришли аджайл-консультанты и все не выродилось в полностью бессмысленные пляски народов Океании.
Было это взято из авральной модели затыкания дыр.

> 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/



Логичный вывод мудрых аджайл-консультантов - давайте же сделаем всю работу постоянным авральным затыканием дыр.
>>775811
190 Кб, 665x706
#396 #775811
>>775800

> 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.

>>775819>>775840
#397 #775813
>>775799
Аджайл нормален, когда ребилд всей системы не стоит ничего и занимает 10 минут. В промышленности такое бывает редко, в айти - часто, но не прямо сказать, чтобы всегда. То есть по сути когда вся разработка - это и есть проектирование, аджайл нормален.
В любом случае странно дрочить что на водопад, что на аджайл, это разные методы со своими достоинствами и недостатками.

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


Ну это капитализм - вытянуть из работника ресурсы по-максимуму, не беря при этом на себя ответственность за кривое ТЗ. При водопаде если клиент подписал этап, то все, пизда, контрактор может ссылаться на эту подпись, даже если там явно невыгодное решение, а устроить это довольно просто, ведь заказчик не может знать так много о разработке, как исполнитель.
#398 #775819
>>775811

>culture of terminal juniority


Годно выразил.
На русский точно даже и не переведешь.
Страна вечного детства блджад.
>>775821>>775840
3 Кб, 236x236
#399 #775821
>>775819
Полного и окончательного детства.
#400 #775840
>>775811
>>775819
Вам что угодно дай - будете ныть всё равно.
>>775885
#401 #775885
>>775840
Этого двачую. Программач превратился в сборище вечно ноющих идиотов, которым всё не так. Хорошо, что подобных макак не пускают к управлению.
#402 #775973
Хуйню тут развели. Высокоуровневое программирование невозможно без абстракций. Для абстракций лучше всего подходит ООП. Кривые абстракции - дефект программиста, а не ООП. Наследование в ООП не является обязательным к использованию. У меня все.
#403 #775980
>>775973
Объект - плохая абстракция, потому как не является композабельной
>>775985>>787291
#404 #775985
>>775980
Объекты с множеством конструкторов и 1 функцией exec - самая лучшая абстракция, которая неплохо себя документирует. Всегда так делаю.
>>776361>>776388
#405 #775998
>>775973

>Для абстракций лучше всего подходит ООП


Пиздец ты даун.
#406 #775999
Лучшей абстракцией является инфинити-группойд. Идите учите математику, неучи.
#407 #776002
>>775973

>Для абстракций лучше всего подходит ООП.


Потому что ничего другого ты не видел и не знаешь.

>Кривые абстракции - дефект программиста, а не ООП.


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

>Наследование в ООП не является обязательным к использованию


А так как других способов реализации полиморфизма в ОПП нет, то полиморфизм не нужен, заебись.
>>776013>>776026
#408 #776013
>>776002

>Но источник некривых программистов, которым не помешает даже ООП, пока не обнаружен.


Смотрите, Прямой заехал!

>А так как других способов реализации полиморфизма в ОПП нет, то полиморфизм не нужен, заебись.


Ты че? Ебанутый? Че ты там делаешь?
#409 #776019
>>775778
Лучшая абстракция - U-комбинатор.
#410 #776026
>>776002

>других способов реализации полиморфизма


Во-первых, наследование никак не связано с полиморфизмом. Во-вторых, полиморфизм это костыль для ЯП со статической типизацией.
>>776028
#411 #776028
>>776026
Наследование - это кривой костыль, которым полиморфизм реализуется в ООП-парадигме, потому что других не завезли.
>>776034
#412 #776032
Человеческий язык является языком ООП.
Но нет же, ООП плохой, негодный. Пушкин с Толстым хуйню написали, надо переписать на ассемблере.
#413 #776034
>>776028
Ты говно с мочой путаешь. Наследование это повторное использование кода. Полиморфизм к нему никаким боком.
>>776045
#414 #776045
>>776034
Тебе уже в говновики даже написали

> Подтипизация (subtyping), или полиморфизм подтипов (subtype polymorphism), означает, что поведение параметрически полиморфной функции ограничивается множеством типов, связанных в иерархию «супертип — подтип»

>>776053
33 Кб, 460x276
#415 #776052
ООП - это штука, которая позволяет держать сложность под контролем, запихивая ее в иерархические интерфейсы.
ООД - это штука, которая говорит: раз мы можем держать сложность под контролем, не надо ей озабачиваться во время проектирования, а надо тупо плодить объекты на каждый чих. И создает сложность гораздо быстрее, чем ООП в состоянии ее контролировать.
>>776056
#416 #776053
>>776045
То крестоебы писали, у них родовая травма.
Наследование изначально не для полиморфизма, а для повторного использования кода.
>>776062
#417 #776056
>>776052

>надо тупо плодить объекты на каждый чих


а вот за это я бы арматурой по рукам бил, за каждую лишнюю сущность
#418 #776062
>>776053

>Изначально



Тред хоть почитай в котором пишешь.
>>772766
>>776072
#419 #776072
>>776062
Согласен, слово "изначально" было лишнее.
Но продолжаю настаивать, что полиморфизм через наследование - это костыль
>>776546
#420 #776361
>>775985
Ты там функции эмулируешь что ли?
>>776389
#421 #776388
>>775985
Нахуя метод exec, если можно перегрузить оператор вызова.
#422 #776389
>>776361
Функции значительно хуже документируются.
>>776470
#423 #776470
>>776389
Так глупо, что даже толсто. Поведение функций зависит только от аргументов и влияет лишь на возвращаемое значение, поэтому зачастую по одной только сигнатуре можно понять, что она делает.
Например:
head :: [a] -> a
или посложнее:
compose :: (b -> c) -> (a -> b) -> a -> c
maybe :: b -> (a -> b) -> Maybe a -> b
У объектов же есть есть ещё подводная часть айсберга - его внутреннее состояние и связи с другими объектами, у которых оно тоже есть, а это уже очень трудно поддается документированию.
#424 #776487
>>776470

>Поведение функций зависит только от аргументов и влияет лишь на возвращаемое значение


Неправильно. И объекты, и функции, могут как обладать внутренним состоянием, так и не обладать. Причем даже не обладая внутренним состоянием, они могут иметь квази-внутреннее состояние (путем возврата модифицированной копии). Здесь никакой разницы нет.

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


Ну давай, расскажи мне, что делает [Float] -> IO [Float].
#425 #776546
>>776072

> полиморфизм через наследование - это костыль



А такое возможно вообще? Пример справедливый для этой части Вселенной, пожалуйста.
>>776645
#426 #776572
>>771908
Ты ООП изобрел. Пишешь просто похоже на каком нибудь урезанном форке си
#427 #776580
>>771908
У тебя получилась in-memory база данных без SQL.
Если у тебя язык без GC то непонятно кто будет освобождать память. Если с GC то советую для реестра объектов использовать weak references.
И вообще давай там без фанатизма, глобальные переменные ругают не зря.
#428 #776614
Тред не читал. http://shaffner.us/cs/papers/tarpit.pdf уже упоминали?
#429 #776618
>>776470

>зачастую по одной только сигнатуре можно понять, что она делает


Это ещё один функци-анальный миф:
val sendto : file_descr -> bytes -> int -> int -> msg_flag list -> sockaddr -> int
Видишь эти два int -> int? Расскажи-ка мне, что это и зачем.
>>776627
#430 #776627
>>776618

> что это


Это говно, не делай так.
Haskell дал им type и newtype, но нет, не хочу давать нормальные имена типам, хочу жрать только базовые... и далее по пасте.
Я понимаю, что в мейнстриме все хуево даже с базовыми вещами вроде именования типов (хотя тайпдеф даже в сишечке есть), ну в хачкеле-то зачем продолжать жрать это говно? Там свое есть.
>>776649
#431 #776645
>>776546
Как сразу и было >>772766
#432 #776646
>>776470

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


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"

#433 #776649
>>776627
Они от этого пропадут или что? Или можно подписать "абстрактно-могадическая рекурсивная фабрика интов" чтобы было всё просто и понятно?
>>776653
#434 #776653
>>776649
Во-первых, они от этого станут понятными.
Во-вторых, они начнут выполнять свою основную задачу - специализацию (после валидации) данных, попавших из одной части программы в другую, чтобы не проверять их корректность в каждой функции на входе.

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

В перле для этого был taint mode, который решал эту задачу не через жопу а просто и удобно - но во многом потому перл больше и не с нами, слишком уж все было в нем просто и удобно.
>>776903
#435 #776657
>>775309
Годно. В прошлый раз было 2.
Паста работает, продолжайте форс.
#436 #776903
>>776653

> слишком уж все было в нем просто и удобно.


А также нечитаемо.
>>776913
#437 #776913
>>776903
Во-первых, читаемо.
Во-вторых, когда плохой код можно легко визуально отличить от хорошего - это довольно удобно. На Python или Java, например, это сделать на порядок сложнее.

Плохой код и хороший код можно написать на любом языке, странно что ты этого не знаешь.
#438 #777524
Не подскажет кто программу для автоматического заполнения гугловских форм ,к примеру форма - https://docs.google.com/forms/d/1PvUaFTc4eMPUTeqa3UFnH4g9fFGyxJ07h6hp94yqweo/viewform?c=0&w=1 ,нужно чтобы вбивало постоянно 1 и те же указанные данные автоматически каждую минуту
>>777902
#439 #777902
>>777524
Самому сделать не?
#440 #777939
>>772633

> Я вот с ходу могу сказать, что гуйню лучше моделировать стрелками, чем объектами


Кукарекнул петух.

> а про гуй пусть лучше спецы по гуи напишут, от них то мы и узнаем


Так и автор копипасты петух, а не спец по гую. А вот спецы из Эппла выбрали именно ООП для моделирования сложного GUI на Mac OS X.
>>777984
#441 #777984
>>777939

>спецы из Эппла выбрали именно ООП


Это спецы из NeXT выбрали. "Спецы" из Apple тогда пешком под стол ходили.
Выбрали неудачно, поэтому NeXT загнулся.
Но ничего другого с собой принести Жобсу не было когда опять в огрызку позвали.
>>778034
#442 #778034
>>777984
Можно было с нуля разработать. В любом случае, самый крутой GUI всегда (с первого Мака) делали в Apple, а поделки борщехлебов на стрелках и монадах недалеко ушли от Tk. Полупрозрачность? Резиновая верстка? Создание своих компонент? Аппаратное ускорение и 3D эффекты? Нет, не слышали.
#443 #778308
>>778034
Самый крутой GUI сейчас вообще на вебе делают.
#444 #778312
>>778034
Самый крутой гуй никакого отношения к ООП не имеет и называется FRP.
#445 #778313
>>778034

>поделки борщехлебов на стрелках и монадах недалеко ушли от Tk



>>772766
#446 #778560
Тащемта, я делал гуй на entity component systems, и получалось не хуже (а местами сильно лучше) оопепешного.
>>778566>>778981
#447 #778566
>>778560
Тащем - то те полтора пользователя этого гуя блевали в сторонку от этого поделия.

Проблемы которые решает FRP ортогональны проблематике хорошего UI. Поэтому сравнение со сложившимися практиками интересно только разработчикам. Вопросы надежности и корректности, как и удобство разработки, пользователям по барабану.
>>778570>>779144
#448 #778570
>>778566
Уёбище, научись пробелы ставить между дефисом, пол часа пытался прочитать первое предложение.

Тащем-то, ты — хуесос.
>>778770
#449 #778770
>>778570
А какое отношение это имеет к тому, что ты гавно написал?
>>778996
#450 #778981
>>778560
ООП в GUI все только усложняет.
#451 #778996
>>778770
Я тут вообще мимо проходил, просто ты тупое уёбище портящее ощущение от чтения сосачика.
#452 #779006
>>775300
Не смотрел, но полагаю 0. Учить мартыханов программировать на Хаскелле смысла не имеет, а нормальный Хаскеллист может поехать в Лондон или в Сингапур, зачем ему обязательно стоять в московских пробках по пути в бирюлёво?
#453 #779144
>>778566
FRP - это норкомания, когда ты на каждый чих заводишь отдельный стрим?
>>779169
#454 #779169
>>779144

>на каждый чих заводишь отдельный стрим?


Почему бы и нет? Хотя можно гораздо проще - без FRP и классического списка событий. Тупо глобальный gui.update(), который иерархически прогоняет список накопившихся событий по компонентам. То есть Form1 при вызове update прогоняет его вместе с рисовательным ресурсом через все дочерние виджеты. Нет FRP-наркомании, нет onClick ебанатства. Для простой логики можно все разруливать на уровне формы, в одной жирной функции. Для сложных виджетов делать подписку на onEvent. Что-то вроде immediate gui, но без обязательного перестроения на каждый апдейт.
>>779180
#455 #779180
>>779169
Графическая оболочка Lisa делала это ещё в 1983.
>>779186
#456 #779186
>>779180
Ну и правильно. Идея строгого разделения рисования-логики кнопочек-логики приложения - отрыжка 90-х. Гораздо удобнее все чохом лепить, с абстракциями где необходимо.
>>780960
#457 #780960
>>779186
Где же ты был тогда, герой архитектуры? Столько бы сотен тысяч человеко-часов спас, научил бы индустрию

> чохом лепить, с абстракциями где необходимо.



А ну да, в 90х же твоя мамка только в первый класс пошла
>>783032
#458 #782975
>>772766
ООП это просто красивый способ зашить стейт-монаду в синтаксис так, чтобы этим было удобно пользоваться.
>>783022>>783217
#459 #783022
>>782975
Нет никаких монад. Проснись, ты говоришь на петушином новоязе.
#460 #783032
>>780960

>научил бы индустрию


Нахуя мне кого-то учить? Пусть сами думают.
#461 #783037
>>770268 (OP)
Модель акторов, Эрланг.
/thread
>>789186
#462 #783217
>>782975
Хаотично меняющиеся стейты в тысячах объектов - это по-твоему state-монада?
>>783448
#463 #783448
>>783217
Каждый объект O соответствует стейт монаде со стейтом состоящим из записи R со всеми полями объекта O.
Нестатические методы - это функции типов
method : ..args.. -> State R result
#464 #783522
Объектно-ориентированная парадигма была выдумана
чтобы как-то организовать мышление в случаях,
когда программы большие, и не запутаться

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

Но беда в том, что ООП превратилось в монстра,
который не помогает как птице, 'увидеть задачу
с высоты', но ОБСЛУЖИВАЕТ САМ СЕБЯ - б'ольшая
часть умственных усилий тратится на то, чтобы
создавать и помнить детали самих ООП patterns

В этом смысле, это как бюрократия: министерство
с/хозяйства на 70% занято поддержанием внутренних
процессов, которые создает само, и лишь на остаток
как-то соотносится с действительностью.

Доказательством тому служат на порядок более
пухлые и раза в 1.5-2 более долгие при выполнении
программы ООП, по сравнению с программами на
процедурных языках (и тем более на функциональных)
>>783564>>783565
#465 #783564
>>783522
Да откуда ж вы лезете-то в таком количестве.

>>772766

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

>>783596
#466 #783565
>>783522
Это поэма?
#467 #783596
>>783564

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


Да похуй в каком виде это реализовать: через параметризованные модули, через какие-нибудь "контексты", через классы/объекты, через стейт монады. Главное, что это должно быть реализовано в языке, причём так, чтобы этим можно было удобно пользоваться на каждом шагу, потому что оно нужно на каждом шагу.
>>783621
#468 #783621
>>783596
Что "это"?
>>783719
sage #469 #783719
>>783621
дибил
>>784934
#470 #783822
>>770268 (OP)
Жиза на оп-пике
#471 #784934
>>783719
Это ясно уже по первым строкам написанного и по манере общения. Анончик спрашивает, что сказать то хотел?
#472 #787291
>>775980

>Объект - плохая абстракция, потому как не является композабельной


Монады тоже не композабельны в общем случае, напомню.
>>787298
#473 #787297
>>770268 (OP)
Лень читать тред. Напомни, анон, есть ли у борщехлебов что-нибудь подобное божественному Qt?
>>787299>>787412
#474 #787298
>>787291
С монадами, стрелками и эффектами есть куда разиваться.
http://okmij.org/ftp/Haskell/extensible/index.html

С объектами - тупик.
>>787427
#475 #787299
>>787302
#476 #787302
>>787299
И чем он лучше? Там хоть свои компоненты можно делать?
>>787305>>787308
#477 #787305
>>787302

>можно ли делать


>Lisp


В Лиспе можно делать всё.
>>787306>>787398
#478 #787306
>>787305
Только это не нужно как и он сам.
#479 #787308
>>787302
Тебе хватило одной минуты и сорока семи секунд чтобы ознакомиться с совершенно новой для тебя, и сложной технологией, и успеть задать хорошо обдуманный, конструктивный вопрос.
Да ты блджад Феномен.
>>787379
#480 #787379
>>787308
Не нужно учить весь лисп, чтобы понять, что это говно без задач.
#481 #787398
>>787305
Любая достаточно сложная программа на Си или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp.
Филип Гринспен

…в том числе и сам Common Lisp.
Роберт Моррис
#482 #787412
>>787297

> 2016


> потешный ком костылей на гигабайт для формочек


Напомни, анон, есть ли у байтослесарей что-нибудь подобное божественному Apache Spark?
>>787413
#484 #787415
>>787413

> Hadoop


> речь про Spark


> only about 1.75GB


> сравнивает с локалхостом


> нинужна!


Лол блять, до чего же тупое животное.
>>787433
#485 #787427
>>787298
Структура кода и её свойства оверрейтед. Важно что код делает, с точностью до изоморфизма.
А сделать красивое и удобное апи поверх содержательного кода можно бесконечным количеством способов,
и на мейнстримном ООП в том числе.
Лично я мечтаю о юзабельном языке, на котором нельзя написать две разные программы, делающие одно и то же.
#486 #787429
>>787427

> языке, на котором нельзя написать две разные программы, делающие одно и то же.


Урезанный ассемблер, без альтернативных инструкций и джампов.
#487 #787433
>>787415

> 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/

#488 #787453
>>787427

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


Такой язык не будет Тьюринг-полным.
Если бы было иначе, то ты такой
[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]
>>787528
#489 #787528
>>787453
А потом скайнет такой: >>787453 не нужен, правильно будет:
дайте мне описание задачи я сам закодирую.
#490 #787693
>>787427
Был тут когда-то курс по окамлу. Для него пацаны написали автоматический проверяльщик заданий, который генерировал правильные значения на лету и сравнивал их с теми, которые выдаёт твой код. Сравнивал, конечно, через "=" (а как ещё-то?). И были в том курсе задачки с флоатами. И всё, вроде бы, нормально, потому что полученные одним и тем же путём флоаты, на одном и том же компьютере всегда будут иметь одно и то же значение. Вот только есть одна маленькая проблемка - если ты, например, сохранил число в переменную, а не подставил само выражение, то это уже другой путь. В общем, первую задачу я решил за ~15 минут, после чего ещё часа полтора пытался угадать, как они написали эталонную программу. Остальные задачи я не решил (точнее, решил, но в зачёте было 0, по понятным причинам). А теперь представь, что тебе это надо делать для каждой программы, иначе она не будет конпеляться. Ты же первый назовёшь этот язык говном и больше никогда к нему не притронешься.
#491 #789125
>>787427

>нельзя написать две разные программы, делающие одно и то же


Ничего хорошего из этой затеи не выйдет. Насколько я понял, лямбда-исчисление с одним типом подходит, но если ты добавляешь натуральные числа, то ничего не выйдет в общем случае, а в частном случае тебе придется подробно указать максимум информации о функции в ее типе, чтобы что-то можно было доказывать.
Лучше уж просто хранить в распределенной базе данных хеш от AST функции и ее значений, как пацаны что Unison делают собираются.
#492 #789186
>>783037
Такое же бесполезное говно как и ООП, кстати, и тот же хайп вокруг него. История идёт по кругу.
Тред утонул или удален.
Это копия, сохраненная 26 июля 2016 года.

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

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
« /pr/В начало тредаВеб-версияНастройки
/a//b//mu//s//vg/Все доски