Здравствуйте, samius, Вы писали:

I>>Я такое давал своим детям несколько лет назад, кроме рекурсии. Это была настольная игра. Дочка только-только пошла в школу и нормально справлялась.
S>Есть координаты настольной игры?

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

I>>Человек, который принимает решения определяет вообще всё, соответсвенно степень влияния менеджмента выше любых технических вопросов. Например, менеджер не только может принять решение о технологии, но и может убрать бюджет из разработки и передать в тестирование "а для багфикса студентов наймём"
S>Конечно, но когда я сравниваю влияние яп, я пытаюсь мысленно изолировать все остальные факторы. Т.е. берем 2 равные команды и при прочих равных одной даем писать на одном языке, другой — на другом.

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

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

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

I>>Пример из жизни, менеджер и архитект по совместительству: "давайте на нетворк драйв поместим Хромиум портабл, что бы юзерам не надо было ни инсталировать, ни копировать". А тот факт, что Хромиум так работать не может, его не сильно интересует, и менеджер включает "гестапо": "Крешится Хромиум — вы неправильно ваш жээс пишете, не надо мне сказки рассказывать".
I>>В итоге — полгода война между менеджером и командой разработчиков закончилась пирровой победой разработчиков, а времени на внятное решение уже нет.

S>Менеджер решает, а разработчик — делает. Кушать будут с того, что сделал разработчик. Потому, диалог и понимание здесь решают больше, чем может решить менеджер в одни ворота. Это организация процесса и ее я предлагаю вынести за скобки при сравнении эффективности применения разных инструментов (фп или ип).

Если цель добиться качества на конкретном проекте, то менеджмент и коммуникация влияют намного сильнее парадигмы. Поэтому держаться за парадигму лично я смысла большого не вижу — чистое ФП нужно брать тогда, когда нужны гарантии корретной работы. Руками такое не обеспечишь.

I>>Или такие варианты:
I>>"А давай ты до конца митинга вот эту фичу запилишь"
I>>"Мы договорились на месяц, но надо сделать за 10 дней, + дополнительно две новые фичи, что бы показать какие мы крутые"
I>>"Давай ты за выходные дофиксишь баклог"
I>>Надо объяснять, что все функционалисты выпилились из того проекта?
S>Если можно выпиливаться, то в порядке вещей вообще выпиливаться из такого проекта, невзирая на парадигму. Выглядит так, будто функционалисты оказались прошареннее.

Быстрее всего выпиливаются те, кто наиболее востребован. Функционалист, если он адекватен как человек, как правило очень быстро находит новое место.

I>>Некоторые решения необратимы. Например "у нас на бенче 100 джаваскрипт сеньоров, будем писать на node" Наличие таких мер влияет на качество гораздо сильнее парадигмы.
S>Безусловно. Но кто заставляет держать таких решал на местах, где они принимают такие решения? Это же просто враги любой разработки, не говоря уж о бизнесе.

Я больше скажу — бизнес сам слишком часто рубит свои же хорошие начинания. Например, сами проводят собеседования на проект, который написан в функционально-реактивном стиле. Парадокс — собеседования успешно проходят в основном студенты или недавние студенты, а вот сеньоры разных сортов или не проходят, или проходят и уходят не задерживаясь. Я посмотрел, что же они спрашивают. Оказалось, что алгоритмические задачи типа рюкзаков, при чем хотят не перебор а какое нибудь эффективно решение на динамическом программировании и тд.
Фактически, эти задачи проверяют один единственный аспект, который на проекте вобщем не востребован — ну негде в рядовом приложении применить знания динамического программирования. Студенты еще помнят такие вещи, худо-бедно проходят собеседования. Сеньоры такое встречают не каждый день и даже не каждые полгода. А если проходят собес, то быстро теряют к нему интерес, т.к. математику там применить негде.
Итого — в проекте очень быстро начинается хаос. Пример хаоса — десериализуем и процессим 20мб граф в виде json в браузере. Очевидно, что все будет мерзнуть. Решение — граф транслируем в массив на сервере, а на клиент отдадим немного другим json теми же 20мб Теперь мерзнет и сервер и браузер. "Ну и что — у нас всего 5 запросов в минуту!"

Другой пример — бизнес вынуждает людей уровня сеньора заниматься всевозможными monkey job, при этом не хочет набирать ни опсов, ни девопсов, ни тестировщиков, типа "это всё код, а код лучше всего умеют писать девелоперы!!!"
Почему этим занят бизнес — а потому, что они платят деньги и вот так они обращались со своими разработчиками. Идея зашла в тупик, но они проигрывают её еще раз, но уже с оффшорными командами.