LINUX.ORG.RU
ФорумTalks

В догонку к флейму про память.


0

0

По мотивам <a href="http://www.linux.org.ru/jump-message.jsp?msgid=2158109 ">Что каждый программист должен знать о памяти</a>

ЛОР традиционно разделился на два полярных мнения. Часть лоровцев остаивала

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

некоторые же придерживались прямо противоположных взглядов:

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

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

Итак, основная ошибка обоих сторон заключаются в том, что они рассматривают программу и эвм как две отдельные сущности, а это не верно. Сторонники оптимизации смотрят на проблему со стороны железа, ингорируя проблемы написания и сопровождения оптимизированных программ, тогда как противники стремятся максимально облегчить написание программ и им безразличны проблемы железа, пытающегося выполнить этот код за мало-мальски приемлимое время. Более правильный подход заключается в том, чтобы рассматривать программу и эвм как единую аппаратно-програмную сущность. (При этом не важно, что железо и софт поставляют разные дистрибьютеры). Проблему оптимизации следуюет рассматривать не в техническом, а в экономическом аспекте. С одной стороны нужно минимизировать затраты на написание програмной части. И тут на сцену выходит вижуал бэйсик, жаба, до-диез и другие флагманы ИНДУСтрии. С другой стороны также требуется минимизировать аппаратную часть ибо коммунизма до сих пор так и не построили (хотя пора бы уже по моему) и железо стоит денег. Таким образом мы имеем следующие зависимости:

* чем программы лучше тем она дороже, т.к. её написание требует большего времени, лучших программистов и большего их количества;

* чем программа лучше, тем меньше требование к аппаратной части;

* чем эвм дороже, тем она быстрее.

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

Проиллистрируем эти соображения простым примером. В коментариях к статье противникам оптимизации указывали на чрежмерную прожорливасть мозиллы как на результат, к которому приводит небрежное программирование. Рассмотрим гипотетическую ситуацию, пусть разработкой браузера займутся высококласные специалисты. Однако спецов мало, на всех не хватает и чтобы заманить их в свой проект mozilla foundation придётся как-то их промотивировать. Скорее всего деньгами. И браузер станет платным. Допустим оные профи смогут добиться снижения ресурсопотребления до уровня lynx при сохранения функционала мозиллы. Но браузер станет стоить штукубаксов. Пользователи встанут перед выбором: либо купить этот браузер, либо на эти же деньги купить новое железо, на котором и старый мозилла тормозить не будет. Думаю ясно что выберет конечный потребитель. Таким образом тормозное убожество оказывается лучше, чем действиельно качественная программа.

Вывод: программописательская отрасль не является вещью в себе, но подчиняется законам экономики точно так же как и все остальные отрасли промышленности. Текущее положение в it сфере обусловленно рядом социально-экономическим причин и оно принципиально несводимо к противостоянию пионер---быдлокодер. Уяснив это дискуссию о вреде и пользе оптимизации можно считать закрытой.

★★★★★

>Уяснив это дискуссию о вреде и пользе оптимизации можно считать закрытой.

А я вот недавно стихи о любви написал. Закрыл тему.

anonymfus ★★★★
()
Ответ на: комментарий от anonymfus

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

ugoday ★★★★★
() автор топика

>Уяснив это дискуссию о вреде и пользе оптимизации можно считать закрытой.

Пришел лесник и выгнал всех из леса.

anonymous
()

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

Сравним, например, компиз и аэро. Компиз легче, быстрее, но при этом фичастее - следствие отсуствия дедлайнов и расчета экономической выгоды.

blaster999 ★★
()

Опять обкурился. Второе высшее получаешь чтоль экономическое и к хорошим мастерам промывки мозгов попал, ага?

Gharik
()

>спецов мало, на всех не хватает и чтобы заманить их в свой проект mozilla foundation придётся как-то их промотивировать. Скорее всего деньгами.

до этого места всё нормально.

>И браузер станет платным

а вот тут угодай начал гнать,


типа хинт: MoFo уже давно не Fo, а очень даже Co и б. у этой Co нынче есть.

Muromec ☆☆
()

Первый раз, наверное, не смог дочитать пост до конца. Ужас, это ж какое-то просто занудство. :-)

smh ★★★
()

Вы, кажется, считаете, что, кроме производительности, нет других критериев оценки качества ПО. Примем это, так как независимая оценка параметров имеет смысл. Т. о., в следующих утверждениях "лучше" — это быстрее. Также согласимся для простоты, что оплата труда программистов соответствует эффективности их деятельности.

>чем программа лучше тем она дороже, т.к. её написание требует большего времени, лучших программистов и большего их количества;

Не верно, так как результаты труда программистов зависят не только от их усилий, но и от поставленных целей и, главное, от предыдущего состояния проекта. То есть, какие бы хорошие программисты не работали бы на FF и Mozilla, при условии развития существующей кодовой базы, сохранения совместимости с существующей моделью расширений, сохранения в движке костылей для поддержки отображения неправильных страниц, они не смогли бы добиться значимо лучших результатов, чем сейчас.

>чем программа лучше, тем меньше требование к аппаратной части;

Не верно, так как, например, многопоточные алгоритмы быстрее работают в многоядерных/многопроцессорных системах; 64-х битный код в задачах с большими целыми числами (шифрование, например) вполне может дать и 400%-ное ускорение по сравнению с 32-х битным, ну и т. д..

>чем эвм дороже, тем она быстрее

Хотя это и не так, связь есть.

>а стоимость аппаратной части --- монотонной возрастающей кривой (чем программа хуже, тем эвм нужна лучше)

Бессмысленное утверждение в рамках вашей модели. Разобраться, почему — Ваше домашнее задание. Кстати, это главная ошибка в ваших рассуждениях.

>Где-то эти две кривые пересекутся и именно там будет находиться минимум себестоимости.

Минимум себестоимости — это минимум себестоимости, когда производительность программы минимальна, производительность железа минимальна. Без поставленной извне цели оптимум не найти. Его можно определить при фиксированной производительности, например.

>Рассмотрим гипотетическую ситуацию, пусть разработкой браузера займутся высококласные специалисты. Однако спецов мало, на всех не хватает и чтобы заманить их в свой проект mozilla foundation придётся как-то их промотивировать. Скорее всего деньгами. И браузер станет платным. Допустим оные профи смогут добиться снижения ресурсопотребления до уровня lynx при сохранения функционала мозиллы. Но браузер станет стоить штукубаксов. Пользователи встанут перед выбором: либо купить этот браузер, либо на эти же деньги купить новое железо, на котором и старый мозилла тормозить не будет. Думаю ясно что выберет конечный потребитель.

НЕЛЬЗЯ с помощью хоть каких специалистов довести FF до вменяемого состояния (см. выше). Можно написать новый браузер. Деньги можно тянуть не с конечных пользователей, а только с корпораций (как это и происходит сейчас), ведь при наличии бесплатной альтернативы сейчас никто не заплатит и доллара за платный браузер (вспомните, как Опера постепенно стала бесплатной).

В мире Open Source даже очень плохие проекты не умирают до конца (сколько некрофилии проскакивает порой в новостях?). Поэтому на "старый" FF не перестанут тратиться ресурсы сообщества, даже если браузер перепишут заново.

Браузеров, несколько более производительных, чем FF, полно. Это Опера, Конкверрор, Сафари, и, на некоторых тестах, даже IE7 (!!!). Однако они все либо закрытые, либо не кросс-платформенные. Поэтому выбор сообщества очевиден: FF. Проблемма в том, что, когда Конкверрор станет кросплатформенным, толпа фанатиков от FF всё равно не отстанет...

>Вывод: программописательская отрасль не является вещью в себе, но подчиняется законам экономики точно так же как и все остальные отрасли промышленности. Текущее положение в it сфере обусловленно рядом социально-экономическим причин и оно принципиально несводимо к противостоянию пионер---быдлокодер.

Тривиально.

>Уяснив это дискуссию о вреде и пользе оптимизации можно считать закрытой.

Нельзя, так как участникам дискуссии по прежнему не ясно, какие результаты их удовлетворят.

anonymfus ★★★★
()

Стеб, типа? Тогда три раза "Ха!" :-)

Особенно понравилась логика этих двух тезисов:

> ...основная ошибка обоих сторон заключаются в том, что они рассматривают программу и эвм как две отдельные сущности, а это не верно. Сторонники оптимизации смотрят на проблему со стороны железа, ингорируя проблемы написания и сопровождения оптимизированных программ, тогда как противники стремятся максимально облегчить написание программ и им безразличны проблемы железа...

> ...спецов мало, на всех не хватает и чтобы заманить их в свой проект mozilla foundation придётся как-то их промотивировать. Скорее всего деньгами. И браузер станет платным. Допустим оные профи смогут добиться снижения ресурсопотребления до уровня lynx при сохранения функционала мозиллы. Но браузер станет стоить штукубаксов....

Прямо средоточие современной маркетоидной диалектики!

Забавно, что большинство нынешних студентов-информатиков на старших курсах именно так и думают -- их этому теперь в школе учат...

Die-Hard ★★★★★
()

> * чем программы лучше тем она дороже, т.к. её написание требует большего времени, лучших программистов и большего их количества;

ack

> * чем программа лучше, тем меньше требование к аппаратной части;

ack

> * чем эвм дороже, тем она быстрее.

не факт - вы забыли про брендовое железо, где накрутка может быть и 100% по сравнению с аналогичным по пр-ти железом noname из соседнего супермаркета.

// wbr

klalafuda ★☆☆
()

> Вывод: программописательская отрасль не является вещью в себе, но подчиняется законам экономики точно так же как и все остальные отрасли промышленности. Текущее положение в it сфере обусловленно рядом социально-экономическим причин и оно принципиально несводимо к противостоянию пионер---быдлокодер. Уяснив это дискуссию о вреде и пользе оптимизации можно считать закрытой.

понимаете, чтобы осознать этот вывод нужно хотя бы минимальное количество времени реально проработать в этой индус-трии, иметь за плечами личный разносторонний опыт для сравнения etc. чего многим спорщикам на LORе по понятным причинам сильно не хватает :) так что все закономерно.

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от anonymfus

> Браузеров, несколько более производительных, чем FF, полно. Это Опера, Конкверрор, Сафари, и, на некоторых тестах, даже IE7 (!!!). Однако они все либо закрытые, либо не кросс-платформенные. Поэтому выбор сообщества очевиден: FF. Проблемма в том, что, когда Конкверрор станет кросплатформенным, толпа фанатиков от FF всё равно не отстанет...

kq быстрее ff? спасибо, развеселили :)))

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от Die-Hard

> Прямо средоточие современной маркетоидной диалектики! Забавно, что большинство нынешних студентов-информатиков на старших курсах именно так и думают -- их этому теперь в школе учат...

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

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от Gharik

> Опять обкурился. Второе высшее получаешь чтоль экономическое и к хорошим мастерам промывки мозгов попал, ага?

или мне изменяет память, или я ни разу не видел ваши комментарии в Development. впрочем, надо полагать, у вас накопился богатый личный опыт разработки программного обеспечения что вы с уверенностью высказываете столь категоричные суждения касательно методологии разработки ПО. IMHO грех скрывать такие богатства от народа. заглядывайте почаще в наш уголок, не стесняйтесь. ждем'с.

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от blaster999

> Не стоит забывать о джастфофане.

Согласен. Я писал только о рыночной составляющией программирования, в которой под эффективностью понимается максимизация прибыли предприятия. Если программирование --- хобби, то критерием эффективности является максимизация удовольствия, получаемого от процесса написания программы и здесь действуют внерыночные закономерности.

> проекты получают патчи, оптимизирующие расход ресурсов, от совершенно посторонних людей.

У меня сложилось впечатление, что большинству людей гораздо интереснее реализовывать новые возможности программа, а не воевать с железом, хотя конечно существуют и люди, получающие удовольствие от написания быстрых и лёгких программ. Но их мало.

> Еще, если программу не собираются продавать, то разработчики сделают большую ставку на стабильность и оптимизацию,

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

ugoday ★★★★★
() автор топика
Ответ на: комментарий от Muromec

> типа хинт: MoFo уже давно не Fo, а очень даже Co и б. у этой Co нынче есть.

Замечание тебе и многим другим лоровцам: такое ощущение, что вы не привыкли мыслить абстрактно. Пример с мозиллой это не более чем наглядная иллюстрация. Особенности жизни конкретно этого проекта мне не интересны. Более того, это сильно упрощённый пример, в реальности будет не одна программа в старой и новой ипостаси, а некоторый набор программ, для которых будут разные альтернативы. Например в качестве офисного пакета можно использовать ОО.о, а можно и МСО. Последний дороже, функциональнее и меньше любит ховать оперативы. Если таких альтернатив набирается много, а скорее всего это так, дешевле купить более мощный комп. И всё.

ugoday ★★★★★
() автор топика
Ответ на: комментарий от smh

> Первый раз, наверное, не смог дочитать пост до конца.

Тренируй усидчивость, читай умные книжки. Капитал, например.

> просто занудство.

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

ugoday ★★★★★
() автор топика
Ответ на: комментарий от anonymfus

> кроме производительности, нет других критериев оценки качества ПО.

Ну почему же, такие критерии есть, но в данном случае я создаю модель, тоесть некоторое ограниченное, упрощённое представление о реальности. В целом такой подход эффективен.

> Не верно, так как результаты труда программистов зависят не только от их усилий, но и от поставленных целей и, главное, от предыдущего состояния проекта.

Ты прав, но это не отменяет моих рассуждений. Я говорю не о функциональных, а о статистических зависимостях. Вероятность написания хорошей программы хорошими программистами хорошей программы выше, чем плохими. Хотя конечно есть и исключения, когда профи создают худший продукт по тем или иным причинам.

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

> Без поставленной извне цели оптимум не найти.

минимум функции есть вещь объективная и в каких-либо внешних целях не нуждающаяся.

ugoday ★★★★★
() автор топика
Ответ на: комментарий от Die-Hard

> Прямо средоточие современной маркетоидной диалектики!

Дяденька, а раскажите как всё происходит на самом деле.

ugoday ★★★★★
() автор топика
Ответ на: комментарий от klalafuda

> не факт - вы забыли про брендовое железо,

Я этим смело пренебрегаю. Как правило когда говорят об оптимизации речь идёт о таком большом снижении требовании к эвм, что дисперсия цен на дешёвое/дорогое железо будет много больше чем дисперсия цен на одно железо от разных поставщиков. Дико извиняюсь за привлечение аппарата мат. статистики ибо им не все владеют, но без него придётся сильно много писать и формулировки получаются очень кривые.

ugoday ★★★★★
() автор топика
Ответ на: комментарий от ugoday

> Вероятность написания хорошей программы хорошими программистами хорошей программы

Блин, когда же на лоре будет редактирование сообщений!

ugoday ★★★★★
() автор топика

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

asgard
()

Всё-таки экономическая эффективность это не главный критерий. Критерий - это способность программы решать задачу при некотором количестве имеющихся ресурсов. Если браузер (программа массового использования) минуту (очень большое время отзыва) рендерит страницу (решает свою основную задачу) на массово распостранённом железе (так как программа массовая) - это плохой браузер.

А вот если это корпоративное приложение на J2EE, и пишется оно быстро, но работает на имеющемся железе неторопливо - тут действительно можно строить кривые и анализировать графики. Только встаёт вопрос о том, что для предприятия предпочтительнее - поменять специалиста на более "эффективного", принять на работу двух новых специалистов, или купить новое железо под одну задачу.

Xellos ★★★★★
()
Ответ на: комментарий от ugoday

>минимум функции есть вещь объективная и в каких-либо внешних целях не нуждающаяся

Не совсем так. Минимум немонотонной (а она не монотонная) функции многих переменных сильно зависит от граничных условий.

Xellos ★★★★★
()
Ответ на: комментарий от klalafuda

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

По этому надо определиться для начала расход конкретно каких ресурсов волнует общественность. Или чем лучше программа, тем она ближе глобального экстремума многомерной функции расхода ресурсов?

Время программистов тоже ресурс. Кому нужна идеальная программа, которая будет выпущена через 3 года после того как рынок уже устаканиться?

anonymousI
()
Ответ на: комментарий от Xellos

> Критерий - это способность программы решать задачу

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

> Если браузер ... минуту ... рендерит страницу ... на массово распостранённом железе ... - это плохой браузер.

браузер плохой в техническом смысле, да. Но при этом он может быть хорошим в смысле экономическом. Здесь нет противоречия.

Кроме того можно латентност системы внести в техзадание.

ugoday ★★★★★
() автор топика
Ответ на: комментарий от Xellos

Зависит от степени упрощённости модели. Если всё свести к двум переменным стоимость-быстродействие, то получится один объективный минимум.

ugoday ★★★★★
() автор топика
Ответ на: комментарий от ugoday

А если всё свести к одной переменной? Например, к времени разработки? Или к порогу вхождения (превед, M$)?

Xellos ★★★★★
()
Ответ на: комментарий от ugoday

>браузер плохой в техническом смысле, да. Но при этом он может быть хорошим в смысле экономическом.

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

Xellos ★★★★★
()
Ответ на: комментарий от Die-Hard

> Прямо средоточие современной маркетоидной диалектики!

> Забавно, что большинство нынешних студентов-информатиков на старших курсах именно так и думают -- их этому теперь в школе учат...

Интересно было бы послушать Вашу альтернативную трактовку

annoynimous ★★★★★
()
Ответ на: комментарий от ugoday

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

+100 :)))

annoynimous ★★★★★
()
Ответ на: комментарий от Xellos

> к времени разработки?

Получим аналогичную картину. Либо быстро, но на жабе (превед новый комп, где оно сможет работать), либо на цэ с хардкорной оптимизацией, но на рынок оно выйдет на 5 лет позже.

> к порогу вхождения

Не понял, к порогу вхождения в ЯП или в программу, напсанную на этом ЯП?

ugoday ★★★★★
() автор топика
Ответ на: комментарий от Xellos

> Плохой он в экономическом смысле,

Если для этого же железа существует браузер который стоит дешевле, а работает лучше, то твой вывод верен, иначе нет.

ugoday ★★★★★
() автор топика
Ответ на: комментарий от ugoday

>Замечание тебе и многим другим лоровцам: такое ощущение, что вы не привыкли мыслить абстрактно. Пример с мозиллой это не более чем наглядная иллюстрация

ну я и говорю. теория более-менее, а с примером дико прогнал.

Muromec ☆☆
()
Ответ на: комментарий от ugoday

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

А это, стало быть, классическое оправдание зануды :-))

smh ★★★
()
Ответ на: комментарий от ugoday

Ну если начать говорить о монополизации, о ГМК, об олигархическом капитализме - мы далеко уйдём от темы.

Xellos ★★★★★
()
Ответ на: комментарий от klalafuda

> или мне изменяет память, или я ни разу не видел ваши комментарии в Development. впрочем, надо полагать, у вас накопился богатый личный опыт разработки программного обеспечения что вы с уверенностью высказываете столь категоричные суждения касательно методологии разработки ПО. IMHO грех скрывать такие богатства от народа. заглядывайте почаще в наш уголок, не стесняйтесь. ждем'с.

КОгда-то я обещал модераторам флеймить и троллить исключительно в пределах Толксов, лишь изредка заглядывая в другие разделы. Впрочем, в любом случае, бремя доказательства ложится на утверждающего позитивный факт, а оного я тут так и не увидел.

Gharik
()
Ответ на: комментарий от klalafuda

Во-первых, исходный флейм про память тут немного боком: статью писал системный программист, и под словом "программист" он ОЧЕВИДНО имел в виду "системный программист".

>> Прямо средоточие современной маркетоидной диалектики! Забавно, что большинство нынешних студентов-информатиков на старших курсах именно так и думают -- их этому теперь в школе учат...

>> было бы интересно почитать ваше опровержение. ...

Опровержение ЧЕГО? "Маркетоидной диалектики"?

ugoday вполне "логично" воспроизвел современную маркетоидную диалектику, так примерно они и рассуждают. Другое дело, что из противоречивых посылок можно заведомо получить все, что угодно: если в левой части стоит ложь, то импликация истинна независимо от правой части.

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

Цитированные мной ( Die-Hard(25.09.2007 2:09:23) ) положения очень интересно соотносятся друг с другом в историческом аспекте: _сначала_ Билл Гейтс придумал продавать программы, а не "единую аппаратно - програмную сущность", а _потом_, когда из этого развилась целая индустрия со своими законами, маркетоиды вдруг сообразили, что конечного пользователя интересуют все же именно работающая железяка... В результате новаторских исследований и очередного изобретения велосипедов родились гениальные идеи типа "Проблему оптимизации следует рассматривать не в техническом, а в экономическом аспекте", неожиданно преломляемые в рамках привычных софтиндустиальных пониятий ("чем программы лучше тем она дороже; чем программа лучше, тем меньше требование к аппаратной части; чем эвм дороже, тем она быстрее").

Разумеется, вне зависимости от истинности / ложности импликации в целом, все конечные выводы (правые части), в большинстве случаев истинны или ложны независимо от начальных условий. Например, одна из исходных посылок "модели" ugoday'а: "чем программа лучше, тем она дороже" -- ИМХО очевидно ложный вывод из "маркетоидной диалектики". Происхождение этого "вывода" тоже очевидно: механическое перенесение характерных отношений "материального" рынка на рынок софтиндустрии, призванное скрыть паразитический характер этой самой индустрии в современном виде. По пунктам же я более - менее согласен с anonymfus (25.09.2007 1:37:33). Возражения ugoday (25.09.2007 9:12:49) свелись к тому, что "в рамках его модели он (ugoday) прав, а anonymfus -- нет".

Die-Hard ★★★★★
()

Для Ынтырпрайз дело обстоит так, как Вы описали. Но если рассматривать прикладные программы (не узкоспециализированные проффесиональные продукты) то соотношение числа разработчиков/пользователей заметно отличается ;) тут скорее приходится выбирать между 3мя направлениями при некоторм имеющимся количестве ресурсов: 1) улучшение собственнно кода, снижение ресурсоёмкости, повышение стабильности, то есть техническая сторона вопроса. 2)добавление новых фич, улучшение пользовательских характеристик. 3) ну и собственно маркетинг, реклама, различные виды продавливания продукта вплоть до откатов, и прочие не посредственно не связанные с 1 и 2 пунктами действия.

И тормознутость ФФ связано вовсе не с тем, что у Мозиллы Инк. нет денег на хороших программистов, просто они предпочитают тратить их на хороших менеджеров и рекламу.

DNA_Seq ★★☆☆☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.