alf
(1) Растворение паттернов. Вообще любой хорошо подходящий к задаче код (DDD: Ubiquitous Language) имеет привычку выносить из системы мусор. На моем опыте чаще всего вылетали многократно повторяющиеся проверки, но были и целые подсистемы, делающие ничего очень сложным способом. Это все правда, но это настолько простая мысль, что я поражен что кто-то может в ней найти что-то свежее.
хотя хрен с ним, чего это я. Пусть Алан Кей отдувается. ‎- alf
+100500. В своё время читал её же в изложении Патрышева (мол, design patterns в ООП ни на что не ложатся в ФП и просто исчезают, т.к. там не надо обходить косяки концепции). Для того, чтобы такая мысль появилась, нужен опыт хоть какой-то работы в другой концепции. А это трудно; например, в старшей школе я прилично знал бейсик, ассебмлер PDP-11, паскаль и фортран, но попытки читать книжки про лисп и смоллток вообще провалились, я ничего не понял, оно совсем не ложилось ни на что известное мне про компьютеры. ‎- 9000
(2) Несмотря на все счастье от пункта 1, он обычно съедает преизрядно времени, а для конечного клиента от этого пользы мало — в лучшем случае код начнет быстрее работать, но кто сказал что это было целью? Возможно, _дальше_ будет проще — но это серьезная ставка, которая может и не сыграть. Фаулер и иже с ним предлагают просто прятать (хотя бы минимальный) рефакторинг в оценку каждой задачи, и запасаться стальными яйцами и тестами. В существующей же системе тестов меньше, а ставки выше. ‎- alf
- в существующей системе яйца стальнее ‎- Все собаки попадают в рай
(3) Сам тезис о более мощном языке очень интересный, и упомянутый тут Норвиг, к слову, как раз среди тех, кому я не верю, но очень хочу понять, почему они говорят то что они говорят. Вот его презентация времен Арлекина: http://norvig.com/design-patterns/design-patterns.pdf — и он, я так понимаю, один из первых продает рант о том что Design Patterns изрядной частью просто издержки ООП. Это правда, кстати, так оно и есть, но паттерны в функциональном и/или динамическом коде не "исчезают" и не "растворяются" — они просто удобнее записываются. Strategy — это просто функция, ок, но у этой функции есть проблема, которую она решает, способ, и название. Вот вам паттерн. Command — тоже просто функция, но команды нам надо пасти либо как историю, либо как список в UI, либо... и называться они будут все так же командами. Да даже если учить джаверов скале, я съэкономлю день как минимум, сказав что тайпкласс в скале — это Adapter. ‎- alf
(4) Дальше о более мощных языках. Окасаки уже под конец книги, когда читатель просит пощады, пишет "...and even `update` is simpler if you are comfortable with higher-order functions." Окасаки, во второй трети книги, расшаркивается по поводу higher-order functions? Что-то мне подсказывает, что он не просто кокетничает. ‎- alf
(5) То же самое с монадами, см. выступления Мартина Одерски, который таки не хочет тащить их в Скалу, *потому что сложно.* ‎- alf
То есть просто более "мощные" инструменты сами по себе как-то не очень работают. Хаскель отличный язык, все любят показывать как написать решето Эратосфена в две строки: primes = sieve [2..] where { sieve (p : xs) = p : sieve [x | x <− xs, x ‘mod‘ p > 0] } — только, увы, This computation may take a few seconds, and do several garbage collections, as there is a lot of recursion going on. — https://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf — и это преданные сторонники языка лажают, не враги. Просто потому что чем мощнее инструмент,... ‎- alf
Да, дальше можно взять Эрика Майера и Rx. Безумно прекрасный инструмент, простой и красивый. Пока работает, и пока все отдают себе отчет в том, что, где, чего, и почему ждет. Но пока до проблем дело не дошло — чистое счастье. Так вот, чем мощнее инструмент, тем больше способов прострелить себе ногу даже не понимая что у тебя в руках ружье. Я понимаю, что это утверждение уровня хабровых наездов на Махоткина, но оно от этого не перестает быть правдой: мощный инструмент требует очень мощных рабочих. ‎- alf
И проблема, мне кажется, все-таки не в инструменте. Как хохмили ребята из Azul про многопоточность, процессоры готовы давно, языки в общем тоже. Люди — нет. ‎- alf
То есть либо мы начинаем учить людей лучше — хороший ход, но небыстрый, либо мы ищем другой способ решать проблемы. Часть проблемы, как справедливо отметили, в том что изрядное количество проблем существует только у нас в голове. И поскольку многие фреймворки брошены на проблему, которую мы придумали, то можно просто выбросить фреймворки, и... пойти решать проблему вручную? Тут я рискую бороться с чучелком, потому что тезиса я собственно не видел. Положим, решение проблем вручную даст нам возможность из переосмыслить. Мне кажется нет, этого не случится: люди, придумавшие проблему, обычно умеют хорошо убеждать себя в том что проблема _важна_. И вместо более простого кода мы получаем сложный код и еще один фреймворк, только недоделанный. ‎- alf
А если доделанный, то тут недавно поминали https://xkcd.com/927/ ‎- alf
Вот если бы ты сразу так написал, был бы осмысленный диалог. Завтра отвечу, сразу напишу что согласен со многим, но есть нюансы. ‎- big data in petite analysts
То есть более верный способ, мне кажется — перестать <s>шеймить сиськи</s> наезжать на код, который, скорее всего, делает что просили — и делает это неплохо. В конце концов, весь этот ад — последствия того что вместо кошмарного EJB2 (full disclosure: я читал тонкую брошюрку, а не толстую книгу, поэтому EJB2 никогда не казался мне тем адом, про который все говорят, ну да не суть) и еще не появившегося EJB3 появился прекрасный новый _простой_ Spring. Просто к тому моменту, как сняли этот стектрейс, в него уже притащили все. Увы. ‎- alf
Вместо этого надо рассказывать, почему проблема не важна — или как ее решать без кода. Либо, как в случае многих новых систем, просто делать свое и заменять старое. Многие так и делают, вот скажем Spring... OH WAIT. ‎- alf
сорри, понял что не смогу написать. во первых слишком много и сложно получается, во вторых очень тяжело построить цельный нарратив чтобы все связать. я, честно сказать, не готов на этот эпический подвиг. как нибудь постараюсь потихоньку накидать отдельные куски в рабочем порядке, если появится вдохновение. ‎- big data in petite analysts
Ну у меня нарратив тоже разваливается, как видишь, но я к нему ещё вернусь. ‎- alf
ddd - это дебаггер :D ‎- silpol
Да, к примеру ^^^^^^^^^^^ тут: ровно такой же алгоритм, чуть более многословно, можно записать на Go (он приведён на главной странице golang.org), и получить примерно те же проблемы. Штука не в мощном инструменте, а в простодушном алгоритме. Есть ряд алгоритмов, "чуть менее" очевидных, типа алгоритма Дейкстры, которые и быстрее, и экономнее, притом на любом языке. ‎- 9000
^ да в том-то и дело, что решето Эратосфена — это вполне конкретный алгоритм, и достаточно быстрый. Просто адепты хотят продать, вот и врут по мелочи. А мощность инструмента приводит к тому что обман видно далеко не сразу. ‎- alf
@alf: Ну, он быстрый возможно, если деления не использовать, а использовать счётчики и выбрасывания, но и тогда он по понятным причинам замедляется по ходу дела. А так, как записан, он, считай, квадратичный по числу найденных чисел, т.к. каждое число надо проверить на делимость относительно всех предыдущих. Не удивительно, что он 100 чисел выдаёт бодро, на 1000 слегка задумывается, а на 10000 задумывается на много секунд. (Кстати, в том комменте неверный алгоритм, там надо немножко длиннее, и квадратичность сразу вылезет.) ‎- 9000