"пофессионалы ушли, пришли менагеры." — Вот вот, а вернее им на смену пришли Индусы (смотрите презентацию Google OS ...)
Первая причина в том, что руководят проектами менеджеры которым подавай быструю прибыль, и если ПО уже запускается но еще не прошло тестирование, его сразу выкладывают на прилавки, мол на юзерах протестим, главное по быстрому срубить бабок пока конкуренты не выпустили чего по круче ...
Вторая, то что всякие новые технологии "быстрого" программирования пошли в массы и теперь каждый второй пятиклассник уже программер (кул хацкер).
Ну и третье, это конечно оптимизация и культура программирования. Никто более не думает об оптимизации, запускается проЖка у меня дома, значит у всех тоже должна работать ... Нет ни одной современной игры, которая идет без тормозов на заявленных для нее же минимальных системных требованиях.
Отличный коментарий. Ещё не забываем о производителях железа, которым, чтобы не загнуться, необходимо что-то постоянно выпускать, а вот здесь уже сговор с ведущими софтописателями (не будем оглашать их имена).
Дайте мне один ненужный. Давно хочу дома локалку соорудить по-больше чем из двух компов :))
Мысль в статье правильная высказана и это уже почти все понимают. Только отрасль не станет "пересматривать свое отношение к необходимости модернизации ПК в угоду надуманным принципам". Потому что пока можно рубить деньги с покупателей за "новые сверхмощные процессоры" это будет происходить и дальше.
Утяжеление программ и одновременное снижение их эффективности — основа повышения затрат на железо. Цены же на ПО остаются прежними или растут за счет добавления новых функций. Производители в выигрыше = изменений не будет.
у мня комп помощнее стоит чем целерон, но я люблю играть, а софт предпочитаю юзать старый, как например график вьювер Acdsee v2 и не про, а старый классик. Много софта портабл с урезанными, мне нафиг ненужными, функциями. ток полноценные стоят брауйзер и антивирь.
К сожалению разрозненность производителей свободных ОС, как основы свободного ПО, мешает этому.
Разнообразие дистрибутивов Linux часто объявляется как преимущество, в то время как для конечного массового пользователя это оказывается главным недостатком.
На старых машинах будут стоять старые версии тех же программ которые стоят на новых машинах. Отдельно их выделять не стоит. Конечно это опять же относится к массовой установке ПО.
качественное и свободное (то есть бесплатное) оч сложно сделать без каких либо целей. а просто так ни кто не будет писать, настраивать, вылизывать код для хорошего приложения, максимум смотрелка иль плеер
Сговор производителей hard и soft! Если при начале инсталляции MS Windows XP SP2 жмакать на F5, выскочит сообщение: "У вас что, i486 стоит?" Т.е. Винда XP SP2 может работать на 486-м процессоре!
Скорее даже не сговор, а интуитивное понимание того, что не нужно стараться сделать более легкую и быструю программу, если через пол года скорость работы железа итак позволит ее запускать.
Проследить можно на примере массового отказа от C++ позволяющего очень эффективно управлять памятью, требуя при этом гораздо большего внимания и времени на разработку и отладку.
Скорость разработки становится гораздо важнее, а проблемы скорости работы продукта перекладываются на железо.
Это вопрос математики, сколько стоит проезд по памяти если к объекту А вызывается (виртуальная) функция а, которая вызывает (виртуальную) функцию б объекта Б, которая удаляет объект А. Реально такие ошибки ищутся ГОДАМИ в C++ и являются дефектом архитектуры (проявление ошибки имеет вероятностный характер порядка 1-3% случаев но с core dump). В Java все работает, только есть проблемка с коммитед памятью так как выйти на уровень потребелния памяти как в C++ уже точно не получится.
Так что не только проблемы скорости но и проблемы стабильности.
Уточнение понятие "стоит" — имеется в виду в деньгах. Причем смотреть можно с двух сторон:
1. Стоимость толкового разработчика (в человеко-часах) C++ который не допустит этого ляпа, относительно Java разработчика-индийца которому такой ляп по барабану
2. Стоимость потерь компании в результате слета программы.
Рыночная экономика по определению должна производить мусор, иначе будет затоваривание. Всё нормально. Дело не в компьютерах и программах, проблема гораздо глубже и серьёзнее.
Комментарии
Первая причина в том, что руководят проектами менеджеры которым подавай быструю прибыль, и если ПО уже запускается но еще не прошло тестирование, его сразу выкладывают на прилавки, мол на юзерах протестим, главное по быстрому срубить бабок пока конкуренты не выпустили чего по круче ...
Вторая, то что всякие новые технологии "быстрого" программирования пошли в массы и теперь каждый второй пятиклассник уже программер (кул хацкер).
Ну и третье, это конечно оптимизация и культура программирования. Никто более не думает об оптимизации, запускается проЖка у меня дома, значит у всех тоже должна работать ... Нет ни одной современной игры, которая идет без тормозов на заявленных для нее же минимальных системных требованиях.
Мысль в статье правильная высказана и это уже почти все понимают. Только отрасль не станет "пересматривать свое отношение к необходимости модернизации ПК в угоду надуманным принципам". Потому что пока можно рубить деньги с покупателей за "новые сверхмощные процессоры" это будет происходить и дальше.
Утяжеление программ и одновременное снижение их эффективности — основа повышения затрат на железо. Цены же на ПО остаются прежними или растут за счет добавления новых функций. Производители в выигрыше = изменений не будет.
Разнообразие дистрибутивов Linux часто объявляется как преимущество, в то время как для конечного массового пользователя это оказывается главным недостатком.
На старых машинах будут стоять старые версии тех же программ которые стоят на новых машинах. Отдельно их выделять не стоит. Конечно это опять же относится к массовой установке ПО.
Проследить можно на примере массового отказа от C++ позволяющего очень эффективно управлять памятью, требуя при этом гораздо большего внимания и времени на разработку и отладку.
Скорость разработки становится гораздо важнее, а проблемы скорости работы продукта перекладываются на железо.
Так что не только проблемы скорости но и проблемы стабильности.
1. Стоимость толкового разработчика (в человеко-часах) C++ который не допустит этого ляпа, относительно Java разработчика-индийца которому такой ляп по барабану
2. Стоимость потерь компании в результате слета программы.