-
17 мар 10"пофессионалы ушли, пришли менагеры." — Вот вот, а вернее им на смену пришли Индусы (смотрите презентацию Google OS ...)
Первая причина в том, что руководят проектами менеджеры которым подавай быструю прибыль, и если ПО уже запускается но еще не прошло тестирование, его сразу выкладывают на прилавки, мол на юзерах протестим, главное по быстрому срубить бабок пока конкуренты не выпустили чего по круче ...
Вторая, то что всякие новые технологии "быстрого" программирования пошли в массы и теперь каждый второй пятиклассник уже программер (кул хацкер).
Ну и третье, это конечно оптимизация и культура программирования. Никто более не думает об оптимизации, запускается проЖка у меня дома, значит у всех тоже должна работать ... Нет ни одной современной игры, которая идет без тормозов на заявленных для нее же минимальных системных требованиях. -
17 мар 10Дайте мне один ненужный. Давно хочу дома локалку соорудить по-больше чем из двух компов :))
Мысль в статье правильная высказана и это уже почти все понимают. Только отрасль не станет "пересматривать свое отношение к необходимости модернизации ПК в угоду надуманным принципам". Потому что пока можно рубить деньги с покупателей за "новые сверхмощные процессоры" это будет происходить и дальше.
Утяжеление программ и одновременное снижение их эффективности — основа повышения затрат на железо. Цены же на ПО остаются прежними или растут за счет добавления новых функций. Производители в выигрыше = изменений не будет. -
-
-
17 мар 10К сожалению разрозненность производителей свободных ОС, как основы свободного ПО, мешает этому.
Разнообразие дистрибутивов Linux часто объявляется как преимущество, в то время как для конечного массового пользователя это оказывается главным недостатком.
На старых машинах будут стоять старые версии тех же программ которые стоят на новых машинах. Отдельно их выделять не стоит. Конечно это опять же относится к массовой установке ПО.
-
-
-
17 мар 10Скорее даже не сговор, а интуитивное понимание того, что не нужно стараться сделать более легкую и быструю программу, если через пол года скорость работы железа итак позволит ее запускать.
Проследить можно на примере массового отказа от C++ позволяющего очень эффективно управлять памятью, требуя при этом гораздо большего внимания и времени на разработку и отладку.
Скорость разработки становится гораздо важнее, а проблемы скорости работы продукта перекладываются на железо.-
17 мар 10Это вопрос математики, сколько стоит проезд по памяти если к объекту А вызывается (виртуальная) функция а, которая вызывает (виртуальную) функцию б объекта Б, которая удаляет объект А. Реально такие ошибки ищутся ГОДАМИ в C++ и являются дефектом архитектуры (проявление ошибки имеет вероятностный характер порядка 1-3% случаев но с core dump). В Java все работает, только есть проблемка с коммитед памятью так как выйти на уровень потребелния памяти как в C++ уже точно не получится.
Так что не только проблемы скорости но и проблемы стабильности.-
17 мар 10Уточнение понятие "стоит" — имеется в виду в деньгах. Причем смотреть можно с двух сторон:
1. Стоимость толкового разработчика (в человеко-часах) C++ который не допустит этого ляпа, относительно Java разработчика-индийца которому такой ляп по барабану
2. Стоимость потерь компании в результате слета программы.
-
-
-
-
Сделано с
NoNaMe