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

S>Что там может быть не понятно? Кол-во случаев освоения за 1-2 недели на общее кол-во попыток освоить. Например (цифры с потолка), ты утверждаешь что 20 из 100 (т.е. 0.2) студентов осваивают ип за 2 недели. Но только 1 из 100 (0.01) осваивает фп за 2 недели. Если у тебя нет таких данных, то я вообще не понимаю, что и с чем ты сравниваешь.

Статистики я не веду. Из наблюдений функциональщину легко осваивают студенты математических специальностей. У остальных в норме ожидать затруднений.
Что касается детей на кружках алгоритмики/робототехники, то я как то не вижу смысла давать функции за 5 лет до того, как их дадут в школе

I>>5) уровень разработки на проекте, например, подходы к тестированию, проектированию и тд
S>Безусловно зависит от. Но это перечисление, т.е. пункты неполного и неупорядоченного списка.

Это в порядке убывания важности. Если речь именно про качество, то начинать нужно с требований, т.к. качество это степень соответствия требованиям.

I>>И где то во втором десятке идут языки программирования и парадигмы. Например, при прочих равных, функционалист, которому наплевать и на работу, и на команду, и на результат, гораздо хуже ответственного педантичного студента императивщика.
S>Языки программирования и парадигмы не могут идти во втором десятке. Пример, возьмем для сравнения C++ с богатыми (даже стандартными) библиотеками и какой-нибудь срисованный с него MQL без спецификаций, почти без документации и абсолютно без совместимых библиотек. Почти на любом нетривиальном проекте при прочих равных мы обнаружим такую разницу в кол-ве багов, что она с головой покроет весь твой список. Это даже учитывая то, что работа с MQL не требует специальной подготовки специалиста, владеющего C или С++.

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

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

Здесь ровно так же — все известно на этапе принятия решения. Соответсвенно критическая часть не парадигма, а то, как принимают решения о выборе технологий.

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

S>Что там может быть не понятно? Кол-во случаев освоения за 1-2 недели на общее кол-во попыток освоить. Например (цифры с потолка), ты утверждаешь что 20 из 100 (т.е. 0.2) студентов осваивают ип за 2 недели. Но только 1 из 100 (0.01) осваивает фп за 2 недели. Если у тебя нет таких данных, то я вообще не понимаю, что и с чем ты сравниваешь.

Статистики я не веду. Из наблюдений функциональщину легко осваивают студенты математических специальностей. У остальных в норме ожидать затруднений.
Что касается детей на кружках алгоритмики/робототехники, то я как то не вижу смысла давать функции за 5 лет до того, как их дадут в школе
Собственно, у меня была идея вести такой кружок, но в данный момент это просто идея.

I>>5) уровень разработки на проекте, например, подходы к тестированию, проектированию и тд
S>Безусловно зависит от. Но это перечисление, т.е. пункты неполного и неупорядоченного списка.

Это в порядке убывания важности. Если речь именно про качество, то начинать нужно с требований, т.к. качество это степень соответствия требованиям.

I>>И где то во втором десятке идут языки программирования и парадигмы. Например, при прочих равных, функционалист, которому наплевать и на работу, и на команду, и на результат, гораздо хуже ответственного педантичного студента императивщика.
S>Языки программирования и парадигмы не могут идти во втором десятке. Пример, возьмем для сравнения C++ с богатыми (даже стандартными) библиотеками и какой-нибудь срисованный с него MQL без спецификаций, почти без документации и абсолютно без совместимых библиотек. Почти на любом нетривиальном проекте при прочих равных мы обнаружим такую разницу в кол-ве багов, что она с головой покроет весь твой список. Это даже учитывая то, что работа с MQL не требует специальной подготовки специалиста, владеющего C или С++.

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

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

Здесь ровно так же — все известно на этапе принятия решения. Соответсвенно критическая часть не парадигма, а то, как принимают решения о выборе технологий.