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

I>>Что касается детей на кружках алгоритмики/робототехники, то я как то не вижу смысла давать функции за 5 лет до того, как их дадут в школе
I>>Собственно, у меня была идея вести такой кружок, но в данный момент это просто идея.
S>Нет смысла. Нужна самая доступная форма. Видел где-то интерактивный web-учебник для детей с автоматизацией робота на питоне. Не проникся. Моим по-крайней мере рано. Что-то вот такое (https://lightbot.com/) планирую подсунуть.

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

I>>Как только приняли решение в пользу MQL, автоматически планка качества упала, даже если мы еще ни одной строчки не написали.
I>>Соответсвенно, сам принцип принятия решения важнее особенностей технологии.
S>Мы говорим не о принципах принятия решения, а о наличии влияния яп на качество результата. Ты выяснил, что влияет, даже если ни одной строчки еще не написали. А ты говоришь, во втором десятке факторов!

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

S>>>Я уж не говорю про разницу в кол-ве багов между исполнением проекта на ассемблере и C#.

I>>Здесь ровно так же — все известно на этапе принятия решения. Соответсвенно критическая часть не парадигма, а то, как принимают решения о выборе технологий.
S>Принятие решения (у меня по-крайней мере) — процесс итерационный. Выкатываешь продукт, требования меняются с ростом эксплуатации, старое решение не тащит. Тут и начинается самое интересное в принятии решений.

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

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

I>>Что касается детей на кружках алгоритмики/робототехники, то я как то не вижу смысла давать функции за 5 лет до того, как их дадут в школе
I>>Собственно, у меня была идея вести такой кружок, но в данный момент это просто идея.
S>Нет смысла. Нужна самая доступная форма. Видел где-то интерактивный web-учебник для детей с автоматизацией робота на питоне. Не проникся. Моим по-крайней мере рано. Что-то вот такое (https://lightbot.com/) планирую подсунуть.

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

I>>Как только приняли решение в пользу MQL, автоматически планка качества упала, даже если мы еще ни одной строчки не написали.
I>>Соответсвенно, сам принцип принятия решения важнее особенностей технологии.
S>Мы говорим не о принципах принятия решения, а о наличии влияния яп на качество результата. Ты выяснил, что влияет, даже если ни одной строчки еще не написали. А ты говоришь, во втором десятке факторов!

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

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

S>>>Я уж не говорю про разницу в кол-ве багов между исполнением проекта на ассемблере и C#.

I>>Здесь ровно так же — все известно на этапе принятия решения. Соответсвенно критическая часть не парадигма, а то, как принимают решения о выборе технологий.
S>Принятие решения (у меня по-крайней мере) — процесс итерационный. Выкатываешь продукт, требования меняются с ростом эксплуатации, старое решение не тащит. Тут и начинается самое интересное в принятии решений.

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