М.Двач / Программирование

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

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

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.

151 Кб, 1948x858

Убедите меня, что ООП не полное говно без задач. 15 Июн, 20:22 #770268 В конец треда | Веб

Убедите меня, что ООП не полное говно без задач. С примерами, никаких "кококо куд кудах а вот у меня в голове сферическая задача в вакууме которая без ООП не решается"

Ответы>>770274>>770287>>770292>>770314>>770335>>770343>>770409>>770496>>770585>>770674>>770782>>771066>>771635>>771902>>772649>>772676>>773903>>783037>>783822>>787297

15 Июн, 20:24 #2 #770270

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

15 Июн, 20:32 #3 #770274

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

sage 15 Июн, 20:46 #4 #770287

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

15 Июн, 20:47 #5 #770288

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

Ответы>>770295

15 Июн, 20:57 #6 #770292

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

Ответы>>770298>>770420

15 Июн, 20:58 #7 #770295

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

Ответы>>770302

15 Июн, 20:59 #8 #770298

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

35 Кб, 595x479

15 Июн, 21:01 #9 #770300

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

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

Ответы>>772633

15 Июн, 21:02 #10 #770302

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

Ответы>>770305

15 Июн, 21:04 #11 #770305

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

Ответы>>770328

sage 15 Июн, 21:16 #12 #770314

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

15 Июн, 21:32 #13 #770328

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

15 Июн, 21:36 #14 #770335

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

Ответы>>770394

15 Июн, 21:36 #15 #770336

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

Ответы>>770375

sage 15 Июн, 21:40 #16 #770343

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

57 Кб, 433x604

15 Июн, 22:12 #17 #770375

>>770336
Этому нет, но есть
http://blogerator.ru/page/oop_why-objects-have-failed

15 Июн, 22:12 #18 #770379

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

Ответы>>770395

15 Июн, 22:22 #19 #770394

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

Ответы>>770468>>773901

74 Кб, 512x504

15 Июн, 22:23 #20 #770395

>>770379

15 Июн, 22:36 #21 #770409

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

Ответы>>771064>>771304

15 Июн, 22:42 #22 #770420

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

Ответы>>770477>>773897

15 Июн, 23:44 #23 #770468

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

Ответы>>770626>>770795

15 Июн, 23:47 #24 #770472

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

Ответы>>770480>>770481

15 Июн, 23:52 #25 #770477

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

Ответы>>770479

15 Июн, 23:54 #26 #770479

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

Ответы>>770484

15 Июн, 23:54 #27 #770480

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

Ответы>>770483

15 Июн, 23:54 #28 #770481

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

15 Июн, 23:55 #29 #770483

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

Ответы>>770494

15 Июн, 23:56 #30 #770484

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

Ответы>>770491

16 Июн, 00:02 #31 #770491

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

16 Июн, 00:04 #32 #770494

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

16 Июн, 00:07 #33 #770496

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

Ответы>>770663>>770675

16 Июн, 01:51 #34 #770558

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

Ответы>>770565

16 Июн, 02:01 #35 #770565

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

Ответы>>770573>>770574

16 Июн, 02:44 #36 #770573

>>770565
На лиспе

Ответы>>770575

16 Июн, 02:52 #37 #770574

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

16 Июн, 02:55 #38 #770575

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

16 Июн, 03:56 #39 #770585

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

Ответы>>770588

16 Июн, 04:01 #40 #770588

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

16 Июн, 05:30 #41 #770620

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

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

Ответы>>770635

67 Кб, 603x407

16 Июн, 06:39 #42 #770626

>>770468
А кто сказал, что должна быть древовидная иерархия?

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

Ответы>>770660

16 Июн, 07:23 #43 #770631

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

Ответы>>770633>>770637

16 Июн, 07:27 #44 #770633

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

Ответы>>770649>>770652

16 Июн, 07:31 #45 #770635

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

16 Июн, 07:34 #46 #770637

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

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

16 Июн, 07:47 #47 #770649

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

16 Июн, 07:57 #48 #770652

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

16 Июн, 08:12 #49 #770660

>>770626
No true Scottsman fallacy.

16 Июн, 08:18 #50 #770663

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

Ответы>>770667>>770673

16 Июн, 08:27 #51 #770667

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

Ответы>>770673>>770680>>770729

16 Июн, 08:31 #52 #770673

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

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

Ответы>>770727>>770765

16 Июн, 08:32 #53 #770674

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

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

16 Июн, 08:38 #54 #770675

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

22 Кб, 260x331

16 Июн, 08:40 #55 #770680

>>770667

16 Июн, 10:22 #56 #770727

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

Ответы>>770765>>770789

16 Июн, 10:24 #57 #770729

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

7 Кб, 980x515

6 Кб, 979x513

16 Июн, 11:29 #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, точных цифр особо не помню). Почему так?

Ответы>>770772>>770776>>770784

16 Июн, 11:48 #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.

16 Июн, 11:48 #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

16 Июн, 11:52 #60 #770776

>>770765

Изучай

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

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

16 Июн, 12:00 #61 #770782

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

Ответы>>770787

16 Июн, 12:00 #62 #770784

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

16 Июн, 12:00 #63 #770785

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

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

Ответы>>770788>>771698

16 Июн, 12:02 #64 #770787

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

Ответы>>770796

16 Июн, 12:03 #65 #770788

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

Ответы>>770805

16 Июн, 12:04 #66 #770789

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

16 Июн, 12:08 #67 #770795

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

Ответы>>773900

16 Июн, 12:10 #68 #770796

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

Ответы>>770808>>770814>>770816

16 Июн, 12:16 #69 #770805

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

16 Июн, 12:23 #70 #770808

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

16 Июн, 12:26 #71 #770814

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

Ответы>>770840>>770851>>771023

16 Июн, 12:26 #72 #770816

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

Ответы>>771026

16 Июн, 12:58 #73 #770840

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

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

Ответы>>770843>>770851>>771698

16 Июн, 13:09 #74 #770843

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

Ответы>>770844>>771698

16 Июн, 13:12 #75 #770844

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

Ответы>>770850

16 Июн, 13:19 #76 #770850

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

16 Июн, 13:20 #77 #770851

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

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

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

Ответы>>770859>>770860>>771023>>772020

16 Июн, 13:26 #78 #770859

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

16 Июн, 13:27 #79 #770860

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

16 Июн, 16:02 #80 #771023

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

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

Ответы>>771027>>771051

16 Июн, 16:05 #81 #771026

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

16 Июн, 16:06 #82 #771027

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

Ответы>>771028>>771032>>771035

16 Июн, 16:07 #83 #771028

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

16 Июн, 16:10 #84 #771032

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

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

Ответы>>771036>>771054

16 Июн, 16:11 #85 #771035

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

16 Июн, 16:11 #86 #771036

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

Ответы>>771049

16 Июн, 16:19 #87 #771049

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

Ответы>>771061>>773159

16 Июн, 16:19 #88 #771051

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

Ответы>>771052

16 Июн, 16:21 #89 #771052

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

Ответы>>771055>>771057

16 Июн, 16:22 #90 #771054

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

16 Июн, 16:25 #91 #771055

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

Ответы>>771056

16 Июн, 16:26 #92 #771056

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

Ответы>>771059

16 Июн, 16:28 #93 #771057

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

16 Июн, 16:29 #94 #771059

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

Ответы>>771062

16 Июн, 16:32 #95 #771061

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

Ответы>>771063

16 Июн, 16:32 #96 #771062

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

Ответы>>771074

16 Июн, 16:33 #97 #771063

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

Ответы>>771068>>771087

16 Июн, 16:34 #98 #771064

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

Ответы>>771305

206 Кб, 1000x1200

16 Июн, 16:36 #99 #771066

>>770268 (OP)
>Subhuman

16 Июн, 16:38 #100 #771068

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

Ответы>>771076>>771078

16 Июн, 16:41 #101 #771074

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

16 Июн, 16:42 #102 #771076

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

Ответы>>771100>>773444

16 Июн, 16:44 #103 #771078

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

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

Ответы>>771100

16 Июн, 16:51 #104 #771087

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

Ответы>>771099

16 Июн, 16:54 #105 #771099

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

Ответы>>771106

16 Июн, 16:54 #106 #771100

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

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

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

Ответы>>771115>>771156

16 Июн, 16:55 #107 #771106

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

Ответы>>771114>>771117

16 Июн, 17:00 #108 #771114

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

16 Июн, 17:01 #109 #771115

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

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

Ответы>>771123

16 Июн, 17:02 #110 #771117

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

16 Июн, 17:10 #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

16 Июн, 17:29 #112 #771152

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

Ответы>>771162

16 Июн, 17:32 #113 #771156

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

Ответы>>771162

16 Июн, 17:34 #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).

16 Июн, 17:39 #115 #771162

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

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

Ответы>>771174>>771178

16 Июн, 17:50 #116 #771174

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

16 Июн, 17:51 #117 #771178

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

Ответы>>773199

16 Июн, 20:28 #118 #771304

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

Ответы>>771305

16 Июн, 20:28 #119 #771305

>>771064
>>771304

16 Июн, 20:42 #120 #771312

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

Ответы>>771314>>771332>>771592

16 Июн, 20:43 #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

16 Июн, 20:56 #122 #771332

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

17 Июн, 00:19 #123 #771592

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

Ответы>>771606>>771609

17 Июн, 00:53 #124 #771606

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

Ответы>>771622

17 Июн, 00:56 #125 #771609

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

17 Июн, 01:12 #126 #771622

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

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

Ответы>>771626

17 Июн, 01:17 #127 #771626

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

17 Июн, 01:45 #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

17 Июн, 02:59 #129 #771661

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

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

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

Ответы>>772468

17 Июн, 03:14 #130 #771665

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

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

17 Июн, 04:19 #131 #771680

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

17 Июн, 04:22 #132 #771682

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

17 Июн, 04:31 #133 #771684

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

Ответы>>771685

17 Июн, 04:34 #134 #771685

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

17 Июн, 05:03 #135 #771694

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

17 Июн, 05:33 #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} на кадр.

Ответы>>771703>>771704>>771792

17 Июн, 06:22 #137 #771703

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

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

17 Июн, 06:28 #138 #771704

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

Ответы>>771708

17 Июн, 07:05 #139 #771708

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

Ответы>>771715

17 Июн, 07:32 #140 #771715

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

17 Июн, 07:36 #141 #771716

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

Ответы>>772774

17 Июн, 07:39 #142 #771718

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

17 Июн, 07:49 #143 #771723

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

Ответы>>771737>>771881

17 Июн, 07:53 #144 #771724

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

17 Июн, 08:04 #145 #771728

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

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

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

17 Июн, 08:18 #146 #771734

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

17 Июн, 08:23 #147 #771737

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

Ответы>>771745

140 Кб, 2400x2083

17 Июн, 08:24 #148 #771738

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

17 Июн, 08:41 #149 #771745

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

17 Июн, 08:54 #150 #771752

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

17 Июн, 10:32 #151 #771787

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

Ответы>>771801

17 Июн, 10:36 #152 #771792

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

Ответы>>771808

17 Июн, 10:41 #153 #771801

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

Ответы>>771817

17 Июн, 10:42 #154 #771805

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

17 Июн, 10:46 #155 #771808

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

17 Июн, 10:53 #156 #771813

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

17 Июн, 10:53 #157 #771814

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

17 Июн, 10:56 #158 #771817

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

Ответы>>771820

17 Июн, 11:00 #159 #771820

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

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

Ответы>>771841

17 Июн, 11:07 #160 #771832

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

Ответы>>771840

17 Июн, 11:15 #161 #771840

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

17 Июн, 11:17 #162 #771841

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

Ответы>>771850

17 Июн, 11:22 #163 #771845

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

17 Июн, 11:27 #164 #771850

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

Ответы>>771856

17 Июн, 11:32 #165 #771856

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

Ответы>>771866

17 Июн, 11:39 #166 #771866

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

17 Июн, 11:49 #167 #771877

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

17 Июн, 11:55 #168 #771881

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

Ответы>>771896

17 Июн, 12:10 #169 #771896

>>771881

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

Ответы>>771904>>772285

17 Июн, 12:14 #170 #771902

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

Ответы>>771908

17 Июн, 12:16 #171 #771904

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

Ответы>>771912

17 Июн, 12:23 #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

17 Июн, 12:27 #173 #771912

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

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

Ответы>>771924

17 Июн, 12:46 #174 #771924

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

Ответы>>771937

17 Июн, 13:01 #175 #771937

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

Ответы>>771939

17 Июн, 13:06 #176 #771939

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

Ответы>>771946

17 Июн, 13:25 #177 #771946

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

Ответы>>771951

17 Июн, 13:34 #178 #771951

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

Ответы>>771958

169 Кб, 550x778

17 Июн, 13:43 #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

17 Июн, 13:45 #180 #771958

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

17 Июн, 14:02 #181 #771964

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

Ответы>>771965>>772029

17 Июн, 14:04 #182 #771965

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

Ответы>>771992>>772021

17 Июн, 14:35 #183 #771992

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

Ответы>>771995

17 Июн, 14:39 #184 #771995

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

Ответы>>772021

17 Июн, 14:54 #185 #772005

>>771314
ВНЕЗАПНО

17 Июн, 15:16 #186 #772020

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

17 Июн, 15:18 #187 #772021

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

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

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

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

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

17 Июн, 15:18 #187 #772021

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

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

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

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

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

Показать весь текст

17 Июн, 15:24 #188 #772029

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

Ответы>>772034>>772042

17 Июн, 15:29 #189 #772034

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

17 Июн, 15:38 #190 #772042

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

Кек

Ответы>>772049

17 Июн, 15:46 #191 #772049

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

Ответы>>772058

17 Июн, 15:56 #192 #772058

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

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

Ответы>>772062

17 Июн, 16:03 #193 #772062

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

Ответы>>772074>>772075>>772081

17 Июн, 16:07 #194 #772064

>>772060
>Vulkan

Ответы>>772066

17 Июн, 16:08 #195 #772066

>>772064
Что Vulkan?

Ответы>>772111

17 Июн, 16:17 #196 #772074

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

17 Июн, 16:18 #197 #772075

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

Ответы>>772132

17 Июн, 16:21 #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

17 Июн, 16:32 #199 #772102

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

17 Июн, 16:37 #200 #772110

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

17 Июн, 16:37 #201 #772111

>>772066

>>771957

17 Июн, 16:47 #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

17 Июн, 16:49 #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

17 Июн, 16:54 #204 #772132

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

Ответы>>772140

17 Июн, 17:00 #205 #772140

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

Ответы>>772177

17 Июн, 17:39 #206 #772177

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

Ответы>>772203

17 Июн, 18:02 #207 #772203

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

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

17 Июн, 18:16 #208 #772222

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

17 Июн, 18:33 #209 #772241

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

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

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

Ответы>>772244>>772261

17 Июн, 18:35 #210 #772244

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

Ответы>>772246

17 Июн, 18:36 #211 #772246

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

17 Июн, 18:47 #212 #772261

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

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

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

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

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

Ответы>>772265>>772274

17 Июн, 18:54 #213 #772265

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

17 Июн, 19:02 #214 #772270

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

101 Кб, 890x670

17 Июн, 19:05 #215 #772274

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

Ответы>>772290>>772292>>772293

17 Июн, 19:19 #216 #772285

>>771896
Это мимо.

17 Июн, 19:25 #217 #772290

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

Ответы>>772291>>772297>>772300>>772316

17 Июн, 19:27 #218 #772291

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

17 Июн, 19:30 #219 #772292

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

17 Июн, 19:31 #220 #772293

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

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

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

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

Ответы>>772359

17 Июн, 19:35 #221 #772297

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

Ответы>>772306>>772315>>772328

17 Июн, 19:36 #222 #772300

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

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

Ответы>>772311>>772316

17 Июн, 19:40 #223 #772306

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

Ответы>>772328

17 Июн, 19:42 #224 #772311

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

Ответы>>772549>>772763

17 Июн, 19:47 #225 #772315

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

Ответы>>772370

17 Июн, 19:47 #226 #772316

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

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

17 Июн, 19:57 #227 #772328

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

Ответы>>772370

17 Июн, 20:21 #228 #772359

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

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

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

Ответы>>772438>>772763

17 Июн, 20:28 #229 #772370

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

17 Июн, 20:49 #230 #772391

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

Ответы>>772775

17 Июн, 21:45 #231 #772438

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

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

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

17 Июн, 22:11 #232 #772468

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

Ответы>>772485>>772491

17 Июн, 22:26 #233 #772485

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

Ответы>>772489

17 Июн, 22:31 #234 #772489

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

Ответы>>772530

17 Июн, 22:32 #235 #772491

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

Ответы>>772513

17 Июн, 22:46 #236 #772513

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

Ответы>>772530

17 Июн, 22:58 #237 #772530

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

Ответы>>772798

17 Июн, 23:07 #238 #772549

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

Ответы>>772608

17 Июн, 23:41 #239 #772608

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

sage 18 Июн, 00:02 #240 #772633

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

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

Ответы>>772766>>772972>>775380>>777939

18 Июн, 00:12 #241 #772649

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

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

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

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

Ответы>>773082

SAGE 18 Июн, 00:22 #242 #772676

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

Ответы>>772766

18 Июн, 04:29 #243 #772763

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

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

18 Июн, 05:02 #244 #772766

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

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

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

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

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

18 Июн, 05:02 #244 #772766

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

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

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

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

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

Показать весь текст
Ответы>>772834>>773849>>776062>>776645>>778313>>782975>>783564

18 Июн, 06:45 #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

18 Июн, 06:56 #246 #772775

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

18 Июн, 08:50 #247 #772794

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

Ответы>>772799

18 Июн, 08:59 #248 #772798

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

Ответы>>772800>>772823>>772967

18 Июн, 09:00 #249 #772799

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

Ответы>>772804

18 Июн, 09:03 #250 #772800

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

Ответы>>772814

18 Июн, 09:11 #251 #772804

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

Ответы>>772805>>772808>>772809>>773055

18 Июн, 09:11 #252 #772805

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

18 Июн, 09:28 #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

18 Июн, 09:29 #254 #772809

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

18 Июн, 09:33 #255 #772810

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

Ответы>>772813

18 Июн, 09:44 #256 #772813

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

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

Ответы>>772818>>772819

18 Июн, 09:44 #257 #772814

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

Ответы>>772816>>772968

18 Июн, 09:48 #258 #772816

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

18 Июн, 09:50 #259 #772818

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

18 Июн, 09:51 #260 #772819

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

Ответы>>772820

18 Июн, 09:53 #261 #772820

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

Ответы>>772824>>772836

18 Июн, 09:59 #262 #772823

>>772798
>А еще call/cc

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

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

18 Июн, 09:59 #263 #772824

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

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

Ответы>>772825

127 Кб, 820x482

18 Июн, 10:00 #264 #772825

>>772824
>маааам, я хочу эту хуйню только от огрызкааа
>но ведь огрызки это сделают только к 2030
>мааам, это будет ИННОВАЦИЯ

Ответы>>772828

18 Июн, 10:01 #265 #772826

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

Ответы>>772832

18 Июн, 10:05 #266 #772828

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

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

1138 Кб, 1920x1200

18 Июн, 10:09 #267 #772832

>>772826
Для огрызкоманов стоять на голове это не то что им нужно, я не спорю. Им нужны более активные, более вовлекающие формы.
https://en.wikipedia.org/wiki/HumancentiPad

18 Июн, 10:16 #268 #772834

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

Ответы>>772842

18 Июн, 10:22 #269 #772836

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

18 Июн, 10:27 #270 #772842

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

Ответы>>772860

18 Июн, 10:47 #271 #772860

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

Ответы>>772865

30 Кб, 357x400

18 Июн, 10:57 #272 #772865

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

Ответы>>772867

18 Июн, 11:00 #273 #772867

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

Ответы>>772870

18 Июн, 11:05 #274 #772870

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

18 Июн, 11:44 #275 #772890

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

18 Июн, 11:53 #276 #772903

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

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

Ответы>>772913

18 Июн, 12:00 #277 #772908

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

Ответы>>772912

18 Июн, 12:00 #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, где ! — обозначение линейности/уникальности.

18 Июн, 12:06 #279 #772912

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

18 Июн, 12:06 #280 #772913

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

Ответы>>772916

18 Июн, 12:08 #281 #772916

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

Ответы>>772917

18 Июн, 12:09 #282 #772917

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

Ответы>>772919

18 Июн, 12:09 #283 #772919

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

Ответы>>772920

18 Июн, 12:10 #284 #772920

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

Ответы>>772922

18 Июн, 12:13 #285 #772922

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

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

Ответы>>772923

18 Июн, 12:15 #286 #772923

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

18 Июн, 12:25 #287 #772932

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

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

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

18 Июн, 12:34 #288 #772938

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

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

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

18 Июн, 12:43 #289 #772945

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

18 Июн, 12:44 #290 #772946

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

107 Кб, 423x397

18 Июн, 12:53 #291 #772952

немного старое (2013), но интересное
http://www.leafpetersen.com/leaf/publications/ifl2013/haskell-gap.pdf

18 Июн, 13:03 #292 #772961

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

Ответы>>772987

18 Июн, 13:06 #293 #772966

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

18 Июн, 13:08 #294 #772967

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

18 Июн, 13:10 #295 #772968

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

18 Июн, 13:14 #296 #772972

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

18 Июн, 13:35 #297 #772987

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

Ответы>>772993

18 Июн, 13:41 #298 #772993

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

18 Июн, 14:11 #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

18 Июн, 14:21 #300 #773040

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

18 Июн, 14:27 #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/

18 Июн, 14:32 #302 #773047

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

Ответы>>773064

18 Июн, 14:36 #303 #773055

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

18 Июн, 14:38 #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

18 Июн, 14:45 #305 #773064

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

Ответы>>773067

18 Июн, 14:48 #306 #773067

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

18 Июн, 15:06 #307 #773082

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

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

18 Июн, 15:16 #308 #773099

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

/тред

Ответы>>773110

sage 18 Июн, 15:23 #309 #773104

> subhuman
> fleas = 14
axaxaxaxxax

18 Июн, 15:31 #310 #773110

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

Ответы>>773128

18 Июн, 15:49 #311 #773125

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

Ответы>>773158

18 Июн, 15:59 #312 #773128

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

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

Ответы>>773129>>773162>>773843>>773898>>775381

18 Июн, 15:59 #313 #773129

>>773128
>над

18 Июн, 16:35 #314 #773158

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

45 Кб, 500x225

18 Июн, 16:38 #315 #773159

>>771049

Ответы>>773165>>773425

18 Июн, 16:41 #316 #773162

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

18 Июн, 16:41 #317 #773165

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

Ответы>>773171

18 Июн, 16:45 #318 #773171

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

Ответы>>773176

18 Июн, 16:48 #319 #773176

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

Ответы>>773189

18 Июн, 16:57 #320 #773189

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

18 Июн, 17:04 #321 #773199

>>771178
YO!

18 Июн, 20:23 #322 #773425

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

18 Июн, 20:34 #323 #773436

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

168 Кб, 2560x1024

18 Июн, 20:42 #324 #773444

>>771076
>2010

Ответы>>773481

18 Июн, 21:09 #325 #773481

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

Ответы>>773493>>773507

18 Июн, 21:22 #326 #773493

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

18 Июн, 21:34 #327 #773507

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

Ответы>>773957>>774371

19 Июн, 05:02 #328 #773843

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

19 Июн, 05:15 #329 #773849

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

19 Июн, 07:27 #330 #773897

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

19 Июн, 07:29 #331 #773898

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

19 Июн, 07:31 #332 #773900

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

Ответы>>773929

19 Июн, 07:31 #333 #773901

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

Ответы>>773929

sage 19 Июн, 07:33 #334 #773903

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

Ответы>>773929

19 Июн, 08:44 #335 #773929

>>773900
>>773901
>>773903
Фрустрация жабообезьяны лол.

Ответы>>773930

sage 19 Июн, 08:45 #336 #773930

>>773929
Чини детектор, я на plain c пишу.

Ответы>>773943

19 Июн, 09:22 #337 #773943

>>773930
Как трансфореры монад делаешь?

Ответы>>773944

sage 19 Июн, 09:23 #338 #773944

>>773943
Лифтингом.

Ответы>>773946

19 Июн, 09:24 #339 #773946

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

Ответы>>773947

61 Кб, 618x418

sage 19 Июн, 09:25 #340 #773947

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

Ответы>>773950

19 Июн, 09:35 #341 #773950

>>773947
Сила - это хорошо, но можно ведь и удобней, если ум добавить.
> https://www.reddit.com/r/programming/comments/4mzlvi/10_lesserknown_programming_languages_worth/d42lbie

19 Июн, 09:43 #342 #773957

>>773507
Сейчас бы поутешать самого себя.

19 Июн, 15:52 #343 #774371

>>773507
Ситуация примерно такая: в джаве отношение мартыханских вакансий к нормальным - 10/1, в хаскеле 1/10, при этом нормальных вакансий на джаве в 100 раз больше чем на хаскеле. Я не к тому что хаскель хуже джавы или что-то в этом роде, просто такова реальность.

Ответы>>775300

20 Июн, 14:09 #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

20 Июн, 14:32 #345 #775233

>>775209
>оверхед на branch predictor
Начиная с Haswell брэнч предиктор на свитчах уже не промахивается практически.

Ответы>>775277

20 Июн, 14:58 #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 Хороший учебник, всё расписано подробно. Сам по нему учился. Рекомендую.

20 Июн, 15:37 #347 #775277

>>775233
А где вообще можно увидеть тесты на эту тему? Или вручную закупать процессоры разных лет и самостоятельно проверять?

Ответы>>775308

20 Июн, 16:25 #348 #775300

>>774371
Сколько в Москве сейчас открытых вакансий на Хаскелле?

Ответы>>775309>>779006

20 Июн, 16:29 #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

20 Июн, 16:30 #350 #775309

>>775300

Ответы>>776657

20 Июн, 16:59 #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, с другой - описание последовательности вычислений с имплицитным стейтом. Вот только без стейта обойтись все равно никак, а если представить, что последовательность процедур в императивной параше и есть последовательность вычислений, то выходит, что монады это, буквально, та же хуйня, только с лишним слоем абстракции?

20 Июн, 16:59 #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, с другой - описание последовательности вычислений с имплицитным стейтом. Вот только без стейта обойтись все равно никак, а если представить, что последовательность процедур в императивной параше и есть последовательность вычислений, то выходит, что монады это, буквально, та же хуйня, только с лишним слоем абстракции?

Показать весь текст
Ответы>>775332>>775337>>775341

20 Июн, 17:09 #352 #775332

>>775329
Без стейта не надо обходиться.
Хаскельное удобство не в том чтоб не было стейта, или не было мутаций, или не было IO, или не было сайд-эффектов. Оно только в том чтобы все эти эффекты были эксплицитно обозначены, легко отделялись друг от друга и от кода без эффектов, и с этим всем было удобно работать.
В Racket ты мог бы на полную мощности использовать контракты и typed racket, со своими плюсами и своими минусами для тех же целей.

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

Ответы>>775359

20 Июн, 17:16 #353 #775337

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

Ответы>>775359

20 Июн, 17:22 #354 #775341

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

Ответы>>775343>>775359

20 Июн, 17:34 #355 #775343

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

> В фортране ты эмулируешь стек
В Алголе запилили нормальный уже.

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

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

Ответы>>775359>>775361

20 Июн, 18:04 #356 #775359

>>775332
>Без стейта не надо обходиться.
Никто и не говорит, что надо.
>>775337
man irony
>>775341
>Твоя ошибка в том, что ты, соснув с питоном, не начал изучать причины своего отсоса (мы обсуждали в соседнем треде, в динамическом языке нужно 100% покрытия "тестами типизации", чтобы оно хоть как-то работало), а решил, что это язык виноват.
Питон был взят для прототипирования, просто вначале хорошо пошло, думал на нем и доделаю.
>>775343
>Он не решил что язык виноват. Он сообщает что на собственном опыте убедился вот в чем - в том что если (как он в первой же фразе и объявил) архитектурить не умеешь - в данном случае потому что опыта нет - то язык может тебя в разной степени заставить это делать (пусть и не самым оптимальным образом, но хоть как-нибудь), а может не заставлять.
В точку. Ну и еще про небходимость правильного выбора инструмента (я считаю, питон для тех случаев, когда баша или перла немного не хватает, ну или для рапид прототайпинга).

Ответы>>775376

20 Июн, 18:11 #357 #775361

>>775343
>Не "пердолишься", а аккуратно и эксплицитно работаешь с ним.
>эксплицитно
https://www.youtube.com/watch?v=5tkMi72w8j0
>Он не решил что язык виноват
Он взял мейнстримный язык, наговнокодил, и потом взял экзотику. Т.е. вместо того, чтобы понять, что с собой не так, хает питон. Еще пара таких итераций и очередное золотце готово.

Ответы>>775376

20 Июн, 18:54 #358 #775376

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

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

Ответы>>775385>>775426>>775444

20 Июн, 18:57 #359 #775380

>>772633
Хуя ты пиздабол. Налепил слов на *ция, как будто это придаст смысл и большую значимость твоему высеру. Пиздец, и с таким апломбом ещё... Как будто бы только что статью в энциклопедию написал.

Ответы>>775384

20 Июн, 18:58 #360 #775381

>>773128
С хуя ли не получилось? Кончай кукарекать.

Ответы>>775384

20 Июн, 19:02 #361 #775384

>>775380
>>775381
Каникулы, прекрасные каникулы.

20 Июн, 19:03 #362 #775385

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

Ответы>>775386>>775434

20 Июн, 19:05 #363 #775386

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

Ответы>>775387>>775426

20 Июн, 19:07 #364 #775387

>>775386
Очень велик, когда изначальный подход - это
>вроде multiple dispatch и синглтонов, да еще с такими-то метаклассами, почти как в CLOS/MOP, сказка прям

20 Июн, 20:32 #365 #775426

>>775386
Не, я хаскель не осваивал. Считаю, что еще не дорос. Про монадки знал в общих чертах. А у схемы весь стандарт на 50 страниц, осваивать нечего.
>>775376
>язык, который ему в данном случае бил по рукам и тем самым помог не говнокодить.
При желании и на ванильном r5rs можно запилить python-like oop и говнокодить в нем, а еще srfi есть какие-то, вроде, с подобием ооп. Тут я сам себя по рукам бил, схему взял из-за макросов, наличия ровно нихуя в стандартной библиотеке, да и вообще люблю лишп. Вместо нее мог быть тот же питон, это вообще не важно, тут про ооп vs монадки, а не языкосрач

Ответы>>775447

20 Июн, 20:46 #366 #775434

>>775385
Ты прав, так и есть, вкусив всех прелестей ооп, я выбрал другой подход и получилось чуть лучше.

20 Июн, 21:03 #367 #775444

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

Ответы>>775447>>775468

20 Июн, 21:11 #368 #775447

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

Ответы>>775451

20 Июн, 21:20 #369 #775451

>>775447
В итоге - чтобы понять как надо было это делать с самого начала потребовалось сделать два прототипа на выброс.

Ответы>>775491

20 Июн, 21:25 #370 #775456

Alan Kay - главный зачинатель ОО-культа, сегодня отвечает на вопросы публики

https://news.ycombinator.com/item?id=11939851

20 Июн, 21:36 #371 #775468

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

Ответы>>775491

20 Июн, 22:14 #372 #775491

>>775451
А как иначе?
>>775468
>личинку лиспера, т.е. говно нации
Один лиспер = целая нация?
Да, схема - не лисп. Только синтаксис похож.

Ответы>>775535

20 Июн, 22:56 #373 #775535

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

Ответы>>775541>>775571

20 Июн, 23:07 #374 #775541

>>775535
> дизайнится, и пишется один раз - и сразу работает
такая хуита бывает только в госзаказах

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

Ответы>>775548>>775764

20 Июн, 23:12 #375 #775548

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

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

Ответы>>775550>>775553

20 Июн, 23:14 #376 #775550

>>775548
>Технические Задания, Эскизные Проекты, Рабочие Проекты, и Технические Проекты, не говоря о документации
Вся эта хуйня существует только в вотерфол мирке, который умер в нормальных странах ещё в 80е, кроме госпараши разумеется

Ответы>>775584

20 Июн, 23:16 #377 #775553

>>775548
>документации
Это присутствует в любом проекте, не важно от методологии, но это не решает описанной выше проблемы.

Ответы>>775634

20 Июн, 23:28 #378 #775571

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

20 Июн, 23:43 #379 #775584

>>775550
Какой же ты даун.
мимокрокодил

21 Июн, 00:42 #380 #775634

>>775553
Я и не говорил что документация сама по себе волшебным магическим образом решает проблемы.
Проблемы решаются головой. Ей же осмысливается опыт, выводы из опыта применяются к новым проектам - потому что решения и задачи в погромировании на 95% типовые и одни и те же. Особенно если общие их черты научиться видеть.
Голову ни одна методология, хотя бы и с самыми скрамными и солидными аджайлами, не заменяет.
Тем более что туда где аджайлы, стендапы и скрамное мракобесие, нормальный, уважающий себя человек чаще всего просто не пойдет.

Ответы>>775662>>775667

21 Июн, 01:22 #381 #775662

>>775634
Ну вот допустим я хочу написать распознавалку новой, хуёвой капчи двача.

Ответы>>775667

21 Июн, 01:25 #382 #775667

>>775634
>>775662
...
Я подозреваю, что для этого не обязательно использовать весь арсенал методов OCR и machine learning, а можно обойтись сопоставлением с маской, или какими-то другими ad hock хаками. Но я не уверен в этом.
Как мне без прототипа в голове определить возможно это или нет?

Ответы>>775668>>775676

21 Июн, 01:25 #383 #775668

>>775667
ad hoс, конечно же

21 Июн, 01:39 #384 #775676

>>775667
Ты даже задачу не можешь сформулировать.
Сколько капч тебе надо распознавать - одну в час или миллион в секунду?
Когда эта капча сменится другой - окей ли выкинуть распознавалку и начать все сначала или лучше потратить X времени сразу на нормальную?
И еще десяток подобных вопросов.
Потрать час-два времени, подумай над ними хорошенько, расставь приоритеты.
Станешь уже на 30-50% ближе к правильным решениям.

Ответы>>775687

21 Июн, 01:55 #385 #775687

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

Ответы>>775688>>775691>>775778

21 Июн, 01:56 #386 #775688

>>775687
Тредов и досок много, поэтому придётся делать несколько запросов в секунду.

21 Июн, 02:01 #387 #775691

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

Ответы>>775703

21 Июн, 03:02 #388 #775703

>>775691
Это ты не понял. Я показал конкретный пример того как так случается, что чёткой постановки задачи нет.
У меня есть только широкая формулировка большой задачи, из которой никак не вывести детали реализации. Когда нет дяди в галстуке который бы принёс на блюдечке спецификацию. Только ты один на один с дикой природой. Архитектор, ПМ и кодер в одном лице. Твоя задача сделать жизнеспособный продукт или объяснить почему это невозможно.
Ты сам должен провести инвестигейшн, выяснить какая у двача и у клаудфлейра политика бана за частые запросы и частое неправильное распознавание капчи. Проверить что лучше - использовать API или парсить треды. Если парсить треды, то какую версию - десктопную или мобильную.
А потом ещё найти где хостинг подешевле. И тут интересное ещё не заканчивается. Сканер двача это только часть проекта. Вебмки я в итоге собираюсь выкачивать и процессить, и для этого нужен достаточно мощный сервер. Есть хостинги подешевле, где в полиси запрещается использовать все ядра в режиме 24/7, а есть полноценные vds, но стоят они заметно дороже. Чтобы сказать какой сервер мне нужен (и сколько ядер на нём) мне надо знать как меняется количество вебмок на дваче в течении недели, каковы пики и средняя нагрузка, и какой среди вебмок процент повторов в долгосрочной перспективе. С этими данными я смогу сказать а по карману ли мне вообще этот проект или это всё воздушные замки.
Но вот загвоздка - чтобы собрать эти данные нужна прога, которая сканит двач и находит вебмки.
Если проект реализовать с моим бюджетом невозможно, то я хочу узнать об этом как можно раньше. Поэтому я пишу прототип, и другого варианта не вижу.
Проектирование делается после рисёрча, а его зачастую невозможно провести без прототипа.
Конечно всё проще если ты упитанный розовощёкий офисный кретин, которому начальник присылает спецификацию. Но эта простота обусловлена тем, что во-первых за тебя подумал аналитики, ПМ и тимлид, а во-вторых не исключено, что высшее руководство рассматривает весь твой проект как прототип, и если не взлетит он, то будут извлечены уроки и запилят новый.

21 Июн, 03:02 #388 #775703

>>775691
Это ты не понял. Я показал конкретный пример того как так случается, что чёткой постановки задачи нет.
У меня есть только широкая формулировка большой задачи, из которой никак не вывести детали реализации. Когда нет дяди в галстуке который бы принёс на блюдечке спецификацию. Только ты один на один с дикой природой. Архитектор, ПМ и кодер в одном лице. Твоя задача сделать жизнеспособный продукт или объяснить почему это невозможно.
Ты сам должен провести инвестигейшн, выяснить какая у двача и у клаудфлейра политика бана за частые запросы и частое неправильное распознавание капчи. Проверить что лучше - использовать API или парсить треды. Если парсить треды, то какую версию - десктопную или мобильную.
А потом ещё найти где хостинг подешевле. И тут интересное ещё не заканчивается. Сканер двача это только часть проекта. Вебмки я в итоге собираюсь выкачивать и процессить, и для этого нужен достаточно мощный сервер. Есть хостинги подешевле, где в полиси запрещается использовать все ядра в режиме 24/7, а есть полноценные vds, но стоят они заметно дороже. Чтобы сказать какой сервер мне нужен (и сколько ядер на нём) мне надо знать как меняется количество вебмок на дваче в течении недели, каковы пики и средняя нагрузка, и какой среди вебмок процент повторов в долгосрочной перспективе. С этими данными я смогу сказать а по карману ли мне вообще этот проект или это всё воздушные замки.
Но вот загвоздка - чтобы собрать эти данные нужна прога, которая сканит двач и находит вебмки.
Если проект реализовать с моим бюджетом невозможно, то я хочу узнать об этом как можно раньше. Поэтому я пишу прототип, и другого варианта не вижу.
Проектирование делается после рисёрча, а его зачастую невозможно провести без прототипа.
Конечно всё проще если ты упитанный розовощёкий офисный кретин, которому начальник присылает спецификацию. Но эта простота обусловлена тем, что во-первых за тебя подумал аналитики, ПМ и тимлид, а во-вторых не исключено, что высшее руководство рассматривает весь твой проект как прототип, и если не взлетит он, то будут извлечены уроки и запилят новый.

Показать весь текст
Ответы>>775742>>775784

21 Июн, 07:32 #389 #775742

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

21 Июн, 07:39 #390 #775743

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

21 Июн, 08:45 #391 #775764

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

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

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

Ответы>>775799

21 Июн, 09:12 #392 #775778

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

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

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

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

Ответы>>776019

21 Июн, 09:46 #393 #775784

>>775703
>Поэтому я пишу прототип, и другого варианта не вижу.
>Проектирование делается после рисёрча, а его зачастую невозможно провести без прототипа.
Это ad-hoc прототипы маленьких чстей системы, которых в процессе проектирования делается куча по полчаса на каждый.
Это НЕ версии всей системы целиком "на выброс", о которых и шла речь изначально.

22 Кб, 600x208

21 Июн, 10:09 #394 #775799

>>775764
Так аджайл-сектанты ведь на полном серьезе утверждают что заранее вообще ничего знать невозможно!
Ни какое у прибора должно быть энергопотребление, ни какой зелененький цвет. Потому что неподвластно это уму человеческому, и проектирование - тайна великая есмь, из глубины веков, забытое искусство ацтеков.
А такие вещи как анализ требований и спецификации - слова неприличные, в аджайл-манямирке не употребляемые.

http://www.markjowen.com/2014/09/01/is-agile-a-cult/

Ответы>>775813

21 Июн, 10:22 #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

21 Июн, 10:38 #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

21 Июн, 10:45 #397 #775813

>>775799
Аджайл нормален, когда ребилд всей системы не стоит ничего и занимает 10 минут. В промышленности такое бывает редко, в айти - часто, но не прямо сказать, чтобы всегда. То есть по сути когда вся разработка - это и есть проектирование, аджайл нормален.
В любом случае странно дрочить что на водопад, что на аджайл, это разные методы со своими достоинствами и недостатками.
>Логичный вывод мудрых аджайл-консультантов - давайте же сделаем всю работу постоянным авральным затыканием дыр.
Ну это капитализм - вытянуть из работника ресурсы по-максимуму, не беря при этом на себя ответственность за кривое ТЗ. При водопаде если клиент подписал этап, то все, пизда, контрактор может ссылаться на эту подпись, даже если там явно невыгодное решение, а устроить это довольно просто, ведь заказчик не может знать так много о разработке, как исполнитель.

21 Июн, 10:55 #398 #775819

>>775811
>culture of terminal juniority
Годно выразил.
На русский точно даже и не переведешь.
Страна вечного детства блджад.

Ответы>>775821>>775840

3 Кб, 236x236

21 Июн, 11:00 #399 #775821

>>775819
Полного и окончательного детства.

21 Июн, 11:46 #400 #775840

>>775811
>>775819
Вам что угодно дай - будете ныть всё равно.

Ответы>>775885

21 Июн, 12:55 #401 #775885

>>775840
Этого двачую. Программач превратился в сборище вечно ноющих идиотов, которым всё не так. Хорошо, что подобных макак не пускают к управлению.

21 Июн, 15:20 #402 #775973

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

Ответы>>775980>>775998>>776002

21 Июн, 15:24 #403 #775980

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

Ответы>>775985>>787291

21 Июн, 15:27 #404 #775985

>>775980
Объекты с множеством конструкторов и 1 функцией exec - самая лучшая абстракция, которая неплохо себя документирует. Всегда так делаю.

Ответы>>776361>>776388

21 Июн, 15:40 #405 #775998

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

21 Июн, 15:41 #406 #775999

Лучшей абстракцией является инфинити-группойд. Идите учите математику, неучи.

21 Июн, 15:43 #407 #776002

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

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

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

Ответы>>776013>>776026

21 Июн, 15:59 #408 #776013

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

>А так как других способов реализации полиморфизма в ОПП нет, то полиморфизм не нужен, заебись.
Ты че? Ебанутый? Че ты там делаешь?

21 Июн, 16:04 #409 #776019

>>775778
Лучшая абстракция - U-комбинатор.

21 Июн, 16:18 #410 #776026

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

Ответы>>776028

21 Июн, 16:20 #411 #776028

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

Ответы>>776034

21 Июн, 16:22 #412 #776032

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

21 Июн, 16:25 #413 #776034

>>776028
Ты говно с мочой путаешь. Наследование это повторное использование кода. Полиморфизм к нему никаким боком.

Ответы>>776045

21 Июн, 16:34 #414 #776045

>>776034
Тебе уже в говновики даже написали

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

Ответы>>776053

33 Кб, 460x276

21 Июн, 16:42 #415 #776052

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

Ответы>>776056

21 Июн, 16:43 #416 #776053

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

Ответы>>776062

21 Июн, 16:48 #417 #776056

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

21 Июн, 16:50 #418 #776062

>>776053
>Изначально

Тред хоть почитай в котором пишешь.
>>772766

Ответы>>776072

21 Июн, 17:06 #419 #776072

>>776062
Согласен, слово "изначально" было лишнее.
Но продолжаю настаивать, что полиморфизм через наследование - это костыль

Ответы>>776546

21 Июн, 20:51 #420 #776361

>>775985
Ты там функции эмулируешь что ли?

Ответы>>776389

21 Июн, 21:32 #421 #776388

>>775985
Нахуя метод exec, если можно перегрузить оператор вызова.

21 Июн, 21:35 #422 #776389

>>776361
Функции значительно хуже документируются.

Ответы>>776470

21 Июн, 22:54 #423 #776470

>>776389
Так глупо, что даже толсто. Поведение функций зависит только от аргументов и влияет лишь на возвращаемое значение, поэтому зачастую по одной только сигнатуре можно понять, что она делает.
Например:
head :: [a] -> a
или посложнее:
compose :: (b -> c) -> (a -> b) -> a -> c
maybe :: b -> (a -> b) -> Maybe a -> b
У объектов же есть есть ещё подводная часть айсберга - его внутреннее состояние и связи с другими объектами, у которых оно тоже есть, а это уже очень трудно поддается документированию.

Ответы>>776487>>776618>>776646

21 Июн, 23:10 #424 #776487

>>776470
>Поведение функций зависит только от аргументов и влияет лишь на возвращаемое значение
Неправильно. И объекты, и функции, могут как обладать внутренним состоянием, так и не обладать. Причем даже не обладая внутренним состоянием, они могут иметь квази-внутреннее состояние (путем возврата модифицированной копии). Здесь никакой разницы нет.
>поэтому зачастую по одной только сигнатуре можно понять, что она делает.
Ну давай, расскажи мне, что делает [Float] -> IO [Float].

22 Июн, 00:27 #425 #776546

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

А такое возможно вообще? Пример справедливый для этой части Вселенной, пожалуйста.

Ответы>>776645

22 Июн, 01:27 #426 #776572

>>771908
Ты ООП изобрел. Пишешь просто похоже на каком нибудь урезанном форке си

22 Июн, 02:03 #427 #776580

>>771908
У тебя получилась in-memory база данных без SQL.
Если у тебя язык без GC то непонятно кто будет освобождать память. Если с GC то советую для реестра объектов использовать weak references.
И вообще давай там без фанатизма, глобальные переменные ругают не зря.

22 Июн, 04:05 #428 #776614

Тред не читал. http://shaffner.us/cs/papers/tarpit.pdf уже упоминали?

22 Июн, 04:45 #429 #776618

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

Ответы>>776627

22 Июн, 06:04 #430 #776627

>>776618
> что это
Это говно, не делай так.
Haskell дал им type и newtype, но нет, не хочу давать нормальные имена типам, хочу жрать только базовые... и далее по пасте.
Я понимаю, что в мейнстриме все хуево даже с базовыми вещами вроде именования типов (хотя тайпдеф даже в сишечке есть), ну в хачкеле-то зачем продолжать жрать это говно? Там свое есть.

Ответы>>776649

22 Июн, 07:27 #431 #776645

>>776546
Как сразу и было >>772766

22 Июн, 07:29 #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"

22 Июн, 07:52 #433 #776649

>>776627
Они от этого пропадут или что? Или можно подписать "абстрактно-могадическая рекурсивная фабрика интов" чтобы было всё просто и понятно?

Ответы>>776653

22 Июн, 08:04 #434 #776653

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

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

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

Ответы>>776903

22 Июн, 08:20 #435 #776657

>>775309
Годно. В прошлый раз было 2.
Паста работает, продолжайте форс.

22 Июн, 13:39 #436 #776903

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

Ответы>>776913

22 Июн, 13:43 #437 #776913

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

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

22 Июн, 22:45 #438 #777524

Не подскажет кто программу для автоматического заполнения гугловских форм ,к примеру форма - https://docs.google.com/forms/d/1PvUaFTc4eMPUTeqa3UFnH4g9fFGyxJ07h6hp94yqweo/viewform?c=0&w=1 ,нужно чтобы вбивало постоянно 1 и те же указанные данные автоматически каждую минуту

Ответы>>777902

23 Июн, 11:55 #439 #777902

>>777524
Самому сделать не?

23 Июн, 12:17 #440 #777939

>>772633
> Я вот с ходу могу сказать, что гуйню лучше моделировать стрелками, чем объектами
Кукарекнул петух.
> а про гуй пусть лучше спецы по гуи напишут, от них то мы и узнаем
Так и автор копипасты петух, а не спец по гую. А вот спецы из Эппла выбрали именно ООП для моделирования сложного GUI на Mac OS X.

Ответы>>777984

23 Июн, 12:45 #441 #777984

>>777939
>спецы из Эппла выбрали именно ООП
Это спецы из NeXT выбрали. "Спецы" из Apple тогда пешком под стол ходили.
Выбрали неудачно, поэтому NeXT загнулся.
Но ничего другого с собой принести Жобсу не было когда опять в огрызку позвали.

Ответы>>778034

23 Июн, 13:53 #442 #778034

>>777984
Можно было с нуля разработать. В любом случае, самый крутой GUI всегда (с первого Мака) делали в Apple, а поделки борщехлебов на стрелках и монадах недалеко ушли от Tk. Полупрозрачность? Резиновая верстка? Создание своих компонент? Аппаратное ускорение и 3D эффекты? Нет, не слышали.

Ответы>>778308>>778312>>778313

23 Июн, 20:08 #443 #778308

>>778034
Самый крутой GUI сейчас вообще на вебе делают.

23 Июн, 20:11 #444 #778312

>>778034
Самый крутой гуй никакого отношения к ООП не имеет и называется FRP.

23 Июн, 20:13 #445 #778313

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

>>772766

24 Июн, 05:27 #446 #778560

Тащемта, я делал гуй на entity component systems, и получалось не хуже (а местами сильно лучше) оопепешного.

Ответы>>778566>>778981

24 Июн, 07:40 #447 #778566

>>778560
Тащем - то те полтора пользователя этого гуя блевали в сторонку от этого поделия.

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

Ответы>>778570>>779144

24 Июн, 08:03 #448 #778570

>>778566
Уёбище, научись пробелы ставить между дефисом, пол часа пытался прочитать первое предложение.

Тащем-то, ты — хуесос.

Ответы>>778770

24 Июн, 14:53 #449 #778770

>>778570
А какое отношение это имеет к тому, что ты гавно написал?

Ответы>>778996

24 Июн, 20:34 #450 #778981

>>778560
ООП в GUI все только усложняет.

24 Июн, 20:47 #451 #778996

>>778770
Я тут вообще мимо проходил, просто ты тупое уёбище портящее ощущение от чтения сосачика.

24 Июн, 20:57 #452 #779006

>>775300
Не смотрел, но полагаю 0. Учить мартыханов программировать на Хаскелле смысла не имеет, а нормальный Хаскеллист может поехать в Лондон или в Сингапур, зачем ему обязательно стоять в московских пробках по пути в бирюлёво?

24 Июн, 23:30 #453 #779144

>>778566
FRP - это норкомания, когда ты на каждый чих заводишь отдельный стрим?

Ответы>>779169

25 Июн, 00:22 #454 #779169

>>779144
>на каждый чих заводишь отдельный стрим?
Почему бы и нет? Хотя можно гораздо проще - без FRP и классического списка событий. Тупо глобальный gui.update(), который иерархически прогоняет список накопившихся событий по компонентам. То есть Form1 при вызове update прогоняет его вместе с рисовательным ресурсом через все дочерние виджеты. Нет FRP-наркомании, нет onClick ебанатства. Для простой логики можно все разруливать на уровне формы, в одной жирной функции. Для сложных виджетов делать подписку на onEvent. Что-то вроде immediate gui, но без обязательного перестроения на каждый апдейт.

Ответы>>779180

25 Июн, 00:39 #455 #779180

>>779169
Графическая оболочка Lisa делала это ещё в 1983.

Ответы>>779186

25 Июн, 00:51 #456 #779186

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

Ответы>>780960

27 Июн, 08:14 #457 #780960

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

А ну да, в 90х же твоя мамка только в первый класс пошла

Ответы>>783032

29 Июн, 07:55 #458 #782975

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

Ответы>>783022>>783217

29 Июн, 10:50 #459 #783022

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

29 Июн, 11:00 #460 #783032

>>780960
>научил бы индустрию
Нахуя мне кого-то учить? Пусть сами думают.

29 Июн, 11:07 #461 #783037

>>770268 (OP)
Модель акторов, Эрланг.
/thread

Ответы>>789186

29 Июн, 16:32 #462 #783217

>>782975
Хаотично меняющиеся стейты в тысячах объектов - это по-твоему state-монада?

Ответы>>783448

29 Июн, 20:16 #463 #783448

>>783217
Каждый объект O соответствует стейт монаде со стейтом состоящим из записи R со всеми полями объекта O.
Нестатические методы - это функции типов
method : ..args.. -> State R result

29 Июн, 20:58 #464 #783522

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

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

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

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

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

Ответы>>783564>>783565

29 Июн, 21:27 #465 #783564

>>783522
Да откуда ж вы лезете-то в таком количестве.

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

Ответы>>783596

29 Июн, 21:29 #466 #783565

>>783522
Это поэма?

29 Июн, 21:49 #467 #783596

>>783564
> философия ООП, которая превратила все картины, загораживающие дырки на обоях, в "краеугольные камни" концепции и "имманентные особенности человеческого мЫшленья"
Да похуй в каком виде это реализовать: через параметризованные модули, через какие-нибудь "контексты", через классы/объекты, через стейт монады. Главное, что это должно быть реализовано в языке, причём так, чтобы этим можно было удобно пользоваться на каждом шагу, потому что оно нужно на каждом шагу.

Ответы>>783621

29 Июн, 22:05 #468 #783621

>>783596
Что "это"?

Ответы>>783719

sage 29 Июн, 22:57 #469 #783719

>>783621
дибил

Ответы>>784934

29 Июн, 23:56 #470 #783822

>>770268 (OP)
Жиза на оп-пике

01 Июл, 05:48 #471 #784934

>>783719
Это ясно уже по первым строкам написанного и по манере общения. Анончик спрашивает, что сказать то хотел?

03 Июл, 22:36 #472 #787291

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

Ответы>>787298

03 Июл, 22:44 #473 #787297

>>770268 (OP)
Лень читать тред. Напомни, анон, есть ли у борщехлебов что-нибудь подобное божественному Qt?

Ответы>>787299>>787412

03 Июл, 22:44 #474 #787298

>>787291
С монадами, стрелками и эффектами есть куда разиваться.
http://okmij.org/ftp/Haskell/extensible/index.html

С объектами - тупик.

Ответы>>787427

03 Июл, 22:46 #475 #787299

>>787297
Есть намного лучше - https://common-lisp.net/project/mcclim/excite.html

Ответы>>787302

03 Июл, 22:47 #476 #787302

>>787299
И чем он лучше? Там хоть свои компоненты можно делать?

Ответы>>787305>>787308

03 Июл, 22:50 #477 #787305

>>787302
>можно ли делать
>Lisp
В Лиспе можно делать всё.

Ответы>>787306>>787398

03 Июл, 22:51 #478 #787306

>>787305
Только это не нужно как и он сам.

03 Июл, 22:52 #479 #787308

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

Ответы>>787379

04 Июл, 01:26 #480 #787379

>>787308
Не нужно учить весь лисп, чтобы понять, что это говно без задач.

04 Июл, 02:29 #481 #787398

>>787305
Любая достаточно сложная программа на Си или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp.
Филип Гринспен

…в том числе и сам Common Lisp.
Роберт Моррис

04 Июл, 04:15 #482 #787412

>>787297
> 2016
> потешный ком костылей на гигабайт для формочек
Напомни, анон, есть ли у байтослесарей что-нибудь подобное божественному Apache Spark?

Ответы>>787413

04 Июл, 04:45 #483 #787413

>>787412
http://aadrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html

Ответы>>787415

04 Июл, 05:00 #484 #787415

>>787413
> Hadoop
> речь про Spark
> only about 1.75GB
> сравнивает с локалхостом
> нинужна!
Лол блять, до чего же тупое животное.

Ответы>>787433

04 Июл, 06:02 #485 #787427

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

Ответы>>787429>>787453>>787693>>789125

04 Июл, 06:10 #486 #787429

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

04 Июл, 06:47 #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/

04 Июл, 08:20 #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

04 Июл, 11:00 #489 #787528

>>787453
А потом скайнет такой: >>787453 не нужен, правильно будет:
дайте мне описание задачи я сам закодирую.

04 Июл, 14:38 #490 #787693

>>787427
Был тут когда-то курс по окамлу. Для него пацаны написали автоматический проверяльщик заданий, который генерировал правильные значения на лету и сравнивал их с теми, которые выдаёт твой код. Сравнивал, конечно, через "=" (а как ещё-то?). И были в том курсе задачки с флоатами. И всё, вроде бы, нормально, потому что полученные одним и тем же путём флоаты, на одном и том же компьютере всегда будут иметь одно и то же значение. Вот только есть одна маленькая проблемка - если ты, например, сохранил число в переменную, а не подставил само выражение, то это уже другой путь. В общем, первую задачу я решил за ~15 минут, после чего ещё часа полтора пытался угадать, как они написали эталонную программу. Остальные задачи я не решил (точнее, решил, но в зачёте было 0, по понятным причинам). А теперь представь, что тебе это надо делать для каждой программы, иначе она не будет конпеляться. Ты же первый назовёшь этот язык говном и больше никогда к нему не притронешься.

05 Июл, 23:45 #491 #789125

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

06 Июл, 00:36 #492 #789186

>>783037
Такое же бесполезное говно как и ООП, кстати, и тот же хайп вокруг него. История идёт по кругу.

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

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

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.

« /pr/В начало тредаВеб-версияНастройки/a//b//mu//s//vg/Все доски

Пользуетесь скринридером — пишите, что можно улучшить.
Host-Food.ru — надёжный хостинг от 12 руб/мес | Free DNS
Зеркала М.Двача: m2ch.hk, m2ch.lib, m2chfapiswfw2wcakptqp4o6ltgchvjuxfab7urxlduraomtlnhw5xad.onion