Этого треда уже нет.
Это копия, сохраненная 26 июля 2016 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 26 июля 2016 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
151 Кб, 1948x858
Убедите меня, что ООП не полное говно без задач. С примерами, никаких "кококо куд кудах а вот у меня в голове сферическая задача в вакууме которая без ООП не решается"
Что такое ооп в твоем понимании?
>>770268 (OP)
Да, если в языке есть нормальная система типов, то ООП ни к чему.
Да, если в языке есть нормальная система типов, то ООП ни к чему.
>>770268 (OP)
Альтернатива?
Альтернатива?
> Убедите меня, что ООП не полное говно без задач.
Зачем? Оно потому и умерло, что без задач.
Ответы>>770295
>>770268 (OP)
Да, ООП говно. Достаточно посмотреть как идет развитие каких-нибудь проектов, которые писали хотя бы 5-10 лет на крестах. Там пиздец, мрак и ужас. 99% времени тратится на ковыряние в старом говнокоде из спагетти-многоэтажек. Но боюсь, что это проблема не самого ООП, а больших систем в целом. Написать говна можно и на хаскелле и на агде.
Да, ООП говно. Достаточно посмотреть как идет развитие каких-нибудь проектов, которые писали хотя бы 5-10 лет на крестах. Там пиздец, мрак и ужас. 99% времени тратится на ковыряние в старом говнокоде из спагетти-многоэтажек. Но боюсь, что это проблема не самого ООП, а больших систем в целом. Написать говна можно и на хаскелле и на агде.
Ответы>>770302
>>770292
Вините программистов.
Вините программистов.
35 Кб, 595x479
На ООП хорошо ложатся некоторые задачи, например всякие там ГУЙовины и все такое.
А вообще ООП говно, потому что только его не хватает, приходится обмазываться компонентным подходом и всем таким.
А вообще ООП говно, потому что только его не хватает, приходится обмазываться компонентным подходом и всем таким.
Ответы>>772633
>>770295
Переродилось до такой степени, что типажи в расте по сути своей ничем не отличаются от классов типов в хаскеле? В новые языки наследование или совсем не завозят, или настоятельно рекомендуют его не использовать.
Переродилось до такой степени, что типажи в расте по сути своей ничем не отличаются от классов типов в хаскеле? В новые языки наследование или совсем не завозят, или настоятельно рекомендуют его не использовать.
Ответы>>770305
>>770302
А чем типажи в пидоРасте отличаются от множественного наследования в крестах ?
А чем типажи в пидоРасте отличаются от множественного наследования в крестах ?
Ответы>>770328
>>770268 (OP)
Альтернатива
Альтернатива
>>770305
Хотя бы тем, что не имеют экземпляров и вообще не являются типами, поддерживают как параметрический полиморфизм, так и ad-hoc, не страдают алмазными проблемами, ну и так далее. Ты можешь, конечно привести какое-нибудь обмазанное шаблонами виртуальное наследование виртуальных классов, но это же не ООП, это С++.
Хотя бы тем, что не имеют экземпляров и вообще не являются типами, поддерживают как параметрический полиморфизм, так и ad-hoc, не страдают алмазными проблемами, ну и так далее. Ты можешь, конечно привести какое-нибудь обмазанное шаблонами виртуальное наследование виртуальных классов, но это же не ООП, это С++.
>>770268 (OP)
Основная беда в наследовании, которое действительно только вредит, и в излишней инкапсуляции, которая полезна, но с ООП слишком чрезмерно используется.
Основная беда в наследовании, которое действительно только вредит, и в излишней инкапсуляции, которая полезна, но с ООП слишком чрезмерно используется.
Ответы>>770394
Есть ли перевод этого поста?
http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end
http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end
Ответы>>770375
>>770268 (OP)
Альтернатива?
Альтернатива?
Доставьте боевых картинок, где унижают Джаву и ООП в пользу Си.
Ответы>>770395
>>770268 (OP)
GoF почитаешь, тогда поговорим.
GoF почитаешь, тогда поговорим.
>>770292
Таки да. Линух потому и жив, что его писали на Си. Писали бы на плюсах - утонул бы в говне и ушел бы в забвение десяток лет назад.
Таки да. Линух потому и жив, что его писали на Си. Писали бы на плюсах - утонул бы в говне и ушел бы в забвение десяток лет назад.
>>770394
В любом наследовании. Беда наследования в том, что оно пытается сущности представить в виде иерархии, что возможно только в очень редких случаях. Это понятно каждому, кто пытался отсортировать файлы на диске. Множественно наследование как раз костыль, с помощью которого от древовидной структуры пытались уйти.
>Не в наследовании а в множественном наследовании
В любом наследовании. Беда наследования в том, что оно пытается сущности представить в виде иерархии, что возможно только в очень редких случаях. Это понятно каждому, кто пытался отсортировать файлы на диске. Множественно наследование как раз костыль, с помощью которого от древовидной структуры пытались уйти.
>>770420
А kobjects (kernel objects) там сдуру существуют? Си-не Си, а где ООП было нужно, там оно естественно появилось.
А kobjects (kernel objects) там сдуру существуют? Си-не Си, а где ООП было нужно, там оно естественно появилось.
Ответы>>770479
>>770472
Достаточно стоить код так, чтобы его части легко друг с другом соединялись. Благо, современные языки предоставляют множество возможностей для этого.
Достаточно стоить код так, чтобы его части легко друг с другом соединялись. Благо, современные языки предоставляют множество возможностей для этого.
Ответы>>770483
>>770472
Ампутируй органы наследования.
Ампутируй органы наследования.
>>770480
Проблема в том, что они легко соединяются только в момент написания. А через полгода, например, уже далеко не легко.
>чтобы его части легко друг с другом соединялись
Проблема в том, что они легко соединяются только в момент написания. А через полгода, например, уже далеко не легко.
Ответы>>770494
>>770484
Просто полиморфизм. Без ООП.
Просто полиморфизм. Без ООП.
>>770483
Ну, допилить до состыковки проще, чем перепиливать иерархию наследования. Особенно, если предусмотрена какая-либо гибкость.
Впрочем, твой вопрос формулируется проще: «как строить архитектуру приложения так, чтобы через полгода не пришлось всё выкинуть и начать заново?».
Ну, допилить до состыковки проще, чем перепиливать иерархию наследования. Особенно, если предусмотрена какая-либо гибкость.
Впрочем, твой вопрос формулируется проще: «как строить архитектуру приложения так, чтобы через полгода не пришлось всё выкинуть и начать заново?».
>>770268 (OP)
Всевозможные симуляторы, включая компьютерные игры, неплохо реализуются с использованием ООП. Тот же NS-3 без ООП сложно представить. NS-2 был говнищем ебаным.
Всевозможные симуляторы, включая компьютерные игры, неплохо реализуются с использованием ООП. Тот же NS-3 без ООП сложно представить. NS-2 был говнищем ебаным.
ООП - полное говно, что тут обсуждать?
Чаще всего используется для костыльной эмуляции простейшего полиморфизма, потому что в типичном ОО-языке никаких других средств для этого не предусмотрено.
С модульностью то же самое.
Чаще всего используется для костыльной эмуляции простейшего полиморфизма, потому что в типичном ОО-языке никаких других средств для этого не предусмотрено.
С модульностью то же самое.
Ответы>>770565
>>770565
На том что лучшим образом подходит для задачи, с учетом целевых приоритетов и ограничений.
На том что лучшим образом подходит для задачи, с учетом целевых приоритетов и ограничений.
>>770573
Иногда на Лиспе.
На нем очень удобно быстро закостылить прототип какой-то подсистемы, которую непонятно как лучше всего делать. Потом иногда можно переписать на чем-то другом, в зависимости от задачи, иногда можно и так оставить.
Иногда на Лиспе.
На нем очень удобно быстро закостылить прототип какой-то подсистемы, которую непонятно как лучше всего делать. Потом иногда можно переписать на чем-то другом, в зависимости от задачи, иногда можно и так оставить.
>>770268 (OP)
Очередной борщехлеб, изучивший на мамкиной шее математику, возмущается тому, что программируют не такие элитные люди как он, и им почему то хватает полутора абстракций, которые у борщехлеба, в отличие от нормальных людей, почему-то не укладываются в голове и на работу его соответственно не берут. Все что борщехлеб не в состоянии освоить объявляется им ООП, а те кто не берут его на работу - тупыми взрослыми
Очередной борщехлеб, изучивший на мамкиной шее математику, возмущается тому, что программируют не такие элитные люди как он, и им почему то хватает полутора абстракций, которые у борщехлеба, в отличие от нормальных людей, почему-то не укладываются в голове и на работу его соответственно не берут. Все что борщехлеб не в состоянии освоить объявляется им ООП, а те кто не берут его на работу - тупыми взрослыми
Ответы>>770588
>>770613
https://wiki.theory.org/YourLanguageSucks#Ruby_sucks_because
Хочешь увидеть нормальную реализацию ООП в динамических языках - смотри на CLOS.
https://wiki.theory.org/YourLanguageSucks#Ruby_sucks_because
Хочешь увидеть нормальную реализацию ООП в динамических языках - смотри на CLOS.
Ответы>>770635
67 Кб, 603x407
>>770468
А кто сказал, что должна быть древовидная иерархия?
У меня наследование используется только, если мне надо получить набстройку над определенным типом.
А кто сказал, что должна быть древовидная иерархия?
У меня наследование используется только, если мне надо получить набстройку над определенным типом.
Ответы>>770660
Четыре слова: инкапсуляция, полиморфизм, абстракция, наследование.
Если тебе, оп, так не нравится то, на чём ты кодишь - у тебя всегда есть ассемблер или вообще прямые машинные коды.
Берёшь и пилишь свой язык таким, какой ты его видишь. Что ещё нужно?
Если тебе, оп, так не нравится то, на чём ты кодишь - у тебя всегда есть ассемблер или вообще прямые машинные коды.
Берёшь и пилишь свой язык таким, какой ты его видишь. Что ещё нужно?
>>770631
Лол студентота(или ты уже джун?), ты такая няшная)))
>считает ассемблер единственной альтернативой ООП-раши
>костылюция, костылеморфизм, костыляция, костылирование
Лол студентота(или ты уже джун?), ты такая няшная)))
>>770620
Его кто-то использует? Хотя это же скобкомирок, всегда умиляли скобкоёбы которые пишут все тот же грязный, сайдэффектный имеративный код, но только со смайликами, и считает себя илитой.
>CLOS
Его кто-то использует? Хотя это же скобкомирок, всегда умиляли скобкоёбы которые пишут все тот же грязный, сайдэффектный имеративный код, но только со смайликами, и считает себя илитой.
>>770631
Один из столпов ООП ты забыл, еще один (наследование) - это только инструмент для реализации в ООП другого - полиморфизма.
Один из столпов ООП ты забыл, еще один (наследование) - это только инструмент для реализации в ООП другого - полиморфизма.
>Берёшь и пилишь свой язык
>Не слышал ни об одном языке, который не использует кривых ООП-костылей кроме ассемблера.
>>770633
Не считаю. Говорю же, пусть берёт машинные коды и пилит то, что считакт нужным.
Ассемблер привёл лишь как ближайший к машинному коду, который сейчас знаю.
Велосипеды.
Не считаю. Говорю же, пусть берёт машинные коды и пилит то, что считакт нужным.
Ассемблер привёл лишь как ближайший к машинному коду, который сейчас знаю.
> костыли
Велосипеды.
>>770626
No true Scottsman fallacy.
No true Scottsman fallacy.
>>770496
ААА практически на чистой сишке пишутся, без использования крестовых фич.
>неплохо реализуются с использованием ООП
ААА практически на чистой сишке пишутся, без использования крестовых фич.
>>770268 (OP)
Зачем тебя убеждать в ложном утверждении?
Eiffel - самая каноничъная реализация ООП на сегодняшний день. И смотри, что из этого вышло: http://lavironsoftware.blogspot.ru/2012/04/eiffel-studio-review.html .
Зачем тебя убеждать в ложном утверждении?
Eiffel - самая каноничъная реализация ООП на сегодняшний день. И смотри, что из этого вышло: http://lavironsoftware.blogspot.ru/2012/04/eiffel-studio-review.html .
>>770496
В играх вроде в основном компонентный подход, а не "чистое" ооп.
В играх вроде в основном компонентный подход, а не "чистое" ооп.
>>770673
https://youtu.be/rX0ItVEVjHc?t=1h23m48s
Из плюсов исползуют очень мало фич, на самом деле. Очень простой код, мало абстракций, соответственно, под каждую игру много перелопачивается. Если ты не пишешь жирное middleware вроде UE4, конечно. Там раздолье абстракций.
Весь рендер на видюхе сейчас. На ЦПУ только шедулер, который в комманд буфер шейдеры складывает, а в шейдерах никаких перегрузок операторов делать не надо, там для векторов все встроено.
>Ебать манямирок
https://youtu.be/rX0ItVEVjHc?t=1h23m48s
Из плюсов исползуют очень мало фич, на самом деле. Очень простой код, мало абстракций, соответственно, под каждую игру много перелопачивается. Если ты не пишешь жирное middleware вроде UE4, конечно. Там раздолье абстракций.
>даже рендер (самая нагруженная часть) без перегрузки операторов и прочего – боль
Весь рендер на видюхе сейчас. На ЦПУ только шедулер, который в комманд буфер шейдеры складывает, а в шейдерах никаких перегрузок операторов делать не надо, там для векторов все встроено.
7 Кб, 980x515
6 Кб, 979x513
>>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, точных цифр особо не помню). Почему так?
>даже рендер (самая нагруженная часть) без перегрузки операторов и прочего – боль
А нахуя вообще там перегрузка операторов? Кто-то умножает источники света на анимированные модели? Зачем?
>>770727
>Очень простой код, мало абстракций
Хм, подожди-ка.
Движок может поддерживать, например, рендер в D39, D3D11 и OGL. Как это реализовать без абстракций? Написание всяких конструкций вида if(m_mode = MODE_D3D11) убивает на корню всю оптимизацию, ибо будут происходить регулярные ошибки branch predictor'а. А когда есть какой-нибудь AbstractRenderer, от которого наследуется 3 разных класса, то всё идеально. С виртуальными функциями проблем не будет - т.к. функции разных рендереров не перемешаны, а разбиты по файлам, то промахов кэша происходить не будет.
Далее, в движке могут быть разные классы объектов. Но у большинства из них есть общие свойства - скажем, и модель какого-нибудь ОБЧР, и какой-нибудь точечный источник света рисуются одинаково, только с разными настройками и разными шейдерами. При этом, скажем, и тот, и другой объект могут быть анимированы и обновлять своё состояние через какую-нибудь функцию Update. И опять же, как это реализовывать без абстраций?
------------------------------------------------------
К слову, я заметил один интересный эффект, связанный с виртуальными функциями. Как известно, можно сделать абстрактный полиморфизм без них - просто подставляя при создании класса правильный указатель на функцию.
Вот код: http://pastebin.com/cZ0YymnV
Так вот, эффект в том, что в Debug-сборке виртуальная версия значительно медленнее, но в Release-сборке она несколько быстрее(тестировал на i7-6700K). К слову, на стареньком i5-760 виртуальная версия почему-то всегда быстрее( примерно 45с против 80с в debug и 3.0с против 3.2с в release, точных цифр особо не помню). Почему так?
>>770765
Те же яйца, только в профиль
Unconditional branch, fixed target
Infinite loop
goto statement
break or continue statement
End of the 'then' clause of an if/else statement (to jump past the else clause)
Non-virtual function call
Unconditional branch, variable target
Returning from a function
Virtual function call
Function pointer call
switch statement (if compiled into a jump table)
Conditional branch, fixed target
if statement
switch statement (if compiled into a series of if/else statements)
Loop condition tests
The && and || operators
The ternary ?: operator
Conditional branch, variable target
Less likely to show up under normal conditions, but the compiler may synthesize one as an optimization, combining two of the above cases. For example, on x86, the compiler may optimize code like if (condition) { obj->VirtualFunctionCall(); } into a conditional indirect jump like jne *%eax if it appears at the end of a function due to tail call optimization.
> Написание всяких конструкций вида if(m_mode = MODE_D3D11) убивает на корню всю оптимизацию, ибо будут происходить регулярные ошибки branch predictor'а. А когда есть какой-нибудь AbstractRenderer, от которого наследуется 3 разных класса, то всё идеально. С виртуальными функциями проблем не будет
Те же яйца, только в профиль
Unconditional branch, fixed target
Infinite loop
goto statement
break or continue statement
End of the 'then' clause of an if/else statement (to jump past the else clause)
Non-virtual function call
Unconditional branch, variable target
Returning from a function
Virtual function call
Function pointer call
switch statement (if compiled into a jump table)
Conditional branch, fixed target
if statement
switch statement (if compiled into a series of if/else statements)
Loop condition tests
The && and || operators
The ternary ?: operator
Conditional branch, variable target
Less likely to show up under normal conditions, but the compiler may synthesize one as an optimization, combining two of the above cases. For example, on x86, the compiler may optimize code like if (condition) { obj->VirtualFunctionCall(); } into a conditional indirect jump like jne *%eax if it appears at the end of a function due to tail call optimization.
>>770765
Те же яйца, только в профиль
Unconditional branch, fixed target
Infinite loop
goto statement
break or continue statement
End of the 'then' clause of an if/else statement (to jump past the else clause)
Non-virtual function call
Unconditional branch, variable target
Returning from a function
Virtual function call
Function pointer call
switch statement (if compiled into a jump table)
Conditional branch, fixed target
if statement
switch statement (if compiled into a series of if/else statements)
Loop condition tests
The && and || operators
The ternary ?: operator
Conditional branch, variable target
Less likely to show up under normal conditions, but the compiler may synthesize one as an optimization, combining two of the above cases. For example, on x86, the compiler may optimize code like if (condition) { obj->VirtualFunctionCall(); } into a conditional indirect jump like jne *%eax if it appears at the end of a function due to tail call optimization.
> Написание всяких конструкций вида if(m_mode = MODE_D3D11) убивает на корню всю оптимизацию, ибо будут происходить регулярные ошибки branch predictor'а. А когда есть какой-нибудь AbstractRenderer, от которого наследуется 3 разных класса, то всё идеально. С виртуальными функциями проблем не будет
Те же яйца, только в профиль
Unconditional branch, fixed target
Infinite loop
goto statement
break or continue statement
End of the 'then' clause of an if/else statement (to jump past the else clause)
Non-virtual function call
Unconditional branch, variable target
Returning from a function
Virtual function call
Function pointer call
switch statement (if compiled into a jump table)
Conditional branch, fixed target
if statement
switch statement (if compiled into a series of if/else statements)
Loop condition tests
The && and || operators
The ternary ?: operator
Conditional branch, variable target
Less likely to show up under normal conditions, but the compiler may synthesize one as an optimization, combining two of the above cases. For example, on x86, the compiler may optimize code like if (condition) { obj->VirtualFunctionCall(); } into a conditional indirect jump like jne *%eax if it appears at the end of a function due to tail call optimization.
Ответы>>770785
>>770268 (OP)
Игровой 3D движок. Хуй ты его без ООП напишешь.
Игровой 3D движок. Хуй ты его без ООП напишешь.
Ответы>>770787
>>770765
Там DoD во все поля. Организация данных примерно как в БД (с нарушением нормализации, где производительность требует). То есть объект "робот" размазан по куче таблиц - скелеты, анимации, материалы с прозрачностью, без, и т.д. При рендере/апдейте, соответственно, ты не работаешь с абстрактными объектами через виртуальные функции, а прогоняешь таблицы через функции - отфильтровать сферические коллайдеры из таблицы со сферами, заполнив таблицу для более точно коллижена, например.
>И опять же, как это реализовывать без абстраций?
Там DoD во все поля. Организация данных примерно как в БД (с нарушением нормализации, где производительность требует). То есть объект "робот" размазан по куче таблиц - скелеты, анимации, материалы с прозрачностью, без, и т.д. При рендере/апдейте, соответственно, ты не работаешь с абстрактными объектами через виртуальные функции, а прогоняешь таблицы через функции - отфильтровать сферические коллайдеры из таблицы со сферами, заполнив таблицу для более точно коллижена, например.
>>770772
Суть-то как раз в том, что в первом случае не нужен branch predictor(в ассемблере преобразовывается в конструкцию вида call dword ptr[0xbabe], а по указателю уже подставляется адрес нужной функции). Во втором уже не обойтись без него.
В итоге в первом случае оверхед - просто дополнительный переход по адресу. При хорошем кэше это вообще ни на что не влияет. Во втором случае - вероятность ошибки предсказателя. А это остановка конвейера и всё, пиздец. Тактов 7-8 очень легко потерять. Если это будет вызываться в цикле, то оверхед будет очень заметен.
>Unconditional branch, variable target
>Conditional branch, fixed target
Суть-то как раз в том, что в первом случае не нужен branch predictor(в ассемблере преобразовывается в конструкцию вида call dword ptr[0xbabe], а по указателю уже подставляется адрес нужной функции). Во втором уже не обойтись без него.
В итоге в первом случае оверхед - просто дополнительный переход по адресу. При хорошем кэше это вообще ни на что не влияет. Во втором случае - вероятность ошибки предсказателя. А это остановка конвейера и всё, пиздец. Тактов 7-8 очень легко потерять. Если это будет вызываться в цикле, то оверхед будет очень заметен.
>>770782
Не знать о существовании иных техник для управления сложностью кроме кривых костылей ООП в 2016 году.
Не знать о существовании иных техник для управления сложностью кроме кривых костылей ООП в 2016 году.
Ответы>>770796
>>770785
Ты знаешь о существовании branch prediction, но не знаешь о branch target prediction, почему так? Дочитываешь до середины, потом засыпаешь?
Ты знаешь о существовании branch prediction, но не знаешь о branch target prediction, почему так? Дочитываешь до середины, потом засыпаешь?
Ответы>>770805
>>770727
А ты что ожидаешь? Что проект на плюсах обязательно вымазан наследованием в 800 предков, с шаблонной магией и виртуальной хуитой?
>плюсов исползуют очень мало фич
А ты что ожидаешь? Что проект на плюсах обязательно вымазан наследованием в 800 предков, с шаблонной магией и виртуальной хуитой?
>>770468
Можно вообще обойтись без наследования (в Visual Basic 6 его не было, например). Любое наследование легко заменяется композицией объектов. Основа ООП (по Алану Кэю) - объекты и сообщения, которые они отправляют друг другу и обрабатывают. А "три принципа" придумал Страуструп, и они довольно сомнительны (инкапсуляция есть в любом языке с заданием области видимости вплоть до ассемблера, а для полиморфизма достаточно разрешить overload для функций).
Можно вообще обойтись без наследования (в Visual Basic 6 его не было, например). Любое наследование легко заменяется композицией объектов. Основа ООП (по Алану Кэю) - объекты и сообщения, которые они отправляют друг другу и обрабатывают. А "три принципа" придумал Страуструп, и они довольно сомнительны (инкапсуляция есть в любом языке с заданием области видимости вплоть до ассемблера, а для полиморфизма достаточно разрешить overload для функций).
Ответы>>773900
>>770787
Ну и где процедурные/функциональные движки с йоба графоном? Вот Кармак скажем долго выебывался, а однако Doom 3 пришлось ему писать на крестах.
Ну и где процедурные/функциональные движки с йоба графоном? Вот Кармак скажем долго выебывался, а однако Doom 3 пришлось ему писать на крестах.
>>770788
Просто обо всём этом я где-то полтора года назад узнал из книжки Game Engine Architecture, где всякие промахи кэша и предсказатели переходов были рассмотрены довольно поверхностно.
Просто обо всём этом я где-то полтора года назад узнал из книжки Game Engine Architecture, где всякие промахи кэша и предсказатели переходов были рассмотрены довольно поверхностно.
>>770796
Криворукие игроделы ничего кроме сишечки не знают, щито поделать
Криворукие игроделы ничего кроме сишечки не знают, щито поделать
>>770796
Почти везде в ААА. Сишечка в функциональном стиле - чистые функции, иммьютебл стейт все дела.Кармак почти в каждом выступлении последнее время рассказывает про прелести функционального программирования.
>Ну и где процедурные/функциональные движки с йоба графоном?
Почти везде в ААА. Сишечка в функциональном стиле - чистые функции, иммьютебл стейт все дела.Кармак почти в каждом выступлении последнее время рассказывает про прелести функционального программирования.
>>770796
Уважающий себя борщехлеб не будет марать руки об игори, очевидно же. Игори для детей.
>функциональные
Уважающий себя борщехлеб не будет марать руки об игори, очевидно же. Игори для детей.
Ответы>>771026
>>770814
Кармак пиздит дохуя, еблоторговец раскрученный, сам ничего оосбенного за всю карьеру не написав.
Функциональный стиль и мьютабл-иммьютабл друг другу ортогональны, и immutable быстрым не будет никогда. Даже упоротые хаскелеры когда им надо БЫСТРО, берутся за IORef, STRef и MVar, ловко выкручиваясь тем что mutable references на immutable values это ВНЕЗАПНО не mutable variables.
Кармак пиздит дохуя, еблоторговец раскрученный, сам ничего оосбенного за всю карьеру не написав.
Функциональный стиль и мьютабл-иммьютабл друг другу ортогональны, и immutable быстрым не будет никогда. Даже упоротые хаскелеры когда им надо БЫСТРО, берутся за IORef, STRef и MVar, ловко выкручиваясь тем что mutable references на immutable values это ВНЕЗАПНО не mutable variables.
>>770840
Например, пересоздавать на каждом кадре стейт игры заново, гораздо быстрее и проще, чем апдейтить мутабельный стейт.
>и immutable быстрым не будет никогда
Например, пересоздавать на каждом кадре стейт игры заново, гораздо быстрее и проще, чем апдейтить мутабельный стейт.
>>770843
Дельты же хранить можно. При сете создается дельта которая держит ссылку на предыдущую версию.
> пересоздавать на каждом кадре стейт игры заново
Дельты же хранить можно. При сете создается дельта которая держит ссылку на предыдущую версию.
Ответы>>770850
>>770844
Нафига? Весь стейт - несколько мегабайт, максимум. Хранишь два-три кадра, при создании нового кадра копируешь предыдущий с обновлением.
Нафига? Весь стейт - несколько мегабайт, максимум. Хранишь два-три кадра, при создании нового кадра копируешь предыдущий с обновлением.
>>770840
>>770814
Блядь! Я только что осознал! Рендеринг - это НА 100% функциональный стиль. Пиздеееец, я столько времени его использовал и даже не думал об этом.
Смотрите сами:
Шейдер - чистая функция. Если подать туда одинаковые буферы, одинаковые константы и одинаковые текстурвы, то и результат будет одинаков.
Более того! Всякие SetVertexShader - это функции высшего порядка.
ВСЕ объекты для контроля рендеринга - различные ID3D11RasterizerState иммутабельны.
В случае с D3D12 всё ещё круче - практически ВСЕ настройки, включающие в себя шейдеры, режим отрисовки, тип топологии примитивов и т.д., ВСЁ ЭТО упаковано в иммутабельный ID3D12PipelineState. При рендериге просто вызывается функция SetPipelineState для контроля этого! И она чистая!
Охуеть. В рендеринге СТОЛЬКО функциональщины. Я даже не знаю теперь, как к этому относиться.
>>770814
Блядь! Я только что осознал! Рендеринг - это НА 100% функциональный стиль. Пиздеееец, я столько времени его использовал и даже не думал об этом.
Смотрите сами:
Шейдер - чистая функция. Если подать туда одинаковые буферы, одинаковые константы и одинаковые текстурвы, то и результат будет одинаков.
Более того! Всякие SetVertexShader - это функции высшего порядка.
ВСЕ объекты для контроля рендеринга - различные ID3D11RasterizerState иммутабельны.
В случае с D3D12 всё ещё круче - практически ВСЕ настройки, включающие в себя шейдеры, режим отрисовки, тип топологии примитивов и т.д., ВСЁ ЭТО упаковано в иммутабельный ID3D12PipelineState. При рендериге просто вызывается функция SetPipelineState для контроля этого! И она чистая!
Охуеть. В рендеринге СТОЛЬКО функциональщины. Я даже не знаю теперь, как к этому относиться.
>>770851
Охуеть открытие. Рендеринг функциональный, потому что GPU суперпараллельный, это любому должно быть очевидно.
Охуеть открытие. Рендеринг функциональный, потому что GPU суперпараллельный, это любому должно быть очевидно.
>>770814
Примеры? Ну кроме недописанного шутера на хаскеле (да и тот по графону ближе к Quake 2). Кармак пиздеть может что угодно, вот когда очередной id Tech будет не на крестах, я ему поверю.
>>770851
Там не только шейдеры. Игровой движок это целая ОС в миниатюре. Грамотно построить архитектуру, и чтобы еще быстро работало, можно только на ООП (C++, Delphi, D или тому подобном) .
> Почти везде в ААА.
Примеры? Ну кроме недописанного шутера на хаскеле (да и тот по графону ближе к Quake 2). Кармак пиздеть может что угодно, вот когда очередной id Tech будет не на крестах, я ему поверю.
>>770851
Там не только шейдеры. Игровой движок это целая ОС в миниатюре. Грамотно построить архитектуру, и чтобы еще быстро работало, можно только на ООП (C++, Delphi, D или тому подобном) .
>>770816
Дык, ясное дело, что Кармаки и Ньюэллы они инфантилы, вот сидящий на шее у мамки борщехлеб совсем другое дело.
> Игори для детей.
Дык, ясное дело, что Кармаки и Ньюэллы они инфантилы, вот сидящий на шее у мамки борщехлеб совсем другое дело.
>>771023
Нет.
Но утверждение "грамотно построить архитектуру, и чтоб еще быстро работало, и чтоб еще обязательно на С++, который только и знают криворукие игроделы, и сделать это все с помощью криворуких игроделов, которые не могут ни во что кроме ООП, можно только с помощью ООП"
>Грамотно построить архитектуру, и чтобы еще быстро работало, можно только на ООП
Нет.
Но утверждение "грамотно построить архитектуру, и чтоб еще быстро работало, и чтоб еще обязательно на С++, который только и знают криворукие игроделы, и сделать это все с помощью криворуких игроделов, которые не могут ни во что кроме ООП, можно только с помощью ООП"
>>771027
*будет правдой.
*будет правдой.
>>771032
Я и говорю.
> и чтоб еще обязательно на С++, который только и знают криворукие игроделы, и сделать это все с помощью криворуких игроделов, которые не могут ни во что кроме ООП
Я и говорю.
Ответы>>771049
>>771036
Так криворукие игроделы хоть делают и выпускают рабочий продукт, в отличие от мамкиных борщехлёбов, визжащих о превосходстве фп.
Так криворукие игроделы хоть делают и выпускают рабочий продукт, в отличие от мамкиных борщехлёбов, визжащих о превосходстве фп.
Ответы>>771052
>>771051
Как на сисечке можно сделать функции высшего порядка? Путем черной магии в виде исполнения ссылки на фунцкию?
>на сишечке в функциональном стиле
Как на сисечке можно сделать функции высшего порядка? Путем черной магии в виде исполнения ссылки на фунцкию?
>>771032
UT, CryEngine - middleware, движок с редакторами. Остальное, считай, легаси из 90-х, написанное писишными программистами, которые консоль и голое железо в глаза не видели. К тому же там не сказано, в каком стиле у них С++.
UT, CryEngine - middleware, движок с редакторами. Остальное, считай, легаси из 90-х, написанное писишными программистами, которые консоль и голое железо в глаза не видели. К тому же там не сказано, в каком стиле у них С++.
>>771052
Под "функциональным стилем" имелись ввиду чистые функции и в основном иммьютабл стейт, отстутствие ООП.
Под "функциональным стилем" имелись ввиду чистые функции и в основном иммьютабл стейт, отстутствие ООП.
Ответы>>771056
>>771055
Больше на процедурность с иммутабильностью смахивает. Какое же это ФП без функций высшего порядка.
Больше на процедурность с иммутабильностью смахивает. Какое же это ФП без функций высшего порядка.
Ответы>>771059
>>771049
Делает и выпускает много чего много кто.
В игродельной индустрии - там же замкнутый порочный круг. Берут только бородатых сишечников, потому что ну епта у нас же все на сишечке, они в свою очередь нихера кроме сишечки и ООП не знают и знать не хотят.
В других индустриях ФП успешно используется, в том числе и там где высоки требования к производительности, в том числе и с использованием языков Си и С++.
Делает и выпускает много чего много кто.
В игродельной индустрии - там же замкнутый порочный круг. Берут только бородатых сишечников, потому что ну епта у нас же все на сишечке, они в свою очередь нихера кроме сишечки и ООП не знают и знать не хотят.
В других индустриях ФП успешно используется, в том числе и там где высоки требования к производительности, в том числе и с использованием языков Си и С++.
Ответы>>771063
>>771059
SQL это декларативное функциональное программирование, чего тут удивительного.
SQL это декларативное функциональное программирование, чего тут удивительного.
Ответы>>771074
>>771061
Например?
>В других индустриях ФП успешно используется, в том числе и там где высоки требования к производительности,
Например?
>>771062
Ну я и говорю, что не все ФП выглядит как хаскел. Функциональные практики in the wild ближе к SQL чем к ML.
Ну я и говорю, что не все ФП выглядит как хаскел. Функциональные практики in the wild ближе к SQL чем к ML.
>>771068
На самом деле нет. У тебя по ссылке откровенное наглое вранье. Вот разоблачение:
http://flyingfrogblog.blogspot.ru/2010/05/why-is-haskell-used-so-little-in.html
На самом деле нет. У тебя по ссылке откровенное наглое вранье. Вот разоблачение:
http://flyingfrogblog.blogspot.ru/2010/05/why-is-haskell-used-so-little-in.html
>>771068
Куча нонеймов и фейсбук, интел и с ан анд т и пр. где на всю корпорацию 1 внутренняя утилита на хаскелле, ахуеть теперь.
Конкретные примеры давай. Риалтайм рендер уровня source 2 хотя бы.
Куча нонеймов и фейсбук, интел и с ан анд т и пр. где на всю корпорацию 1 внутренняя утилита на хаскелле, ахуеть теперь.
Конкретные примеры давай. Риалтайм рендер уровня source 2 хотя бы.
Ответы>>771100
>>771087
И там тоже пишут основную часть на питоне/р, а все числодробилки на сях, хотя перформанс в этой области никому не всрался.
И там тоже пишут основную часть на питоне/р, а все числодробилки на сях, хотя перформанс в этой области никому не всрался.
Ответы>>771106
>>771078
Ну охуеть можно. ABN Amro ему нонейм. Alcatel-Lucent ему нонейм. Bank of America Merril Lynch ему нонейм.
Это я еще до буквы B не дошел.
А контора из пяти бородатых сишечников, кидающих треугольнички в GPU - доооо, это сирьооозная ендустрия.
>>771076
Я сразу говорил что речь не про Haskell, а про ФП. В перечисленных лавках, и во многих других, часто пишут на разных языках, в том числе и на Си и на С++. Но вот набирают туда людей прицельно со знанием Хаскеля. Потому что они умеют в ФП, что и нужно. А в ООП и так любая макака умеет, хрена ли там уметь. И человек умеющий в ФП, напишет и на С++ приличный ФП код, когда надо на С++.
А вот наборот получается хуево. Поэтому и слышно со стороны криворуких игроделов только нинууужна
Ну охуеть можно. ABN Amro ему нонейм. Alcatel-Lucent ему нонейм. Bank of America Merril Lynch ему нонейм.
Это я еще до буквы B не дошел.
А контора из пяти бородатых сишечников, кидающих треугольнички в GPU - доооо, это сирьооозная ендустрия.
>>771076
Я сразу говорил что речь не про Haskell, а про ФП. В перечисленных лавках, и во многих других, часто пишут на разных языках, в том числе и на Си и на С++. Но вот набирают туда людей прицельно со знанием Хаскеля. Потому что они умеют в ФП, что и нужно. А в ООП и так любая макака умеет, хрена ли там уметь. И человек умеющий в ФП, напишет и на С++ приличный ФП код, когда надо на С++.
А вот наборот получается хуево. Поэтому и слышно со стороны криворуких игроделов только нинууужна
>>771099
На питоне/р прототипируют алгоритмы, а в продакшене вся инфрастрктура на JVM.
На питоне/р прототипируют алгоритмы, а в продакшене вся инфрастрктура на JVM.
>>771100
Человек умеющий в фп скорее нагреет процессор.
А бородатые сишники тем не менее написали явно поболее пары внутренних утилит. не знаю на счёт самого компилятора, на рантайм у хачкеля, ВНЕЗАПНО БЛЯДЬ, сишный
Человек умеющий в фп скорее нагреет процессор.
А бородатые сишники тем не менее написали явно поболее пары внутренних утилит. не знаю на счёт самого компилятора, на рантайм у хачкеля, ВНЕЗАПНО БЛЯДЬ, сишный
Ответы>>771123
>>771106
Ты похоже не в курсе что за означает "бигдата". Это не хуйлоад, сам ознакомься с значением термина.
Ты похоже не в курсе что за означает "бигдата". Это не хуйлоад, сам ознакомься с значением термина.
>>771115
Ну так а чего на рантайме останавливаться, давай до внутренностей процессоров и порчих железок дойдем, в которые криворукие игроделы с охуенно важным видом кидают треугольнички. А там ВНЕЗАПНО, из того самого списка
Но это все хуйня, конечно, треугольнички потом внутрь этого всего кидать - задача важнее. Это тебе любой таджик с лопатой объяснит что каток, грейдер и асфальтоукладчик сделать - это чепуха, главное лопатой щебень для них раскидывать.
Ну так а чего на рантайме останавливаться, давай до внутренностей процессоров и порчих железок дойдем, в которые криворукие игроделы с охуенно важным видом кидают треугольнички. А там ВНЕЗАПНО, из того самого списка
> Bluespec, Inc. Waltham, Massachusetts
> Developing a modern integrated circuit (ASIC or FPGA) is an enormously expensive process involving specification, modeling (to choose and fix the architecture), design (to describe what will become silicon) and verification (to ensure that it meets the specs), all before actually committing anything to silicon (where the cost of a failure can be tens of millions of dollars). Bluespec, Inc. is a three year-old company that provides language facilities, methodologies, and tools for this purpose, within the framework of the IEEE standard languages SystemVerilog and SystemC, but borrowing ideas heavily from Term Rewriting Systems and functional programming languages like Haskell. In this talk, after a brief technical overview to set the context, we will describe our tactics and strategies, and the challenges we face, in introducing declarative programming ideas into this field, both externally (convincing customers about the value of these ideas) and internally (using Haskell for our tool implementation).
Но это все хуйня, конечно, треугольнички потом внутрь этого всего кидать - задача важнее. Это тебе любой таджик с лопатой объяснит что каток, грейдер и асфальтоукладчик сделать - это чепуха, главное лопатой щебень для них раскидывать.
Ответы>>771162
>>771100
Прицельно набирают спецов с нужным опытом. Хаскелиты без знания предметной области никому не всрались.
Очень спорно. ФП в основном в академиях используется, а академический год обычно не очень хорош.
Потому что никому не нужно
>Но вот набирают туда людей прицельно со знанием Хаскеля
Прицельно набирают спецов с нужным опытом. Хаскелиты без знания предметной области никому не всрались.
>человек умеющий в ФП, напишет и на С++ приличный ФП код
Очень спорно. ФП в основном в академиях используется, а академический год обычно не очень хорош.
>А вот наборот получается хуево
Потому что никому не нужно
Ответы>>771162
>>771123
>After a bit of digging, I was horrified to discover that almost all of the "success stories" listed on the Haskell in Industry page were fakes. Anygma may ship a product in the future but do not intend to write it in Haskell. Ansemond had a product and are actually a real software company but (according to their blog) there was "no Haskell" in their product. Antiope didn't list any products at all, let alone ones written in Haskell. Bluespec were advertising their product but their customer testimonials were from "Elvis Lives", "Chicken Man", "Painful Eliminations", "Mr. Bigglesworth" and two people from the founders' University. The prominent member of the Haskell community from Credit Suisse told us that his employer was seriously invested in Haskell with over a hundred developers and that he was personally responsible for much of their Haskell development but this turned out to be another deception: Credit Suisse have over a hundred developers using other languages, he had been a large proportion of a tiny number of Haskell developers and Haskell never caught on at Credit Suisse (they are now merely maintaining legacy Haskell code).
>>771152
Компания ПРОДАЕТ тулзы для создания чипов, игродел!
Ты себе представляешь сложность этой поебени?
Или ты думаешь что скорость там никого не ебет?
Знаешь сколько времени занимает в каком-нибудь бытовом-народном Квартусе чекинг или генерация RTL? А это время - это живые деньги, если ты думаешь что для производителей чипов - то есть покупателей этих тулзов все это не имеет значения.
>>771156
Кто бы мог чего другого от криворуких игроделов ожидать.
Компания ПРОДАЕТ тулзы для создания чипов, игродел!
Ты себе представляешь сложность этой поебени?
Или ты думаешь что скорость там никого не ебет?
Знаешь сколько времени занимает в каком-нибудь бытовом-народном Квартусе чекинг или генерация RTL? А это время - это живые деньги, если ты думаешь что для производителей чипов - то есть покупателей этих тулзов все это не имеет значения.
>>771156
>Нинуужна
Кто бы мог чего другого от криворуких игроделов ожидать.
>>771162
Криворукие игроделы выпускают продукт, который продается, пряморукие борщехлебы выпускают воздух с запахом нечищеных зубов.
>Кто бы мог чего другого от криворуких игроделов ожидать
Криворукие игроделы выпускают продукт, который продается, пряморукие борщехлебы выпускают воздух с запахом нечищеных зубов.
Ответы>>773199
Грят, хаскель - последний писк моды? Я поверхностно пощупал пхп, жиес, жаву, но не смог в них закатиться. И вот думаю, попробовать изучить хаскель.
как там в хаскеле? дефицит кадров?
как там в хаскеле? дефицит кадров?
>>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 Хороший учебник, всё расписано подробно. Сам по нему учился. Рекомендую.
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
>>771312
А еще в жопу все ябутся.
А еще в жопу все ябутся.
>>771312
https://www.ohaskell.guide/
А вообще в хаскеле конечно не хватает очередного неразобравшегося в ООП, вот прям ждут тебя, на стену лезут.
https://www.ohaskell.guide/
А вообще в хаскеле конечно не хватает очередного неразобравшегося в ООП, вот прям ждут тебя, на стену лезут.
>>771592
Не посоветуешь чего почитать, чтобы в ООП разобраться полностью? Просто в большинстве книг по языкам он идёт как что-то побочное и даётся отрывками. Желательно с примерами на питоне.
Не посоветуешь чего почитать, чтобы в ООП разобраться полностью? Просто в большинстве книг по языкам он идёт как что-то побочное и даётся отрывками. Желательно с примерами на питоне.
Ответы>>771622
>>771592
Почему не разобравшегося? Я в нем отлично разобрался, просто работы на ООП языках нет ибо сейчас каждый школьник учит какой-нибудь питон. пхп, жиес, кресты или жаву и далее по пасте.
Почему не разобравшегося? Я в нем отлично разобрался, просто работы на ООП языках нет ибо сейчас каждый школьник учит какой-нибудь питон. пхп, жиес, кресты или жаву и далее по пасте.
>>771606
В голосину.
Choose your destiny:
C++ | C# | Java
> в ООП разобраться полностью
> Желательно с примерами на питоне.
В голосину.
Choose your destiny:
C++ | C# | Java
Ответы>>771626
>>771622
То есть на питоне ООП нинужен?
Ну прям сорта. Пусть будут плюсы, в них я чутка умею.
То есть на питоне ООП нинужен?
> Choose your destiny:
Ну прям сорта. Пусть будут плюсы, в них я чутка умею.
>>770268 (OP)
ООП - гоано без задач. По пунктам:
1. ООП - это экзистенциальная типизация. Но 90% программ пишутся и без экзистенциальных типов, а если они нужны, их и подрубить можно.
2. ООП - это сабтайпинг. Сабтайпинг в 99% задач не нужен, в оставшихся 0.5% он эмулируется тайпклассами (причем тайпклассы строго больше ООП, поскольку они могут в мультидиспатчинг, а ООП - нет) и еще в 0.5% extensible records-ми (причем extensible records строго больше ООП, потому что они могут structural equality, а ООП - нет).
2.5. ООП - это RTTI. RTTI не нужен, даже лень объяснять почему. Впрочем, если нужен, в нормальных языках он есть, по желанию.
3. ООП - это namespace resolver. Вот тут оно неплохО. Но есть модули, линзы, record field disambiguation наконец, короче, разрешение пространств имён в ООП реально неплохо сделано, но есть альтернативы, позволяющие делать всё то же самое, не привнося в программу минусов ООП.
Но это всё лирика. На самом деле всё зависит от программиста. И как их различить? Предложу простой критерий:
A - программист говорит, что ООП не нужно.
Б - программист говорит, что ООП нужно.
В - программист знает, чем рекурсия отличается от корекурсии.
Г - программист не знает, чем рекурсия отличается от корекурсии.
Д -программист не знает, что такое рекурсия.
Ответы:
АВ - нормальный программист
БВ - фрик
АГ - быдлокодер
БГ - быдлокодер
Д - не програмист
AБ - мастер взаимоисключающих параграфов, фрик и быдлокодер.
ООП - гоано без задач. По пунктам:
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
>>771635
В OCaml есть, в Haskell - хуй.
Сделали только неделю назад
>>771651
Паттерн-матчинг это инструмент для диспетчеризации и, если есть сложные структуры — средство декомпозиции сложных структур (в частном случае — кортежей). Отношение к функциональному программированию он имеет, но весьма опосредованное. Есть языки с паттерн матчингом не являющиеся функциональными (Prolog) и функциональные языки без паттерн матчинга (Scheme).
В Haskell это инструмент очень низкоуровневый, если у вас в функциях огромные свитчи, то вы явно что-то неправильно делаете.
>модули
В OCaml есть, в Haskell - хуй.
>record field disambiguation
Сделали только неделю назад
>>771651
Паттерн-матчинг это инструмент для диспетчеризации и, если есть сложные структуры — средство декомпозиции сложных структур (в частном случае — кортежей). Отношение к функциональному программированию он имеет, но весьма опосредованное. Есть языки с паттерн матчингом не являющиеся функциональными (Prolog) и функциональные языки без паттерн матчинга (Scheme).
В Haskell это инструмент очень низкоуровневый, если у вас в функциях огромные свитчи, то вы явно что-то неправильно делаете.
Ответы>>772468
>>771651
Ну конечно, особенно если завести искуственного общего предка "некий Объект" - заипись, компилятор не ругается, все прекрасно. Что толку от такой "типизации" никакой - да и хрен с ним.
Haskell - экзистенциальные типы и HList (http://okmij.org/ftp/Haskell/HList-ext.pdf, https://hackage.haskell.org/package/HList-0.4.2.0), в Scala тоже все есть.
>ООП как раз в этом плане и хорошо тем, что гетерогенный список (который нужен в разы чаще, чем множественная диспетчеризация) пишется просто и приятно
Ну конечно, особенно если завести искуственного общего предка "некий Объект" - заипись, компилятор не ругается, все прекрасно. Что толку от такой "типизации" никакой - да и хрен с ним.
Haskell - экзистенциальные типы и HList (http://okmij.org/ftp/Haskell/HList-ext.pdf, https://hackage.haskell.org/package/HList-0.4.2.0), в Scala тоже все есть.
>>771671
Но хочу я не этого.
Я хочу сделать список, и явно указать что в нем могут содержаться только сущности типов, которые можно рисовать И сериализовывать. Просто перечислить эти необходимые свойства, а никаких еботических их гибридов не делать, потому что это костыль. И чтобы компилятор ругался когда какой-то джуниор в этот список пытался положить что-то, что либо не seriаlizable, либо не drawable.
>В ООП ты делаешь IDrawable, ISerialazble, далее создаешь IDrawableSeriazableEbotable (это основной проеб ООП), и делаешь array<IDrawableSeriazableEbotable>, все. Проеб тут возникает в том, что если у тебя нет возможности реализовать интерфейс Ebotable для круга, допустим, у тебя возникнет pure virutal function call, а система типов тебя никак не проверит
Но хочу я не этого.
Я хочу сделать список, и явно указать что в нем могут содержаться только сущности типов, которые можно рисовать И сериализовывать. Просто перечислить эти необходимые свойства, а никаких еботических их гибридов не делать, потому что это костыль. И чтобы компилятор ругался когда какой-то джуниор в этот список пытался положить что-то, что либо не seriаlizable, либо не drawable.
Ответы>>771685
>>771684
Еще лучше, конечно, еще и явно не указывать. Пусть компилятор сам посмотрит что я с элементами этого списка делаю, и ругается если где-то в коде вынув из списка элемент его пытаются нарисовать, а при добавлении в список рисовабельность не проверяется.
>и явно указать
Еще лучше, конечно, еще и явно не указывать. Пусть компилятор сам посмотрит что я с элементами этого списка делаю, и ругается если где-то в коде вынув из списка элемент его пытаются нарисовать, а при добавлении в список рисовабельность не проверяется.
Хуйня какая-то у нас получилась к 2016 году.
Смотри, в чем была изначальная претензия к ООП-дизайну? В том что он принуждает к эссенциализму, то есть структурировать сущности по тому чем они являются. Ущербность самой такой постановки вопроса и скудность термина "является" мы можем увидеть на примере птеродактиля и летучей мыши - они чем являются, и в какую стало быть иерархию их помещать - в какую не помести, все неудобно. С точки зрения летучести вроде надо к птицам, а с точки зрения, например, яиц и теплокровности - мало того что в другую, так еще и не в одну, а в разные. И выбирай по какому принципу тебе важней классифицировать, но не ошибись, потому что выбрать для удобной работы можно либо летучесть, либо теплокровность, либо яйцекладкость, и только один раз.
А ведь хочется вот здесь единообразно поработать со всеми летучими, а вот тут, столь же единообразно, уже со всеми теплокровными. То есть работать не с онтологией, прибитой гвоздями, а с ортогональными проекциями.
Придумали множественное наследование, но получилось опять не слишком заебись, из-за наследования имплементаций и традиционного для ООП state в каждом объекте, который традиционно еще и mutable - получалась каша, баги и боль.
Потом придумали отрывать имплементацию и множественно наследовать и (или) миксинить только интерфейсы. Получилось уже лучше, но все равно криво, потому что каждый раз создавать абстрактный класс, только для того чтоб перечислить в нем нужные мне в этом месте свойства - это какая-то хуита.
Смотри, в чем была изначальная претензия к ООП-дизайну? В том что он принуждает к эссенциализму, то есть структурировать сущности по тому чем они являются. Ущербность самой такой постановки вопроса и скудность термина "является" мы можем увидеть на примере птеродактиля и летучей мыши - они чем являются, и в какую стало быть иерархию их помещать - в какую не помести, все неудобно. С точки зрения летучести вроде надо к птицам, а с точки зрения, например, яиц и теплокровности - мало того что в другую, так еще и не в одну, а в разные. И выбирай по какому принципу тебе важней классифицировать, но не ошибись, потому что выбрать для удобной работы можно либо летучесть, либо теплокровность, либо яйцекладкость, и только один раз.
А ведь хочется вот здесь единообразно поработать со всеми летучими, а вот тут, столь же единообразно, уже со всеми теплокровными. То есть работать не с онтологией, прибитой гвоздями, а с ортогональными проекциями.
Придумали множественное наследование, но получилось опять не слишком заебись, из-за наследования имплементаций и традиционного для ООП state в каждом объекте, который традиционно еще и mutable - получалась каша, баги и боль.
Потом придумали отрывать имплементацию и множественно наследовать и (или) миксинить только интерфейсы. Получилось уже лучше, но все равно криво, потому что каждый раз создавать абстрактный класс, только для того чтоб перечислить в нем нужные мне в этом месте свойства - это какая-то хуита.
>>770785
А что лежит в переменной по этому адресу - хуй его знает.
Dude, было бы это 7-8 тактов - всем было бы на это наплевать. Простой кэш-мисс - это 200+ тактов, остановка конвеера - и того больше.
Вот и приходится людям извращаться, придумывая своё ооп поверх крестов (Анальный Акробат Андрюша делал презентацию по этому поводу на цппкон14, по-моему, можешь в ютубе поискать - что-то там про кресты и производительность).
Алсо, даже ассемблерщики более пятнадцати лет назад дошли до нормального ооп, а крестобляди всё разлагаются www.wasm.ru/article/71
>>770840
Смешная шутка. Он написал дум, который работал на компьютерах, которые на тот момент не могли выдавать подобную графику в реалтайме. Он написал первую полностью трёхмерную игру, движок которой так или иначе является предком половины современных движков. Он первый начал опенсорсить свои движки. Он с дремучих времён участвовал в развитии опенгля (вместе со всякими нвидиями). По большому счёту, именно благодаря ему ты имеешь 3д ускоритель в пекарне. Алсо, первой игрой, использующей шейдеры, была quake 3, если я не ошибаюсь.
>>770843
Это только кажется с теоретической точки зрения. На самом деле, ты не один раз пересоздаёшь весь стейт, а по чуть-чуть его меняешь, поэтому у тебя будет огромная куча {xyu with dlina = new_dlina xyu.dlina} на кадр.
>call dword ptr[0xbabe]
А что лежит в переменной по этому адресу - хуй его знает.
>Тактов 7-8 очень легко потерять
Dude, было бы это 7-8 тактов - всем было бы на это наплевать. Простой кэш-мисс - это 200+ тактов, остановка конвеера - и того больше.
Вот и приходится людям извращаться, придумывая своё ооп поверх крестов (Анальный Акробат Андрюша делал презентацию по этому поводу на цппкон14, по-моему, можешь в ютубе поискать - что-то там про кресты и производительность).
Алсо, даже ассемблерщики более пятнадцати лет назад дошли до нормального ооп, а крестобляди всё разлагаются www.wasm.ru/article/71
>>770840
>Кармак
>ничего оосбенного за всю карьеру не написав
Смешная шутка. Он написал дум, который работал на компьютерах, которые на тот момент не могли выдавать подобную графику в реалтайме. Он написал первую полностью трёхмерную игру, движок которой так или иначе является предком половины современных движков. Он первый начал опенсорсить свои движки. Он с дремучих времён участвовал в развитии опенгля (вместе со всякими нвидиями). По большому счёту, именно благодаря ему ты имеешь 3д ускоритель в пекарне. Алсо, первой игрой, использующей шейдеры, была quake 3, если я не ошибаюсь.
>>770843
Это только кажется с теоретической точки зрения. На самом деле, ты не один раз пересоздаёшь весь стейт, а по чуть-чуть его меняешь, поэтому у тебя будет огромная куча {xyu with dlina = new_dlina xyu.dlina} на кадр.
>>771698
Да, дедушка умный, куда б мы без него.
>По большому счёту, именно благодаря ему
Да, дедушка умный, куда б мы без него.
> свет лучше чем в 2007-ом году можно сделать и делают, только не Кармак. Кармак, напоминаю, в 2011ом году выпустил игру на лайтмапах (то есть с той же технологией освещения, которую он использовал в Quake 1). Он очень умный, наверное, но не любит спешить со своими революционными алгоритмами
>http://live13.livejournal.com/423196.html?thread=1148700#t1148700
>>771698
>Очередной гениальный замысел Кармака
>Кто не знает, так работала его мегатекстура, только даже она была чуть умнее - делала feedback pass сначала и находила все страницы в сцене, но все равно это был страшный тормоз. Останавливать GPU и грузить страницу по первому fault - будет тормознее на порядки.
>большая проблема начиная с PS3 - программисты не знают и знать не хотят как работает железо не смотря на 100500 презентаций, которые для них делают. Упираются рогом и ваяют хренотень как им хочется, а хочется странного очень часто. Например, хочется continuous submit на PS4. Плевать, что тормозит не по-децки, так у них же еще там баг на баге сидит и багом погоняет. Что, конечно, неудивительно, потому что человек, который знает достаточно, чтобы его написать правильно, это делать не будет потому что этих знаний более чем достаточно, чтобы понять почему это не нужно делать
Ответы>>771708
>>771704
Кармак, который (хуй с ним) десять лет двигал прогресс в области компьютерной интерактивной реалтайм графики, или какой-то нонейм хуй? Какой тяжёлый вопрос.
А, теперь всё встало на свои места.
Ок, пошли по пунктам.
Ну, во-первых, в оригинальном квейке, по-моему, не лайтмапы. Но хуй с ними. Почему лайтмапы? Да потому, что выглядят охуенно. А нормальное освещение с таким же качеством тяжеловато было сделать. Потому что, всегда быстрее не считать.
Дизайнеры уровней и хуйдожники, я слышал, от неё радугой кончают. Но ещё можно вспомнить, что Кармак обосрался во второй кваке с трёхмерными взрывами. Почему? А это проблема всех первопроходцев. Сначала ты делаешь криво, потому что опыта нет, потом уже люди (ты сам), которым не нужно искать новую дорогу, кладут асфальт.
Кармак, который (хуй с ним) десять лет двигал прогресс в области компьютерной интерактивной реалтайм графики, или какой-то нонейм хуй? Какой тяжёлый вопрос.
>communities
>fprog
А, теперь всё встало на свои места.
>вот, Моська, знать, она сильна, коль лает на слона
Ок, пошли по пунктам.
>Кармак, напоминаю, в 2011ом году выпустил игру на лайтмапах (то есть с той же технологией освещения, которую он использовал в Quake 1).
Ну, во-первых, в оригинальном квейке, по-моему, не лайтмапы. Но хуй с ними. Почему лайтмапы? Да потому, что выглядят охуенно. А нормальное освещение с таким же качеством тяжеловато было сделать. Потому что, всегда быстрее не считать.
>Кармак так никому и не смог внятно объяснить, что с ее помощью можно сделать такого, чего нельзя гораздо быстрее сделать без нее
Дизайнеры уровней и хуйдожники, я слышал, от неё радугой кончают. Но ещё можно вспомнить, что Кармак обосрался во второй кваке с трёхмерными взрывами. Почему? А это проблема всех первопроходцев. Сначала ты делаешь криво, потому что опыта нет, потом уже люди (ты сам), которым не нужно искать новую дорогу, кладут асфальт.
Ответы>>771715
>>771708
Кармак у нас первопроходец.
Ебущий свою мегатекстуру с лайтмапами уже второй десяток, не сумевший сделать ни одной консольной игры, торгующий лицом (это сложно, потому что лицо-то как раз закрыто Шлемом Виртуальной Реальности - тут никто кроме Кармака не справится) в шарашках, продающих наступление эры VR под свист воздуха в надуваемом ими мыльном пузыре?
>это проблема всех первопроходцев
Кармак у нас первопроходец.
Ебущий свою мегатекстуру с лайтмапами уже второй десяток, не сумевший сделать ни одной консольной игры, торгующий лицом (это сложно, потому что лицо-то как раз закрыто Шлемом Виртуальной Реальности - тут никто кроме Кармака не справится) в шарашках, продающих наступление эры VR под свист воздуха в надуваемом ими мыльном пузыре?
>>771709
Ну это то же самое что автомат для стрижки - который тоже неплохо работает, если у клиента голова квадратная, и еще и строго утвержденного размера.
Понятно что если вся требуемая в задаче иерархия это кружочек и квадратик, то все заебись.
Плохо то что такие задачи за пределами собеседований с джуниорами в полуподвальных лухософтах встречаются редко.
>Современное ООП, с довольно плоской иерархиев
Ну это то же самое что автомат для стрижки - который тоже неплохо работает, если у клиента голова квадратная, и еще и строго утвержденного размера.
Понятно что если вся требуемая в задаче иерархия это кружочек и квадратик, то все заебись.
Плохо то что такие задачи за пределами собеседований с джуниорами в полуподвальных лухософтах встречаются редко.
Ответы>>772774
>>771711
Потом оно перестанет помещаться в instruction cache и будут только пуки, а все чики уйдут к конкурентам
>Сделай 2 копии кода, и тебя все заинлайнится и будет чики-пуки
Потом оно перестанет помещаться в instruction cache и будут только пуки, а все чики уйдут к конкурентам
>>771711
В языках типа Java есть JIT, который, особенно при ярко выраженном наличии hot path - что бывает довольно часто - это дело оптимизнет. Но в бенчмарках этого не покажут, потому что с дефолтными настройками оптимизнет оно только через десяток тысяч итераций по этому месту, а бенчмаркальщики слишком тупы чтобы об этом знать и настройки настроить, так что до JIT в бенчмарках обычно дело не доходит совсем.
>двойного перехода указатель на объект->адрес VMT->смещение по VMT страшнее. Это, кстати, основная причина принципиальных тормозов языков типа Java.
В языках типа Java есть JIT, который, особенно при ярко выраженном наличии hot path - что бывает довольно часто - это дело оптимизнет. Но в бенчмарках этого не покажут, потому что с дефолтными настройками оптимизнет оно только через десяток тысяч итераций по этому месту, а бенчмаркальщики слишком тупы чтобы об этом знать и настройки настроить, так что до JIT в бенчмарках обычно дело не доходит совсем.
>>> Судя по требованию двух USB 3.0 весь трэкинг делается на CPU из сырого стрима с датчиков/камер. Это неудивительно, компьют они использовать не могут (иначе Нвидия и Вин7 и 8 в пролете), а DSP в хэдсете - а) нужно уметь и б) сделает хэдсет еще дороже
>>Блджд, шестиосевой аксель-инклинометр с калманом на борту стоит 40 центов. 40 центов, Карл! Оптовикам дают СДК к микрухе, которая позволяет задействовать нутряной ДСП для детекции жестов-хуестов и прочей хрени.
> Не стоит забывать, что CTO у них Кармак, который в железе ничего никогда не понимал.
>>771732
Понимать может только Кармак, потому что он Кармак, понятно.
Понимать может только Кармак, потому что он Кармак, понятно.
>>771723
Ты самый умный просто, долбоёб.
Иди почитай как перформанс жявы на каком нибудь benchmarksgame измеряется, потом пизди.
Ты самый умный просто, долбоёб.
Иди почитай как перформанс жявы на каком нибудь benchmarksgame измеряется, потом пизди.
Ответы>>771745
140 Кб, 2400x2083
>я 2000го года рождения и не знаю, что было до рейджа, поэтому этого не было
>сейчас Кармак обсирается (то есть, на самом деле - нет, но я считаю, что он обсирается), поэтому все его прошлые заслуги аннулируются и больше ничего не значат
>а ещё вот вам посты от хуй_вообще_знает_кого_чью_компетентность_никак_не_проверить, которые подверждают мою точку зрения (на самом деле, это не моя точка зрения, я просто прочёл эти посты и ПРОЗРЕЛ)
>я лучше знаю, а вы все тупые семёны
Здорово.
>>771737
Дык жабадебилы все время орут про бенчмарки, а вот попробуй любое жавопобедилие запустить и оно будет адово тормозить. Еще и ОЗУ жрать, да, но еще и тормозить. А еще это говно тормозит. Адово. Но зато бенчмарки.
Дык жабадебилы все время орут про бенчмарки, а вот попробуй любое жавопобедилие запустить и оно будет адово тормозить. Еще и ОЗУ жрать, да, но еще и тормозить. А еще это говно тормозит. Адово. Но зато бенчмарки.
>>771748
Вопрос - и нахрена ж ей джва USB 3.0 (и еще один - для контроллера, но мы не о нем)?
>данные акселерометра занимают так мало (килобайты полосы)
Вопрос - и нахрена ж ей джва USB 3.0 (и еще один - для контроллера, но мы не о нем)?
> Из всех "изобретений" Джона Кармака, тесселляция - единственное, что используется кем-то кроме несчастных покупателей id Tech. Наверное потому, что Кармак только хвалился тесселляцией, но так ее и не сделал
Ответы>>771801
>>771698
Нет, он на BSP в 3D сдулся, и побежал за помощью к Абрашу. С окулусом, кстати, такая же фигня. Без Абраша он долго не просидел, выписал себе помогать.
>Он написал первую полностью трёхмерную игру
Нет, он на BSP в 3D сдулся, и побежал за помощью к Абрашу. С окулусом, кстати, такая же фигня. Без Абраша он долго не просидел, выписал себе помогать.
Ответы>>771808
>>771787
Ну Миша, кстати, тоже люит пиздеть, какие вокруг лохи, а сам в 2011 году выпускает игру с графоном уровня 2003. Да и судя по mobygames, остальной послужной список у него не оче.
Ну Миша, кстати, тоже люит пиздеть, какие вокруг лохи, а сам в 2011 году выпускает игру с графоном уровня 2003. Да и судя по mobygames, остальной послужной список у него не оче.
Ответы>>771817
>>771793
Я к тому, что "написал первую трехмерную игру" - это довольно громко сказано.
Я к тому, что "написал первую трехмерную игру" - это довольно громко сказано.
>>771811
Просто Кармака преподносят как гения программирования 3Д, хотя его достижения в этой области далеко в прошлом, учитывая темпы развития.
>Но личность Кармака трудно недооценить
Просто Кармака преподносят как гения программирования 3Д, хотя его достижения в этой области далеко в прошлом, учитывая темпы развития.
>>771811
С того что надули из него Великого Игро Девелопера, и какую бы хуйню он не нес, только и слышно про него.
С того что надули из него Великого Игро Девелопера, и какую бы хуйню он не нес, только и слышно про него.
>>771801
Это все любят, но его на каждой ярмарке хоть не показывают и бложек не обсуждают на каждом перекрестке
Это все любят, но его на каждой ярмарке хоть не показывают и бложек не обсуждают на каждом перекрестке
Ответы>>771820
>>771817
Да и полезное что-то можно от него иногда узнать http://live13.livejournal.com/462582.html?thread=1403894#t1403894
А от Кармака только "покупай, торопись" и великие идеи о мегатекстурах будущего.
Да и полезное что-то можно от него иногда узнать http://live13.livejournal.com/462582.html?thread=1403894#t1403894
А от Кармака только "покупай, торопись" и великие идеи о мегатекстурах будущего.
Ответы>>771841
>>771831
Полезное - то что на книжку эту можно времени не тратить, не говоря уж про забивание мозгов
Полезное - то что на книжку эту можно времени не тратить, не говоря уж про забивание мозгов
Ответы>>771840
>>771832
"Бесполезна для ААА под консоли" не значит бесполезна вообще для геймдева.
"Бесполезна для ААА под консоли" не значит бесполезна вообще для геймдева.
>>771820
Наоборот, у Кармака гораздо более интересные твитор и пейсбук. Без поливания всех говном, пещерного расизма и гомофобии.
>А от Кармака только
Наоборот, у Кармака гораздо более интересные твитор и пейсбук. Без поливания всех говном, пещерного расизма и гомофобии.
Ответы>>771850
>>771836
Ну я же не говорю что читать надо некритично, без понимания того зачем чувак пишет и какие у него в LA фрустрации, особенно глядя на Кармака.
Но именно эта едкая negativity (тем более что ее можно спокойно пропускать мимо ушей) и сопутствующий ей взгляд на какие-то вещи, события и персоны, дает возможность не только посмотреть на некоторые вещи с более других сторон чем это принято и несется из всех репродукторов, но и, что часто даже продуктивней, о чем-то самостоятельно задуматься.
Тот же GoF book намного более полезен и хорош (если, где, кому и когда он вообще может быть полезен и хорош) когда ты понимаешь откуда оно взялось, зачем, причем тут Смаллток, и кем, почему, и в качестве чего это было сделано в Симуле, и почему Алан Кей похож с одной стороны на Кармака, а с другой - на автора Хагакурэ, который тоже немного опоздал родиться и немного переусердствовал в развитии концепций того, прекрасного прошлого времени, над которыми в то, прекрасное старое время все причастные максимум пожали бы плечами.
Ну я же не говорю что читать надо некритично, без понимания того зачем чувак пишет и какие у него в LA фрустрации, особенно глядя на Кармака.
Но именно эта едкая negativity (тем более что ее можно спокойно пропускать мимо ушей) и сопутствующий ей взгляд на какие-то вещи, события и персоны, дает возможность не только посмотреть на некоторые вещи с более других сторон чем это принято и несется из всех репродукторов, но и, что часто даже продуктивней, о чем-то самостоятельно задуматься.
Тот же GoF book намного более полезен и хорош (если, где, кому и когда он вообще может быть полезен и хорош) когда ты понимаешь откуда оно взялось, зачем, причем тут Смаллток, и кем, почему, и в качестве чего это было сделано в Симуле, и почему Алан Кей похож с одной стороны на Кармака, а с другой - на автора Хагакурэ, который тоже немного опоздал родиться и немного переусердствовал в развитии концепций того, прекрасного прошлого времени, над которыми в то, прекрасное старое время все причастные максимум пожали бы плечами.
>>771856
Человек, измученный нарзаном.
Я когда с индусами работал, тоже порой головой об стол бился. Не столько от качества кода, сколько от attitude.
Это в Воронеже хорошо к ним относиться, когда их нет в радиусе 1000 км
Человек, измученный нарзаном.
Я когда с индусами работал, тоже порой головой об стол бился. Не столько от качества кода, сколько от attitude.
Это в Воронеже хорошо к ним относиться, когда их нет в радиусе 1000 км
>>771868
Да, это со многими так. Читаешь какого-нибудь умного (вроде бы) парня про просторы большого театра в области lockless алгоритмов, и ВНЕЗАПНО он как начнет про социальную справедливость, раскулачивание Уолл-Стрит и угнетенных (Демократами, но это никогда в сообщение не помещается по загадочным причинам) миноритис Чикагщины - хоть отписывайся.
Тэги же придумали специально для этого, но никто не пользуется.
Да, это со многими так. Читаешь какого-нибудь умного (вроде бы) парня про просторы большого театра в области lockless алгоритмов, и ВНЕЗАПНО он как начнет про социальную справедливость, раскулачивание Уолл-Стрит и угнетенных (Демократами, но это никогда в сообщение не помещается по загадочным причинам) миноритис Чикагщины - хоть отписывайся.
Тэги же придумали специально для этого, но никто не пользуется.
>>771723
Давай, расскажи мне как он это оптимзирует. Что он такого делает, что двойного cache miss не происходит.
Давай, расскажи мне как он это оптимзирует. Что он такого делает, что двойного cache miss не происходит.
Ответы>>771896
>>770268 (OP)
Я придерживаюсь СТРУКТУРИРОВАННОГО ПРОГРАММИРОВАНИЯ (СП). Мое личное изобретение.
Я придерживаюсь СТРУКТУРИРОВАННОГО ПРОГРАММИРОВАНИЯ (СП). Мое личное изобретение.
Ответы>>771908
>>771896
Никакие инлайны и девиртуализация не спасут при организации памяти в жвм с неебическими индиректами и адовым оверхедом по 500% из-за боксинга неба и аллаха.
Никакие инлайны и девиртуализация не спасут при организации памяти в жвм с неебическими индиректами и адовым оверхедом по 500% из-за боксинга неба и аллаха.
Ответы>>771912
>>771902
Поясняю. Во главе идеи - один суперобъект, назовем проектом.
Весь код это его функции и методы.
Программа запускается через метод Object.run (), который может содержать различные методы инициализации (например Object.preload (), Object.init ()).
Создание объектов происходит так, например кнопки:
Все объекты автоматически получают цифровое порядковое id и ссылки на них можно найти в Object.id<objects_id>. Чтобы найти объекты не по id, а по внутреннему тегу или свойству, используется метод Object.get.object (..) - указываем что нужно найти, например пару { name: 'menu' }
Конечно даже в сотне постов не описать всех деталей, но если вы обладаете зачатками интеллекта, то даже эти пару абзацев способны дать почву для создания полной картины.
Поясняю. Во главе идеи - один суперобъект, назовем проектом.
Весь код это его функции и методы.
Программа запускается через метод Object.run (), который может содержать различные методы инициализации (например Object.preload (), Object.init ()).
Создание объектов происходит так, например кнопки:
>Object.create.button (..) // метод в качестве аргументов принимает параметры, положение, текст, текстуру и прочее
Все объекты автоматически получают цифровое порядковое id и ссылки на них можно найти в Object.id<objects_id>. Чтобы найти объекты не по id, а по внутреннему тегу или свойству, используется метод Object.get.object (..) - указываем что нужно найти, например пару { name: 'menu' }
Конечно даже в сотне постов не описать всех деталей, но если вы обладаете зачатками интеллекта, то даже эти пару абзацев способны дать почву для создания полной картины.
>>771904
Java неплохо оптимизируется в тех местах где надо и тогда когда надо
http://mechanical-sympathy.blogspot.ru/2012/10/compact-off-heap-structurestuples-in.html
Пердолиться с указателями во всех остальных частях программы, которые составляют обычно 98.74%, при этом не нужно.
Java неплохо оптимизируется в тех местах где надо и тогда когда надо
http://mechanical-sympathy.blogspot.ru/2012/10/compact-off-heap-structurestuples-in.html
Пердолиться с указателями во всех остальных частях программы, которые составляют обычно 98.74%, при этом не нужно.
Ответы>>771924
>>771912
Это ебаный ад off-heap пердолинга. Проще на крестах переписать.
Потому что эти 98% - блоат из бесполезных ФабрикАбстрактныхФабрик, которые как-то оптимизировать можно только выкинув их совсем.
>Java неплохо оптимизируется в тех местах
Это ебаный ад off-heap пердолинга. Проще на крестах переписать.
>которые составляют обычно 98.74% при этом не нужно
Потому что эти 98% - блоат из бесполезных ФабрикАбстрактныхФабрик, которые как-то оптимизировать можно только выкинув их совсем.
Ответы>>771937
>>771924
Даже предположив что ты действительно мог бы все это переписать, есть еще и другие факторы - например, время, бюджет и уровень персонала.
Те фабрики фабрик, которые ты будешь переписывать пока Солнце не упадет на Землю, можно поручить менее квалифицированному персоналу, и это будет не только быстрее, но в том числе и значительно дешевле.
Даже предположив что ты действительно мог бы все это переписать, есть еще и другие факторы - например, время, бюджет и уровень персонала.
Те фабрики фабрик, которые ты будешь переписывать пока Солнце не упадет на Землю, можно поручить менее квалифицированному персоналу, и это будет не только быстрее, но в том числе и значительно дешевле.
Ответы>>771939
>>771937
Вот поэтому оптимизацией жабы заниматься абсолютно бессмысленно. Как и пытаться писать на ней что-то кроме жирного интерпрайза.
Вот поэтому оптимизацией жабы заниматься абсолютно бессмысленно. Как и пытаться писать на ней что-то кроме жирного интерпрайза.
Ответы>>771946
>>771939
Совсем наоборот, именно ее-то оптимизацией заниматься осмысленно.
Оптимизируя 1% критичного к производительности кода, ты получаешь 90% прироста общей производительности, весь остальной код пишут дешевые джава-макаки - это очень хороший результата в подавляющем количестве случаев.
За бортом остаются буквально считанные задачи - жесткий реалтайм, часть эмбедовки, консольные игродвижки.
Совсем наоборот, именно ее-то оптимизацией заниматься осмысленно.
Оптимизируя 1% критичного к производительности кода, ты получаешь 90% прироста общей производительности, весь остальной код пишут дешевые джава-макаки - это очень хороший результата в подавляющем количестве случаев.
За бортом остаются буквально считанные задачи - жесткий реалтайм, часть эмбедовки, консольные игродвижки.
Ответы>>771951
>>771946
Проблема в том, что в джавакоде обычно нет 1% критической части. Потери размазаны по всему коду равномерно. А затраты на написание быстрого кода ОЧЕНЬ высоки, поскольку джава как язык не поощряет работу с примитивными типами и off-heap.
Проблема в том, что в джавакоде обычно нет 1% критической части. Потери размазаны по всему коду равномерно. А затраты на написание быстрого кода ОЧЕНЬ высоки, поскольку джава как язык не поощряет работу с примитивными типами и off-heap.
Ответы>>771958
169 Кб, 550x778
Время бородатых игроделов-сишников с ООП уходит
> 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
>>771951
Может быть где-то такое и бывает, но мне сходу сложно себе представить такое, процент критического кода, конечно, варьируется и 1% бывает не всегда (хотя и удивительно часто), но до 5% обычно укладывается.
>в джавакоде обычно нет 1% критической части. Потери размазаны по всему коду равномерно
Может быть где-то такое и бывает, но мне сходу сложно себе представить такое, процент критического кода, конечно, варьируется и 1% бывает не всегда (хотя и удивительно часто), но до 5% обычно укладывается.
>>771957
Ты правда считаешь, что это означает, что все станут на хаскеле писать? GPU-программирование FP-friendly с самого начала, но все языки там - варианты си.
>much more FP friendly
Ты правда считаешь, что это означает, что все станут на хаскеле писать? GPU-программирование FP-friendly с самого начала, но все языки там - варианты си.
>>771964
Чистые ФП языки это маразм. Просто добавят в попсовые языки ФП парадигму. Java 8, например.
Чистые ФП языки это маразм. Просто добавят в попсовые языки ФП парадигму. Java 8, например.
>>771965
Ахуеть, там же лямбды и мап-редюч-И так далее в стандартной библиотеке! Ахуеть, фп язык!
Плюсы у тебя, наверно, на уровне с хачкеллем стоят?
>Java 8, например.
Ахуеть, там же лямбды и мап-редюч-И так далее в стандартной библиотеке! Ахуеть, фп язык!
Плюсы у тебя, наверно, на уровне с хачкеллем стоят?
Ответы>>771995
>>771992
Так это только начало. Там еще стримы добавили, композишн, maybe-типы и все такое. А в 9ке обещают модули, настоящие.
Но там еще надо дохуя вычистить, исключения, для начала.
Ну ладно, жаба жабой, а вот в кресты ФП парадигму норм добавится.
Так это только начало. Там еще стримы добавили, композишн, maybe-типы и все такое. А в 9ке обещают модули, настоящие.
Но там еще надо дохуя вычистить, исключения, для начала.
Ну ладно, жаба жабой, а вот в кресты ФП парадигму норм добавится.
Ответы>>772021
>>771314
ВНЕЗАПНО
ВНЕЗАПНО
>>771965
>>771995
Модули это конечно хорошо. Только и с лямбда фишечками C#, Java и подобные им "гибридные" языки останутся глубоко императивными. Все это натягивание ФП на ОПП, причем совершено не с той стороны, выглядит бредово. Принцип "снаружи ООП, а внутри методов — ФП". Какой ФП? Внутри каких методов? ФП как раз должен быть снаружи, а внутри хоть ассемблер.
Какие есть плюсы у ФП на примере хаскеля?
1) Более-менее полноценная поддержка для комбинирования комбинаторов.
2) Возможность рассуждать об этих комбинаторах как о математических объектах (с оговорками).
Для этого нужна более-менее нормальная система типов, полноценная поддержка ленивости, специальные оптимизации, и контроль за эффектами как сам по себе, так и для нормальной работы ленивости и оптимизатора. Неплохо было бы еще и завершимость проверять, чего в хаскеле нет и в этом смысле (как и в аспекте системы типов) он язык компромиссный и недоделанный. Собственно, на этом направлении и идет дальнейшее развитие как самого хаскеля, так и связанное с появлением родственных языков вроде омеги, агды и идриса. В этих языках могут отказаться от ленивости по умолчанию, но не от контроля за эффектами.
В любом же "гибридном" языке вы получаете отказ от контроля за эффектами (потому что так не бывает когда здесь контролируем, здесь не контролируем, это получается нигде не контролируем) — а это сразу значит что с рассуждениями о коде, нормальной ленивостью и оптимизациями можно распрощаться, а значит и с полноценным комбинированием комбинаторов. Даже если у нас остается у нас только более-менее полноценная система типов, то мы попадаем в мертвую зону между хаскелем и так называемыми "гибридами", забитую мертвыми ML-ями и дышащим на ладан окамлом. Это вечные девяностые — прогресс отсюда никуда не двинуть.
Тем не менее, от гибридов и языки мертвой зоны выгодно отличаются полноценными системами типов и модулей, которыми гибриды жертвуют ради использования библиотек и рантаймов популярных мейнстримовых языков, но — по всей видимости — этого недостаточно.
Обычное ООП, мейнстримовое, с сабтайпингом, а не марсианское-структурное, какое возможно в хаскеле и некоторых "негибридных" мл-ях, наносит такой удар по системе типов, что о хоть сколько нибудь полноценной поддержке ФП говорить уже не приходится. "Гибриды" любят декларировать "мультипарадигменность", но ФП там, как колбаса при коммунизме: чего не спроси — отвечают, что потребности нет
>>771995
Модули это конечно хорошо. Только и с лямбда фишечками C#, Java и подобные им "гибридные" языки останутся глубоко императивными. Все это натягивание ФП на ОПП, причем совершено не с той стороны, выглядит бредово. Принцип "снаружи ООП, а внутри методов — ФП". Какой ФП? Внутри каких методов? ФП как раз должен быть снаружи, а внутри хоть ассемблер.
Какие есть плюсы у ФП на примере хаскеля?
1) Более-менее полноценная поддержка для комбинирования комбинаторов.
2) Возможность рассуждать об этих комбинаторах как о математических объектах (с оговорками).
Для этого нужна более-менее нормальная система типов, полноценная поддержка ленивости, специальные оптимизации, и контроль за эффектами как сам по себе, так и для нормальной работы ленивости и оптимизатора. Неплохо было бы еще и завершимость проверять, чего в хаскеле нет и в этом смысле (как и в аспекте системы типов) он язык компромиссный и недоделанный. Собственно, на этом направлении и идет дальнейшее развитие как самого хаскеля, так и связанное с появлением родственных языков вроде омеги, агды и идриса. В этих языках могут отказаться от ленивости по умолчанию, но не от контроля за эффектами.
В любом же "гибридном" языке вы получаете отказ от контроля за эффектами (потому что так не бывает когда здесь контролируем, здесь не контролируем, это получается нигде не контролируем) — а это сразу значит что с рассуждениями о коде, нормальной ленивостью и оптимизациями можно распрощаться, а значит и с полноценным комбинированием комбинаторов. Даже если у нас остается у нас только более-менее полноценная система типов, то мы попадаем в мертвую зону между хаскелем и так называемыми "гибридами", забитую мертвыми ML-ями и дышащим на ладан окамлом. Это вечные девяностые — прогресс отсюда никуда не двинуть.
Тем не менее, от гибридов и языки мертвой зоны выгодно отличаются полноценными системами типов и модулей, которыми гибриды жертвуют ради использования библиотек и рантаймов популярных мейнстримовых языков, но — по всей видимости — этого недостаточно.
Обычное ООП, мейнстримовое, с сабтайпингом, а не марсианское-структурное, какое возможно в хаскеле и некоторых "негибридных" мл-ях, наносит такой удар по системе типов, что о хоть сколько нибудь полноценной поддержке ФП говорить уже не приходится. "Гибриды" любят декларировать "мультипарадигменность", но ФП там, как колбаса при коммунизме: чего не спроси — отвечают, что потребности нет
>>771965
>>771995
Модули это конечно хорошо. Только и с лямбда фишечками C#, Java и подобные им "гибридные" языки останутся глубоко императивными. Все это натягивание ФП на ОПП, причем совершено не с той стороны, выглядит бредово. Принцип "снаружи ООП, а внутри методов — ФП". Какой ФП? Внутри каких методов? ФП как раз должен быть снаружи, а внутри хоть ассемблер.
Какие есть плюсы у ФП на примере хаскеля?
1) Более-менее полноценная поддержка для комбинирования комбинаторов.
2) Возможность рассуждать об этих комбинаторах как о математических объектах (с оговорками).
Для этого нужна более-менее нормальная система типов, полноценная поддержка ленивости, специальные оптимизации, и контроль за эффектами как сам по себе, так и для нормальной работы ленивости и оптимизатора. Неплохо было бы еще и завершимость проверять, чего в хаскеле нет и в этом смысле (как и в аспекте системы типов) он язык компромиссный и недоделанный. Собственно, на этом направлении и идет дальнейшее развитие как самого хаскеля, так и связанное с появлением родственных языков вроде омеги, агды и идриса. В этих языках могут отказаться от ленивости по умолчанию, но не от контроля за эффектами.
В любом же "гибридном" языке вы получаете отказ от контроля за эффектами (потому что так не бывает когда здесь контролируем, здесь не контролируем, это получается нигде не контролируем) — а это сразу значит что с рассуждениями о коде, нормальной ленивостью и оптимизациями можно распрощаться, а значит и с полноценным комбинированием комбинаторов. Даже если у нас остается у нас только более-менее полноценная система типов, то мы попадаем в мертвую зону между хаскелем и так называемыми "гибридами", забитую мертвыми ML-ями и дышащим на ладан окамлом. Это вечные девяностые — прогресс отсюда никуда не двинуть.
Тем не менее, от гибридов и языки мертвой зоны выгодно отличаются полноценными системами типов и модулей, которыми гибриды жертвуют ради использования библиотек и рантаймов популярных мейнстримовых языков, но — по всей видимости — этого недостаточно.
Обычное ООП, мейнстримовое, с сабтайпингом, а не марсианское-структурное, какое возможно в хаскеле и некоторых "негибридных" мл-ях, наносит такой удар по системе типов, что о хоть сколько нибудь полноценной поддержке ФП говорить уже не приходится. "Гибриды" любят декларировать "мультипарадигменность", но ФП там, как колбаса при коммунизме: чего не спроси — отвечают, что потребности нет
>>771995
Модули это конечно хорошо. Только и с лямбда фишечками C#, Java и подобные им "гибридные" языки останутся глубоко императивными. Все это натягивание ФП на ОПП, причем совершено не с той стороны, выглядит бредово. Принцип "снаружи ООП, а внутри методов — ФП". Какой ФП? Внутри каких методов? ФП как раз должен быть снаружи, а внутри хоть ассемблер.
Какие есть плюсы у ФП на примере хаскеля?
1) Более-менее полноценная поддержка для комбинирования комбинаторов.
2) Возможность рассуждать об этих комбинаторах как о математических объектах (с оговорками).
Для этого нужна более-менее нормальная система типов, полноценная поддержка ленивости, специальные оптимизации, и контроль за эффектами как сам по себе, так и для нормальной работы ленивости и оптимизатора. Неплохо было бы еще и завершимость проверять, чего в хаскеле нет и в этом смысле (как и в аспекте системы типов) он язык компромиссный и недоделанный. Собственно, на этом направлении и идет дальнейшее развитие как самого хаскеля, так и связанное с появлением родственных языков вроде омеги, агды и идриса. В этих языках могут отказаться от ленивости по умолчанию, но не от контроля за эффектами.
В любом же "гибридном" языке вы получаете отказ от контроля за эффектами (потому что так не бывает когда здесь контролируем, здесь не контролируем, это получается нигде не контролируем) — а это сразу значит что с рассуждениями о коде, нормальной ленивостью и оптимизациями можно распрощаться, а значит и с полноценным комбинированием комбинаторов. Даже если у нас остается у нас только более-менее полноценная система типов, то мы попадаем в мертвую зону между хаскелем и так называемыми "гибридами", забитую мертвыми ML-ями и дышащим на ладан окамлом. Это вечные девяностые — прогресс отсюда никуда не двинуть.
Тем не менее, от гибридов и языки мертвой зоны выгодно отличаются полноценными системами типов и модулей, которыми гибриды жертвуют ради использования библиотек и рантаймов популярных мейнстримовых языков, но — по всей видимости — этого недостаточно.
Обычное ООП, мейнстримовое, с сабтайпингом, а не марсианское-структурное, какое возможно в хаскеле и некоторых "негибридных" мл-ях, наносит такой удар по системе типов, что о хоть сколько нибудь полноценной поддержке ФП говорить уже не приходится. "Гибриды" любят декларировать "мультипарадигменность", но ФП там, как колбаса при коммунизме: чего не спроси — отвечают, что потребности нет
>>771964
А чего б на нем и не писать? Если роль того что крутится на CPU все больше сводится к control plane, простаивающей при этом 90% времени в виду явно избыточной для ее задач мощности современных процессоров. Все остальное (data plane) едет в GPU с SSD само, и считается там, и показывается прямо оттуда.
А чего б на нем и не писать? Если роль того что крутится на CPU все больше сводится к control plane, простаивающей при этом 90% времени в виду явно избыточной для ее задач мощности современных процессоров. Все остальное (data plane) едет в GPU с SSD само, и считается там, и показывается прямо оттуда.
>>772029
С того, что все будет адово тормозить из-за боксинга и аллокаций. Или придется писать в стиле мало отличающемся от нынешнего.
>А чего б на нем и не писать?
С того, что все будет адово тормозить из-за боксинга и аллокаций. Или придется писать в стиле мало отличающемся от нынешнего.
>>772029
Я чот представил как будут работать требовательные к процессору игрушки (стратегии, игры с физикой), или насколько придётся отупить и без того ебланский ИИ в стрелялочках
Кек
Я чот представил как будут работать требовательные к процессору игрушки (стратегии, игры с физикой), или насколько придётся отупить и без того ебланский ИИ в стрелялочках
Кек
Ответы>>772049
>>772042
Алгоритмы физики и ИИ в любом случае придется в будущем переписывать под массивно-параллельность, потому что скорость ядер CPU увеличиваться больше не планирует, только их количество.
Да и оптимизатор хаскеля на месте не стоит, и движется во многом именно в сторону распараллеливания - и руки у него сишечкой не связаны в этом.
Алгоритмы физики и ИИ в любом случае придется в будущем переписывать под массивно-параллельность, потому что скорость ядер CPU увеличиваться больше не планирует, только их количество.
Да и оптимизатор хаскеля на месте не стоит, и движется во многом именно в сторону распараллеливания - и руки у него сишечкой не связаны в этом.
Ответы>>772058
>>772049
Вот именно – скорость кода хачкелля упирается в оптимизатор, в отличие от си.
Да и GC с увеличением кол-ва потоков увеличит оверхед, что довольно сомнительная затея.
Вот именно – скорость кода хачкелля упирается в оптимизатор, в отличие от си.
Да и GC с увеличением кол-ва потоков увеличит оверхед, что довольно сомнительная затея.
Ответы>>772062
>>772058
Качество оптимизатора Си упирается в Си.
И вот с этим ничего не поделать, и никаких прорывов впереди не ожидается - неоткуда. Алиасинг и некоторые другие проблемы вытекают прямиком из самого языка Си.
Уровень хаскельного оптимизатора совсем другой, и то что он может наоптимизировать благодаря возможности рассуждать о хаскельном коде на совсем другом уровне - и сейчас уже очень неплохо, и есть куда пилить. При этом уровень сложений в человеко-часах в современные сишные оптимизаторы и GHC отличается в какие-то дикие порядки раз.
Качество оптимизатора Си упирается в Си.
И вот с этим ничего не поделать, и никаких прорывов впереди не ожидается - неоткуда. Алиасинг и некоторые другие проблемы вытекают прямиком из самого языка Си.
Уровень хаскельного оптимизатора совсем другой, и то что он может наоптимизировать благодаря возможности рассуждать о хаскельном коде на совсем другом уровне - и сейчас уже очень неплохо, и есть куда пилить. При этом уровень сложений в человеко-часах в современные сишные оптимизаторы и GHC отличается в какие-то дикие порядки раз.
>>772062
Алиасинг забарывается одним модификатором переменной и хотя бы каплей внимательности.
Вась, успокойся уже.
Алиасинг забарывается одним модификатором переменной и хотя бы каплей внимательности.
Вась, успокойся уже.
>>772062
Наверное поэтому у наивного qsort на хаскеле реальная асимптотика больше n^2 из-за постоянных переаллокаций и копирования.
>Уровень хаскельного оптимизатора совсем другой
Наверное поэтому у наивного qsort на хаскеле реальная асимптотика больше n^2 из-за постоянных переаллокаций и копирования.
Ответы>>772132
>>772062
Вот тут за чудо параллельность и производительность хаскеля поясняют:
http://flyingfrogblog.blogspot.ru/2016/05/disadvantages-of-purely-functional.html
Вот тут за чудо параллельность и производительность хаскеля поясняют:
http://flyingfrogblog.blogspot.ru/2016/05/disadvantages-of-purely-functional.html
>There is no efficient purely functional unsorted dictionary or set
>There is no purely functional weak hash table
>There are no purely functional concurrent collections
>Most graph algorithms look worse and run much slower when written in an FP style.
>All existing implementations of functional programming languages, both pure and impure, happen to allocate far too much by design
>Purely functional programming is theoretically good for parallelism but bad for performance in practice, which is the sole purpose of parallelism
>>772081
>The author of the post is a longtime troll.
>https://www.reddit.com/r/haskell/comments/4ogle3/post_about_the_disadvantages_of_functional/
>>772106
>мышка сломалась, кликнуть не смог
>>https://www.reddit.com/r/haskell/comments/4ogle3/post_about_the_disadvantages_of_functional/
>>772106
Не ad hominem, но важные уточнения контекста, для верной поправки на bias при чтении этой "критики"
Не 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)
>>772125
Шрифты плохо настроены?
Шрифты плохо настроены?
> That said, the claim that there are no purely functional versions of certain data structures and algorithms that have the same complexity as mutable versions is true. Although its better to say that there are certain data structures / algos for which immutable versions don't keep the same performance profile.
> But that doesn't mean haskell much less FP is fundamentally flawed for those algos and structures -- it just means you use the mutable versions of them. And FP in general and haskell in particular have no problem with mutation -- in haskell you just get to be more granular and controlled with it through explicit management of effects
>>772075
Если я правильно понял о чем ты, "наивный qsort" в хаскеле это никакой не qsort, а другой алгоритм, использующий похожую идею.
>>772081
Не буду защищать хаскель, не пишу на нем и никогда не делал бенчмарков связанных с ним, но этот челик по всей видимости путает иммутабельность и ФП.
Если я правильно понял о чем ты, "наивный qsort" в хаскеле это никакой не qsort, а другой алгоритм, использующий похожую идею.
>>772081
Не буду защищать хаскель, не пишу на нем и никогда не делал бенчмарков связанных с ним, но этот челик по всей видимости путает иммутабельность и ФП.
Ответы>>772140
>>772132
Он не путает, у него четкая бизнес-цель.
Хэши сильно оптимизнули, кстати, после именно этой попытки Харропа доебаться до мышей.
Он не путает, у него четкая бизнес-цель.
Хэши сильно оптимизнули, кстати, после именно этой попытки Харропа доебаться до мышей.
Ответы>>772177
Ответы>>772203
>>772214
Ты сейчас его сравниваешь с сишечкой, где код хорошо описывается выражением "нам дали ведро болтов и гаек, сейчас мы легко всего в 100000 строк построим из этого синхрофазотрон ни разу не уронив себе на ногу отбойный молоток, который мы построим отдельно всего в 25000 строк" или с каким-то идеальным языком, названия которого по причине скромности не приводишь?
Ты сейчас его сравниваешь с сишечкой, где код хорошо описывается выражением "нам дали ведро болтов и гаек, сейчас мы легко всего в 100000 строк построим из этого синхрофазотрон ни разу не уронив себе на ногу отбойный молоток, который мы построим отдельно всего в 25000 строк" или с каким-то идеальным языком, названия которого по причине скромности не приводишь?
Раз такой пири говно льётся друг на друга рекой, попрошу толковых ораторов свыше помочь Java-даунумне.
Хотелось бы знать и понимать то, о чем говорили ораторы свыше. Как я вижу, для этого нужны: дискретная математика, компьютерная схемотехника, что-то по устройству операционных систем и низкоуровневый язык(очевидная няшная?)
Поправьте, знатоки. Реквестирую от вас roadway, только не в стиле "Ищешь сегодня книжку ..."
Хотелось бы знать и понимать то, о чем говорили ораторы свыше. Как я вижу, для этого нужны: дискретная математика, компьютерная схемотехника, что-то по устройству операционных систем и низкоуровневый язык(очевидная няшная?)
Поправьте, знатоки. Реквестирую от вас roadway, только не в стиле "Ищешь сегодня книжку ..."
>>772241
Про джаву? Вот:
https://www.cs.virginia.edu/kim/publicity/pldi09tutorials/memory-efficient-java-tutorial.pdf
Про джаву? Вот:
https://www.cs.virginia.edu/kim/publicity/pldi09tutorials/memory-efficient-java-tutorial.pdf
Ответы>>772246
>>772244
Нет, в целом об устройстве ПК, принципах работы ОС, и игро-индустрия.
Нет, в целом об устройстве ПК, принципах работы ОС, и игро-индустрия.
>>772241
Не нужна. Неплохо для умения в реляционные СУБД иметь общее представление о first order logic, и только. Нужно будет графы зачем-нибудь пораскрашивать - в справочнике алгоритм посмотришь.
Общее понимание того как устроен процессор - на уровне "есть кэши уровней 1-N, шины обмена с памятью, и более тормозная периферия, причем latency и bandwith это разные вещи"
Общие понятие - вот ядро, вот сисколы, вот скедулер, вот процессы, вот os-level треды, вот между ними IPC.
10 ассемблерных инструкций чтобы иногда понять не хуиты ли понаделал вот тут мне компилятор
Все остальное - разбираешься по надобности
> дискретная математика
Не нужна. Неплохо для умения в реляционные СУБД иметь общее представление о first order logic, и только. Нужно будет графы зачем-нибудь пораскрашивать - в справочнике алгоритм посмотришь.
> компьютерная схемотехника
Общее понимание того как устроен процессор - на уровне "есть кэши уровней 1-N, шины обмена с памятью, и более тормозная периферия, причем latency и bandwith это разные вещи"
> что-то по устройству операционных систем
Общие понятие - вот ядро, вот сисколы, вот скедулер, вот процессы, вот os-level треды, вот между ними IPC.
> и низкоуровневый язык
10 ассемблерных инструкций чтобы иногда понять не хуиты ли понаделал вот тут мне компилятор
Все остальное - разбираешься по надобности
>>772261
Пусть и суперкратко, но годно. Заскринил, будет хотя бы от чего оттолкнуться
Пусть и суперкратко, но годно. Заскринил, будет хотя бы от чего оттолкнуться
>>772224
Так ты не путай свои стилистические идиосинкразии уровня "мда, неэлегантно у вас здесь, сударь, выходит, неэлегантно-с" с "у хаскеля проблемы с mutable state".
Так ты не путай свои стилистические идиосинкразии уровня "мда, неэлегантно у вас здесь, сударь, выходит, неэлегантно-с" с "у хаскеля проблемы с mutable state".
101 Кб, 890x670
>>772261
А потом получаем непонимание того как происходит переполнение при арифметических операциях, откуда берутся неточности при работе с флоатами и как писать/читать/менять сложные логические условия.
>дискретная математика не нужна.
А потом получаем непонимание того как происходит переполнение при арифметических операциях, откуда берутся неточности при работе с флоатами и как писать/читать/менять сложные логические условия.
>>771896
Это мимо.
Это мимо.
>>772274
Человеку, который это не понимает, никакая дискретка не поможет.
>А потом получаем непонимание того как происходит переполнение при арифметических операциях, откуда берутся неточности при работе с флоатами и как писать/читать/менять сложные логические условия.
Человеку, который это не понимает, никакая дискретка не поможет.
>>772274
Тебе дай, ты бы его циклические группы для этого учить заставил. Столкнется с этим сам - прочитает за вечер что это такое и что с этим делать.
То же самое. Большинство программистов вообще ни разу в жизни с этим не сталкивались, и большинство из этого большинства - и не столкнутся.
Он же джавщик - значит взять Drools и поебаться с ним на выходных. Когда и если возникнет надобность. После выходных поймет что не совсем понимает как эта хуйня работает - возьмет книжку, почитает.
В процессе решения конкретной задачи все на порядок лучше осваивается и выучивается чем этот стандартный bottom-up подход "докажем пока все теоремы из первого тома, а зачем мы это делали вы узнаете на пятом курсе"
> непонимание того как происходит переполнение при арифметических операциях
Тебе дай, ты бы его циклические группы для этого учить заставил. Столкнется с этим сам - прочитает за вечер что это такое и что с этим делать.
> откуда берутся неточности при работе с флоатами
То же самое. Большинство программистов вообще ни разу в жизни с этим не сталкивались, и большинство из этого большинства - и не столкнутся.
> как писать/читать/менять сложные логические условия
Он же джавщик - значит взять Drools и поебаться с ним на выходных. Когда и если возникнет надобность. После выходных поймет что не совсем понимает как эта хуйня работает - возьмет книжку, почитает.
В процессе решения конкретной задачи все на порядок лучше осваивается и выучивается чем этот стандартный bottom-up подход "докажем пока все теоремы из первого тома, а зачем мы это делали вы узнаете на пятом курсе"
Ответы>>772359
>>772290
Даже веб-программисту надо знать законы де Моргана и понимать, почему вдруг оказалось, что 30%*70% != 21%.
Даже веб-программисту надо знать законы де Моргана и понимать, почему вдруг оказалось, что 30%*70% != 21%.
>>772290
Переполнения и флоаты - чтоб считать.
писать/читать/менять сложные логические условия - чтоб, например, валидатор был нормальный, а не лапша из 50 if-ов, причем на каждую формочку своя, совпадающая с остальными на 90%
Переполнения и флоаты - чтоб считать.
писать/читать/менять сложные логические условия - чтоб, например, валидатор был нормальный, а не лапша из 50 if-ов, причем на каждую формочку своя, совпадающая с остальными на 90%
>>772297
Ему бы про транзакции хотя бы самые основы понять, 21% это хоть сразу вылезет и нащальника надает
Ему бы про транзакции хотя бы самые основы понять, 21% это хоть сразу вылезет и нащальника надает
Ответы>>772328
>>772300
Мне за это заплатят больше? Нет? Ну и иди нахуй со своим задротским говном, мне и без него неплохо живётся.
>писать/читать/менять сложные логические условия - чтоб, например, валидатор был нормальный, а не лапша из 50 if-ов, причем на каждую формочку своя, совпадающая с остальными на 90%
Мне за это заплатят больше? Нет? Ну и иди нахуй со своим задротским говном, мне и без него неплохо живётся.
Ответы>>772370
>>772293
Боюсь он просто не будет представлять размеры пробела в своих знаниях и какую книжку ему надо прочитать. Поэтому всё ограничится прогулкой по стековерфлоу и перебором вариантов или задалбыванием опытного коллеги.
Потому что руководство не доверит им работу на которой с такими проблемами можно столкнуться.
Когда он напишет что-то вроде !(!A || !B) у него ничего нигде на защемит, и необходимости что-либо читать он не осознает.
>Столкнется с этим сам - прочитает за вечер
>возьмет книжку, почитает.
Боюсь он просто не будет представлять размеры пробела в своих знаниях и какую книжку ему надо прочитать. Поэтому всё ограничится прогулкой по стековерфлоу и перебором вариантов или задалбыванием опытного коллеги.
>большинство из этого большинства - и не столкнутся.
Потому что руководство не доверит им работу на которой с такими проблемами можно столкнуться.
>Он же джавщик - значит взять Drools и поебаться с ним на выходных. Когда и если возникнет надобность.
Когда он напишет что-то вроде !(!A || !B) у него ничего нигде на защемит, и необходимости что-либо читать он не осознает.
>>771671
Откуда этот фантазёр знает как я делаю?
В ООП нет гетерогенных списков, обмудок, единственный ОО-язык который их позволяет делать - это Скала.
>Это не я делаю, это тот, у которого "90% программ пишутся и без экзистенциальных типов" так делает.
Откуда этот фантазёр знает как я делаю?
>В ООП гетерогенные списки везде
В ООП нет гетерогенных списков, обмудок, единственный ОО-язык который их позволяет делать - это Скала.
Ответы>>772775
>>772359
Так поясни мне, пожалуйста, как не быть тупым. Напиши роад-мэп, чтобы я знал.
Я тут за математику сел плотно. Алгебра + Лин.Алгебра + Тригонометрия. Плюс комбинаторика.
Что посоветуешь по дискретной математике? Что ещё добавить?
Так поясни мне, пожалуйста, как не быть тупым. Напиши роад-мэп, чтобы я знал.
Я тут за математику сел плотно. Алгебра + Лин.Алгебра + Тригонометрия. Плюс комбинаторика.
Что посоветуешь по дискретной математике? Что ещё добавить?
>>771661
На основании чего ты считаешь схему функциональным языком? Да и паттерн матчинга нет только в стандарте, в котором есть средства для его реализации (коих немеряно).
>и функциональные языки без паттерн матчинга (Scheme)
На основании чего ты считаешь схему функциональным языком? Да и паттерн матчинга нет только в стандарте, в котором есть средства для его реализации (коих немеряно).
>>772468
А на основании чего ты её таковой не считаешь? В твоем представлении ФП = ML-like?
А на основании чего ты её таковой не считаешь? В твоем представлении ФП = ML-like?
Ответы>>772489
>>772468
Чего-чего немеряно? Реализаций сопоставления с образцом на схеме? Их, полноценных, едва ли на пальцы одной руки хватит.
>коих немеряно
Чего-чего немеряно? Реализаций сопоставления с образцом на схеме? Их, полноценных, едва ли на пальцы одной руки хватит.
Ответы>>772513
>>772491
Да хуле ты к словам цепляешься, епты бля. Главное, что они есть. А вообще, почти в каждой имплементации есть своя реализация, в chicken есть, в guile есть. Ну и каждый уважающий себя скобкоеб писал свою, я, например, писал
Да хуле ты к словам цепляешься, епты бля. Главное, что они есть. А вообще, почти в каждой имплементации есть своя реализация, в chicken есть, в guile есть. Ну и каждый уважающий себя скобкоеб писал свою, я, например, писал
Ответы>>772530
>>772489
Схема достаточно чиста. Но а если уж совсем занудничать, то может оказаться, что в мире нет ни одного функционально чистого языка.
А вот отсутствие АТД и сопоставления с образцом в схеме делает её менее ФП в моём представлении.
>>772513
Писал-то каждый, но пригодных для применения из них - единицы.
Схема достаточно чиста. Но а если уж совсем занудничать, то может оказаться, что в мире нет ни одного функционально чистого языка.
А вот отсутствие АТД и сопоставления с образцом в схеме делает её менее ФП в моём представлении.
>>772513
Писал-то каждый, но пригодных для применения из них - единицы.
Ответы>>772798
>>772549
Меня и так не заставят
Меня и так не заставят
>>770300
О, дружище, "ООП хорошо для GUI" - это примерно такой же спид, как и "ООП хорошо для всего" - когда программисты обожглись об ООП, но проблемы гуйни глубже формошлёпства не исследовали, поэтому решили "ну ладно, ООП для %моей_предметной_области% - говно, но ведь КНОПКА - это же объект!!1". Ты ведь понимаешь, о чем я, а уёбок? Повторю другими словами на всякий случай: когда ты был маленьким и глупым и нихуя не шарил в своей предметной области, ты думал, что "всё есть (некий абстрактный) объект (про который я нихуя не знаю)" и что ООП идеально этот факт моделирует. Потом ты немного подрос и поумнел, и выделил в своей области множество взаимосвязей и закономерностей. И она наполнилась морфизмами, функторами, отражениями, естественными преобразованиями, пределами, копределами, сопряжениями и прочими знаниями, для моделирования которых убогое ООП ну никак не подходит. А гуй для тебя так и остался той областью, в которой ты нихуя не шаришь. Так вот, уёбок, не надо экстраполировать свою самоуверенность на все отрасли человеческой деятельности. Если ты охуенный спец по обработке сигналов, это еще не значит, что ты охуенный спец по чистке туалетов или лепке крудов. И если ты не видишь в лепке крудов никаких закономерностей, это еще не значит, что их там нет, и что любой виджет есть объект и не более того. Закономерностей там более чем дохуя. Я вот с ходу могу сказать, что гуйню лучше моделировать стрелками, чем объектами, а истинный спец по гуи тебе наверняка категорий пять навернёт, охватывающих визуализацию, валидацию, интернационализацию и локализацию, лейаут, помощь людям с ограниченными возможностями и хуй знает, что там еще может быть.. Поэтому пиши про то, что знаешь, а про гуй пусть лучше спецы по гуи напишут, от них то мы и узнаем, столь ли там хорошо ООП, или приходится еще каким-нибудь xml-ем в жопу поябываться.
>На ООП хорошо ложатся некоторые задачи, например всякие там ГУЙовины
О, дружище, "ООП хорошо для GUI" - это примерно такой же спид, как и "ООП хорошо для всего" - когда программисты обожглись об ООП, но проблемы гуйни глубже формошлёпства не исследовали, поэтому решили "ну ладно, ООП для %моей_предметной_области% - говно, но ведь КНОПКА - это же объект!!1". Ты ведь понимаешь, о чем я, а уёбок? Повторю другими словами на всякий случай: когда ты был маленьким и глупым и нихуя не шарил в своей предметной области, ты думал, что "всё есть (некий абстрактный) объект (про который я нихуя не знаю)" и что ООП идеально этот факт моделирует. Потом ты немного подрос и поумнел, и выделил в своей области множество взаимосвязей и закономерностей. И она наполнилась морфизмами, функторами, отражениями, естественными преобразованиями, пределами, копределами, сопряжениями и прочими знаниями, для моделирования которых убогое ООП ну никак не подходит. А гуй для тебя так и остался той областью, в которой ты нихуя не шаришь. Так вот, уёбок, не надо экстраполировать свою самоуверенность на все отрасли человеческой деятельности. Если ты охуенный спец по обработке сигналов, это еще не значит, что ты охуенный спец по чистке туалетов или лепке крудов. И если ты не видишь в лепке крудов никаких закономерностей, это еще не значит, что их там нет, и что любой виджет есть объект и не более того. Закономерностей там более чем дохуя. Я вот с ходу могу сказать, что гуйню лучше моделировать стрелками, чем объектами, а истинный спец по гуи тебе наверняка категорий пять навернёт, охватывающих визуализацию, валидацию, интернационализацию и локализацию, лейаут, помощь людям с ограниченными возможностями и хуй знает, что там еще может быть.. Поэтому пиши про то, что знаешь, а про гуй пусть лучше спецы по гуи напишут, от них то мы и узнаем, столь ли там хорошо ООП, или приходится еще каким-нибудь xml-ем в жопу поябываться.
>>770268 (OP)
Класс - это тупо программный модуль, изолированный средствами языка. Ты можешь писать на сях изолированные модули, можешь на плюсах в виде классов. Реальное ООП как в смартталке (или как его) не реализовали ибо там помоему упорото совсем.
ООП живо, потому что можно одну группу макак отделить от другой, а между ними повесить интерфейсы и макаки не будут мешать друг другу работая в рамках контракта интерфейса.
ВСЕ, никакие блять наследования и полиморфизмы и использование повторного кода, а тупо возможно разбиение макак одной задачи на группы и увеличить скорость разработки - рынок решил (а не программисты, как они свято верят в это)
>ООП сложно, оно не нужно, я не осилил
Класс - это тупо программный модуль, изолированный средствами языка. Ты можешь писать на сях изолированные модули, можешь на плюсах в виде классов. Реальное ООП как в смартталке (или как его) не реализовали ибо там помоему упорото совсем.
ООП живо, потому что можно одну группу макак отделить от другой, а между ними повесить интерфейсы и макаки не будут мешать друг другу работая в рамках контракта интерфейса.
ВСЕ, никакие блять наследования и полиморфизмы и использование повторного кода, а тупо возможно разбиение макак одной задачи на группы и увеличить скорость разработки - рынок решил (а не программисты, как они свято верят в это)
Ответы>>773082
>>770268 (OP)
Блядь, всегда проигрываю с того, когда прилетают сюда обладатели функциональщины головного мозга(хотя сам ФП котирую) и начинаются кукареки с линзами, бананами, гиломорфизмами, классами типов и пр. При этом всегда уходят в крайности: ООП маздай, пыхопидоры сосут, крестоблядь не человек. Вот только, вероятно, у большинства здешних "мамкиных хаскелистов" проектов больше 20к строк кода и не было, а гитхаб акк так и не наполнен проектами на божественном ML/Haskell/Agda(если вообще наполнен).
Блядь, всегда проигрываю с того, когда прилетают сюда обладатели функциональщины головного мозга(хотя сам ФП котирую) и начинаются кукареки с линзами, бананами, гиломорфизмами, классами типов и пр. При этом всегда уходят в крайности: ООП маздай, пыхопидоры сосут, крестоблядь не человек. Вот только, вероятно, у большинства здешних "мамкиных хаскелистов" проектов больше 20к строк кода и не было, а гитхаб акк так и не наполнен проектами на божественном ML/Haskell/Agda(если вообще наполнен).
Ответы>>772766
>>772359
Ты прав, скорее всего будет именно так.
Но накачивать ньюба всем около-CS матаном под завязку - тоже не выход. Без реальной задачи и потребности ее решить (а не "сдать курсовик" и подобное) КПД будет меньше чем у паровоза.
Люди делятся на тех кто хочет сделать по-человечески и да нахер оно мне надо, и так платят (>>772311). С первыми вариант "почитать книжку on demand" работает, со вторыми не работает ничего, хоть в Стэнфорд его отправь. Традиционный ВУЗоподход в результате бессмысленно мучает первых и никак не влияет на вторых.
>он просто не будет представлять размеры пробела в своих знаниях и какую книжку ему надо прочитать. Поэтому всё ограничится прогулкой по стековерфлоу
Ты прав, скорее всего будет именно так.
Но накачивать ньюба всем около-CS матаном под завязку - тоже не выход. Без реальной задачи и потребности ее решить (а не "сдать курсовик" и подобное) КПД будет меньше чем у паровоза.
Люди делятся на тех кто хочет сделать по-человечески и да нахер оно мне надо, и так платят (>>772311). С первыми вариант "почитать книжку on demand" работает, со вторыми не работает ничего, хоть в Стэнфорд его отправь. Традиционный ВУЗоподход в результате бессмысленно мучает первых и никак не влияет на вторых.
>>772633
Те кто исследовал ЧСХ придумали functional reactive programming а никакое не ООП.
Отлично ложится на комбинаторы.
https://www.youtube.com/watch?v=fRdU5yHsAA4
Заодно ответ на >>772676
ООП хорошо подходило для сочетания двух условий - "у нас есть задачи дискретно-событийного моделирования" и "у нас есть Algol60 и больше нихуя". К Алголу60 оказалось очень легко прикрутить несколько полезных (для той задачи) хаков, которые (на тех компьютерах) еще и были дешевы в смысле скорости. Сначала они хотели сделать препроцессор (что логично - Страуструп через много лет тоже начал с этого и собирался этим и ограничиться), но им понадобились и некоторые другие расширения Алгола и ограничиться препроцессором не удалось.
И все эти "Концепции ООП" появлялись именно таким способом: вот интересный (и дешевый в реализации) эффект — как мы можем его использовать? Началось все с того, что понадобилось придумать новый (быстрый) способ передачи параметров в процедуры. Стандартные алголовские способы: по значению и по имени были медленными по разным причинам. Тогда Хоар изобрел ссылки и null. Раз уж структурная эквивалентность оказалось сложной в реализации, сравнивать стали адреса, по которым "объекты" располагаются — появилось identity. Обратили внимание на то, что блок памяти B, структурированный в начале так же, как и блок A можно обрабатывать процедурами, написанными для работы с A — появился "префиксинг" (даже синтаксически объявление класса родителя было префиксным), под который потом подвели идеологию и назвали "наследованием" (ну и понятно, почему сначала никаких "множественных наследований" не было — что такое "множественный префиксинг"?). К рекордам добавили процедуры, диспетчеризующиеся по одному аргументу. Почему именно по одному? Потому что по n > 1 — сложно в реализации.
Прекрасно решили свои задачи дискретно-событийного моделирования, на тех компьютерах что у них были, и успокоились. Но пришел Алан Кей и все испортил. Кей и прочие смолтокеры захотели сделать не такой вот "натянутый" на структурное программирование ООП, а идеологически чистый и непротиворечивый. Для этого они подвели базу под все эти технические срезания углов. Получилась чистая реализация идей, придуманных для быстроты и простоты реализации, только медленная и сложная. Они не смогли все это заставить вертеться с приемлемой скоростью до 90-х годов, когда стало уже поздно. Чтоб ввести Симула-лайк ООП в мейнстрим понадобилось только (временно) отказаться от сборщика мусора. Однако, вся философия и методология ООП, паттерны и юнит-тесты и т.д., придуманные смолтокерами не пропали, а были адаптированы мейнстримом.
Смолток — это не "изначальное древнее ООП", а возрождение умирающего старого и реформация неправильного ООП, загнувшееся, правда, раньше нем неправильное, пока по настоящему древнее ООП все продолжало умирать. Ну и, понятно, философия ООП, которая превратила все картины, загораживающие дырки на обоях, в "краеугольные камни" концепции и "имманентные особенности человеческого мЫшленья"
> программисты обожглись об ООП, но проблемы гуйни глубже формошлёпства не исследовали
Те кто исследовал ЧСХ придумали functional reactive programming а никакое не ООП.
> лейаут
Отлично ложится на комбинаторы.
https://www.youtube.com/watch?v=fRdU5yHsAA4
Заодно ответ на >>772676
ООП хорошо подходило для сочетания двух условий - "у нас есть задачи дискретно-событийного моделирования" и "у нас есть Algol60 и больше нихуя". К Алголу60 оказалось очень легко прикрутить несколько полезных (для той задачи) хаков, которые (на тех компьютерах) еще и были дешевы в смысле скорости. Сначала они хотели сделать препроцессор (что логично - Страуструп через много лет тоже начал с этого и собирался этим и ограничиться), но им понадобились и некоторые другие расширения Алгола и ограничиться препроцессором не удалось.
И все эти "Концепции ООП" появлялись именно таким способом: вот интересный (и дешевый в реализации) эффект — как мы можем его использовать? Началось все с того, что понадобилось придумать новый (быстрый) способ передачи параметров в процедуры. Стандартные алголовские способы: по значению и по имени были медленными по разным причинам. Тогда Хоар изобрел ссылки и null. Раз уж структурная эквивалентность оказалось сложной в реализации, сравнивать стали адреса, по которым "объекты" располагаются — появилось identity. Обратили внимание на то, что блок памяти B, структурированный в начале так же, как и блок A можно обрабатывать процедурами, написанными для работы с A — появился "префиксинг" (даже синтаксически объявление класса родителя было префиксным), под который потом подвели идеологию и назвали "наследованием" (ну и понятно, почему сначала никаких "множественных наследований" не было — что такое "множественный префиксинг"?). К рекордам добавили процедуры, диспетчеризующиеся по одному аргументу. Почему именно по одному? Потому что по n > 1 — сложно в реализации.
Прекрасно решили свои задачи дискретно-событийного моделирования, на тех компьютерах что у них были, и успокоились. Но пришел Алан Кей и все испортил. Кей и прочие смолтокеры захотели сделать не такой вот "натянутый" на структурное программирование ООП, а идеологически чистый и непротиворечивый. Для этого они подвели базу под все эти технические срезания углов. Получилась чистая реализация идей, придуманных для быстроты и простоты реализации, только медленная и сложная. Они не смогли все это заставить вертеться с приемлемой скоростью до 90-х годов, когда стало уже поздно. Чтоб ввести Симула-лайк ООП в мейнстрим понадобилось только (временно) отказаться от сборщика мусора. Однако, вся философия и методология ООП, паттерны и юнит-тесты и т.д., придуманные смолтокерами не пропали, а были адаптированы мейнстримом.
Смолток — это не "изначальное древнее ООП", а возрождение умирающего старого и реформация неправильного ООП, загнувшееся, правда, раньше нем неправильное, пока по настоящему древнее ООП все продолжало умирать. Ну и, понятно, философия ООП, которая превратила все картины, загораживающие дырки на обоях, в "краеугольные камни" концепции и "имманентные особенности человеческого мЫшленья"
>>772633
Те кто исследовал ЧСХ придумали functional reactive programming а никакое не ООП.
Отлично ложится на комбинаторы.
https://www.youtube.com/watch?v=fRdU5yHsAA4
Заодно ответ на >>772676
ООП хорошо подходило для сочетания двух условий - "у нас есть задачи дискретно-событийного моделирования" и "у нас есть Algol60 и больше нихуя". К Алголу60 оказалось очень легко прикрутить несколько полезных (для той задачи) хаков, которые (на тех компьютерах) еще и были дешевы в смысле скорости. Сначала они хотели сделать препроцессор (что логично - Страуструп через много лет тоже начал с этого и собирался этим и ограничиться), но им понадобились и некоторые другие расширения Алгола и ограничиться препроцессором не удалось.
И все эти "Концепции ООП" появлялись именно таким способом: вот интересный (и дешевый в реализации) эффект — как мы можем его использовать? Началось все с того, что понадобилось придумать новый (быстрый) способ передачи параметров в процедуры. Стандартные алголовские способы: по значению и по имени были медленными по разным причинам. Тогда Хоар изобрел ссылки и null. Раз уж структурная эквивалентность оказалось сложной в реализации, сравнивать стали адреса, по которым "объекты" располагаются — появилось identity. Обратили внимание на то, что блок памяти B, структурированный в начале так же, как и блок A можно обрабатывать процедурами, написанными для работы с A — появился "префиксинг" (даже синтаксически объявление класса родителя было префиксным), под который потом подвели идеологию и назвали "наследованием" (ну и понятно, почему сначала никаких "множественных наследований" не было — что такое "множественный префиксинг"?). К рекордам добавили процедуры, диспетчеризующиеся по одному аргументу. Почему именно по одному? Потому что по n > 1 — сложно в реализации.
Прекрасно решили свои задачи дискретно-событийного моделирования, на тех компьютерах что у них были, и успокоились. Но пришел Алан Кей и все испортил. Кей и прочие смолтокеры захотели сделать не такой вот "натянутый" на структурное программирование ООП, а идеологически чистый и непротиворечивый. Для этого они подвели базу под все эти технические срезания углов. Получилась чистая реализация идей, придуманных для быстроты и простоты реализации, только медленная и сложная. Они не смогли все это заставить вертеться с приемлемой скоростью до 90-х годов, когда стало уже поздно. Чтоб ввести Симула-лайк ООП в мейнстрим понадобилось только (временно) отказаться от сборщика мусора. Однако, вся философия и методология ООП, паттерны и юнит-тесты и т.д., придуманные смолтокерами не пропали, а были адаптированы мейнстримом.
Смолток — это не "изначальное древнее ООП", а возрождение умирающего старого и реформация неправильного ООП, загнувшееся, правда, раньше нем неправильное, пока по настоящему древнее ООП все продолжало умирать. Ну и, понятно, философия ООП, которая превратила все картины, загораживающие дырки на обоях, в "краеугольные камни" концепции и "имманентные особенности человеческого мЫшленья"
> программисты обожглись об ООП, но проблемы гуйни глубже формошлёпства не исследовали
Те кто исследовал ЧСХ придумали functional reactive programming а никакое не ООП.
> лейаут
Отлично ложится на комбинаторы.
https://www.youtube.com/watch?v=fRdU5yHsAA4
Заодно ответ на >>772676
ООП хорошо подходило для сочетания двух условий - "у нас есть задачи дискретно-событийного моделирования" и "у нас есть Algol60 и больше нихуя". К Алголу60 оказалось очень легко прикрутить несколько полезных (для той задачи) хаков, которые (на тех компьютерах) еще и были дешевы в смысле скорости. Сначала они хотели сделать препроцессор (что логично - Страуструп через много лет тоже начал с этого и собирался этим и ограничиться), но им понадобились и некоторые другие расширения Алгола и ограничиться препроцессором не удалось.
И все эти "Концепции ООП" появлялись именно таким способом: вот интересный (и дешевый в реализации) эффект — как мы можем его использовать? Началось все с того, что понадобилось придумать новый (быстрый) способ передачи параметров в процедуры. Стандартные алголовские способы: по значению и по имени были медленными по разным причинам. Тогда Хоар изобрел ссылки и null. Раз уж структурная эквивалентность оказалось сложной в реализации, сравнивать стали адреса, по которым "объекты" располагаются — появилось identity. Обратили внимание на то, что блок памяти B, структурированный в начале так же, как и блок A можно обрабатывать процедурами, написанными для работы с A — появился "префиксинг" (даже синтаксически объявление класса родителя было префиксным), под который потом подвели идеологию и назвали "наследованием" (ну и понятно, почему сначала никаких "множественных наследований" не было — что такое "множественный префиксинг"?). К рекордам добавили процедуры, диспетчеризующиеся по одному аргументу. Почему именно по одному? Потому что по n > 1 — сложно в реализации.
Прекрасно решили свои задачи дискретно-событийного моделирования, на тех компьютерах что у них были, и успокоились. Но пришел Алан Кей и все испортил. Кей и прочие смолтокеры захотели сделать не такой вот "натянутый" на структурное программирование ООП, а идеологически чистый и непротиворечивый. Для этого они подвели базу под все эти технические срезания углов. Получилась чистая реализация идей, придуманных для быстроты и простоты реализации, только медленная и сложная. Они не смогли все это заставить вертеться с приемлемой скоростью до 90-х годов, когда стало уже поздно. Чтоб ввести Симула-лайк ООП в мейнстрим понадобилось только (временно) отказаться от сборщика мусора. Однако, вся философия и методология ООП, паттерны и юнит-тесты и т.д., придуманные смолтокерами не пропали, а были адаптированы мейнстримом.
Смолток — это не "изначальное древнее ООП", а возрождение умирающего старого и реформация неправильного ООП, загнувшееся, правда, раньше нем неправильное, пока по настоящему древнее ООП все продолжало умирать. Ну и, понятно, философия ООП, которая превратила все картины, загораживающие дырки на обоях, в "краеугольные камни" концепции и "имманентные особенности человеческого мЫшленья"
>>771716
Но иногда это самый правильный подход - оквадратить головы.
> то же самое что автомат для стрижки - который тоже неплохо работает, если у клиента голова квадратная
Но иногда это самый правильный подход - оквадратить головы.
> But we should not be too quick to cast aside our OO tools. For an internal business tool, we can be the American Psychiatric Association - forcing users to agree on a single unambiguous classifaction, to draw lines in the sand that are arbitrary (“5 months of grief is normal, 6 months is depression”) but nonetheless very useful. In some organizations I’ve found that the very process of codifying the rules - forcing business users to agree once and for all on whether the tripartite division of a Hong Kong contract is the same thing as the bipartite split of a three-part London contract or a different kind of thing - is, if anything, more useful than the working software we produce. Done well, the resulting software can be more authoritative, more discoverable, perhaps even more correct than the loose-schemaed functional equivalent.
> http://m50d.github.io/2014/12/08/object-oriented-essentialism.html
>>772391
Потому что это единственный язык с неигрушечной типизацией ООП.
Цену за это пришлось заплатить такую, что хуйзнает, надо ли все это было делать.
В общем-то нет языка, который может "запарить" мозг сильнее, чем скала. Скала имеет мозговыносящую систему типов, не имеющую аналогов в том смысле, что нет другого языка, в котором ООП было бы адекватно статически типизировано. Это крайне сложная и амбициозная задача, буквально все остальные создатели ООЯ на каком-то этапе плюнули и решили: "Статическая типизация — это сложно, лучше будем динамически кастить". Правда, весь этот околодинамический цирк с конями в скале остался "для совместимости" (и дополнительного выноса мозга)
>единственный ОО-язык который их позволяет делать - это Скала
Потому что это единственный язык с неигрушечной типизацией ООП.
Цену за это пришлось заплатить такую, что хуйзнает, надо ли все это было делать.
В общем-то нет языка, который может "запарить" мозг сильнее, чем скала. Скала имеет мозговыносящую систему типов, не имеющую аналогов в том смысле, что нет другого языка, в котором ООП было бы адекватно статически типизировано. Это крайне сложная и амбициозная задача, буквально все остальные создатели ООЯ на каком-то этапе плюнули и решили: "Статическая типизация — это сложно, лучше будем динамически кастить". Правда, весь этот околодинамический цирк с конями в скале остался "для совместимости" (и дополнительного выноса мозга)
На ОО Objective-C и Swift пишутся программы для лучшей ОС, которую используют программисты в достойнейших компаниях – macOS. А если работодатель не купил вам аймак или макбук – значит, он жид ебаный.
По поводу Obj-C – ладно, плохой аргумент, просто какой язык использовался Эпплом с 1983 года, такой и остался, с небольшими изменениями.
Но Swift разработан с учётом всех best practices. И всё равно имеет ОО парадигму.
По поводу Obj-C – ладно, плохой аргумент, просто какой язык использовался Эпплом с 1983 года, такой и остался, с небольшими изменениями.
Но Swift разработан с учётом всех best practices. И всё равно имеет ОО парадигму.
Ответы>>772799
>>772530
Что значит "достаточно" чиста? Если одна и та же функция может выдать разный результат при одинаковых аргументах, то ни о какой функциональной чистоте и речи быть не может. А еще call/cc, где континуация не то, что не возвращает ничего (что уже противоречит принципам фп), она не возвращается в принципе.
Какое там адт, когда типов, в принципе, нет.
>Схема достаточно чиста.
Что значит "достаточно" чиста? Если одна и та же функция может выдать разный результат при одинаковых аргументах, то ни о какой функциональной чистоте и речи быть не может. А еще call/cc, где континуация не то, что не возвращает ничего (что уже противоречит принципам фп), она не возвращается в принципе.
>АТД
Какое там адт, когда типов, в принципе, нет.
>>772794
Как же, как же, помним, помним.
iPhone был тоже "разработан с учетом всех best practices". До какой версии в нем не было даже copy и paste? НИНУЖНА ведь.
iPad тоже был "разработан с учетом всех best practices". Сколько лет у него не было номрального стилуса? НИНУЖНА ведь.
Вот и в этом уёбище все то же самое. Огрызкопрограммистам ничего не нужно, у них есть iTunes, AppleTV и XCode.
>Swift разработан с учётом всех best practices
Как же, как же, помним, помним.
iPhone был тоже "разработан с учетом всех best practices". До какой версии в нем не было даже copy и paste? НИНУЖНА ведь.
iPad тоже был "разработан с учетом всех best practices". Сколько лет у него не было номрального стилуса? НИНУЖНА ведь.
Вот и в этом уёбище все то же самое. Огрызкопрограммистам ничего не нужно, у них есть iTunes, AppleTV и XCode.
Ответы>>772804
>>772798
Ведь если возвращать несуществующий костыльный фейк "состояние вселенной", все магическим образом меняется.
>континуация не то, что не возвращает ничего (что уже противоречит принципам фп),
Ведь если возвращать несуществующий костыльный фейк "состояние вселенной", все магическим образом меняется.
Ответы>>772814
>>772799
Вот что действительно не нужно. Удачи им с их стилусами по 100$, который при этом отсосёт с заглотом у проф. стилусов для рисования за ту же цену.
Да нет, это ты уебан просто, не сравнивай свифт с го.
Алсо, он у эпла как оарп у майкрософта – компания его спонсирует, но ничем анально не ограждает.
>Сколько лет у него не было номрального стилуса
Вот что действительно не нужно. Удачи им с их стилусами по 100$, который при этом отсосёт с заглотом у проф. стилусов для рисования за ту же цену.
>Вот и в этом уёбище все то же самое.
Да нет, это ты уебан просто, не сравнивай свифт с го.
Алсо, он у эпла как оарп у майкрософта – компания его спонсирует, но ничем анально не ограждает.
>>772804
Стилус - не для рисования, уебан ты эдакий.
Это на огрызках с ним больше ничего нельзя кроме рисования сделать, потому что десятилетия НИНУЖНА привели к тому у огрызка вместо поддержки стилуса в приложениях, SDK и API, пронизывающих всю экосистему (https://blogs.windows.com/buildingapps/2016/04/06/create-ideate-and-collaborate-build-apps-powered-by-windows-ink/) нет НИХУЯ кроме "можно нарисовать котика! yay!"
Стилус - не для рисования, уебан ты эдакий.
Это на огрызках с ним больше ничего нельзя кроме рисования сделать, потому что десятилетия НИНУЖНА привели к тому у огрызка вместо поддержки стилуса в приложениях, SDK и API, пронизывающих всю экосистему (https://blogs.windows.com/buildingapps/2016/04/06/create-ideate-and-collaborate-build-apps-powered-by-windows-ink/) нет НИХУЯ кроме "можно нарисовать котика! yay!"
>>772808
Стилус в таком устройстве – бесполезная хуйня ради хуйни, как и на телефонах.
Я-то в чём оговорился, поехавший мамкин нищеброд-борщехлёб? Это модерновый язык, в котором куча фич, в том числе и из функциональщины, без "нинужна" как в го.
Стилус в таком устройстве – бесполезная хуйня ради хуйни, как и на телефонах.
>Я и не сравнивал, но ты сам проговорился.
Я-то в чём оговорился, поехавший мамкин нищеброд-борщехлёб? Это модерновый язык, в котором куча фич, в том числе и из функциональщины, без "нинужна" как в го.
Ответы>>772813
>>772810
Огромная-преогромная. Даже до лютой императивщины Java 8 как до Луны, не говоря уж о C#.
Ясно, понятно. Не видел, не пробовал, не знаешь.
НИНУЖНА
>куча фич, в том числе и из функциональщины
Огромная-преогромная. Даже до лютой императивщины Java 8 как до Луны, не говоря уж о C#.
>бесполезная хуйня
Ясно, понятно. Не видел, не пробовал, не знаешь.
НИНУЖНА
>>772800
Не, я хуйню сказал, "ничего" в схеме это тоже объект. Но акцент был вот на этом:
Не, я хуйню сказал, "ничего" в схеме это тоже объект. Но акцент был вот на этом:
>она не возвращается в принципе
>>772813
Щас бы написать хуйню не видев кода на свифте...
Ну и нахуя же он мне на системе, разработанной для тыканья пальцем? Можешь дальше свои окошки в оконном режиме на шиндовз планшетах двигать им, оч полезно.
>Даже до лютой императивщины Java 8 как до Луны, не говоря уж о C#.
Щас бы написать хуйню не видев кода на свифте...
>НИНУЖНА
Ну и нахуя же он мне на системе, разработанной для тыканья пальцем? Можешь дальше свои окошки в оконном режиме на шиндовз планшетах двигать им, оч полезно.
>>772813
Ах да, ты же скинул видосик где им пишут заметочки и рисуют! Ахуеть полезность!
Ах да, ты же скинул видосик где им пишут заметочки и рисуют! Ахуеть полезность!
Ответы>>772820
>>772798
Которое НИНУЖНА
>А еще call/cc
Которое НИНУЖНА
>Это вполне реализуемо в языках с полноценным call-with-current-continuation, то есть код функции будет одинаковым для T, для AnyMonad<T>
>>772820
На десктопной ос в планшете ясен хуй что без него всё печально, чо уж. Не можем разработать ПО - разработаем палочку с блютусом.
>маааам, мне впаривают хуйню ради хуйни!
>ну дык не ведись, хуле ты.
>но ведь я хачу быдь нитаким как все с айпадами... и у меня нет денег...
На десктопной ос в планшете ясен хуй что без него всё печально, чо уж. Не можем разработать ПО - разработаем палочку с блютусом.
Ответы>>772825
127 Кб, 820x482
>>772824
>маааам, я хочу эту хуйню только от огрызкааа
>но ведь огрызки это сделают только к 2030
>мааам, это будет ИННОВАЦИЯ
Ответы>>772828
>>772808
Стандартный аргумент когда больше нечего противопоставить:
- Смотри, а я на голове стоять умею!
Стандартный аргумент когда больше нечего противопоставить:
- Смотри, а я на голове стоять умею!
Ответы>>772832
>>772825
А чо, кто-то кроме огрызка выпускает нормальные планшеты, а не хуйню на яве без планшетных приложений/хуйню с десктопной ОС, которая либо ебаный кирпич похуже любого ноутбука (но не может его заменить при этом) либо приложений нет вообще (НИНУЖНА!), и хоть один конкурент у огрызковых планшетов по соотношению батарейка/эргономичность есть?
Нету => конкуренция говно без задач.
А чо, кто-то кроме огрызка выпускает нормальные планшеты, а не хуйню на яве без планшетных приложений/хуйню с десктопной ОС, которая либо ебаный кирпич похуже любого ноутбука (но не может его заменить при этом) либо приложений нет вообще (НИНУЖНА!), и хоть один конкурент у огрызковых планшетов по соотношению батарейка/эргономичность есть?
Нету => конкуренция говно без задач.
1138 Кб, 1920x1200
>>772826
Для огрызкоманов стоять на голове это не то что им нужно, я не спорю. Им нужны более активные, более вовлекающие формы.
https://en.wikipedia.org/wiki/HumancentiPad
Для огрызкоманов стоять на голове это не то что им нужно, я не спорю. Им нужны более активные, более вовлекающие формы.
https://en.wikipedia.org/wiki/HumancentiPad
>>772766
Чистое ООП вообще очень сложно сделать быстрым. В чистом ООП уровня смолтока или джавы без примитивов, все функции должны быть виртуальными, все объекты должны создаваться в куче и менеджится сборщиком, работа с объектами только через ссылки. Естественно, такой язык быстрым быть не может, поскольку на железо не ложится никак.
>только медленная и сложная
Чистое ООП вообще очень сложно сделать быстрым. В чистом ООП уровня смолтока или джавы без примитивов, все функции должны быть виртуальными, все объекты должны создаваться в куче и менеджится сборщиком, работа с объектами только через ссылки. Естественно, такой язык быстрым быть не может, поскольку на железо не ложится никак.
Ответы>>772842
>>772820
Стилус на экранах меньше 20 дюймов - бесполезная игрушка. У стилуса точность меньше, поэтому приходится писать заметки буквами в два-три раза больше чем на бумаге. При рисовании приходится непрерывно зумить и скроллить, постоянно мешаешь себе пальцами. Как баловство и для быстрых набросков подходит, для более-менее серьезной работы - нет. Хочешь рисовать на экране - копи деньги на большой синтик, или привыкай к обычному вакому.
Стилус на экранах меньше 20 дюймов - бесполезная игрушка. У стилуса точность меньше, поэтому приходится писать заметки буквами в два-три раза больше чем на бумаге. При рисовании приходится непрерывно зумить и скроллить, постоянно мешаешь себе пальцами. Как баловство и для быстрых набросков подходит, для более-менее серьезной работы - нет. Хочешь рисовать на экране - копи деньги на большой синтик, или привыкай к обычному вакому.
>>772834
>уровня смолтока или джавы
>уровня квантовой физики или школьной арифметики
>уровня круизного лайнера или утлой лодочки
Ответы>>772860
>>772842
Да хоть уровня скалы и жабоскрипта, общие недостатки-то одни и те же у всех ООП языков.
Да хоть уровня скалы и жабоскрипта, общие недостатки-то одни и те же у всех ООП языков.
Ответы>>772865
30 Кб, 357x400
>>772860
Но только в Smalltalk можно наслаждаться ими в чистом виде, на полную катушку, только ими, без отвратительных мешающих достоинств.
Но только в Smalltalk можно наслаждаться ими в чистом виде, на полную катушку, только ими, без отвратительных мешающих достоинств.
Ответы>>772867
>>772867
Если бы вместо джавы IBM, Sun и все-все-все решили бы дать миру INTERCAL, ничего бы не изменилось, писали бы все на INTERCAL как миленькие, точно так же как на Java.
Язык в успехе Java никакой роли не играет, как и в успехе Javascript, например.
Если бы вместо джавы IBM, Sun и все-все-все решили бы дать миру INTERCAL, ничего бы не изменилось, писали бы все на INTERCAL как миленькие, точно так же как на Java.
Язык в успехе Java никакой роли не играет, как и в успехе Javascript, например.
>>772878
У хаскеля нет проблем с mutable state. Могу еще раз повторить.
У хаскеля нет проблем с mutable state. Могу еще раз повторить.
>>772894
С системой типой, тотальностью, выводом типов, зависимыми типами, template haskell страшненький. Да много с чем.
Но по сравнению с какой-нибудь джавой или сишечкой это проблемы типа "на моей океанской яхте не работает телевизор на лестнице"
С системой типой, тотальностью, выводом типов, зависимыми типами, template haskell страшненький. Да много с чем.
Но по сравнению с какой-нибудь джавой или сишечкой это проблемы типа "на моей океанской яхте не работает телевизор на лестнице"
Ответы>>772913
Меня просто вымораживает ситуация вокруг haskell.
С одной стороны барьера сидят "хаскелисты", осилившие только скрипты писать да конфиг xmonad настроить, фанатично приравнивающие haskell к ghc, не слышавшие о большинстве type экстешонов их любимого компилятора, не понимающие в чём проблемы с RankNTypes, почему и зачем в Clean были введены афинные типы, а в MLKit — регионы.
Но самое смешное, — их противники. Представьте себе любителя эзотерических язычков, орущего о том, что хаскель переусложнённый, а самое главное — о непопулярности оного. Забавно наблюдать подобные заявления от фанатика схемы или, например, Go. Но любое упоминание хаскеля у них вызывает какой-то нерациональный слепой приступ ярости и душевной боли.
С одной стороны барьера сидят "хаскелисты", осилившие только скрипты писать да конфиг xmonad настроить, фанатично приравнивающие haskell к ghc, не слышавшие о большинстве type экстешонов их любимого компилятора, не понимающие в чём проблемы с RankNTypes, почему и зачем в Clean были введены афинные типы, а в MLKit — регионы.
Но самое смешное, — их противники. Представьте себе любителя эзотерических язычков, орущего о том, что хаскель переусложнённый, а самое главное — о непопулярности оного. Забавно наблюдать подобные заявления от фанатика схемы или, например, Go. Но любое упоминание хаскеля у них вызывает какой-то нерациональный слепой приступ ярости и душевной боли.
Ответы>>772912
>>772894
Всё довольно просто. В ghc (и вообще классических компиляторах haskell) монада IO является особой, несмотря на то, что формально type IO = State RealWorld. Использовать RealWorld вне этой монады не стоит, — ведь ничто не мешает накастовать на него \a -> (a, a), а потом засунуть один из экземпляров абы куда и там его "потерять", то есть доступ к RealWorld в haskell равносилен нечистоте языка (и вообще жутко неэффективно, ибо оптимизации ghc расчитаны на работу с монадой IO (основной аргумент против введения линейных или хотя бы афинных типов как раз то, что большой кусок ghc должен быть переписан)).
Чтобы решить эту проблемы придумали афинные и линейные типы, — первые позволяют использовать значение этого типа не более одного раза, а вторые — ровно один раз. По факту RealWorld должен быть линейным, но в Clean его сделали афинным, — терять его всё равно нельзя, ибо если потеряешь, то не сойдётся тип main'а.
Тут важно заметить, что использование оных не отменяет возможности (да и банальной потребности в удобном интерфейсе) использовать монаду IO, только теперь она будет иметь вид State !RealWorld, где ! — обозначение линейности/уникальности.
Всё довольно просто. В ghc (и вообще классических компиляторах haskell) монада IO является особой, несмотря на то, что формально type IO = State RealWorld. Использовать RealWorld вне этой монады не стоит, — ведь ничто не мешает накастовать на него \a -> (a, a), а потом засунуть один из экземпляров абы куда и там его "потерять", то есть доступ к RealWorld в haskell равносилен нечистоте языка (и вообще жутко неэффективно, ибо оптимизации ghc расчитаны на работу с монадой IO (основной аргумент против введения линейных или хотя бы афинных типов как раз то, что большой кусок ghc должен быть переписан)).
Чтобы решить эту проблемы придумали афинные и линейные типы, — первые позволяют использовать значение этого типа не более одного раза, а вторые — ровно один раз. По факту RealWorld должен быть линейным, но в Clean его сделали афинным, — терять его всё равно нельзя, ибо если потеряешь, то не сойдётся тип main'а.
Тут важно заметить, что использование оных не отменяет возможности (да и банальной потребности в удобном интерфейсе) использовать монаду IO, только теперь она будет иметь вид State !RealWorld, где ! — обозначение линейности/уникальности.
>>772903
Скорее по сравнению с сишкой/явой хакель прозвучит так:
Скорее по сравнению с сишкой/явой хакель прозвучит так:
>чтобы моя яхта плыла, мне нужно вывести типы и зачекать, доказав ей её же правильность, но плывёт она не быстрее черепахи – нужно боксить каждую молекулу воды и преобразовывать руками каждый тип молекулы воды, отличающийся от H2O - добавки соли, например. И самое главное – это всё нужно делать массовым копированием воды чистыми функциями.
Ответы>>772916
>>772919
Так и хаскель не чистый, на нем императивно писать можно не хуже чем на джавочке
Так и хаскель не чистый, на нем императивно писать можно не хуже чем на джавочке
Ответы>>772922
>>772920
Может у тебя ещё всё мутабельное? Не нужно брать одну молекулу воды, и возвращать модифицированную копию?
Смотри чтоб камнями твои браться по шариату после такого не забили, неверный.
Может у тебя ещё всё мутабельное? Не нужно брать одну молекулу воды, и возвращать модифицированную копию?
Смотри чтоб камнями твои браться по шариату после такого не забили, неверный.
Ответы>>772923
>>772922
Если не нужно - не нужно. Если нужно - то нужно.
Хаскель позволяет делать и так и так.
При этом четко очертить и разграничить одно и так от другого и так как тебе надо, проверять это и не заставлять все это проверять тебя - вся прелесть именно в этом
Если не нужно - не нужно. Если нужно - то нужно.
Хаскель позволяет делать и так и так.
При этом четко очертить и разграничить одно и так от другого и так как тебе надо, проверять это и не заставлять все это проверять тебя - вся прелесть именно в этом
>>772927
Этой фразой ты хотел продемонстрировать свое аристократическое нежелание попадать в какие-либо архивы, если я верно тебя понял? Тебя давно волнует вопрос архивов? Хочешь поговорить об этом?
Компромиссная. С чаще всего работающим выводом типов.
Весьма неожиданное утверждение. Многим людям, конечно, вообще нахуй не сдалось что происходит в их коде, и происходит ли оно вообще, и всегда ли оно происходит, или только по четным числам и только при юго-западном ветре не выше 5 метров в секунду. Этих людей обычно пытается периодически побить нащальника, потом их увольняют и они идут копать канавы. Это немного печально, но причем здесь хаскель?
>Ты перечисляешь борщеговно для аутистов
Этой фразой ты хотел продемонстрировать свое аристократическое нежелание попадать в какие-либо архивы, если я верно тебя понял? Тебя давно волнует вопрос архивов? Хочешь поговорить об этом?
> Система типов-то у хаскеля как раз нормальная
Компромиссная. С чаще всего работающим выводом типов.
> трекинг побочных эффектов им нахуй не сдался, они и так в курсе, что проиходит в их коде.
Весьма неожиданное утверждение. Многим людям, конечно, вообще нахуй не сдалось что происходит в их коде, и происходит ли оно вообще, и всегда ли оно происходит, или только по четным числам и только при юго-западном ветре не выше 5 метров в секунду. Этих людей обычно пытается периодически побить нащальника, потом их увольняют и они идут копать канавы. Это немного печально, но причем здесь хаскель?
> одна из самых полных и новых книжек по realizability in category theory. Тут есть практически все важные модели и результаты в области описания рекурсивной математики категориально-порядковым языком. Порог вхождения, правда, высокий, — автор предполагает, что читатель неплохо разбирается как в теории категорий, так и в теории порядка.
> http://www.staff.science.uu.nl/~steke104/proefschrift2.pdf
> Если хочется сначала вникнуть в эту область, то рекомендую начать с монографии Oosten'а "Realizability — An introduction to its categorical side". Тут есть основы и превосходно освещается привычная для рекурсивной математики категория Eff (По сути категория марковского конструктивизма)
>>772942
Я не знаю какие тезисы можно привести в ответ на утверждение о том что людей не волнует корректность их программ, они не хотели бы облегчить себе управление сложностью, помнят весь свой код наизусть (а чужого им не надо), и подобные им.
Мне кажется что адекватный человек таких утверждений делать не станет, а как что-то объяснить человеку неадекватному - я в этом не специалист, этому люди долго учатся, им потом специальные халаты выдают с дипломом.
Я не знаю какие тезисы можно привести в ответ на утверждение о том что людей не волнует корректность их программ, они не хотели бы облегчить себе управление сложностью, помнят весь свой код наизусть (а чужого им не надо), и подобные им.
Мне кажется что адекватный человек таких утверждений делать не станет, а как что-то объяснить человеку неадекватному - я в этом не специалист, этому люди долго учатся, им потом специальные халаты выдают с дипломом.
107 Кб, 423x397
немного старое (2013), но интересное
http://www.leafpetersen.com/leaf/publications/ifl2013/haskell-gap.pdf
http://www.leafpetersen.com/leaf/publications/ifl2013/haskell-gap.pdf
>>772927
Вот это неверный тезис. Большинство багов в программах, потому что программисты не понимают, что на самом деле происходит в их коде.
>они и так в курсе, что проиходит в их коде
Вот это неверный тезис. Большинство багов в программах, потому что программисты не понимают, что на самом деле происходит в их коде.
Ответы>>772987
>>772894
У хаскиля везде всё заебись. Нет кода - нет проблем.
У хаскиля везде всё заебись. Нет кода - нет проблем.
>>772798
Тогда у нас нет чистых ФЯП.
Продолжение и не может ничего вернуть, учи мат.часть
callCC :: ((a -> ContT r m b) -> ContT r m a) -> ContT r m a
>Если одна и та же функция может выдать разный результат при одинаковых аргументах, то ни о какой функциональной чистоте и речи быть не может.
Тогда у нас нет чистых ФЯП.
>А еще call/cc, где континуация не то, что не возвращает ничего (что уже противоречит принципам фп), она не возвращается в принципе.
Продолжение и не может ничего вернуть, учи мат.часть
callCC :: ((a -> ContT r m b) -> ContT r m a) -> ContT r m a
>>772961
В сишных программах не бывает багов.
Во-первых, сишники всегда знают что происходит в их коде.
Во-вторых, сишные программы настолько быстры, что баги просто не успевают происходить.
В сишных программах не бывает багов.
Во-первых, сишники всегда знают что происходит в их коде.
Во-вторых, сишные программы настолько быстры, что баги просто не успевают происходить.
Ответы>>772993
> Functional Programming Can Work for Games
> Why I set out to prove that functional programming could work for games, and what it might mean for modern game dev
> https://medium.com/@bryanedds/functional-game-programming-can-work-95ed0df14f77
> The results of the 2016 Stack Overflow Developer Survey are in! F# came out as the single most highly paid tech worldwide and is amongst the third top paying techs in the US
> https://fsharp.tv/gazettes/f-the-most-highly-paid-tech-worldwide-in-2016/
> F# in the real world
> In this talk we discussed a number of real world use cases of F# at Gamesys
> http://www.slideshare.net/theburningmonk/f-in-the-real-world-ndc/4-1MILLION_USERSACTIVEDAILY
>>773064
Вчерашний день. Кванты пишут DSL для аналитиков, чтоб те сами 90% писали.
Вчерашний день. Кванты пишут DSL для аналитиков, чтоб те сами 90% писали.
>>772649
Всё это можно было делать и в модульном программировании.
>ООП живо, потому что можно одну группу макак отделить от другой, а между ними повесить интерфейсы и макаки не будут мешать друг другу работая в рамках контракта интерфейса.
Всё это можно было делать и в модульном программировании.
Вообще ООП говно, потому что его даже нельзя формализовать. А значит это просто гуманитарное словоблудие и нинужно.
/тред
/тред
Ответы>>773110
> subhuman
> fleas = 14
axaxaxaxxax
>>772927
Зависимые типы далеко не только про «давайте чекать на тайплевеле вообще все», а проблема хаскеля не в изоляции IO, а в том, что он использует монады вместо эффектов для этого.
Зависимые типы далеко не только про «давайте чекать на тайплевеле вообще все», а проблема хаскеля не в изоляции IO, а в том, что он использует монады вместо эффектов для этого.
Ответы>>773158
>>773110
Ну Лука Карделли пытался, но нихуя не получилось же. Даже определение композиции не осилил. А все потому что ООП - обычная такая надстройка под процедурщиной, которая по строгости и уровню формализации является чем-то средним между философским трактатом и юридическим договором. Гуманитарная дрисня в общем. Для даунов.
Поэтому ты либо инженер и пишешь команды на асме, либо прикладной логик-алгебраист и пишешь на Coq и LambdaProlog. Остальная пиздобратия - обычные гуманитарные офисные питухи.
Ну Лука Карделли пытался, но нихуя не получилось же. Даже определение композиции не осилил. А все потому что ООП - обычная такая надстройка под процедурщиной, которая по строгости и уровню формализации является чем-то средним между философским трактатом и юридическим договором. Гуманитарная дрисня в общем. Для даунов.
Поэтому ты либо инженер и пишешь команды на асме, либо прикладной логик-алгебраист и пишешь на Coq и LambdaProlog. Остальная пиздобратия - обычные гуманитарные офисные питухи.
>>773128
Не вижу здесь никакого либо.
Высокоуровневую логику - на языках высокого уровня, необходимые для требуемого быстродействия части - на языках низкого уровня, если нужен небольшой (или большой) rule engine - либо берешь готовый, устраивающий тебя, либо быстренько пишешь на коленке небольшой Prolog - ну, идея понятна.
>либо инженер и пишешь команды на асме, либо прикладной логик-алгебраист и пишешь на Coq и LambdaProlog
Не вижу здесь никакого либо.
Высокоуровневую логику - на языках высокого уровня, необходимые для требуемого быстродействия части - на языках низкого уровня, если нужен небольшой (или большой) rule engine - либо берешь готовый, устраивающий тебя, либо быстренько пишешь на коленке небольшой Prolog - ну, идея понятна.
>>773176
Он вирус скачал и у него брат умер, ты с Ромулом попутал.
Он вирус скачал и у него брат умер, ты с Ромулом попутал.
>>771178
YO!
YO!
>>773159
Дауны не могут в формулу Бине.
Дауны не могут в формулу Бине.
>>772882
То, что ты обосрался в самом начале поста, позволило мне сэкономить время и недочитывать остальной бред.
То, что ты обосрался в самом начале поста, позволило мне сэкономить время и недочитывать остальной бред.
>>773444
Ну, щас-то хаскель в индустрии массово применяют. Вакансий больше, чем на джаву.
Ну, щас-то хаскель в индустрии массово применяют. Вакансий больше, чем на джаву.
>>773481
В той статье аргументы малость протухли. Например, в хаскель завезли stack, а опенсорц стал нормой.
В той статье аргументы малость протухли. Например, в хаскель завезли stack, а опенсорц стал нормой.
>>773481
Мартыханских вакансий конечно больше на джаве, но если говорить про что-нибудь нормальное, то там будет Хаскель.
Мартыханских вакансий конечно больше на джаве, но если говорить про что-нибудь нормальное, то там будет Хаскель.
>>773128
О, анон, ты походу его читал. Собираюсь тоже почитать. Интересно хоть?
>Ну Лука Карделли пытался
О, анон, ты походу его читал. Собираюсь тоже почитать. Интересно хоть?
>>770420
У линукса очень маленькая сложность как у системы. Там, упрощённо говоря, есть некоторая центральная часть типа управления памятью и проч. + куча драйверов. Добавь 100 драйверов или выкини, изменится только суммарное число строк, но не сложность архитектуры.
> Линух потому и жив, что его писали на Си
У линукса очень маленькая сложность как у системы. Там, упрощённо говоря, есть некоторая центральная часть типа управления памятью и проч. + куча драйверов. Добавь 100 драйверов или выкини, изменится только суммарное число строк, но не сложность архитектуры.
>>773128
Почему это не получилось? Очень даже получилось. Только у него говно получилось, длинное и бесполезное.
Почему это не получилось? Очень даже получилось. Только у него говно получилось, длинное и бесполезное.
>>770795
Можно обойтись без наследования, классов, исключений, функций и много всего другого.
Можно обойтись без ног, рук, одной почки и одного лёгкого. Без глаз, ушей и языка. Только вот жизнь станет немного скудной.
>Можно вообще обойтись без наследования
Можно обойтись без наследования, классов, исключений, функций и много всего другого.
Можно обойтись без ног, рук, одной почки и одного лёгкого. Без глаз, ушей и языка. Только вот жизнь станет немного скудной.
Ответы>>773929
Ответы>>773929
Ответы>>773929
>>773507
Сейчас бы поутешать самого себя.
Сейчас бы поутешать самого себя.
>>773507
Ситуация примерно такая: в джаве отношение мартыханских вакансий к нормальным - 10/1, в хаскеле 1/10, при этом нормальных вакансий на джаве в 100 раз больше чем на хаскеле. Я не к тому что хаскель хуже джавы или что-то в этом роде, просто такова реальность.
Ситуация примерно такая: в джаве отношение мартыханских вакансий к нормальным - 10/1, в хаскеле 1/10, при этом нормальных вакансий на джаве в 100 раз больше чем на хаскеле. Я не к тому что хаскель хуже джавы или что-то в этом роде, просто такова реальность.
Ответы>>775300
>>771711
Понимаешь, тогда будет либо отдельные launch_d3d11.exe и launch_ogl.exe. Либо всякие
if(m_mode == MODE_D3D11)
{
D3D11Render();
}.
В первом случае хуйня какая-то. Во втором случае тот же самый оверхед на branch predictor. У меня, правда, возникали идеи - а если он и правда работает статистически, то, может, после прохода 1000 раз по варианту MODE_D3D11 он всегда будет выбирать его? Но я не хочу серьёзно полагаться на такую низкоуровневую вещь, как реализация предсказателя переходов на конкретном процессоре.
Хм. А разве он не может подгрузить в кэш все функции, которые тебе нужны? Он же видит, например, что функции по D3D11 используются много, а OGL в данной сессии не использовались вообще. Или кэш не такой умный? Или это опять же зависит от реализации, как в предыдущем примере?
Ну во-первых, мне просто нравится работа с графикой. Именно с программной стороны. Всякие сложные алгоритмы, эффекты - это пиздец как интересно.
А во-вторых, я и не использовал этого слова.
>Наиболее быстро - шаблонами. В таком коде нет ничего такого, чтобы выполнять проверку или переход по указателю на функцию каждый раз. Сделай 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
>>775209
Начиная с Haswell брэнч предиктор на свитчах уже не промахивается практически.
>оверхед на branch predictor
Начиная с Haswell брэнч предиктор на свитчах уже не промахивается практически.
Ответы>>775277
>>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 Хороший учебник, всё расписано подробно. Сам по нему учился. Рекомендую.
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 Хороший учебник, всё расписано подробно. Сам по нему учился. Рекомендую.
>>775233
А где вообще можно увидеть тесты на эту тему? Или вручную закупать процессоры разных лет и самостоятельно проверять?
А где вообще можно увидеть тесты на эту тему? Или вручную закупать процессоры разных лет и самостоятельно проверять?
Ответы>>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
Если тебе надо на полчаса потестировать, зачем покупать, в эпоху облачных технологий.
http://agner.org/optimize/
http://igoro.com/archive/fast-and-slow-if-statements-branch-prediction-in-modern-processors/comment-page-1/#comment-178540
Если тебе надо на полчаса потестировать, зачем покупать, в эпоху облачных технологий.
Сап, программач. Сразу скажу, что я не программист, не борщехлеб и даже не макака, так что я не шарю за все эти экзистенциальные типы, гетерогенные списки и прочее, прошу отнестись с пониманием, ибо мне кажется, что моя кулстори релевантна треду, в какой-то степени.
Короче, начал пилить проект, подразумевающий дохуя разнородных структур, мутабельный стейт, сорт оф наследование (или сабтайпинг, я хз), модульность, короче, все, для чего придумывалась волшебная таблетка ооп. Взял питон, ну а что, ПРОСТО пишешь и все работает, как я по наивности предполагал. Первые 4к SLOC все и правда шло хорошо, я открывал для себя на практике паттерны ооп, вроде multiple dispatch и синглтонов, да еще с такими-то метаклассами, почти как в CLOS/MOP, сказка прям. Но в какой-то момент была достигнута сингулярность и начался какой-то адовый пиздец, растущий по экспоненциальной зависимости. Конечно, вскрылись фундаментальные ошибки в архитектуре, но дело даже не в этом, а в том, что я просто перестал понимать всю ту лапшу, в которую превратился мой код. Да, я писал поначалу методы, максимум, в 10 (или сколько там по PEP-008) строк, но рано или поздно их приходилось подпирать костылями, плюс мутабельность, когда нихуя не ясно, когда оно там мутирует, а иногда вообще не понять, где мутатор, а где мутант. Причем, я не думаю, что если бы в гвидобейсике была система типов, было бы легче, была бы та же костыльная лапша, только более вербозная. Когда я поймал себя на том, что опустился до глобальных переменных и magic numbers, весь питонокод был отправлен в ад.
Для второй попытки я выбрал Scheme. Изначально самый ванильный R5RS, который из ракеты. Принципиально отказался от мутабельности и сайд эффектов, кроме ио, и, перешагнув через себя, от call/cc (пытался в функциональное ооп на континуациях, но это хуита, все-таки), кроме обработки ошибок. Вместо питоновских объектов - обычные ассоциативные списки, вместо методов - функции, принимающие "объект" и возвращающие модифицированную копию (меня не волновало потребление памяти и скорость), плюс макросы для более удобного последовательного применения этих функций. 4к строк питонокода уместились на схеме в 1к. Примерно тогда же, я осознал, что от общего стейта не сбежать никак, пробовал варианты с multiple return values, но оказалось неудобно, прибегать к set! не хотелось, короче, да, анон, ты прав, я понял, что пытаюсь изобрести монады.
И таки написал реализации >>= и return, ну и макрос для do нотации. Да, это оказалось той самой волшебной таблеткой, сделавшей мой день. Я, наконец-то, смог сконцентрироваться на решении проблемы с помощью языка программирования, а не на борьбе с ним. Только вот (да-да, господа хаскеллисты, это жалкое подобие монад в языке без типов, etc, но все же), мне кажется, или это и есть то же ооп, сделанное через жопу реализованное функционально? То есть, на словах это вещи разные: с одной стороны, мутабельная хуйня в виде black box, с другой - описание последовательности вычислений с имплицитным стейтом. Вот только без стейта обойтись все равно никак, а если представить, что последовательность процедур в императивной параше и есть последовательность вычислений, то выходит, что монады это, буквально, та же хуйня, только с лишним слоем абстракции?
Короче, начал пилить проект, подразумевающий дохуя разнородных структур, мутабельный стейт, сорт оф наследование (или сабтайпинг, я хз), модульность, короче, все, для чего придумывалась волшебная таблетка ооп. Взял питон, ну а что, ПРОСТО пишешь и все работает, как я по наивности предполагал. Первые 4к SLOC все и правда шло хорошо, я открывал для себя на практике паттерны ооп, вроде multiple dispatch и синглтонов, да еще с такими-то метаклассами, почти как в CLOS/MOP, сказка прям. Но в какой-то момент была достигнута сингулярность и начался какой-то адовый пиздец, растущий по экспоненциальной зависимости. Конечно, вскрылись фундаментальные ошибки в архитектуре, но дело даже не в этом, а в том, что я просто перестал понимать всю ту лапшу, в которую превратился мой код. Да, я писал поначалу методы, максимум, в 10 (или сколько там по PEP-008) строк, но рано или поздно их приходилось подпирать костылями, плюс мутабельность, когда нихуя не ясно, когда оно там мутирует, а иногда вообще не понять, где мутатор, а где мутант. Причем, я не думаю, что если бы в гвидобейсике была система типов, было бы легче, была бы та же костыльная лапша, только более вербозная. Когда я поймал себя на том, что опустился до глобальных переменных и magic numbers, весь питонокод был отправлен в ад.
Для второй попытки я выбрал Scheme. Изначально самый ванильный R5RS, который из ракеты. Принципиально отказался от мутабельности и сайд эффектов, кроме ио, и, перешагнув через себя, от call/cc (пытался в функциональное ооп на континуациях, но это хуита, все-таки), кроме обработки ошибок. Вместо питоновских объектов - обычные ассоциативные списки, вместо методов - функции, принимающие "объект" и возвращающие модифицированную копию (меня не волновало потребление памяти и скорость), плюс макросы для более удобного последовательного применения этих функций. 4к строк питонокода уместились на схеме в 1к. Примерно тогда же, я осознал, что от общего стейта не сбежать никак, пробовал варианты с multiple return values, но оказалось неудобно, прибегать к set! не хотелось, короче, да, анон, ты прав, я понял, что пытаюсь изобрести монады.
И таки написал реализации >>= и return, ну и макрос для do нотации. Да, это оказалось той самой волшебной таблеткой, сделавшей мой день. Я, наконец-то, смог сконцентрироваться на решении проблемы с помощью языка программирования, а не на борьбе с ним. Только вот (да-да, господа хаскеллисты, это жалкое подобие монад в языке без типов, etc, но все же), мне кажется, или это и есть то же ооп, сделанное через жопу реализованное функционально? То есть, на словах это вещи разные: с одной стороны, мутабельная хуйня в виде black box, с другой - описание последовательности вычислений с имплицитным стейтом. Вот только без стейта обойтись все равно никак, а если представить, что последовательность процедур в императивной параше и есть последовательность вычислений, то выходит, что монады это, буквально, та же хуйня, только с лишним слоем абстракции?
Сап, программач. Сразу скажу, что я не программист, не борщехлеб и даже не макака, так что я не шарю за все эти экзистенциальные типы, гетерогенные списки и прочее, прошу отнестись с пониманием, ибо мне кажется, что моя кулстори релевантна треду, в какой-то степени.
Короче, начал пилить проект, подразумевающий дохуя разнородных структур, мутабельный стейт, сорт оф наследование (или сабтайпинг, я хз), модульность, короче, все, для чего придумывалась волшебная таблетка ооп. Взял питон, ну а что, ПРОСТО пишешь и все работает, как я по наивности предполагал. Первые 4к SLOC все и правда шло хорошо, я открывал для себя на практике паттерны ооп, вроде multiple dispatch и синглтонов, да еще с такими-то метаклассами, почти как в CLOS/MOP, сказка прям. Но в какой-то момент была достигнута сингулярность и начался какой-то адовый пиздец, растущий по экспоненциальной зависимости. Конечно, вскрылись фундаментальные ошибки в архитектуре, но дело даже не в этом, а в том, что я просто перестал понимать всю ту лапшу, в которую превратился мой код. Да, я писал поначалу методы, максимум, в 10 (или сколько там по PEP-008) строк, но рано или поздно их приходилось подпирать костылями, плюс мутабельность, когда нихуя не ясно, когда оно там мутирует, а иногда вообще не понять, где мутатор, а где мутант. Причем, я не думаю, что если бы в гвидобейсике была система типов, было бы легче, была бы та же костыльная лапша, только более вербозная. Когда я поймал себя на том, что опустился до глобальных переменных и magic numbers, весь питонокод был отправлен в ад.
Для второй попытки я выбрал Scheme. Изначально самый ванильный R5RS, который из ракеты. Принципиально отказался от мутабельности и сайд эффектов, кроме ио, и, перешагнув через себя, от call/cc (пытался в функциональное ооп на континуациях, но это хуита, все-таки), кроме обработки ошибок. Вместо питоновских объектов - обычные ассоциативные списки, вместо методов - функции, принимающие "объект" и возвращающие модифицированную копию (меня не волновало потребление памяти и скорость), плюс макросы для более удобного последовательного применения этих функций. 4к строк питонокода уместились на схеме в 1к. Примерно тогда же, я осознал, что от общего стейта не сбежать никак, пробовал варианты с multiple return values, но оказалось неудобно, прибегать к set! не хотелось, короче, да, анон, ты прав, я понял, что пытаюсь изобрести монады.
И таки написал реализации >>= и return, ну и макрос для do нотации. Да, это оказалось той самой волшебной таблеткой, сделавшей мой день. Я, наконец-то, смог сконцентрироваться на решении проблемы с помощью языка программирования, а не на борьбе с ним. Только вот (да-да, господа хаскеллисты, это жалкое подобие монад в языке без типов, etc, но все же), мне кажется, или это и есть то же ооп, сделанное через жопу реализованное функционально? То есть, на словах это вещи разные: с одной стороны, мутабельная хуйня в виде black box, с другой - описание последовательности вычислений с имплицитным стейтом. Вот только без стейта обойтись все равно никак, а если представить, что последовательность процедур в императивной параше и есть последовательность вычислений, то выходит, что монады это, буквально, та же хуйня, только с лишним слоем абстракции?
Короче, начал пилить проект, подразумевающий дохуя разнородных структур, мутабельный стейт, сорт оф наследование (или сабтайпинг, я хз), модульность, короче, все, для чего придумывалась волшебная таблетка ооп. Взял питон, ну а что, ПРОСТО пишешь и все работает, как я по наивности предполагал. Первые 4к SLOC все и правда шло хорошо, я открывал для себя на практике паттерны ооп, вроде multiple dispatch и синглтонов, да еще с такими-то метаклассами, почти как в CLOS/MOP, сказка прям. Но в какой-то момент была достигнута сингулярность и начался какой-то адовый пиздец, растущий по экспоненциальной зависимости. Конечно, вскрылись фундаментальные ошибки в архитектуре, но дело даже не в этом, а в том, что я просто перестал понимать всю ту лапшу, в которую превратился мой код. Да, я писал поначалу методы, максимум, в 10 (или сколько там по PEP-008) строк, но рано или поздно их приходилось подпирать костылями, плюс мутабельность, когда нихуя не ясно, когда оно там мутирует, а иногда вообще не понять, где мутатор, а где мутант. Причем, я не думаю, что если бы в гвидобейсике была система типов, было бы легче, была бы та же костыльная лапша, только более вербозная. Когда я поймал себя на том, что опустился до глобальных переменных и magic numbers, весь питонокод был отправлен в ад.
Для второй попытки я выбрал Scheme. Изначально самый ванильный R5RS, который из ракеты. Принципиально отказался от мутабельности и сайд эффектов, кроме ио, и, перешагнув через себя, от call/cc (пытался в функциональное ооп на континуациях, но это хуита, все-таки), кроме обработки ошибок. Вместо питоновских объектов - обычные ассоциативные списки, вместо методов - функции, принимающие "объект" и возвращающие модифицированную копию (меня не волновало потребление памяти и скорость), плюс макросы для более удобного последовательного применения этих функций. 4к строк питонокода уместились на схеме в 1к. Примерно тогда же, я осознал, что от общего стейта не сбежать никак, пробовал варианты с multiple return values, но оказалось неудобно, прибегать к set! не хотелось, короче, да, анон, ты прав, я понял, что пытаюсь изобрести монады.
И таки написал реализации >>= и return, ну и макрос для do нотации. Да, это оказалось той самой волшебной таблеткой, сделавшей мой день. Я, наконец-то, смог сконцентрироваться на решении проблемы с помощью языка программирования, а не на борьбе с ним. Только вот (да-да, господа хаскеллисты, это жалкое подобие монад в языке без типов, etc, но все же), мне кажется, или это и есть то же ооп, сделанное через жопу реализованное функционально? То есть, на словах это вещи разные: с одной стороны, мутабельная хуйня в виде black box, с другой - описание последовательности вычислений с имплицитным стейтом. Вот только без стейта обойтись все равно никак, а если представить, что последовательность процедур в императивной параше и есть последовательность вычислений, то выходит, что монады это, буквально, та же хуйня, только с лишним слоем абстракции?
>>775329
Без стейта не надо обходиться.
Хаскельное удобство не в том чтоб не было стейта, или не было мутаций, или не было IO, или не было сайд-эффектов. Оно только в том чтобы все эти эффекты были эксплицитно обозначены, легко отделялись друг от друга и от кода без эффектов, и с этим всем было удобно работать.
В Racket ты мог бы на полную мощности использовать контракты и typed racket, со своими плюсами и своими минусами для тех же целей.
ООП в Хаскель есть, свое, марсиански-структурное, и на изобретения из Симулы похоже не очень.
Без стейта не надо обходиться.
Хаскельное удобство не в том чтоб не было стейта, или не было мутаций, или не было IO, или не было сайд-эффектов. Оно только в том чтобы все эти эффекты были эксплицитно обозначены, легко отделялись друг от друга и от кода без эффектов, и с этим всем было удобно работать.
В Racket ты мог бы на полную мощности использовать контракты и typed racket, со своими плюсами и своими минусами для тех же целей.
ООП в Хаскель есть, свое, марсиански-структурное, и на изобретения из Симулы похоже не очень.
Ответы>>775359
>>775329
Попизди мне тут. Монада - не цель, а средство. В языке с call-cc ты можешь использовать функцию в монадическом коде а не писать отдельную и ехал лифт через лифт, а map через mapM
>это жалкое подобие монад в языке без типов
Попизди мне тут. Монада - не цель, а средство. В языке с call-cc ты можешь использовать функцию в монадическом коде а не писать отдельную и ехал лифт через лифт, а map через mapM
Ответы>>775359
>>775329
Именно так. В фортране ты эмулируешь стек, в сишке кастишь void*, в С++ ебешься с владением, в старой жабе мучаешься без лямбд, а в хаскелле ты явно пердолишься со стейтом. Это неудобство, но иногда это неудобство бывает оправданным (иначе эти языки бы не существовали). Например, в академической среде.
Твоя ошибка в том, что ты, соснув с питоном, не начал изучать причины своего отсоса (мы обсуждали в соседнем треде, в динамическом языке нужно 100% покрытия "тестами типизации", чтобы оно хоть как-то работало), а решил, что это язык виноват.
>Вот только без стейта обойтись все равно никак, а если представить, что последовательность процедур в императивной параше и есть последовательность вычислений, то выходит, что монады это, буквально, та же хуйня, только с лишним слоем абстракции?
Именно так. В фортране ты эмулируешь стек, в сишке кастишь void*, в С++ ебешься с владением, в старой жабе мучаешься без лямбд, а в хаскелле ты явно пердолишься со стейтом. Это неудобство, но иногда это неудобство бывает оправданным (иначе эти языки бы не существовали). Например, в академической среде.
Твоя ошибка в том, что ты, соснув с питоном, не начал изучать причины своего отсоса (мы обсуждали в соседнем треде, в динамическом языке нужно 100% покрытия "тестами типизации", чтобы оно хоть как-то работало), а решил, что это язык виноват.
>>775341
Не "пердолишься", а аккуратно и эксплицитно работаешь с ним.
В Алголе запилили нормальный уже.
В первую очередь все решают вопросы архитектуры. Разбиение на модули, выбор абстракций, интерфейсов между ними, организация кода. 100% покрытия тестами не требуется во многих случаях.
Он не решил что язык виноват. Он сообщает что на собственном опыте убедился вот в чем - в том что если (как он в первой же фразе и объявил) архитектурить не умеешь - в данном случае потому что опыта нет - то язык может тебя в разной степени заставить это делать (пусть и не самым оптимальным образом, но хоть как-нибудь), а может не заставлять.
В разных случаях требуется разное, соотношение затрат времени и сил разное, требования разные, квалификация у всех разная. Мудрый человек не сильно напрягаясь напишет понятный, надежный, легко модифицируемый и быстрый код на любом языке, использовав те проеимущества языка что ему нужны в конкретном случае.
Не "пердолишься", а аккуратно и эксплицитно работаешь с ним.
> В фортране ты эмулируешь стек
В Алголе запилили нормальный уже.
> причины своего отсоса (мы обсуждали в соседнем треде, в динамическом языке нужно 100% покрытия "тестами типизации", чтобы оно хоть как-то работало)
В первую очередь все решают вопросы архитектуры. Разбиение на модули, выбор абстракций, интерфейсов между ними, организация кода. 100% покрытия тестами не требуется во многих случаях.
> а решил, что это язык виноват.
Он не решил что язык виноват. Он сообщает что на собственном опыте убедился вот в чем - в том что если (как он в первой же фразе и объявил) архитектурить не умеешь - в данном случае потому что опыта нет - то язык может тебя в разной степени заставить это делать (пусть и не самым оптимальным образом, но хоть как-нибудь), а может не заставлять.
В разных случаях требуется разное, соотношение затрат времени и сил разное, требования разные, квалификация у всех разная. Мудрый человек не сильно напрягаясь напишет понятный, надежный, легко модифицируемый и быстрый код на любом языке, использовав те проеимущества языка что ему нужны в конкретном случае.
>>775332
Никто и не говорит, что надо.
>>775337
man irony
>>775341
Питон был взят для прототипирования, просто вначале хорошо пошло, думал на нем и доделаю.
>>775343
В точку. Ну и еще про небходимость правильного выбора инструмента (я считаю, питон для тех случаев, когда баша или перла немного не хватает, ну или для рапид прототайпинга).
>Без стейта не надо обходиться.
Никто и не говорит, что надо.
>>775337
man irony
>>775341
>Твоя ошибка в том, что ты, соснув с питоном, не начал изучать причины своего отсоса (мы обсуждали в соседнем треде, в динамическом языке нужно 100% покрытия "тестами типизации", чтобы оно хоть как-то работало), а решил, что это язык виноват.
Питон был взят для прототипирования, просто вначале хорошо пошло, думал на нем и доделаю.
>>775343
>Он не решил что язык виноват. Он сообщает что на собственном опыте убедился вот в чем - в том что если (как он в первой же фразе и объявил) архитектурить не умеешь - в данном случае потому что опыта нет - то язык может тебя в разной степени заставить это делать (пусть и не самым оптимальным образом, но хоть как-нибудь), а может не заставлять.
В точку. Ну и еще про небходимость правильного выбора инструмента (я считаю, питон для тех случаев, когда баша или перла немного не хватает, ну или для рапид прототайпинга).
Ответы>>775376
>>775343
https://www.youtube.com/watch?v=5tkMi72w8j0
Он взял мейнстримный язык, наговнокодил, и потом взял экзотику. Т.е. вместо того, чтобы понять, что с собой не так, хает питон. Еще пара таких итераций и очередное золотце готово.
>Не "пердолишься", а аккуратно и эксплицитно работаешь с ним.
>эксплицитно
https://www.youtube.com/watch?v=5tkMi72w8j0
>Он не решил что язык виноват
Он взял мейнстримный язык, наговнокодил, и потом взял экзотику. Т.е. вместо того, чтобы понять, что с собой не так, хает питон. Еще пара таких итераций и очередное золотце готово.
Ответы>>775376
>>775361
Хорошо - "явным образом" будет достаточно для тебя понятно?
Чтобы "понять что с ним не так" требуется гораздо больше времени чем взять язык, который ему в данном случае бил по рукам и тем самым помог не говнокодить.
Он решил поделиться своим опытом.
>>775359
Это ошибка во многих случаях. Во многих - нет.
Мир разнообразен.
Кто-то берет питон написать небольшую утилиту, кто-то пишет на нем миллионы строк, по-разному бывает.
То что динамические языки дают больше свободы - эти еще нужно уметь правильно воспользоваться. А не себе во вред.
Хорошо - "явным образом" будет достаточно для тебя понятно?
Чтобы "понять что с ним не так" требуется гораздо больше времени чем взять язык, который ему в данном случае бил по рукам и тем самым помог не говнокодить.
Он решил поделиться своим опытом.
>>775359
>питон для тех случаев, когда баша или перла немного не хватает
Это ошибка во многих случаях. Во многих - нет.
Мир разнообразен.
Кто-то берет питон написать небольшую утилиту, кто-то пишет на нем миллионы строк, по-разному бывает.
То что динамические языки дают больше свободы - эти еще нужно уметь правильно воспользоваться. А не себе во вред.
>>772633
Хуя ты пиздабол. Налепил слов на *ция, как будто это придаст смысл и большую значимость твоему высеру. Пиздец, и с таким апломбом ещё... Как будто бы только что статью в энциклопедию написал.
Хуя ты пиздабол. Налепил слов на *ция, как будто это придаст смысл и большую значимость твоему высеру. Пиздец, и с таким апломбом ещё... Как будто бы только что статью в энциклопедию написал.
Ответы>>775384
>>775376
Он выкинул код и написал его заново. Конечно велик шанс, что вторая попытка будет чуть лучше прошлой.
>Чтобы "понять что с ним не так" требуется гораздо больше времени чем взять язык, который ему в данном случае бил по рукам и тем самым помог не говнокодить.
Он выкинул код и написал его заново. Конечно велик шанс, что вторая попытка будет чуть лучше прошлой.
>>775385
Совсем невелик.
Хотя я очень удивлен таким лихим его напором и освоением схемы и хаскеля в кратчайшее время, может быть он и дизайну и архитектуре так же лихо учится, вундеркинд.
Совсем невелик.
Хотя я очень удивлен таким лихим его напором и освоением схемы и хаскеля в кратчайшее время, может быть он и дизайну и архитектуре так же лихо учится, вундеркинд.
>>775386
Очень велик, когда изначальный подход - это
Очень велик, когда изначальный подход - это
>вроде multiple dispatch и синглтонов, да еще с такими-то метаклассами, почти как в CLOS/MOP, сказка прям
>>775386
Не, я хаскель не осваивал. Считаю, что еще не дорос. Про монадки знал в общих чертах. А у схемы весь стандарт на 50 страниц, осваивать нечего.
>>775376
При желании и на ванильном r5rs можно запилить python-like oop и говнокодить в нем, а еще srfi есть какие-то, вроде, с подобием ооп. Тут я сам себя по рукам бил, схему взял из-за макросов, наличия ровно нихуя в стандартной библиотеке, да и вообще люблю лишп. Вместо нее мог быть тот же питон, это вообще не важно, тут про ооп vs монадки, а не языкосрач
Не, я хаскель не осваивал. Считаю, что еще не дорос. Про монадки знал в общих чертах. А у схемы весь стандарт на 50 страниц, осваивать нечего.
>>775376
>язык, который ему в данном случае бил по рукам и тем самым помог не говнокодить.
При желании и на ванильном r5rs можно запилить python-like oop и говнокодить в нем, а еще srfi есть какие-то, вроде, с подобием ооп. Тут я сам себя по рукам бил, схему взял из-за макросов, наличия ровно нихуя в стандартной библиотеке, да и вообще люблю лишп. Вместо нее мог быть тот же питон, это вообще не важно, тут про ооп vs монадки, а не языкосрач
Ответы>>775447
>>775385
Ты прав, так и есть, вкусив всех прелестей ооп, я выбрал другой подход и получилось чуть лучше.
Ты прав, так и есть, вкусив всех прелестей ооп, я выбрал другой подход и получилось чуть лучше.
>>775376
Для чистоты эксперимента надо чтобы он ещё раз написал этот проект на питоне. Вполне возможно успех со схемой вызван тем, что грабли были уже изучены при прототипировании.
>Чтобы "понять что с ним не так" требуется гораздо больше времени чем взять язык, который ему в данном случае бил по рукам и тем самым помог не говнокодить.
Для чистоты эксперимента надо чтобы он ещё раз написал этот проект на питоне. Вполне возможно успех со схемой вызван тем, что грабли были уже изучены при прототипировании.
>>775444
Читай:
>>775426
Будет абсолютно то же самое на питоне с монадами.
>Для чистоты эксперимента надо чтобы он ещё раз написал этот проект на питоне.
Читай:
>>775426
>схему взял из-за макросов, наличия ровно нихуя в стандартной библиотеке, да и вообще люблю лишп. Вместо нее мог быть тот же питон, это вообще не важно
Будет абсолютно то же самое на питоне с монадами.
Ответы>>775451
>>775447
В итоге - чтобы понять как надо было это делать с самого начала потребовалось сделать два прототипа на выброс.
В итоге - чтобы понять как надо было это делать с самого начала потребовалось сделать два прототипа на выброс.
Ответы>>775491
Alan Kay - главный зачинатель ОО-культа, сегодня отвечает на вопросы публики
https://news.ycombinator.com/item?id=11939851
https://news.ycombinator.com/item?id=11939851
>>775444
Для чистоты эксперимента хорошо бы посмотреть на код. Пока все эти слова доверия не вызывают. Я вижу только личинку лиспера, т.е. говно нации.
Для чистоты эксперимента хорошо бы посмотреть на код. Пока все эти слова доверия не вызывают. Я вижу только личинку лиспера, т.е. говно нации.
Ответы>>775491
>>775451
А как иначе?
>>775468
Один лиспер = целая нация?
Да, схема - не лисп. Только синтаксис похож.
А как иначе?
>>775468
>личинку лиспера, т.е. говно нации
Один лиспер = целая нация?
Да, схема - не лисп. Только синтаксис похож.
Ответы>>775535
>>775491
Иначе - это когда прототипов на выброс делать не требуется, а дизайнится, и пишется один раз - и сразу работает.
Для этого нужен опыт.
Малолетние долбоебы называет это waterfall и утверждают что такого не бывает, а нужно соблюдать аджайл, слушать радио Радонеж и переписывать все заново каждые две недели.
>А как иначе?
Иначе - это когда прототипов на выброс делать не требуется, а дизайнится, и пишется один раз - и сразу работает.
Для этого нужен опыт.
Малолетние долбоебы называет это waterfall и утверждают что такого не бывает, а нужно соблюдать аджайл, слушать радио Радонеж и переписывать все заново каждые две недели.
>>775535
такая хуита бывает только в госзаказах
вотерфол это когда заказчик не видит результат пол года, потом получает парашу что вы слепили и посылает вас нахуй, потому что все не так
это любимый способ разработки в военке и НИИ, где все должно быть параллельно и перпендикулярно, а на продукт всем похуй, главное отчеты и работа вместо результата, ведь продукт делается не чтоб зарабатывать бапки, а чтоб горжусь великай родиной
> дизайнится, и пишется один раз - и сразу работает
такая хуита бывает только в госзаказах
вотерфол это когда заказчик не видит результат пол года, потом получает парашу что вы слепили и посылает вас нахуй, потому что все не так
это любимый способ разработки в военке и НИИ, где все должно быть параллельно и перпендикулярно, а на продукт всем похуй, главное отчеты и работа вместо результата, ведь продукт делается не чтоб зарабатывать бапки, а чтоб горжусь великай родиной
>>775541
Для того чтобы было все так существуют Технические Задания, Эскизные Проекты, Рабочие Проекты, и Технические Проекты, не говоря о документации.
Говорил я не об этом, кстати. Но так ты не видел нихуя кроме стэндап-митингов, заменяющих проектирование, то тебе кажется что по-другому и не бывает.
>потому что все не так
Для того чтобы было все так существуют Технические Задания, Эскизные Проекты, Рабочие Проекты, и Технические Проекты, не говоря о документации.
Говорил я не об этом, кстати. Но так ты не видел нихуя кроме стэндап-митингов, заменяющих проектирование, то тебе кажется что по-другому и не бывает.
>>775548
Вся эта хуйня существует только в вотерфол мирке, который умер в нормальных странах ещё в 80е, кроме госпараши разумеется
>Технические Задания, Эскизные Проекты, Рабочие Проекты, и Технические Проекты, не говоря о документации
Вся эта хуйня существует только в вотерфол мирке, который умер в нормальных странах ещё в 80е, кроме госпараши разумеется
Ответы>>775584
>>775548
Это присутствует в любом проекте, не важно от методологии, но это не решает описанной выше проблемы.
>документации
Это присутствует в любом проекте, не важно от методологии, но это не решает описанной выше проблемы.
Ответы>>775634
>>775553
Я и не говорил что документация сама по себе волшебным магическим образом решает проблемы.
Проблемы решаются головой. Ей же осмысливается опыт, выводы из опыта применяются к новым проектам - потому что решения и задачи в погромировании на 95% типовые и одни и те же. Особенно если общие их черты научиться видеть.
Голову ни одна методология, хотя бы и с самыми скрамными и солидными аджайлами, не заменяет.
Тем более что туда где аджайлы, стендапы и скрамное мракобесие, нормальный, уважающий себя человек чаще всего просто не пойдет.
Я и не говорил что документация сама по себе волшебным магическим образом решает проблемы.
Проблемы решаются головой. Ей же осмысливается опыт, выводы из опыта применяются к новым проектам - потому что решения и задачи в погромировании на 95% типовые и одни и те же. Особенно если общие их черты научиться видеть.
Голову ни одна методология, хотя бы и с самыми скрамными и солидными аджайлами, не заменяет.
Тем более что туда где аджайлы, стендапы и скрамное мракобесие, нормальный, уважающий себя человек чаще всего просто не пойдет.
>>775667
ad hoс, конечно же
ad hoс, конечно же
>>775667
Ты даже задачу не можешь сформулировать.
Сколько капч тебе надо распознавать - одну в час или миллион в секунду?
Когда эта капча сменится другой - окей ли выкинуть распознавалку и начать все сначала или лучше потратить X времени сразу на нормальную?
И еще десяток подобных вопросов.
Потрать час-два времени, подумай над ними хорошенько, расставь приоритеты.
Станешь уже на 30-50% ближе к правильным решениям.
Ты даже задачу не можешь сформулировать.
Сколько капч тебе надо распознавать - одну в час или миллион в секунду?
Когда эта капча сменится другой - окей ли выкинуть распознавалку и начать все сначала или лучше потратить X времени сразу на нормальную?
И еще десяток подобных вопросов.
Потрать час-два времени, подумай над ними хорошенько, расставь приоритеты.
Станешь уже на 30-50% ближе к правильным решениям.
Ответы>>775687
>>775676
Задача - обнаруживать новые WEBM как можно ближе к реалтайму делая запросы только с одного айпишника.
Задача - обнаруживать новые WEBM как можно ближе к реалтайму делая запросы только с одного айпишника.
>>775687
Тредов и досок много, поэтому придётся делать несколько запросов в секунду.
Тредов и досок много, поэтому придётся делать несколько запросов в секунду.
>>775687
Ты не понял.
Это был не вопрос к тебе сформулировать для меня задачу более точно.
Это был добрый методологический совет как тебе начать включать голову и хотя бы начать улучшать качество решения твоих задач.
Судя по твоему ответу, тебе это не помогло. Задача сформулирована так же говенно как и в прошлый раз - вопросов к ней с таким дополнением стало только больше.
Может быть ты не умеешь понимать прочитанное - это называется функциональная неграмотность.
Ты не понял.
Это был не вопрос к тебе сформулировать для меня задачу более точно.
Это был добрый методологический совет как тебе начать включать голову и хотя бы начать улучшать качество решения твоих задач.
Судя по твоему ответу, тебе это не помогло. Задача сформулирована так же говенно как и в прошлый раз - вопросов к ней с таким дополнением стало только больше.
Может быть ты не умеешь понимать прочитанное - это называется функциональная неграмотность.
Ответы>>775703
>>775691
Это ты не понял. Я показал конкретный пример того как так случается, что чёткой постановки задачи нет.
У меня есть только широкая формулировка большой задачи, из которой никак не вывести детали реализации. Когда нет дяди в галстуке который бы принёс на блюдечке спецификацию. Только ты один на один с дикой природой. Архитектор, ПМ и кодер в одном лице. Твоя задача сделать жизнеспособный продукт или объяснить почему это невозможно.
Ты сам должен провести инвестигейшн, выяснить какая у двача и у клаудфлейра политика бана за частые запросы и частое неправильное распознавание капчи. Проверить что лучше - использовать API или парсить треды. Если парсить треды, то какую версию - десктопную или мобильную.
А потом ещё найти где хостинг подешевле. И тут интересное ещё не заканчивается. Сканер двача это только часть проекта. Вебмки я в итоге собираюсь выкачивать и процессить, и для этого нужен достаточно мощный сервер. Есть хостинги подешевле, где в полиси запрещается использовать все ядра в режиме 24/7, а есть полноценные vds, но стоят они заметно дороже. Чтобы сказать какой сервер мне нужен (и сколько ядер на нём) мне надо знать как меняется количество вебмок на дваче в течении недели, каковы пики и средняя нагрузка, и какой среди вебмок процент повторов в долгосрочной перспективе. С этими данными я смогу сказать а по карману ли мне вообще этот проект или это всё воздушные замки.
Но вот загвоздка - чтобы собрать эти данные нужна прога, которая сканит двач и находит вебмки.
Если проект реализовать с моим бюджетом невозможно, то я хочу узнать об этом как можно раньше. Поэтому я пишу прототип, и другого варианта не вижу.
Проектирование делается после рисёрча, а его зачастую невозможно провести без прототипа.
Конечно всё проще если ты упитанный розовощёкий офисный кретин, которому начальник присылает спецификацию. Но эта простота обусловлена тем, что во-первых за тебя подумал аналитики, ПМ и тимлид, а во-вторых не исключено, что высшее руководство рассматривает весь твой проект как прототип, и если не взлетит он, то будут извлечены уроки и запилят новый.
Это ты не понял. Я показал конкретный пример того как так случается, что чёткой постановки задачи нет.
У меня есть только широкая формулировка большой задачи, из которой никак не вывести детали реализации. Когда нет дяди в галстуке который бы принёс на блюдечке спецификацию. Только ты один на один с дикой природой. Архитектор, ПМ и кодер в одном лице. Твоя задача сделать жизнеспособный продукт или объяснить почему это невозможно.
Ты сам должен провести инвестигейшн, выяснить какая у двача и у клаудфлейра политика бана за частые запросы и частое неправильное распознавание капчи. Проверить что лучше - использовать API или парсить треды. Если парсить треды, то какую версию - десктопную или мобильную.
А потом ещё найти где хостинг подешевле. И тут интересное ещё не заканчивается. Сканер двача это только часть проекта. Вебмки я в итоге собираюсь выкачивать и процессить, и для этого нужен достаточно мощный сервер. Есть хостинги подешевле, где в полиси запрещается использовать все ядра в режиме 24/7, а есть полноценные vds, но стоят они заметно дороже. Чтобы сказать какой сервер мне нужен (и сколько ядер на нём) мне надо знать как меняется количество вебмок на дваче в течении недели, каковы пики и средняя нагрузка, и какой среди вебмок процент повторов в долгосрочной перспективе. С этими данными я смогу сказать а по карману ли мне вообще этот проект или это всё воздушные замки.
Но вот загвоздка - чтобы собрать эти данные нужна прога, которая сканит двач и находит вебмки.
Если проект реализовать с моим бюджетом невозможно, то я хочу узнать об этом как можно раньше. Поэтому я пишу прототип, и другого варианта не вижу.
Проектирование делается после рисёрча, а его зачастую невозможно провести без прототипа.
Конечно всё проще если ты упитанный розовощёкий офисный кретин, которому начальник присылает спецификацию. Но эта простота обусловлена тем, что во-первых за тебя подумал аналитики, ПМ и тимлид, а во-вторых не исключено, что высшее руководство рассматривает весь твой проект как прототип, и если не взлетит он, то будут извлечены уроки и запилят новый.
>>775691
Это ты не понял. Я показал конкретный пример того как так случается, что чёткой постановки задачи нет.
У меня есть только широкая формулировка большой задачи, из которой никак не вывести детали реализации. Когда нет дяди в галстуке который бы принёс на блюдечке спецификацию. Только ты один на один с дикой природой. Архитектор, ПМ и кодер в одном лице. Твоя задача сделать жизнеспособный продукт или объяснить почему это невозможно.
Ты сам должен провести инвестигейшн, выяснить какая у двача и у клаудфлейра политика бана за частые запросы и частое неправильное распознавание капчи. Проверить что лучше - использовать API или парсить треды. Если парсить треды, то какую версию - десктопную или мобильную.
А потом ещё найти где хостинг подешевле. И тут интересное ещё не заканчивается. Сканер двача это только часть проекта. Вебмки я в итоге собираюсь выкачивать и процессить, и для этого нужен достаточно мощный сервер. Есть хостинги подешевле, где в полиси запрещается использовать все ядра в режиме 24/7, а есть полноценные vds, но стоят они заметно дороже. Чтобы сказать какой сервер мне нужен (и сколько ядер на нём) мне надо знать как меняется количество вебмок на дваче в течении недели, каковы пики и средняя нагрузка, и какой среди вебмок процент повторов в долгосрочной перспективе. С этими данными я смогу сказать а по карману ли мне вообще этот проект или это всё воздушные замки.
Но вот загвоздка - чтобы собрать эти данные нужна прога, которая сканит двач и находит вебмки.
Если проект реализовать с моим бюджетом невозможно, то я хочу узнать об этом как можно раньше. Поэтому я пишу прототип, и другого варианта не вижу.
Проектирование делается после рисёрча, а его зачастую невозможно провести без прототипа.
Конечно всё проще если ты упитанный розовощёкий офисный кретин, которому начальник присылает спецификацию. Но эта простота обусловлена тем, что во-первых за тебя подумал аналитики, ПМ и тимлид, а во-вторых не исключено, что высшее руководство рассматривает весь твой проект как прототип, и если не взлетит он, то будут извлечены уроки и запилят новый.
Это ты не понял. Я показал конкретный пример того как так случается, что чёткой постановки задачи нет.
У меня есть только широкая формулировка большой задачи, из которой никак не вывести детали реализации. Когда нет дяди в галстуке который бы принёс на блюдечке спецификацию. Только ты один на один с дикой природой. Архитектор, ПМ и кодер в одном лице. Твоя задача сделать жизнеспособный продукт или объяснить почему это невозможно.
Ты сам должен провести инвестигейшн, выяснить какая у двача и у клаудфлейра политика бана за частые запросы и частое неправильное распознавание капчи. Проверить что лучше - использовать API или парсить треды. Если парсить треды, то какую версию - десктопную или мобильную.
А потом ещё найти где хостинг подешевле. И тут интересное ещё не заканчивается. Сканер двача это только часть проекта. Вебмки я в итоге собираюсь выкачивать и процессить, и для этого нужен достаточно мощный сервер. Есть хостинги подешевле, где в полиси запрещается использовать все ядра в режиме 24/7, а есть полноценные vds, но стоят они заметно дороже. Чтобы сказать какой сервер мне нужен (и сколько ядер на нём) мне надо знать как меняется количество вебмок на дваче в течении недели, каковы пики и средняя нагрузка, и какой среди вебмок процент повторов в долгосрочной перспективе. С этими данными я смогу сказать а по карману ли мне вообще этот проект или это всё воздушные замки.
Но вот загвоздка - чтобы собрать эти данные нужна прога, которая сканит двач и находит вебмки.
Если проект реализовать с моим бюджетом невозможно, то я хочу узнать об этом как можно раньше. Поэтому я пишу прототип, и другого варианта не вижу.
Проектирование делается после рисёрча, а его зачастую невозможно провести без прототипа.
Конечно всё проще если ты упитанный розовощёкий офисный кретин, которому начальник присылает спецификацию. Но эта простота обусловлена тем, что во-первых за тебя подумал аналитики, ПМ и тимлид, а во-вторых не исключено, что высшее руководство рассматривает весь твой проект как прототип, и если не взлетит он, то будут извлечены уроки и запилят новый.
>>775703
Ты описываешь какой-то оверкилл. Особенно включая экономические факторы. В жизни, а не школьных учебниках, устроено все попроще. С таким подходом к проектированию и разработке как у тебя, быстро в трех соснах заблудишься. Попробуй набить шишек в реальных проектах, вместо теоретизирования.
Ты описываешь какой-то оверкилл. Особенно включая экономические факторы. В жизни, а не школьных учебниках, устроено все попроще. С таким подходом к проектированию и разработке как у тебя, быстро в трех соснах заблудишься. Попробуй набить шишек в реальных проектах, вместо теоретизирования.
Ну что, программистишки. Давай челлендж на написание разгадывалки капчи с хуями.
>>775541
Не бывает. Вот как выглядит разработка прибора:
1. Эскизный проект - теоретики ебашат выкладки, что это возможно. Каждый отдел пишет ТЗ по тому, что он знает
2. Технический проект. Уже более подробное описание.
3. Лабораторное изделие - альфа-версия, так сказать. Изделия ебашится вдоль и поперек, модифицируется прямо паяльником на месте.
4. Стендовое изделие - несколько бета-версий.
5. Штатные изделия - все гонится потоком.
На каждом этапе заказчик принимает все и подписывает.
А ты как хочешь? Каждый день новый прибор за несколько миллионов клепать, чтобы протестить багфикс? Или чтобы заказчик "ой, а нам энергопотребление нужно в 5 раз меньше, и цвет зелененький можно" пиздел на середине разработки? Ты ебанько с промытыми порашей мозгами.
>такая хуита бывает только в госзаказах
Не бывает. Вот как выглядит разработка прибора:
1. Эскизный проект - теоретики ебашат выкладки, что это возможно. Каждый отдел пишет ТЗ по тому, что он знает
2. Технический проект. Уже более подробное описание.
3. Лабораторное изделие - альфа-версия, так сказать. Изделия ебашится вдоль и поперек, модифицируется прямо паяльником на месте.
4. Стендовое изделие - несколько бета-версий.
5. Штатные изделия - все гонится потоком.
На каждом этапе заказчик принимает все и подписывает.
>это любимый способ разработки в военке и НИИ
А ты как хочешь? Каждый день новый прибор за несколько миллионов клепать, чтобы протестить багфикс? Или чтобы заказчик "ой, а нам энергопотребление нужно в 5 раз меньше, и цвет зелененький можно" пиздел на середине разработки? Ты ебанько с промытыми порашей мозгами.
Ответы>>775799
>>775687
Это не задача.
Вот это - задача.
И решать ее разгадыванием капчи - дурацкий способ. Способы нужно перебирать таким образом:
1. Готовое решение - может решение уже сделано. Всегда нужно начинать с анализа конкурентов.
2. Социальное решение - может проще написать Абу и дать ему долю в обмен на API. Это просто нереальный этап для программистишки.
3. Типовое решение. То, что делается всегда в таком случае. Например, набор из 10К прокси.
4. Йоба-решения, требующие R&D.
А далее, если ты опустился до этого варианта, тебе нужно собственно R&D, которое является отдельной работой по своим законам. Именно тут делают ad-hoc прототипы из говна и палок, доказывающие работоспособность каждой из частей.
Чтобы узнать политику бана, тебе достаточно curl. Но еще лучше - спросить. Потому что грузить сервер однообразными запросами - занятие мудацкое изначально.
>Задача - обнаруживать новые WEBM как можно ближе к реалтайму делая запросы только с одного айпишника.
Это не задача.
>обнаруживать новые WEBM как можно ближе к реалтайму
Вот это - задача.
И решать ее разгадыванием капчи - дурацкий способ. Способы нужно перебирать таким образом:
1. Готовое решение - может решение уже сделано. Всегда нужно начинать с анализа конкурентов.
2. Социальное решение - может проще написать Абу и дать ему долю в обмен на API. Это просто нереальный этап для программистишки.
3. Типовое решение. То, что делается всегда в таком случае. Например, набор из 10К прокси.
4. Йоба-решения, требующие R&D.
А далее, если ты опустился до этого варианта, тебе нужно собственно R&D, которое является отдельной работой по своим законам. Именно тут делают ad-hoc прототипы из говна и палок, доказывающие работоспособность каждой из частей.
>Но вот загвоздка - чтобы собрать эти данные нужна прога, которая сканит двач и находит вебмки.
Чтобы узнать политику бана, тебе достаточно curl. Но еще лучше - спросить. Потому что грузить сервер однообразными запросами - занятие мудацкое изначально.
Ответы>>776019
>>775703
Это ad-hoc прототипы маленьких чстей системы, которых в процессе проектирования делается куча по полчаса на каждый.
Это НЕ версии всей системы целиком "на выброс", о которых и шла речь изначально.
>Поэтому я пишу прототип, и другого варианта не вижу.
>Проектирование делается после рисёрча, а его зачастую невозможно провести без прототипа.
Это ad-hoc прототипы маленьких чстей системы, которых в процессе проектирования делается куча по полчаса на каждый.
Это НЕ версии всей системы целиком "на выброс", о которых и шла речь изначально.
22 Кб, 600x208
>>775764
Так аджайл-сектанты ведь на полном серьезе утверждают что заранее вообще ничего знать невозможно!
Ни какое у прибора должно быть энергопотребление, ни какой зелененький цвет. Потому что неподвластно это уму человеческому, и проектирование - тайна великая есмь, из глубины веков, забытое искусство ацтеков.
А такие вещи как анализ требований и спецификации - слова неприличные, в аджайл-манямирке не употребляемые.
http://www.markjowen.com/2014/09/01/is-agile-a-cult/
Так аджайл-сектанты ведь на полном серьезе утверждают что заранее вообще ничего знать невозможно!
Ни какое у прибора должно быть энергопотребление, ни какой зелененький цвет. Потому что неподвластно это уму человеческому, и проектирование - тайна великая есмь, из глубины веков, забытое искусство ацтеков.
А такие вещи как анализ требований и спецификации - слова неприличные, в аджайл-манямирке не употребляемые.
http://www.markjowen.com/2014/09/01/is-agile-a-cult/
Ответы>>775813
Интересно посмотреть откуда были взяты аджайл-модели и какое в них было здравое зерно - пока не пришли аджайл-консультанты и все не выродилось в полностью бессмысленные пляски народов Океании.
Было это взято из авральной модели затыкания дыр.
Логичный вывод мудрых аджайл-консультантов - давайте же сделаем всю работу постоянным авральным затыканием дыр.
Было это взято из авральной модели затыкания дыр.
> 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
>>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.
>>775799
Аджайл нормален, когда ребилд всей системы не стоит ничего и занимает 10 минут. В промышленности такое бывает редко, в айти - часто, но не прямо сказать, чтобы всегда. То есть по сути когда вся разработка - это и есть проектирование, аджайл нормален.
В любом случае странно дрочить что на водопад, что на аджайл, это разные методы со своими достоинствами и недостатками.
Ну это капитализм - вытянуть из работника ресурсы по-максимуму, не беря при этом на себя ответственность за кривое ТЗ. При водопаде если клиент подписал этап, то все, пизда, контрактор может ссылаться на эту подпись, даже если там явно невыгодное решение, а устроить это довольно просто, ведь заказчик не может знать так много о разработке, как исполнитель.
Аджайл нормален, когда ребилд всей системы не стоит ничего и занимает 10 минут. В промышленности такое бывает редко, в айти - часто, но не прямо сказать, чтобы всегда. То есть по сути когда вся разработка - это и есть проектирование, аджайл нормален.
В любом случае странно дрочить что на водопад, что на аджайл, это разные методы со своими достоинствами и недостатками.
>Логичный вывод мудрых аджайл-консультантов - давайте же сделаем всю работу постоянным авральным затыканием дыр.
Ну это капитализм - вытянуть из работника ресурсы по-максимуму, не беря при этом на себя ответственность за кривое ТЗ. При водопаде если клиент подписал этап, то все, пизда, контрактор может ссылаться на эту подпись, даже если там явно невыгодное решение, а устроить это довольно просто, ведь заказчик не может знать так много о разработке, как исполнитель.
>>775811
Годно выразил.
На русский точно даже и не переведешь.
Страна вечного детства блджад.
>culture of terminal juniority
Годно выразил.
На русский точно даже и не переведешь.
Страна вечного детства блджад.
3 Кб, 236x236
>>775819
Полного и окончательного детства.
Полного и окончательного детства.
>>775840
Этого двачую. Программач превратился в сборище вечно ноющих идиотов, которым всё не так. Хорошо, что подобных макак не пускают к управлению.
Этого двачую. Программач превратился в сборище вечно ноющих идиотов, которым всё не так. Хорошо, что подобных макак не пускают к управлению.
Хуйню тут развели. Высокоуровневое программирование невозможно без абстракций. Для абстракций лучше всего подходит ООП. Кривые абстракции - дефект программиста, а не ООП. Наследование в ООП не является обязательным к использованию. У меня все.
>>775980
Объекты с множеством конструкторов и 1 функцией exec - самая лучшая абстракция, которая неплохо себя документирует. Всегда так делаю.
Объекты с множеством конструкторов и 1 функцией exec - самая лучшая абстракция, которая неплохо себя документирует. Всегда так делаю.
Лучшей абстракцией является инфинити-группойд. Идите учите математику, неучи.
>>775973
Потому что ничего другого ты не видел и не знаешь.
Но источник некривых программистов, которым не помешает даже ООП, пока не обнаружен.
А так как других способов реализации полиморфизма в ОПП нет, то полиморфизм не нужен, заебись.
>Для абстракций лучше всего подходит ООП.
Потому что ничего другого ты не видел и не знаешь.
>Кривые абстракции - дефект программиста, а не ООП.
Но источник некривых программистов, которым не помешает даже ООП, пока не обнаружен.
>Наследование в ООП не является обязательным к использованию
А так как других способов реализации полиморфизма в ОПП нет, то полиморфизм не нужен, заебись.
>>776002
Смотрите, Прямой заехал!
Ты че? Ебанутый? Че ты там делаешь?
>Но источник некривых программистов, которым не помешает даже ООП, пока не обнаружен.
Смотрите, Прямой заехал!
>А так как других способов реализации полиморфизма в ОПП нет, то полиморфизм не нужен, заебись.
Ты че? Ебанутый? Че ты там делаешь?
>>775778
Лучшая абстракция - U-комбинатор.
Лучшая абстракция - U-комбинатор.
>>776002
Во-первых, наследование никак не связано с полиморфизмом. Во-вторых, полиморфизм это костыль для ЯП со статической типизацией.
>других способов реализации полиморфизма
Во-первых, наследование никак не связано с полиморфизмом. Во-вторых, полиморфизм это костыль для ЯП со статической типизацией.
Ответы>>776028
>>776026
Наследование - это кривой костыль, которым полиморфизм реализуется в ООП-парадигме, потому что других не завезли.
Наследование - это кривой костыль, которым полиморфизм реализуется в ООП-парадигме, потому что других не завезли.
Ответы>>776034
Человеческий язык является языком ООП.
Но нет же, ООП плохой, негодный. Пушкин с Толстым хуйню написали, надо переписать на ассемблере.
Но нет же, ООП плохой, негодный. Пушкин с Толстым хуйню написали, надо переписать на ассемблере.
>>776028
Ты говно с мочой путаешь. Наследование это повторное использование кода. Полиморфизм к нему никаким боком.
Ты говно с мочой путаешь. Наследование это повторное использование кода. Полиморфизм к нему никаким боком.
Ответы>>776045
>>776034
Тебе уже в говновики даже написали
Тебе уже в говновики даже написали
> Подтипизация (subtyping), или полиморфизм подтипов (subtype polymorphism), означает, что поведение параметрически полиморфной функции ограничивается множеством типов, связанных в иерархию «супертип — подтип»
Ответы>>776053
33 Кб, 460x276
ООП - это штука, которая позволяет держать сложность под контролем, запихивая ее в иерархические интерфейсы.
ООД - это штука, которая говорит: раз мы можем держать сложность под контролем, не надо ей озабачиваться во время проектирования, а надо тупо плодить объекты на каждый чих. И создает сложность гораздо быстрее, чем ООП в состоянии ее контролировать.
ООД - это штука, которая говорит: раз мы можем держать сложность под контролем, не надо ей озабачиваться во время проектирования, а надо тупо плодить объекты на каждый чих. И создает сложность гораздо быстрее, чем ООП в состоянии ее контролировать.
Ответы>>776056
>>776045
То крестоебы писали, у них родовая травма.
Наследование изначально не для полиморфизма, а для повторного использования кода.
То крестоебы писали, у них родовая травма.
Наследование изначально не для полиморфизма, а для повторного использования кода.
Ответы>>776062
>>776052
а вот за это я бы арматурой по рукам бил, за каждую лишнюю сущность
>надо тупо плодить объекты на каждый чих
а вот за это я бы арматурой по рукам бил, за каждую лишнюю сущность
>>776062
Согласен, слово "изначально" было лишнее.
Но продолжаю настаивать, что полиморфизм через наследование - это костыль
Согласен, слово "изначально" было лишнее.
Но продолжаю настаивать, что полиморфизм через наследование - это костыль
Ответы>>776546
>>775985
Нахуя метод exec, если можно перегрузить оператор вызова.
Нахуя метод exec, если можно перегрузить оператор вызова.
>>776389
Так глупо, что даже толсто. Поведение функций зависит только от аргументов и влияет лишь на возвращаемое значение, поэтому зачастую по одной только сигнатуре можно понять, что она делает.
Например:
head :: [a] -> a
или посложнее:
compose :: (b -> c) -> (a -> b) -> a -> c
maybe :: b -> (a -> b) -> Maybe a -> b
У объектов же есть есть ещё подводная часть айсберга - его внутреннее состояние и связи с другими объектами, у которых оно тоже есть, а это уже очень трудно поддается документированию.
Так глупо, что даже толсто. Поведение функций зависит только от аргументов и влияет лишь на возвращаемое значение, поэтому зачастую по одной только сигнатуре можно понять, что она делает.
Например:
head :: [a] -> a
или посложнее:
compose :: (b -> c) -> (a -> b) -> a -> c
maybe :: b -> (a -> b) -> Maybe a -> b
У объектов же есть есть ещё подводная часть айсберга - его внутреннее состояние и связи с другими объектами, у которых оно тоже есть, а это уже очень трудно поддается документированию.
>>776470
Неправильно. И объекты, и функции, могут как обладать внутренним состоянием, так и не обладать. Причем даже не обладая внутренним состоянием, они могут иметь квази-внутреннее состояние (путем возврата модифицированной копии). Здесь никакой разницы нет.
Ну давай, расскажи мне, что делает [Float] -> IO [Float].
>Поведение функций зависит только от аргументов и влияет лишь на возвращаемое значение
Неправильно. И объекты, и функции, могут как обладать внутренним состоянием, так и не обладать. Причем даже не обладая внутренним состоянием, они могут иметь квази-внутреннее состояние (путем возврата модифицированной копии). Здесь никакой разницы нет.
>поэтому зачастую по одной только сигнатуре можно понять, что она делает.
Ну давай, расскажи мне, что делает [Float] -> IO [Float].
>>776072
А такое возможно вообще? Пример справедливый для этой части Вселенной, пожалуйста.
> полиморфизм через наследование - это костыль
А такое возможно вообще? Пример справедливый для этой части Вселенной, пожалуйста.
Ответы>>776645
>>771908
Ты ООП изобрел. Пишешь просто похоже на каком нибудь урезанном форке си
Ты ООП изобрел. Пишешь просто похоже на каком нибудь урезанном форке си
>>771908
У тебя получилась in-memory база данных без SQL.
Если у тебя язык без GC то непонятно кто будет освобождать память. Если с GC то советую для реестра объектов использовать weak references.
И вообще давай там без фанатизма, глобальные переменные ругают не зря.
У тебя получилась in-memory база данных без SQL.
Если у тебя язык без GC то непонятно кто будет освобождать память. Если с GC то советую для реестра объектов использовать weak references.
И вообще давай там без фанатизма, глобальные переменные ругают не зря.
Тред не читал. http://shaffner.us/cs/papers/tarpit.pdf уже упоминали?
>>776470
Это ещё один функци-анальный миф:
val sendto : file_descr -> bytes -> int -> int -> msg_flag list -> sockaddr -> int
Видишь эти два int -> int? Расскажи-ка мне, что это и зачем.
>зачастую по одной только сигнатуре можно понять, что она делает
Это ещё один функци-анальный миф:
val sendto : file_descr -> bytes -> int -> int -> msg_flag list -> sockaddr -> int
Видишь эти два int -> int? Расскажи-ка мне, что это и зачем.
Ответы>>776627
>>776618
Это говно, не делай так.
Haskell дал им type и newtype, но нет, не хочу давать нормальные имена типам, хочу жрать только базовые... и далее по пасте.
Я понимаю, что в мейнстриме все хуево даже с базовыми вещами вроде именования типов (хотя тайпдеф даже в сишечке есть), ну в хачкеле-то зачем продолжать жрать это говно? Там свое есть.
> что это
Это говно, не делай так.
Haskell дал им type и newtype, но нет, не хочу давать нормальные имена типам, хочу жрать только базовые... и далее по пасте.
Я понимаю, что в мейнстриме все хуево даже с базовыми вещами вроде именования типов (хотя тайпдеф даже в сишечке есть), ну в хачкеле-то зачем продолжать жрать это говно? Там свое есть.
Ответы>>776649
>>776470
This.
>У объектов же есть есть ещё подводная часть айсберга - его внутреннее состояние и связи с другими объектами, у которых оно тоже есть, а это уже очень трудно поддается документированию
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"
>>776627
Они от этого пропадут или что? Или можно подписать "абстрактно-могадическая рекурсивная фабрика интов" чтобы было всё просто и понятно?
Они от этого пропадут или что? Или можно подписать "абстрактно-могадическая рекурсивная фабрика интов" чтобы было всё просто и понятно?
Ответы>>776653
>>776649
Во-первых, они от этого станут понятными.
Во-вторых, они начнут выполнять свою основную задачу - специализацию (после валидации) данных, попавших из одной части программы в другую, чтобы не проверять их корректность в каждой функции на входе.
Не надо, проще говоря, использовать String для фамилии пользователя, и не потому что стрингов в хаскеле больше чем расширений GHC, и все они еще хуже совместимы между собой. А потому что проверив эту фамилию на то что она фамилия (буквы там русские-английские, пробелов нет с цифрами), надо пометить ее тем что она уже проверена и это действительно фамилия - проще всего сделать это одноврменно в конструкторе типа LastName. И в сигнатуре функции будет не String, из которого ничего непонятно, а LastName, из которого все понятно.
В перле для этого был taint mode, который решал эту задачу не через жопу а просто и удобно - но во многом потому перл больше и не с нами, слишком уж все было в нем просто и удобно.
Во-первых, они от этого станут понятными.
Во-вторых, они начнут выполнять свою основную задачу - специализацию (после валидации) данных, попавших из одной части программы в другую, чтобы не проверять их корректность в каждой функции на входе.
Не надо, проще говоря, использовать String для фамилии пользователя, и не потому что стрингов в хаскеле больше чем расширений GHC, и все они еще хуже совместимы между собой. А потому что проверив эту фамилию на то что она фамилия (буквы там русские-английские, пробелов нет с цифрами), надо пометить ее тем что она уже проверена и это действительно фамилия - проще всего сделать это одноврменно в конструкторе типа LastName. И в сигнатуре функции будет не String, из которого ничего непонятно, а LastName, из которого все понятно.
В перле для этого был taint mode, который решал эту задачу не через жопу а просто и удобно - но во многом потому перл больше и не с нами, слишком уж все было в нем просто и удобно.
Ответы>>776903
>>776903
Во-первых, читаемо.
Во-вторых, когда плохой код можно легко визуально отличить от хорошего - это довольно удобно. На Python или Java, например, это сделать на порядок сложнее.
Плохой код и хороший код можно написать на любом языке, странно что ты этого не знаешь.
Во-первых, читаемо.
Во-вторых, когда плохой код можно легко визуально отличить от хорошего - это довольно удобно. На Python или Java, например, это сделать на порядок сложнее.
Плохой код и хороший код можно написать на любом языке, странно что ты этого не знаешь.
Не подскажет кто программу для автоматического заполнения гугловских форм ,к примеру форма - https://docs.google.com/forms/d/1PvUaFTc4eMPUTeqa3UFnH4g9fFGyxJ07h6hp94yqweo/viewform?c=0&w=1 ,нужно чтобы вбивало постоянно 1 и те же указанные данные автоматически каждую минуту
Ответы>>777902
>>777524
Самому сделать не?
Самому сделать не?
>>772633
Кукарекнул петух.
Так и автор копипасты петух, а не спец по гую. А вот спецы из Эппла выбрали именно ООП для моделирования сложного GUI на Mac OS X.
> Я вот с ходу могу сказать, что гуйню лучше моделировать стрелками, чем объектами
Кукарекнул петух.
> а про гуй пусть лучше спецы по гуи напишут, от них то мы и узнаем
Так и автор копипасты петух, а не спец по гую. А вот спецы из Эппла выбрали именно ООП для моделирования сложного GUI на Mac OS X.
Ответы>>777984
>>777939
Это спецы из NeXT выбрали. "Спецы" из Apple тогда пешком под стол ходили.
Выбрали неудачно, поэтому NeXT загнулся.
Но ничего другого с собой принести Жобсу не было когда опять в огрызку позвали.
>спецы из Эппла выбрали именно ООП
Это спецы из NeXT выбрали. "Спецы" из Apple тогда пешком под стол ходили.
Выбрали неудачно, поэтому NeXT загнулся.
Но ничего другого с собой принести Жобсу не было когда опять в огрызку позвали.
Ответы>>778034
>>777984
Можно было с нуля разработать. В любом случае, самый крутой GUI всегда (с первого Мака) делали в Apple, а поделки борщехлебов на стрелках и монадах недалеко ушли от Tk. Полупрозрачность? Резиновая верстка? Создание своих компонент? Аппаратное ускорение и 3D эффекты? Нет, не слышали.
Можно было с нуля разработать. В любом случае, самый крутой GUI всегда (с первого Мака) делали в Apple, а поделки борщехлебов на стрелках и монадах недалеко ушли от Tk. Полупрозрачность? Резиновая верстка? Создание своих компонент? Аппаратное ускорение и 3D эффекты? Нет, не слышали.
>>778034
Самый крутой GUI сейчас вообще на вебе делают.
Самый крутой GUI сейчас вообще на вебе делают.
>>778034
Самый крутой гуй никакого отношения к ООП не имеет и называется FRP.
Самый крутой гуй никакого отношения к ООП не имеет и называется FRP.
Тащемта, я делал гуй на entity component systems, и получалось не хуже (а местами сильно лучше) оопепешного.
>>778560
Тащем - то те полтора пользователя этого гуя блевали в сторонку от этого поделия.
Проблемы которые решает FRP ортогональны проблематике хорошего UI. Поэтому сравнение со сложившимися практиками интересно только разработчикам. Вопросы надежности и корректности, как и удобство разработки, пользователям по барабану.
Тащем - то те полтора пользователя этого гуя блевали в сторонку от этого поделия.
Проблемы которые решает FRP ортогональны проблематике хорошего UI. Поэтому сравнение со сложившимися практиками интересно только разработчикам. Вопросы надежности и корректности, как и удобство разработки, пользователям по барабану.
>>778566
Уёбище, научись пробелы ставить между дефисом, пол часа пытался прочитать первое предложение.
Тащем-то, ты — хуесос.
Уёбище, научись пробелы ставить между дефисом, пол часа пытался прочитать первое предложение.
Тащем-то, ты — хуесос.
Ответы>>778770
>>778560
ООП в GUI все только усложняет.
ООП в GUI все только усложняет.
>>778770
Я тут вообще мимо проходил, просто ты тупое уёбище портящее ощущение от чтения сосачика.
Я тут вообще мимо проходил, просто ты тупое уёбище портящее ощущение от чтения сосачика.
>>775300
Не смотрел, но полагаю 0. Учить мартыханов программировать на Хаскелле смысла не имеет, а нормальный Хаскеллист может поехать в Лондон или в Сингапур, зачем ему обязательно стоять в московских пробках по пути в бирюлёво?
Не смотрел, но полагаю 0. Учить мартыханов программировать на Хаскелле смысла не имеет, а нормальный Хаскеллист может поехать в Лондон или в Сингапур, зачем ему обязательно стоять в московских пробках по пути в бирюлёво?
>>779144
Почему бы и нет? Хотя можно гораздо проще - без FRP и классического списка событий. Тупо глобальный gui.update(), который иерархически прогоняет список накопившихся событий по компонентам. То есть Form1 при вызове update прогоняет его вместе с рисовательным ресурсом через все дочерние виджеты. Нет FRP-наркомании, нет onClick ебанатства. Для простой логики можно все разруливать на уровне формы, в одной жирной функции. Для сложных виджетов делать подписку на onEvent. Что-то вроде immediate gui, но без обязательного перестроения на каждый апдейт.
>на каждый чих заводишь отдельный стрим?
Почему бы и нет? Хотя можно гораздо проще - без FRP и классического списка событий. Тупо глобальный gui.update(), который иерархически прогоняет список накопившихся событий по компонентам. То есть Form1 при вызове update прогоняет его вместе с рисовательным ресурсом через все дочерние виджеты. Нет FRP-наркомании, нет onClick ебанатства. Для простой логики можно все разруливать на уровне формы, в одной жирной функции. Для сложных виджетов делать подписку на onEvent. Что-то вроде immediate gui, но без обязательного перестроения на каждый апдейт.
Ответы>>779180
>>779180
Ну и правильно. Идея строгого разделения рисования-логики кнопочек-логики приложения - отрыжка 90-х. Гораздо удобнее все чохом лепить, с абстракциями где необходимо.
Ну и правильно. Идея строгого разделения рисования-логики кнопочек-логики приложения - отрыжка 90-х. Гораздо удобнее все чохом лепить, с абстракциями где необходимо.
Ответы>>780960
>>779186
Где же ты был тогда, герой архитектуры? Столько бы сотен тысяч человеко-часов спас, научил бы индустрию
А ну да, в 90х же твоя мамка только в первый класс пошла
Где же ты был тогда, герой архитектуры? Столько бы сотен тысяч человеко-часов спас, научил бы индустрию
> чохом лепить, с абстракциями где необходимо.
А ну да, в 90х же твоя мамка только в первый класс пошла
Ответы>>783032
>>772766
ООП это просто красивый способ зашить стейт-монаду в синтаксис так, чтобы этим было удобно пользоваться.
ООП это просто красивый способ зашить стейт-монаду в синтаксис так, чтобы этим было удобно пользоваться.
>>782975
Нет никаких монад. Проснись, ты говоришь на петушином новоязе.
Нет никаких монад. Проснись, ты говоришь на петушином новоязе.
Ответы>>789186
>>783217
Каждый объект O соответствует стейт монаде со стейтом состоящим из записи R со всеми полями объекта O.
Нестатические методы - это функции типов
method : ..args.. -> State R result
Каждый объект O соответствует стейт монаде со стейтом состоящим из записи R со всеми полями объекта O.
Нестатические методы - это функции типов
method : ..args.. -> State R result
Объектно-ориентированная парадигма была выдумана
чтобы как-то организовать мышление в случаях,
когда программы большие, и не запутаться
Дело в том, что у человека ограниченная возможность
"обозреть" множество деталей, а потому любые
методы, расширяющие видимое, охватываемое поле
понимания, приводят к "лучшему программированию"
Но беда в том, что ООП превратилось в монстра,
который не помогает как птице, 'увидеть задачу
с высоты', но ОБСЛУЖИВАЕТ САМ СЕБЯ - б'ольшая
часть умственных усилий тратится на то, чтобы
создавать и помнить детали самих ООП patterns
В этом смысле, это как бюрократия: министерство
с/хозяйства на 70% занято поддержанием внутренних
процессов, которые создает само, и лишь на остаток
как-то соотносится с действительностью.
Доказательством тому служат на порядок более
пухлые и раза в 1.5-2 более долгие при выполнении
программы ООП, по сравнению с программами на
процедурных языках (и тем более на функциональных)
чтобы как-то организовать мышление в случаях,
когда программы большие, и не запутаться
Дело в том, что у человека ограниченная возможность
"обозреть" множество деталей, а потому любые
методы, расширяющие видимое, охватываемое поле
понимания, приводят к "лучшему программированию"
Но беда в том, что ООП превратилось в монстра,
который не помогает как птице, 'увидеть задачу
с высоты', но ОБСЛУЖИВАЕТ САМ СЕБЯ - б'ольшая
часть умственных усилий тратится на то, чтобы
создавать и помнить детали самих ООП patterns
В этом смысле, это как бюрократия: министерство
с/хозяйства на 70% занято поддержанием внутренних
процессов, которые создает само, и лишь на остаток
как-то соотносится с действительностью.
Доказательством тому служат на порядок более
пухлые и раза в 1.5-2 более долгие при выполнении
программы ООП, по сравнению с программами на
процедурных языках (и тем более на функциональных)
>>783522
Да откуда ж вы лезете-то в таком количестве.
>>772766
Да откуда ж вы лезете-то в таком количестве.
>>772766
>философия ООП, которая превратила все картины, загораживающие дырки на обоях, в "краеугольные камни" концепции и "имманентные особенности человеческого мЫшленья"
Ответы>>783596
>>783522
Это поэма?
Это поэма?
>>783564
Да похуй в каком виде это реализовать: через параметризованные модули, через какие-нибудь "контексты", через классы/объекты, через стейт монады. Главное, что это должно быть реализовано в языке, причём так, чтобы этим можно было удобно пользоваться на каждом шагу, потому что оно нужно на каждом шагу.
> философия ООП, которая превратила все картины, загораживающие дырки на обоях, в "краеугольные камни" концепции и "имманентные особенности человеческого мЫшленья"
Да похуй в каком виде это реализовать: через параметризованные модули, через какие-нибудь "контексты", через классы/объекты, через стейт монады. Главное, что это должно быть реализовано в языке, причём так, чтобы этим можно было удобно пользоваться на каждом шагу, потому что оно нужно на каждом шагу.
Ответы>>783621
>>770268 (OP)
Жиза на оп-пике
Жиза на оп-пике
>>783719
Это ясно уже по первым строкам написанного и по манере общения. Анончик спрашивает, что сказать то хотел?
Это ясно уже по первым строкам написанного и по манере общения. Анончик спрашивает, что сказать то хотел?
>>775980
Монады тоже не композабельны в общем случае, напомню.
>Объект - плохая абстракция, потому как не является композабельной
Монады тоже не композабельны в общем случае, напомню.
Ответы>>787298
>>770268 (OP)
Лень читать тред. Напомни, анон, есть ли у борщехлебов что-нибудь подобное божественному Qt?
Лень читать тред. Напомни, анон, есть ли у борщехлебов что-нибудь подобное божественному Qt?
>>787291
С монадами, стрелками и эффектами есть куда разиваться.
http://okmij.org/ftp/Haskell/extensible/index.html
С объектами - тупик.
С монадами, стрелками и эффектами есть куда разиваться.
http://okmij.org/ftp/Haskell/extensible/index.html
С объектами - тупик.
Ответы>>787427
Ответы>>787302
>>787305
Только это не нужно как и он сам.
Только это не нужно как и он сам.
>>787302
Тебе хватило одной минуты и сорока семи секунд чтобы ознакомиться с совершенно новой для тебя, и сложной технологией, и успеть задать хорошо обдуманный, конструктивный вопрос.
Да ты блджад Феномен.
Тебе хватило одной минуты и сорока семи секунд чтобы ознакомиться с совершенно новой для тебя, и сложной технологией, и успеть задать хорошо обдуманный, конструктивный вопрос.
Да ты блджад Феномен.
Ответы>>787379
>>787308
Не нужно учить весь лисп, чтобы понять, что это говно без задач.
Не нужно учить весь лисп, чтобы понять, что это говно без задач.
>>787305
Любая достаточно сложная программа на Си или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp.
Филип Гринспен
…в том числе и сам Common Lisp.
Роберт Моррис
Любая достаточно сложная программа на Си или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp.
Филип Гринспен
…в том числе и сам Common Lisp.
Роберт Моррис
>>787297
Напомни, анон, есть ли у байтослесарей что-нибудь подобное божественному Apache Spark?
> 2016
> потешный ком костылей на гигабайт для формочек
Напомни, анон, есть ли у байтослесарей что-нибудь подобное божественному Apache Spark?
Ответы>>787413
Ответы>>787415
>>787413
Лол блять, до чего же тупое животное.
> Hadoop
> речь про Spark
> only about 1.75GB
> сравнивает с локалхостом
> нинужна!
Лол блять, до чего же тупое животное.
Ответы>>787433
>>787298
Структура кода и её свойства оверрейтед. Важно что код делает, с точностью до изоморфизма.
А сделать красивое и удобное апи поверх содержательного кода можно бесконечным количеством способов,
и на мейнстримном ООП в том числе.
Лично я мечтаю о юзабельном языке, на котором нельзя написать две разные программы, делающие одно и то же.
Структура кода и её свойства оверрейтед. Важно что код делает, с точностью до изоморфизма.
А сделать красивое и удобное апи поверх содержательного кода можно бесконечным количеством способов,
и на мейнстримном ООП в том числе.
Лично я мечтаю о юзабельном языке, на котором нельзя написать две разные программы, делающие одно и то же.
>>787427
Урезанный ассемблер, без альтернативных инструкций и джампов.
> языке, на котором нельзя написать две разные программы, делающие одно и то же.
Урезанный ассемблер, без альтернативных инструкций и джампов.
>>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/
>>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]
>Лично я мечтаю о юзабельном языке, на котором нельзя написать две разные программы, делающие одно и то же.
Такой язык не будет Тьюринг-полным.
Если бы было иначе, то ты такой
[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
>>787427
Был тут когда-то курс по окамлу. Для него пацаны написали автоматический проверяльщик заданий, который генерировал правильные значения на лету и сравнивал их с теми, которые выдаёт твой код. Сравнивал, конечно, через "=" (а как ещё-то?). И были в том курсе задачки с флоатами. И всё, вроде бы, нормально, потому что полученные одним и тем же путём флоаты, на одном и том же компьютере всегда будут иметь одно и то же значение. Вот только есть одна маленькая проблемка - если ты, например, сохранил число в переменную, а не подставил само выражение, то это уже другой путь. В общем, первую задачу я решил за ~15 минут, после чего ещё часа полтора пытался угадать, как они написали эталонную программу. Остальные задачи я не решил (точнее, решил, но в зачёте было 0, по понятным причинам). А теперь представь, что тебе это надо делать для каждой программы, иначе она не будет конпеляться. Ты же первый назовёшь этот язык говном и больше никогда к нему не притронешься.
Был тут когда-то курс по окамлу. Для него пацаны написали автоматический проверяльщик заданий, который генерировал правильные значения на лету и сравнивал их с теми, которые выдаёт твой код. Сравнивал, конечно, через "=" (а как ещё-то?). И были в том курсе задачки с флоатами. И всё, вроде бы, нормально, потому что полученные одним и тем же путём флоаты, на одном и том же компьютере всегда будут иметь одно и то же значение. Вот только есть одна маленькая проблемка - если ты, например, сохранил число в переменную, а не подставил само выражение, то это уже другой путь. В общем, первую задачу я решил за ~15 минут, после чего ещё часа полтора пытался угадать, как они написали эталонную программу. Остальные задачи я не решил (точнее, решил, но в зачёте было 0, по понятным причинам). А теперь представь, что тебе это надо делать для каждой программы, иначе она не будет конпеляться. Ты же первый назовёшь этот язык говном и больше никогда к нему не притронешься.
>>787427
Ничего хорошего из этой затеи не выйдет. Насколько я понял, лямбда-исчисление с одним типом подходит, но если ты добавляешь натуральные числа, то ничего не выйдет в общем случае, а в частном случае тебе придется подробно указать максимум информации о функции в ее типе, чтобы что-то можно было доказывать.
Лучше уж просто хранить в распределенной базе данных хеш от AST функции и ее значений, как пацаны что Unison делают собираются.
>нельзя написать две разные программы, делающие одно и то же
Ничего хорошего из этой затеи не выйдет. Насколько я понял, лямбда-исчисление с одним типом подходит, но если ты добавляешь натуральные числа, то ничего не выйдет в общем случае, а в частном случае тебе придется подробно указать максимум информации о функции в ее типе, чтобы что-то можно было доказывать.
Лучше уж просто хранить в распределенной базе данных хеш от AST функции и ее значений, как пацаны что Unison делают собираются.
>>783037
Такое же бесполезное говно как и ООП, кстати, и тот же хайп вокруг него. История идёт по кругу.
Такое же бесполезное говно как и ООП, кстати, и тот же хайп вокруг него. История идёт по кругу.
Тред утонул или удален.
Это копия, сохраненная 26 июля 2016 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 26 июля 2016 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.