Re[65]: Мнение: объектно-ориентированное программирование —
От: samius Япония http://sams-tricks.blogspot.com
Дата: 30.10.19 16:45
Оценка: 18 (1)
Здравствуйте, Ikemefula, Вы писали:

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


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


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

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

I>>>5) уровень разработки на проекте, например, подходы к тестированию, проектированию и тд

S>>Безусловно зависит от. Но это перечисление, т.е. пункты неполного и неупорядоченного списка.

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

Конечно.

I>>>И где то во втором десятке идут языки программирования и парадигмы. Например, при прочих равных, функционалист, которому наплевать и на работу, и на команду, и на результат, гораздо хуже ответственного педантичного студента императивщика.


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

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

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


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

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