Исправление DonkeyHot, (текущая версия) :
питон такой же молоток
Однозначно. Но питонщики имеют шанс заметить, что что-то пошло не так - когда прога медленно работает, и проект ещё можно спасти.
В индустрии работает другой принцип: безобразно, зато однообразно
А должны были бы прибыль считать. Для демонстрации: положим: «скрипач» наскриптовывает одну медленную «функцию» за 1 «дедлайн», а «насильник» за то же время на си - 1 быструю. В базарный день, программы из 1 «горячей» и 1 «одноразовой» ф-ии идут быстрые по 100500 ватеверов, а медленные по 500, ибо никому не нужны, Очевидно, за 2 дедлайна первый заработает 500 а второй 100500, Однако, если они скооперируются, и первый напишет обе «одноразовые», а второй обе «горячие» ф-ии, они вместе заработают на 100000 больше, что почти невозможно поделить не обоюдовыгодно.
Думаю, можно подвигать цифры, и обнаружить, что выгода не положительна только при равных ценах(т.е. скорость никому не нужна).
Кстати, мне рассказали почти уважительную причину писать всё быстрым. Если твоя задача работает на 10000 компутерах, 1% производительности позволяет сэкономить на железе одну зарплату «оптимизатора». Не уверен, как это отражается на стоимости сопровождения и сроках, но это уже можно считать.
контексте гуи есть прикольный tcl
он прикольный не только в контексте гуи. IMO он провалился потому, что его писаки неправильно реализовали интерфейс и списков/словарей. '[lindex [expr $a+$b] $list]'(в деталях не уверен) никак не может соревноваться c 'list[a+b]'
Исправление DonkeyHot, :
питон такой же молоток
Однозначно. Но питонщики имеют шанс заметить, что что-то пошло не так - когда прога медленно работает, и проект ещё можно спасти.
В индустрии работает другой принцип: безобразно, зато однообразно
А должны были бы прибыль считать. Для демонстрации: положим: «скрипач» наскриптовывает одну медленную «функцию» за 1 «дедлайн», а «насильник» за то же время на си - 1 быструю. В базарный день, программы из 1 «горячей» и 1 «одноразовой» ф-ии идут быстрые по 100500 ватеверов, а медленные по 500, ибо никому не нужны, Очевидно, за 2 дедлайна первый заработает 500 а второй 100500, Однако, если они скооперируются, и первый напишет обе «одноразовые», а второй обе «горячие» ф-ии, они вместе заработают на 100000 больше, что почти невозможно поделить не обоюдовыгодно.
Думаю, можно подвигать цифры, и обнаружить, что выгода не положительна только при равных ценах(т.е. скорость никому не нужна).
Кстати, мне рассказали почти уважительную причину писать всё быстрым. Если твоя задача работает на 10000 компутерах, 1% производительности позволяет сэкономить на железе одну зарплату «оптимизатора». Не уверен, как это отражается на стоимости сопровождения и сроках, но это уже можно считать.
контексте гуи есть прикольный tcl
он прикольный не только в контексте гуи. IMO он провалился потому, что его писаки неправильно реализовали интерфейс и списков/словарей. '[lindex [expr a+b] $list]'(в деталях не уверен) никак не может соревноваться c 'list[a+b]'
Исправление DonkeyHot, :
питон такой же молоток
Однозначно. Но питонщики имеют шанс заметить, что что-то пошло не так - когда прога медленно работает, и проект ещё можно спасти.
В индустрии работает другой принцип: безобразно, зато однообразно
А должны были бы прибыль считать. Для демонстрации: положим: «скрипач» наскриптовывает одну медленную «функцию» за 1 «дедлайн», а «насильник» за то же время на си - 1 быструю. В базарный день, программы из 1 «горячей» и 1 «одноразовой» ф-ии идут быстрые по 100500 ватеверов, а медленные по 500, ибо никому не нужны, Очевидно, за 2 дедлайна первый заработает 500 а второй 100500, Однако, если они скооперируются, и первый напишет обе «одноразовые», а второй обе «горячие» ф-ии, они вместе заработают на 100000 больще, что почти невозможно поделить не обоюдовыгодно.
Думаю, можно подвигать цифры, и обнаружить, что выгода не положительна только при равных ценах(т.е. скорость никому не нужна).
Кстати, мне рассказали почти уважительную причину писать всё быстрым. Если твоя задача работает на 10000 компутерах, 1% производительности позволяет сэкономить на железе одну зарплату «оптимизатора». Не уверен, как это отражается на стоимости сопровождения и сроках, но это уже можно считать.
контексте гуи есть прикольный tcl
он прикольный не только в контексте гуи. IMO он провалился потому, что его писаки неправильно реализовали интерфейс и списков/словарей. '[lindex [expr a+b] $list]'(в деталях не уверен) никак не может соревноваться c 'list[a+b]'
Исходная версия DonkeyHot, :
питон такой же молоток
Однозначно. Но питонщики имеют шанс заметить, что что-то пошло не так - когда прога медленно работает, и проект ещё можно спасти.
В индустрии работает другой принцип: безобразно, зато однообразно
А должны были бы прибыль считать. Для демонстрации: положим: «скрипач» наскриптовывает одну медленную «функцию» за 1 «дедлайн, а „насильник“ за то же время на си - 1 быструю. В базарный день, программы из 1 „горячей“ и 1 „одноразовой“ ф-ии идут быстрые по 100500 ватеверов, а медленные по 500, ибо никому не нужны, Очевидно, за 2 дедлайна первый заработает 500 а второй 100500, Однако, если они скооперируются, и первый напишет обе „одноразовые“, а второй обе „горячие“ ф-ии, они вместе заработают на 100000 больще, что почти невозможно поделить не обоюдовыгодно.
Думаю, можно подвигать цифры, и обнаружить, что выгода не положительна только при равных ценах(т.е. скорость никому не нужна).
Кстати, мне рассказали почти уважительную причину писать всё быстрым. Если твоя задача работает на 10000 компутерах, 1% производительности позволяет сэкономить на железе одну зарплату „оптимизатора“. Не уверен, как это отражается на стоимости сопровождения и сроках, но это уже можно считать.
контексте гуи есть прикольный tcl
он прикольный не только в контексте гуи. IMO он провалился потому, что его писаки неправильно реализовали интерфейс и списков/словарей. '[lindex [expr a+b] $list]'(в деталях не уверен) никак не может соревноваться c 'list[a+b]'