+1

(Reply to this)

Это в общем-то близко к правде (если не доводить до абсурда). Хотя критичным является не столько "скорость написания", сколько обозримость и сопровождаемость кода.

Правда есть очень смешной факт - сопровождаемость кода напрямую коррелирует с скоростью выполнения: просто потому, что основные потери на скорости идут не от "неэффективности компилятора" (на которую любят напирать фанаты плюсов/с - точнее на "эффективность С/С++"), а от неудачной алгоритмики/чрезмерных пожираемых ресурсов: а это можно фиксить только в более или менее сопровождаемом коде.

(Reply to this) (Thread)

Ерундой является конкретно
a) противопоставление скорости выполнения скорости/удобству написания/поддержки.
б) Представления этой оппозиции в виде исторической последовательности.

А так, сопровождаемость - это вопрос утилитарный, он бывает и нужен, и важен, но не нужно делать из него культа. (а вот быстродействие - это вопрос не утилитарный, повышение быстродействия позволяет как-то решать новые задачи, которые раньше не решались никак).

(Reply to this) (Parent) (Thread)

>А так, сопровождаемость - это вопрос утилитарный, он бывает и нужен, и
>важен, но не нужно делать из него культа.

Сопровождаемость, поддержка, более точно, способность ПО к развитию, масштабированию, улучшению, - центральный вопрос современной индустрии.

(Reply to this) (Parent) (Thread)

Индустрия - это тоже есть вопрос сугубо утилитарный, и чем скорее ее утилизируют - тем лучше.

(Reply to this) (Parent)

Программа ставшая трудносопровождаемой, очень быстро станет катастрофически неэффективной. Просто потому что всегде есть вилка "качество программы/стоимость улучшения" и несопровождаемость сдвигает ее в сторону наплевания на качество.

Позволю предположить, что 90% линуксного софта жрет на пару-тройку порядков больше ресурсов, чем надо - в принципе все это знают и многие даже знаю как это исправить - но цена модификации кода слишком велика.

(Reply to this) (Parent) (Thread)

Это все экономические и организационные, а не технические вопросы. Важные, нужные - но важные и нужные именно как экономические и организационные, без перекладывания вины на вычислительную технику и научно-технический прогресс в целом.

(Reply to this) (Parent)

Известны ли Вам инструменты разработки программ, сочетающие высокую степень оптимизации кода со производительностью разработки? До сих пор считалось что на одном конце этой шкалы находится ассемблер, а на другом - интерпретируемые языки, но, возможно, передовое мировоззрение дает иное понимание проблемы? Если это так то Вас, надеюсь, не затруднит поделиться своими представлениями.

(Reply to this) (Thread)

Любые.

Навряд ли кто-то будет широко пользоватся инструментами, которые одновременно и слабо оптимизируют код и имеют низкую производительность разработки.

Наличный прогресс в computer science состоит в улучшении обоих параметров, а не в улучшении одного за счет ухудшения другого.

Для одной и той же программы компилятор Це 2008 года даст более эффективный код, чем компилятор Це 1988 года - Вы, надеюсь, не будете с этим спорить?

Интерпретатор Перла 2000 года более эффективно работает со строками, чем интерпретатор бейсика 198го.

И попытки ручного программирования на ассемблере на RISC-(не говоря уже о VLIW-)архитектурах показали крайне невысокую степень оптимизации получающегося кода.

(Reply to this) (Parent) (Thread)

Для одной и той же программы компилятор Це 2008 года даст более эффективный код, чем компилятор Це 1988 года /.../ Интерпретатор Перла 2000 года более эффективно работает со строками, чем интерпретатор бейсика 198го.
Верно, но программы, созданные на Перле и исполняемые интерпретатором Перла, по прежнему работают медленнее чем программы написанные на C. И разрыв этот, несмотря на некоторое уменьшение, по прежнему существенен и вряд ли будет полностью преодолен в обозримом. Навряд ли Вы будете утверждать что C является языком, всегда предпочтительным по сравнению с Перлом, поэтому приходится признать существование задач в которых скоростью исполнения программ жертвуют ради иных приоритетов.

(Reply to this) (Parent) (Thread)

А зачем сокращать разрыв? Это разные инструменты для решения разных задач. И были таковыми и 20 и 40 лет назад. Набор задач же за эти 40 лет если и изменились - то за счет появления совершенно новых областей,Э но никак не за счет замены одной категории другой.

Процент программистов в кодах сейчас относительно может и меньше - за счет как раз этих новых задач - но абсолютное их число больше чем когда-либо в истории.

(Reply to this) (Parent) (Thread)

А зачем сокращать разрыв? Это разные инструменты для решения разных задач.
Я бы хотел обратить Ваше внимание что это утверждение в точности равно утверждению "существуют задачи для которых скорость выполнения менее важна чем иные соображения". В свою очередь, существование таких задач означает что в некоторых случаях утверждение которое Вы взялись опровергать в исходном постинге, верно.

(Reply to this) (Parent)

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

(Reply to this) (Parent)

Вообще-то средний компилятор давно дает код эффективнее (по заданному параметру), чем средний программист на ассемблере.

Попробуйте, например, построить схемку Янова для оптимизации памяти в программе на ассемблере хотя бы из пары тысяч инструкций. А gcc это делает на раз.

(Reply to this) (Parent)

95% людей, говорящих о скорости, не понимают, что такое скорость, и не умеют ей управлять.

(Reply to this)

По моей практике, вовсе не ерунда. Время выполнения нашего кода в большинстве случаев на порядок меньше, чем время отрисовки в браузере, а на стороне сервера - чем время выполнения запросов СУБД. Конечно, и на эти длительности можно повлиять, но лишь до какой-то, обычно не слишком значительной степени.

Посему недавно начальство зарубило моё предложение перейти с голимого HTML'а на валидный XHTML и XUL. Тихой сапой я всё равно на них всё переведу, но распоряжение было - не тратить на это драгоценное время.

(Reply to this) (Thread)

Вот почему-то куча народу возражает вовсе не на те слова, что я сказал.

(Reply to this) (Parent)