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

I>>В твоей картине отсутствует тот, кто пишет код. А вот тенденция такая, что все больше и больше людей идет в разработчики. Фактически, появляются каменщики, бетонщики, арматурщики, маляры, штукатуры и тд — люди, которые выполняют ровно одну задачу.
I>>И что характерно, у них уже нет ни то классного инженерного образования или, ни, тем более, прикладной или теоретической математики. А чем же они могут пользоваться, если абстрактное мышление у них слабовато ?
S>Вот это — большой вопрос. Грубо говоря, в екселе вся "программа" на виду. Если криворукий финансист будет допиливать решение на своём листе, то он запорет только своё решение.

Финансист запорет всю контору своим файликом. Я сколько ни видел таких файликов, они приходят в readonly, что бы абы кто не редактировал. То есть, слишком рисковано доверять одному специалисту в другой области.

S>Императив требует понимания не только "статической" картинки, но и динамики — как состояние изменяется со временем.
S>Большинство ошибок в императиве именно оттуда — у человека есть какая-то картинка, типа "заказ создают, потом аттачат платёж, потом проводят платёж, потом отгружают, потом закрывают".
S>И он пишет код для каждого этапа в святой уверенности, что он представляет себе состояние заказа в момент начала своей программы.
S>А потом оказывается, что совсем другой человек дописал ещё кусочек, и теперь у нас действие "отгрузка" происходит до действия "оплата", и всё взрывается из-за деления на букву О.
S>Причём оба человека свои кусочки по отдельности протестировали, и сходу ткнуть в ошибку ни в одном из них нельзя.

Аналогично и в функциональном, если другой человек дописал еще какой то кусочек. Все ровно то же — нужно понимание динамики.

S>Что мы будем делать с малярами и каменщиками? Чисто-линейных приложений типа "калькулятор" становится всё меньше.

Этих приложений становится всё больше. Когда будет пройдет пик — хрен его знает.

>Мы всё больше пилим data-intensive applications с массовыми совместными изменениями разделяемых данных; кто будет отлаживать всю вот эту лапшу, которую наши флюсоподобные специалисты напишут на императивном языке?

Не сильно знаю, чего именно вы пилите, но везде спрос на фронтов у которых основной скилл это CSS+JS и минимальные навыки кодинга и базовые алгоритмы на уровне "простой фильтр по массиву".

S>Выход один — вообще не давать этим людям шанса работать с состоянием. Только декларативное ФП.

Теоретически, к этому идет, даже на фронте распространяется redux. Одна проблема — такие вещи для многих почему то слишком сложны

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

I>>В твоей картине отсутствует тот, кто пишет код. А вот тенденция такая, что все больше и больше людей идет в разработчики. Фактически, появляются каменщики, бетонщики, арматурщики, маляры, штукатуры и тд — люди, которые выполняют ровно одну задачу.
I>>И что характерно, у них уже нет ни то классного инженерного образования или, ни, тем более, прикладной или теоретической математики. А чем же они могут пользоваться, если абстрактное мышление у них слабовато ?
S>Вот это — большой вопрос. Грубо говоря, в екселе вся "программа" на виду. Если криворукий финансист будет допиливать решение на своём листе, то он запорет только своё решение.

Финансист запорет всю контору своим файликом. Я сколько ни видел таких файликов, они приходят в readonly, что бы абы кто не редактировал. То есть, слишком рисковано доверять одному специалисту в другой области.

S>Императив требует понимания не только "статической" картинки, но и динамики — как состояние изменяется со временем.
S>Большинство ошибок в императиве именно оттуда — у человека есть какая-то картинка, типа "заказ создают, потом аттачат платёж, потом проводят платёж, потом отгружают, потом закрывают".
S>И он пишет код для каждого этапа в святой уверенности, что он представляет себе состояние заказа в момент начала своей программы.
S>А потом оказывается, что совсем другой человек дописал ещё кусочек, и теперь у нас действие "отгрузка" происходит до действия "оплата", и всё взрывается из-за деления на букву О.
S>Причём оба человека свои кусочки по отдельности протестировали, и сходу ткнуть в ошибку ни в одном из них нельзя.

Аналогично и в функциональном, если другой человек дописал еще какой то кусочек. Все ровно то же — нужно понимание динамики.

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

А что, в функциональном не надо думать про это ? Можно подумать все запросы к базе сами выстроятся в нужном порядке.

S>Что мы будем делать с малярами и каменщиками? Чисто-линейных приложений типа "калькулятор" становится всё меньше.

Этих приложений становится всё больше. Когда будет пройдет пик — хрен его знает.

>Мы всё больше пилим data-intensive applications с массовыми совместными изменениями разделяемых данных; кто будет отлаживать всю вот эту лапшу, которую наши флюсоподобные специалисты напишут на императивном языке?

Не сильно знаю, чего именно вы пилите, но везде спрос на фронтов у которых основной скилл это CSS+JS и минимальные навыки кодинга и базовые алгоритмы на уровне "простой фильтр по массиву".

S>Выход один — вообще не давать этим людям шанса работать с состоянием. Только декларативное ФП.

Теоретически, к этому идет, даже на фронте распространяется redux. Одна проблема — такие вещи для многих почему то слишком сложны