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

PD>>Если у нас жесткие технические ограничения по памяти и быстродействию машины , то вариант 3 просто не проходит.
PD>Они не смогут написать код, чтобы уложиться в эти 16 Мбайт. А больше взять неоткуда — машин с большей памятью просто нет.
S>Да всё есть. Просто нужно будет поставить не одну машину с 16 Мбайт, а четыре машины по 16 Мбайт каждая. Это даст разницу в полном Z для вариантов 1, 2, и 3.

С чего вдруг ? При их способе написания они просто в эти 16 Мбайт не уложатся. Хоть 4 машины поставь, хоть 16. Они могут написать более медленный код, и тогда да, добавлением машин можно проблему решить. Но если уж в ограничения по памяти не уложатся, то новые машины тут не помогут. Или разбить процесс на несколько машин и устроить их взаимодействие ? Ну тогда они в сроки не уложатся, да еще и вопрос, сумеют ли вообще сделать.


PD>>А вот если такие ограничения отсутствуют, то и команда-3 сделает продукт. Только памяти он займет в 10 раз больше, чем для команд 1-2, и работать будет в 10 раз медленнее, чем для них же.
S>Всё верно.

Отлично.

PD>>А все равно работает. Заказчик доволен. Он теперь вполне знает, сколько за подобный продукт можно просить. И главное, он теперь знает, какие требования к железу и ПО можно предъявлять. Памяти нужно M Гбайт. Раньше он не знал, а теперь знает. Вот же продукт, он требует M, значит, для задачи такого рода меньше быть не может. Быстродействие — аналогично.
S>С чего это "быть не может"? То, что заказчик — не инженер, не означает, что он идиот.
S>Из того, что есть программа с требованиями M означает ровно одно — в M можно уложиться. Теперь, когда у заказчика или его конкурента возникает аналогичная задача, инженеры не смогут сказать "нам нужно 2M" — заказчик показывает им готовое решение и говорит "ну ведь вот эти уложились в M, значит и вы уложитесь".

Он не идиот, он дилетант. Теперь он понял, что в М можно уложиться. А до этого не знал.
И понял лишь потому, что ему такие требования эта команда типа 3 выставила. С 4 машинами, как ты предлагаешь (допустим, что это все же удалось бы сделать). Он и теперь не знает, что можно было с одной машиной сделать, если бы делала команда 1

PD>>Дальнейшее.

PD>>Закончен проект и они разойдутся. Юниоры — в уверенности, что так код писать можно, и вообще качественный код — это код, который удовлетворяет заказчика. Других требований к нему не может быть.
S>Всё верно.
PD>>А сеньор, глядя на все это , и сам подумает : а не зря ли я писал качественно. Вот сделали проект черт те как, но все работает, заказчик доволен.
S>Всё верно.

Тоже хорошо.

PD>>Юниоры через некоторое время станут сеньорами, вполне уверенными, что сорить памятью и применять неэффективные алгоритмы — это норма.
S>Конечно.

Хорошо.

PD>>И когда через некоторое время заказчик попросит сделать новую работу стоимостью в 200, поручат ее бывшей команде 3. А они потребуют 500, так как с их пониманием что требуется для чего, надо памяти раз в 5 больше или процессор в 5 раз быстрее. На 300 сойдутся, и сделают, с тем же качеством.
S>А куда делись команды 1 и 2?

Ну вообще-то я рассматривал варианты. Если делала команда 1 или 2, то по окончании проекта команда разошлась. Может, они соберутся в другом проекте по типу команды 1 или 2, тогда все опять будет хорошо. А может, их раскидают на 4 команды типа 3 — тогда см. выше.

>Заказчик прекрасно понимает, что монополизация рынка — это плохо, и при прочих равных всё равно запросит коммерческие предложения от всех трёх команд.
S>И если окажется, что в новом проекте команды предлагают разные результаты, то выиграет более профессиональная команда. Так работает рынок.

Заказчик, если ему первый проект делала команда 3, уже уверен, что именно такие ресурсы нужны. И выставит такие же требования на новый проект, умножив на 2, так как новый проект сложнее. И скорее всего обратится в туже фирму, они же все сделали, можно им и опять поручить. Ну а если он все же решится устроить конкурс, то для начала выставит те же требования, что и в прошлом проекте * 2. Что при этом скажет потенциальная команда типа 1 — не знаю. Может, и ответит, что 8 машин тут не надо и 200 единиц стоимости тоже, а хватит и 1 машины и 100. Может, и нет. Зачем себе проблемы создавать, да и лишние 100 единиц не помешают. И сделать можно в стиле команды 3, раз уж такие ресурсы предлагают.

PD>>Вот поэтому мы и имеем, что имеем.
S>Нет, мы имеем то, что имеем, ровно по одной причине — железо стало дешёвым. В реальности окажется так, что команд типа 1 — раз-два и обчёлся. Они готовы взяться за проект, и сделать его быстро и качественно. Но — не сейчас. Сейчас они уже заняты. Приходите к нам через пару лет — и мы вам всё сделаем. Особенно если вы прямо сейчас внесёте предоплату. А если хотите прямо сейчас — то платить сеньорам надо будет не по 20, а по 40. Они же в дефиците, значит разрыв в зарплате между сеньорами и юниорами будет гораздо более значительным. Открытый рынок балансируется ровно так, чтобы экономия на аппаратуре компенсировалась ростом затрат на фонд оплаты труда.

Вполне могу согласиться. Но почему они в дефиците ? А именно потому, что команды типа 3 смогут сделать при этом железе, а в результате это станет нормой, и команды типа 1-2 будет просто не из кого собрать.

S>Мы с вами можем сколько угодно ныть о том, что современная разработка деградировала. Я сам это прекрасно вижу — взять любую "контрольную панель", поставляемую вместе с железками. Что видеокарты, что принтеры — оно же всё ужасное. Гигабайт кода, который помимо умения "переключиться со встроенного видеопроцессора на дискретный" показывает сотни анимированных диалогов, глючит, падает, и тащит с собой две версии питона, джава-машину, и node.js.

Именно. Голландская болезнь.

S>Да, печальное, унылое зрелище. Но — то, что оно такое, означает, что большинство участников рынка это устраивает. Переход к оптимальному и устойчивому софту не даёт зримого конкурентного преимущества, увы.

Согласен. Вполне согласен. Это и есть деградация отрасли. Потеря качества исполнения

S>Помимо этого, есть эффект ограниченной информации. Идеальный баланс работает только в идеализированной модели "полной и достоверной информации", которая в жизни не встречается. Заказчик скорее отдаст заказ команде, с которой есть предыдущий успешный опыт — потому что альтернативные команды обещать-то могут всё, что угодно — в том числе и M/2 памяти и T/3 сроков. А потом окажется, что "не получилось" ни M ни T.
S>Или заказчик был бы готов заказать команде, которая предложит M/2 памяти и T/3 сроков, но он просто не нашёл такую команду. Не успел / не смог / не знал, что такая команда вообще есть.


См. выше.


S>Вот с этими аспектами и стоит бороться — распространять информацию о том, как писать эффективный код. Писать и пропагандировать фреймворки, которые позволяют писать оптимальный код даже нубам, которые сами не очень понимают, как там оно устроено под капотом, и всё ещё с гарантиями корректности получающегося кода.

Глас вопиющего в пустыне. Я еще 20 лет назад тут писал про эффективность, ну и что ? С тех пор только хуже стало.
Нет, не тогда это закончится. Закончится тогда, когда ВТ выйдет на плато. Когда характеристики перестанут расти вообще. Вот тогда понадобятся опять те, кто умеет писать эффективный код. Если они к тому времени останутся.
И то нет уверенности. Просто тогда вместо 1 машины эта команда типа 3 создаст такой кластер, что не дай бог. И будут все уверены, что только так и можно. А стоимость оборудования расти вряд ли будет, она только падает.


S>Потому что, как ни удивительно, требования производительности идут после требований корректности. Никому не нужна программа, которая тратит M/10 памяти, но в половине случаев даёт неверный результат, или падает.

Ну это особый разговор. Я же написал — все 3 команды могут сделать вполне корректно работающее ПО. Если это не выполняется, то говорить не о чем.

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

PD>>Если у нас жесткие технические ограничения по памяти и быстродействию машины , то вариант 3 просто не проходит.
PD>Они не смогут написать код, чтобы уложиться в эти 16 Мбайт. А больше взять неоткуда — машин с большей памятью просто нет.
S>Да всё есть. Просто нужно будет поставить не одну машину с 16 Мбайт, а четыре машины по 16 Мбайт каждая. Это даст разницу в полном Z для вариантов 1, 2, и 3.

С чего вдруг ? При их способе написания они просто в эти 16 Мбайт не уложатся. Хоть 4 машины поставь, хоть 16. Они могут написать более медленный код, и тогда да, добавлением машин можно проблему решить. Но если уж в ограничения по памяти не уложатся, то новые машины тут не помогут. Или разбить процесс на несколько машин и устроить их взаимодействие ? Ну тогда они в сроки не уложатся, да еще и вопрос, сумеют ли вообще сделать.


PD>>А вот если такие ограничения отсутствуют, то и команда-3 сделает продукт. Только памяти он займет в 10 раз больше, чем для команд 1-2, и работать будет в 10 раз медленнее, чем для них же.
S>Всё верно.

Отлично.

PD>>А все равно работает. Заказчик доволен. Он теперь вполне знает, сколько за подобный продукт можно просить. И главное, он теперь знает, какие требования к железу и ПО можно предъявлять. Памяти нужно M Гбайт. Раньше он не знал, а теперь знает. Вот же продукт, он требует M, значит, для задачи такого рода меньше быть не может. Быстродействие — аналогично.
S>С чего это "быть не может"? То, что заказчик — не инженер, не означает, что он идиот.
S>Из того, что есть программа с требованиями M означает ровно одно — в M можно уложиться. Теперь, когда у заказчика или его конкурента возникает аналогичная задача, инженеры не смогут сказать "нам нужно 2M" — заказчик показывает им готовое решение и говорит "ну ведь вот эти уложились в M, значит и вы уложитесь".

Он не идиот, он дилетант. Теперь он понял, что в М можно уложиться. А до этого не знал.
И понял лишь потому, что ему такие требования эта команда типа 3 выставила. С 4 машинами, как ты предлагаешь (допустим, что это все же удалось бы сделать). Он и теперь не знает, что можно было с одной машиной сделать, если бы делала команда 1

PD>>Дальнейшее.

PD>>Закончен проект и они разойдутся. Юниоры — в уверенности, что так код писать можно, и вообще качественный код — это код, который удовлетворяет заказчика. Других требований к нему не может быть.
S>Всё верно.
PD>>А сеньор, глядя на все это , и сам подумает : а не зря ли я писал качественно. Вот сделали проект черт те как, но все работает, заказчик доволен.
S>Всё верно.

Тоже хорошо.

PD>>Юниоры через некоторое время станут сеньорами, вполне уверенными, что сорить памятью и применять неэффективные алгоритмы — это норма.
S>Конечно.

Хорошо.

PD>>И когда через некоторое время заказчик попросит сделать новую работу стоимостью в 200, поручат ее бывшей команде 3. А они потребуют 500, так как с их пониманием что требуется для чего, надо памяти раз в 5 больше или процессор в 5 раз быстрее. На 300 сойдутся, и сделают, с тем же качеством.
S>А куда делись команды 1 и 2?

Ну вообще-то я рассматривал варианты. Если делала команда 1 или 2, то по окончании проекта команда разошлась. Может, они соберутся в другом проекте по типу команды 1 или 2, тогда все опять будет хорошо. А может, их раскидают на 4 команды типа 3 — тогда см. выше.

>Заказчик прекрасно понимает, что монополизация рынка — это плохо, и при прочих равных всё равно запросит коммерческие предложения от всех трёх команд.
S>И если окажется, что в новом проекте команды предлагают разные результаты, то выиграет более профессиональная команда. Так работает рынок.

Заказчик, если ему первый проект делала команда 3, уже уверен, что именно такие ресурсы нужны. И выставит такие же требования на новый проект, умножив на 2, так как новый проект сложнее. И скорее всего обратится в ту же фирму, они же все сделали, можно им и опять поручить. Ну а если он все же решится устроить конкурс, то для начала выставит те же требования, что и в прошлом проекте * 2. Что при этом скажет потенциальная команда типа 1 — не знаю. Может, и ответит, что 8 машин тут не надо и 200 единиц стоимости тоже, а хватит и 1 машины и 100. Может, и нет. Зачем себе проблемы создавать, да и лишние 100 единиц не помешают. И сделать можно в стиле команды 3, раз уж такие ресурсы предлагают.

PD>>Вот поэтому мы и имеем, что имеем.
S>Нет, мы имеем то, что имеем, ровно по одной причине — железо стало дешёвым. В реальности окажется так, что команд типа 1 — раз-два и обчёлся. Они готовы взяться за проект, и сделать его быстро и качественно. Но — не сейчас. Сейчас они уже заняты. Приходите к нам через пару лет — и мы вам всё сделаем. Особенно если вы прямо сейчас внесёте предоплату. А если хотите прямо сейчас — то платить сеньорам надо будет не по 20, а по 40. Они же в дефиците, значит разрыв в зарплате между сеньорами и юниорами будет гораздо более значительным. Открытый рынок балансируется ровно так, чтобы экономия на аппаратуре компенсировалась ростом затрат на фонд оплаты труда.

Вполне могу согласиться. Но почему они в дефиците ? А именно потому, что команды типа 3 смогут сделать при этом железе, а в результате это станет нормой, и команды типа 1-2 будет просто не из кого собрать.

S>Мы с вами можем сколько угодно ныть о том, что современная разработка деградировала. Я сам это прекрасно вижу — взять любую "контрольную панель", поставляемую вместе с железками. Что видеокарты, что принтеры — оно же всё ужасное. Гигабайт кода, который помимо умения "переключиться со встроенного видеопроцессора на дискретный" показывает сотни анимированных диалогов, глючит, падает, и тащит с собой две версии питона, джава-машину, и node.js.

Именно. Голландская болезнь.

S>Да, печальное, унылое зрелище. Но — то, что оно такое, означает, что большинство участников рынка это устраивает. Переход к оптимальному и устойчивому софту не даёт зримого конкурентного преимущества, увы.

Согласен. Вполне согласен. Это и есть деградация отрасли. Потеря качества исполнения

S>Помимо этого, есть эффект ограниченной информации. Идеальный баланс работает только в идеализированной модели "полной и достоверной информации", которая в жизни не встречается. Заказчик скорее отдаст заказ команде, с которой есть предыдущий успешный опыт — потому что альтернативные команды обещать-то могут всё, что угодно — в том числе и M/2 памяти и T/3 сроков. А потом окажется, что "не получилось" ни M ни T.
S>Или заказчик был бы готов заказать команде, которая предложит M/2 памяти и T/3 сроков, но он просто не нашёл такую команду. Не успел / не смог / не знал, что такая команда вообще есть.


См. выше.


S>Вот с этими аспектами и стоит бороться — распространять информацию о том, как писать эффективный код. Писать и пропагандировать фреймворки, которые позволяют писать оптимальный код даже нубам, которые сами не очень понимают, как там оно устроено под капотом, и всё ещё с гарантиями корректности получающегося кода.

Глас вопиющего в пустыне. Я еще 20 лет назад тут писал про эффективность, ну и что ? С тех пор только хуже стало.
Нет, не тогда это закончится. Закончится тогда, когда ВТ выйдет на плато. Когда характеристики перестанут расти вообще. Вот тогда понадобятся опять те, кто умеет писать эффективный код. Если они к тому времени останутся.
И то нет уверенности. Просто тогда вместо 1 машины эта команда типа 3 создаст такой кластер, что не дай бог. И будут все уверены, что только так и можно. А стоимость оборудования расти вряд ли будет, она только падает.


S>Потому что, как ни удивительно, требования производительности идут после требований корректности. Никому не нужна программа, которая тратит M/10 памяти, но в половине случаев даёт неверный результат, или падает.

Ну это особый разговор. Я же написал — все 3 команды могут сделать вполне корректно работающее ПО. Если это не выполняется, то говорить не о чем.