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

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

Люди никак не могут научиться писать программы, которые хотя бы работают без багов. А ты еще хочешь взвалить на них задачу по "повышению общей эффективности"
Догадываешься, к чему это приведет? (только не надо тоже рассказывать, что УЖ ТВОИ программы никогда не глючат — все равно не поверю )

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

PD>Перекодирование строки из файла из 866 в 1251.

PD>Все что я нашел, сводится к

PD>public string MyDecoder(string str)
PD>{
PD> byte[] b = Encoding.GetEncoding(866).GetBytes(str);
PD> str = Encoding.GetEncoding(1251).GetString(b);
PD> return str;
PD>}

PD>или вариациям на эту тему

Есть еще Encoding.Convert
Может быть, он поможет отцу российской демократии?

PD>Я вполне допускаю, что ты сейчас мне это эффективнее напишешь. Ты. А все будут именно это и делать.

Ну и пусть делают. Я лучше буду иметь дело с неэффективной, но работающей реализацией. Чем с дьявольски эффективной, но ни хрена не работающей

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

PD>Собрался наконец написать. Минусов мне за эти тезисы поставят, это уж точно.
Это вряд ли. Наоборот, правду-матку режешь.

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

• Не стоит бояться того, что программисты определенного склада "вымрут". Программистов порождает среда. Когда среда приветствовала нердов — программерами были нерды. Сейчас есть и нерды, которые живут на работе, иногда высовываются в сеть, а живых людей видят только на коференции. Есть и "индусы" — малоквалифицированные люди, которые покрывают потребность в "давай-давай", "нам некогда учиться — надо сдать систему вчера", "если у тебя есть рабочий кусок кода — скопируй его целиком" и так далее. Есть также промежуточное звено — люди, не испытывающие коммуникативных проблем, у которых есть некомпьютерные хобби, но при этом они любят свою работу и стараются делать ее хорошо.
  И все это — исключительно потому, что есть потребность в каждой из этих категорий. Напоремся на потолок производительности — те же индусы научатся писать эффективные программы. Ну, не все, а кроме 99% не сумевших и вымерших
  
• Собственно, о самой эффективности. С одной стороны, я полностью согласен с теми, кто придает максимум значения экономии времени программиста. Ребята, время, когда можно было годами полировать текстовый редактор в одиночку, кануло в лету. Сейчас у нас нет времени на эту ерунду. Нам надо удовлетворять потребности бизнеса очень быстро. В первую очередь это означает переход к групповой разработке. Да, до сих пор очень редко в природе встречаются команды численностью более 10 человек. Я подозреваю — из-за технических и организационных проблем. Любой наш заказчик будет счастлив сократить время разработки вдвое. Кроме этого, большое значение имеет стоимость поддержки.
  Резюме: понятность программы сейчас значительно важнее ее эффективности (в большинстве случаев!). Соответственно, рулят платформы, которые позволяют писать более понятные программы. Рулят платформы, которые предоставляют исчерпывающую информацию об ошибках, а не Сore Dump. Рулят платформы, которые выполняют рутину за разработчика. Чтобы он мог сосредоточиться на написании действительно существенной части. Потому что ему надо будет писать (а его коллегам читать) меньше кода.
  
  Тем не менее, я тоже испытываю дискомфорт, глядя на неэффективности на ровном месте.
  
  В итоге, я свожу свою мысль к следующему замечанию:
  — нельзя ставить эффективность во главу угла. Она не является приоритетом
  — Это не значит, что стоит применять заведомо неэффективные решения.
  Этого простого правила, я считаю, должно быть достаточно. Остается только тонкость с этим "заведомо". (Это слово, кстати, встречается в тексте статьи 273 УК РФ). Тут каждый решает для себя. Главный критерий — насколько дорого обойдется применение альтернативного решения. Если чувствуешь, что объем работ вырастает больше, чем на 20%-50%, то лучше забей. Если стоимость примерно одинакова — применяй лучшее.
  
  Отдельный разговор надо завести об архитектуре. Premature optimization касается только микро-уровня. Если вдруг в саму архитектуру не было заложено возможности по повышению эффективности, то выполнение mature optimization может оказаться postmature, т.е. слишком поздним. И это сведет полученную экономию средств к нулю.
  
  
• Ну, и последнее замечание: Очень важно правильно применять оптимизации. В предыдущем пункте я упоминал про неиспользование откровенно неэффективного кода. В большинстве случаев это будут мелкие глупости, вроде вызова new в цикле или ресайза динамического массива на 1. Так вот, на каждой платформе эти хитрости — свои. И ни в коем случае нельзя переносить привычные методы в другую среду. В дотнете new может означать всего лишь очистку памяти. Округление размера выделяемых объектов до "круглых" типа 32, 64 в дотнете контрэффективно — аллокатор сам разберется с выравниванием, а увеличение размера ускоряет забивание хипа и учащает сборку мусора.
  
  Поэтому для выполнения пункта 2 просто необходимо тщательно изучать среду, в которой работаешь. Чтобы, например, нутром чуять, что
  

  ...(string a, string b, string c)
  {
    return "Hello" + a + b + c;
  }

  
  — эффективно, а за
  

  ...(IEnumerable<string> strings)
  {
    string s = string.Empty;
          foreach(string a in strings) s=s+a;
      return s;
  }

  
  надо бить линейкой.

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

NC>...писать код надо так, чтобы из него можно было получить максимальную денежную прибыль...
NC>...Энтузиастам и "вольным художникам" не место в индустрии...

Мда. Энтузиасты и вольные художники формируют эту индустрию.
Ну да к вечеру вернется McSeem2, он тебе подробнее объяснит

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

GZ>>2. Резидентные серверные программы. Строго наоборот. Они должны адаптировать полностью ресурсы компьютера ради своей эффективности. И никак иначе.

PD>+-. И да, и нет. Потму как этих серверных программ на машине может быть несколько, и лучше бы им не брать все ресурсы компьютера, а то придется по серверу на каждую программу иметь.
Тут я забыл указать некоторый термин. А именно масштабируемость. Как-то повелось, что каждый смотрит на этот термин со своей колокольни, но рискну дать определение. Масштабируемость — способность увеличивать КПД программы в зависимости от аппаратных средств. То есть, вместо того, чтобы переписывать программу когда не стало хватать пропускной способности, заказчику достаточно купить дополнительную память, или дополнительный процессор, или дополнительный компьютер для кластеризации приложения. У масштабируемых решений практически всегда присутсвует одно свойство. Оно всегда медленнее их немасштабируемых аналогов. Если один или два пользователя, то немасштабируемое приложение масштабируемое порвет как грелку. Но масштабируемость это не просто лейбл. Это действительно очень полезное средство для пользователя. Хреново когда придется переписывать программу, или заказывать другую. И дело не только в деньгах. Дело еще в обучении пользователей для нового продукта, проходить весь цикл установки и настройки. Поэтому использование аппаратных средств — важное свойство серверов приложений.
Архитектор обязан следить за масштабируемостью серверов. Вот если он не следит, то это значит недоучка. Ну а недоучки — это тема других топиков.

PD>Если я напишу это же без FrameWork, алгоритм будет тот же, эффективность выше и памяти меньше, то это будет лучше.
В данном случае да. Но можно сделать и так, в случае большого объема приложения, написать основную программу на Net Framework, а наиболее криминальные алгоритмы написать на unmanaged C++(благо он лучше умеет использовать и управлять ресурсами компьютеров).

PD>А то, что на FrameWork ошибок будет меньше — не уверен. Не все сводится к мемори ликам и некорректным индексам.
Да. И это правда. Не все сводится к мемори ликам. Компонентность тоже провоцирует не делать ошибок. А если приложение большое и многофункционально, то недооценивать компонентность нельзя.
Кроме того, тут стоит говорить не только о Framework, но вообще о языках высокого уровня. Не секрет, что язык высокого уровня генерит избыточный код и избыточно использует память. И чем выше язык, тем труднее поддается оптимизация кода компилятором. В принципе, если взять тот-же STL, то говорить о том, что он по скорости 1 в 1 с кодом написанным вручную на С не приходится. А string вообще кошмар, но зато жутко удобный. И только великолепие и сложность компилятора более менее выравнивает ситуацию.

PD>От ошибок алгоритма меня никакой FrameWork не защащает. Складывать килограммы с метрами (вместо того, чтобы умножать) и там вполне можно, .
От этого никто не сможет защитить. Особенно от непроффесионализма. Но тут никто не властен.


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

PD>Я бы эту фразу перевернул.
PD>Большинство программ таково, что они используют значительно больше памяти и процессорного времени, чем им в действительности нужно. Поэтому программ, которые могли бы при оптимальной эффективности использовать память и процессор, не существует (почти), так как при нынешнем стиле написания программ им нужны намного большие ресурсы, которых пока нет.
Фразы не эквивалентны.
Вообще я бы сформулировал свое мнение так. Функицональность возрастает, и аппаратная часть адаптируется под нее. Или наоборот, аппаратная часть возрастает, и функциональность адаптируется под нее. Не важно какая из них верна.

GZ>>Все это ресурсы избыточны для повседневной работы. Мне не жалко 20 мегабайт — если у меня их 500.

PD>Во-во. Тебе надо 20, а берешь 40. Мне надо 50 — беру 80. Ему надо 100 — берет 150. А этому надо еще 100 — пошел вон, памяти больше нет.
А это уже прямой путь в леса богатые дичью. Поверь мне, везде где я работал всегда думали о компьютерах пользователей. Иначе прогоришь.

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

PD>Да, увы, это так. Ты сделаешь быстрее, не спорю. И сэкономишь несколько К$ на своей зарплате. А в итоге 100,000 пользователей потратят несколько сотен тысяч $ на память, которую твоя программа заняла и не использует.
Обычно если заняла, то использует Если не использует — то это ошибка. Если избыточно использует — ошибка алгоритма.
Пользователей больше занимает полезность программы.

GZ>>Для данной конкретной задачи, это корректное замечание. Net — не очень подходит под числодробилки.

PD>Да ведь нам говорят, что .Net — генеральная линия развития, а те, кому она не нравится — неандертальцы. Вот и мне сегодня заказчик сообщил, что планирует нечто на .Net. Пока не знаю что. И не убедишь его, что это , м.б. не лучшее решение.
Ты сам аргументировать не можешь. Если это сложная программа с множеством взаимосвязей и сложной архитектурой, то да. Это будет хороший выбор. Аналог в виде Java — не сильно отличается.

PD>"У нас никогда нет времени на то, чтобы сделать все как следует, но всегда есть время на переделки"
В сложной программе с множеством модулей, взаимосвязей и народа который все это пытается связать — сразу сделать как следует невозможно. Также как написать программу без багов, это должна быть очень простая задача.

PD>Ну и заявление! Дизайн понятен, сопровождение легко, след-но, оптимизировать будет несложно! А то, что для оптимального решения задачи, возможно, надо не в деталях оптимизировать, а все решение пересмотреть и весь дизайн переделать — это ты не допускаешь ? Совсем другим способом ее решать!
Это — ошибка архитектуры. Тяжелая ошибка. Ее боятся. К ней надо по правильному подходить, либо работать методиками которая не подразумевает первоначальное построение архитектуры(типа XP). Все ХР и построено на том, что функционал достраивается, а следовательно нужен понятный и сопровождаемый дизайн. Ради этого рефакторят. И основным свойством кода является не эффективность в плане выполнения, а именно сопровождаемость. Эффективность в плане выполнения — выравнивают потом. Там вообще не знают и не хотят знать, войдет ли или не войдет данная функциональность в том виде в котором она разрабатывалась на начальном этапе.

GZ>>Во — вторых, ты увеличиваешь сложность дизайна тогда когда он наиболее важен. В результате, при добавлении функциональности увеличивается количество ошибок. IMHO Это более тяжко чем неэффективное использование ресурсов.
PD>ИМХО это лечится рано или поздно, а первое — не всегда.
Как раз ошибки вылечить на порядок сложнее. А иногда и невозможно. В непонятном коде значительно сложней найти и локализовать ошибку. Иногда этот код легче переписать чем исправить(такое встречалось), или добавить функциональность. В простом, понятном коде, в котором функицональности все выделены в раздельные сущности, переписать что-то легко. Благо понятно что делаешь.

PD>Да, а вместо Net Framework что предложишь ?
Java. Нельзя от печки требовать, чтобы она стала сново кирпичем. Так и нельзя от net или лиспа, чтобы они управляли ресурсами компьютера также эффективно как это делает более низкоуровневый собрат С++.

PD>Вместо MS Office ?
Тут согласен. Я это и не скрывал.

PD>Опять -таки — все верно, если у тебя единственный заказчик. Ему хоть на 2Gb пиши, если у него их 4. Но я-то о других случаях говорю.
Да хоть тысячи. Перед построением программы, всегда строится примерная картина для кого эта программа предназначена, и что у него есть.

С уважением, Gleb.

Видите ли, колега.

Абстракции — абстрациями, а конкретика — конкретикой.

То, что вы не призываете заниматься микрооптимизацией — это замечательно. Хотя в свете существования компиляторов, которые оптимизируют ассемблерный код лучше, чем 99% программистов — это не так уж и удивительно .Однако из ваших постов можно сделать вывод, что вы отказываете в праве на существование (доминирование?) таким системам, как Java или .net, именно на основе их неоптимальности. И в моих (например) глазах такие тезисы абсолютно равнозначны призывам массово использовать asm для построения UI.

Тезис, который до вас на разные лады пытаются донести десятки участвующих в этой дискусии таков:

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

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

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

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

P.S. А вообще — я сам очень люблю шлифовать код. Но очень редко могу себе это позволить.

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

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

Есть разница оптимизить, потому что это нравится и потому что это надо. Любят оптимизить именно там, где нравится, доводя эффективность до предела в (почти) неиспользуемом коде, а сам код до предельной нечитаемости.

DAN>А тенденция не поменяется пока не закончатся гигагерцы и гигабайты.

Лично я воспринял исходный пост, как предупреждение, что понятие "оптимальный", в частноти, у меня сейчас совсем не такое, как было у автора лет 20 в фигом назад, и даже не такое как было у меня лет 10 назад. Кое что потеряно ради быстрого написания приемлимого для современных компов кода. Призыв писать программы эффективно на сколько возможно, я понимаю как не расслабляться и быть готовым думать про эффективность больше. Именно думать, а не наворачивать супер алгоритмы где умею.

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

PD>Собрался наконец написать. Минусов мне за эти тезисы поставят, это уж точно.
Не видать что-то минусов... Зачем же так сразу пессимистически начинать?

PD> Когда компьютеры были большими, память у них была маленькой и
PD>быстродействие тоже. И поэтому гуру от этих ЭВМ ничего, кроме ассемблера
PD>(автокода, по-тогдашнему) и не признавали.
Давайте условно расставим факты между "тем" и текущим временем.
Что было раньше:
— программирование не было массовым, там работали Профессионалы, но из другой специальности, собственно такой профессии как программист и не существовало
— компьютеры были "хилые", поэтому просто приходилось писать программы компактно и оптимально, по другому они просто были не работали
— сроки разработки программ были большие, соответственно разрабатывались они тщательнее и больше времени уделялось оптимизации (конкуренция и борьба за рынок не были так выражены)
— в ИТ-сфере крутились не очень большие деньги, отрасль только становилась на ноги
— такие свойства как сопровождаемость и архитектура у программ были постоянно совершенствовались до определенного момента (времени этому уделялось больше, да и работали профессионалы, т.е. средний уровень был высокий)

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

Так что криминала не вижу. Так все отрасли развиваются и ИТ — не исключение. Отсутствие "эффективных" программ сейчас вполне объяснимо и терпимо. Так просто надо сейчас и все.

Кстати, заметили ли вы что большинство фундаментальных открытий в ИТ отрасли было сделано в 60-80-е годы? Нет, сейчас тоже что-то открывают, но это эволюционные открытия, а не революционные. Например из-за возросшего быстродействия теперь стало возможным использовать те более эффективные алгоритмы, которые раньше считались слабо перспективными и т.п. И самые "новые" процессоры, шины и алгоритмы уже придумали "дядьки" из 60-х. Но! Это я не к тому, что в отрасли настал кризис, нет! Наоборот — это значит что отрасль сформировалась как таковая, "повзрослела" что-ли, и это здорово. И теперь она будет именно такой (по крайней мере до очередной метаморфозы связанной с кризисом бизнеса в ней, например, но это уже другая история).

Теперешних программистов можно понять. Многие, например, неявно заинтересованы в том чтобы новая версия windows содержала больше ошибок, занимала больше места на диске и в памяти и работала медленнее (и похоже так и будет — исключений здесь не бывает так как того требуют ускорения сроков разработки, увы чудес не бывает). Это позволит им кормиться "на ней" разрабатывая такие же "неэффективные" программы (по занимаемому объему и быстродействию) потому что пользователь вынужден будет улучшить свой компьютер. А значит писать эти программы они будут еще быстрее — а это сейчас главное! Программирование как таковое многим уже не интересно — интересны лишь деньги, которые можно на этом заработать. Зачем что-то оптимизировать, искать ошибки, прорабатывать архитектуру? Как сейчас говорят — "пипл хавает" и баста, главное опередить (ну или скупить на корню) конкурентов. Программирование уже давно не наука, а бизнес!

PD> И вот тогда этот неэффективный стиль программирования даст себя знать!
PD>Сейчас можно просто рассуждать — чего я буду 20 Мбайт экономить, если
PD>пользователь без проблем 256 может докупить ? А вот когда опять в жестких
PD>лимитах работать придется — окажется, что некоторые программы, которые вполне
PD>могли бы быть написаны, написаны не будут, или же будут написаны лет через 10
PD>после того момента, когда они могли бы появиться! Потому что эффективно
PD>работать большинство не умеет. Привычки у них такие — что нам стоит лишних
PD>десяток Мбайт взять!
Вы в корне не правы. Когда (и если) наступят такие времена, что надо будет делать снова "хорошие" программы — за дело опять возьмутся профессионалы, только теперь уже матерые программисты-профессионалы (опыт-то есть!). И они напишут и компилятор паскаля в 64к и еще много чего другого. Людей такого скалада не много, но они есть, и когда часы пробьют — они окажутся востребованней, чем те кто пришел в программисты за легкими деньгами...

Маленький совет сочуствующим автору. Вы любите чистое творчество, сложные неординарные задачи, непаханные поля новых технологий? Уходите из программирования. Я имею ввиду не "телом", а "душой". Т.е. можно продолжать зарабатывать на этом поле деньги, а тем временем прорабатывать новые, хотя бы смежные, отрасли. Чертовски приятно видеть как происходит становление новой технологии! И там есть где разгуляться пока туда не нагрянули люди с огромными мешками денег и не началась грызня за эти самые мешки :-)

Да и еще. Я не хотел обижать нынешних массовых программистов. Даже пресловутых индусов. Никоим образом! Они молодцы и достойно развивают отрасль ставя производство программ на конвейер и шлифуя его и оттачивая в мелочах в т.ч. и на своих ошибках. Это титанический труд!

PD>Пишите свои программы эффективно, господа! По крайней мере настолько, насколько
PD>это возможно!
Перефразируя, можно дать более правильный совет (ИМХО): работу надо стараться делать хорошо, потому что плохо оно само получится. А эффективность программ здесь не причем, если сейчас выгоднее писать быстрее — значит именно это и надо делать. Да и где четкие критерии этой самой эффективности? Они же меняются со временем... Надо писать соответственно текущему уровню развития отрасли. Раньше это было компактно и не спеша, сейчас дешево и быстро, завтра будет еще что-то и т.д... Но при этом — если вы профессионал вы должны уметь писать по-любому из этих критериев и держать руку "на пульсе".

p.s. Все вышеизложенное — это сугубо мое мнение, хотя я старался быть максимально объективным. Ничего личного.

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

NC>Буду краток: писать код надо так, чтобы из него можно было получить максимальную денежную прибыль.
NC>Энтузиастам и "вольным художникам" не место в индустрии.
Именно поэтому на моем винчестере остается все меньше программ, которые делались для получения максимальной денежной выгоды. Так как программы, написаные энтузиастами и вольными художниками все чаще становятся лучше коммерческих собратьев.

Хорошие коммерческие продукты, которые я использую, НЕ живут по правилу "максимальной денежной прибыли", а по правилу "Делать все, чтобы пользователям было удобно — тогда и прибыль будет".

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

pp2>Маленький совет сочуствующим автору. Вы любите чистое творчество, сложные неординарные задачи, непаханные поля новых технологий? Уходите из программирования. Я имею ввиду не "телом", а "душой". Т.е. можно продолжать зарабатывать на этом поле деньги, а тем временем прорабатывать новые, хотя бы смежные, отрасли. Чертовски приятно видеть как происходит становление новой технологии! И там есть где разгуляться пока туда не нагрянули люди с огромными мешками денег и не началась грызня за эти самые мешки

Давайте это Ричарду Столлману (GCC, emacs), Линусу Торвальдсу (Linux), Тео да Радту (OpenBSD), Гвидо ван Россому (Python), Ларри Уоллу (Perl), Якиро Матцумото (Ruby), ...(список можно продолжать)..., раcскажем. А то мужики, право слово, фигней страдают. Надо их жизни-то научить.

---

Ребята, если вы относитесь к программированию как к обычной работе, средству заработка, то и относитесь себе так и дальше. Зачем же подобные советы давать (вот еще один: Re: Об эффективности программ

Автор: Nickolay Ch
Дата: 06.10.05

).

Посмотрите лучше на другие отрасли, которые уже не один век существуют.

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

Или медицина. Неужели Федоровы и Амосовы там всего лишь случайность?

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

C>Здравствуйте, Nickolay Ch, Вы писали:

NC>>Буду краток: писать код надо так, чтобы из него можно было получить максимальную денежную прибыль.
NC>>Энтузиастам и "вольным художникам" не место в индустрии.
C>Именно поэтому на моем винчестере остается все меньше программ, которые делались для получения максимальной денежной выгоды. Так как программы, написаные энтузиастами и вольными художниками все чаще становятся лучше коммерческих собратьев.

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

C>Хорошие коммерческие продукты, которые я использую, НЕ живут по правилу "максимальной денежной прибыли", а по правилу "Делать все, чтобы пользователям было удобно — тогда и прибыль будет".

Далеко не все пользователи, а тем более корпоративные заказчики такие как ты Но не в этом суть. Как всегда, человек читает не то что написанно, а то, что хочет прочесть.
Вообще то, я хотел сказать, что единственным незыблемым критерием того, как надо производить софт, является то, сколько ты за него получишь. Это не значит что надо писать софт "плохо".(Пусть каждый поймет это слово так как ему приятнее). Из этого отправного пункта и идем — если получим больше за то, что сделаем "чтобы пользователям было удобно"(кстати очень сложный и неформализуемымй момент), то будем делать так.
Получим больше за то, что прога занимает минимум места и летает на 100 пеньке — делаем так.
Получим за то, что сляпаем прогу которая жрет полгига и требует 3ГГц проца, но зато сляпана за неделю при минимальных вложениях — делаем так.
Нужен разнообразный функционал — а времени нет, берем богатый, пусть громоздкий, но уже готовый и отлаженный фреймворк. Все зависит от задачи.

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

GN>>ИМХО не стоит забывать, что развитие часто идёт по спирали...
VB>Это не развитие идет по спирали, это просто отдельные люди любят повторять старые и давно известные ошибки...

Под ошибками понимаются дефекты транзисторов, когда их напичкано больше чем позволяет технология?

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

Д>Ну и пусть делают. Я лучше буду иметь дело с неэффективной, но работающей реализацией. Чем с дьявольски эффективной, но ни хрена не работающей

Шас я процитирую (о ужас!) Баяна Ширянова:

     Но  ведь  какая  штука,  спроси  любого  ублюдка  на  улице, что бы  он
предпочел: жить долго, но  скучно, или  коротко, но радостно? И  он  выберет
последнее. Ну да, не все. Но большинство!
     Но, б..,  почему  этот  уличный опрашиваемый  не  согласится  на  такой
вариант: долго  и радостно?  А  потому,  что он думает,  что так не  бывает.
Столько  лет  все  рвались  к   счастливой   жизни,  что  абсолютно  в   ней
разуверились!

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

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Мда. Энтузиасты и вольные художники формируют эту индустрию.
ЗХ>Ну да к вечеру вернется McSeem2, он тебе подробнее объяснит

ЗХ>Конечно, а зачем?



http://www.rsdn.ru/Forum/Message.aspx?mid=1422736&only=1

Автор: McSeem2
Дата: 06.10.05

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

A>О чём я и говорю. Dual-core с точки зрения программы — это два процессора. Если программа однопоточна, как большинство существующих, то никакого увеличения производительности не будет.

Увеличение производительности будет — в многозадачной ОС намного больше одного thread.

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

Научиться мало. Железнае проблемы как обходить? Одному-то процессору мало пропускной способности памяти, а если их больше, то они начинают "мешать" друг другу.

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

Производительность памяти уже давно растёт медленнее производительности ядра CPU. И если внутри кристалов ещё можно что-то делать, то на внешних проводниках всё намного сложнее.

A>и память будет становиться дешевле.

А когда начнут интегрировать RAM в корпус CPU (что бы избавиться от проблем с печатными платами), то как будем добавлять память?

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

PD>Перекодирование строки из файла из 866 в 1251.

PD>Все что я нашел, сводится к

PD>public string MyDecoder(string str)
PD>{
PD> byte[] b = Encoding.GetEncoding(866).GetBytes(str);
PD> str = Encoding.GetEncoding(1251).GetString(b);
PD> return str;
PD>}

Гон. В файле нет строки. В файле есть байты.
Поэтому достаточно использовать ровно один Encoding.Convert.
Если ты из файла получил строку, то ты сам виноват — делаешь три Convert вместо одного.

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

E>Давайте это Ричарду Столлману (GCC, emacs), Линусу Торвальдсу (Linux), Тео да Радту (OpenBSD), Гвидо ван Россому (Python), Ларри Уоллу (Perl), Якиро Матцумото (Ruby), ...(список можно продолжать)..., раcскажем. А то мужики, право слово, фигней страдают. Надо их жизни-то научить.
Вы не совсем правильно поняли. Хотя, возможно я тоже некорректно выразился. Это был всего лишь совет тем кого напрягает текущая ситуация в массовом бизнес-программировании. Обороты его и вправду больше, чем у OSF, и продуктов они выпускают больше (хотя и далеко не факт что лучше, но все же). Open-source движение отчасти противостоит "денежным мешкам" и их методам работы, и действительно эти люди нашли нишу в области ИТ в которой еще можно заниматься более-менее творческим программированием. Я лично только за этих людей и рад этому движению, жаль что оно пока не такое же массовое как и "закрытый софт", поэтому не оно в некоторых вещах определяет, к сожалению, лицо ИТ. Но это вселяет некоторую надежду, что не все еще "потеряно" (хотя я нигде и не говорил что все потеряно). Все они безусловно не "страдают фигней", а занимаются крайне полезными делами и молодцы! Из моих слов никак не следовало, что они не правы или что в программировании больше нет ну совсем уж ничего интересного. Выразился просто слишком уж прямо и эмоционально... Но "закрытое" коммерческое программирование действительно становится больше рутиной, чем творчеством, с этим Вы согласны?

E>Ребята, если вы относитесь к программированию как к обычной работе, средству заработка, то и относитесь себе так и дальше. Зачем же подобные советы давать
[skipped]
E>Посмотрите лучше на другие отрасли, которые уже не один век существуют.
Ну хорошо, первый совет был несколько эмоциональный (уйти из программирования). Но второй-то вполне нормальный! Я советовал всем работать хорошо, что в этом плохого?

E>На образование, например. Там что, нет возможности для творчества? А как же учителя, которых потом всю жизнь с благодарностью вспоминают?
А причем здесь это? В ИТ тоже много хороших людей, которых вспоминают с благодарностью. Но "массового" творчества уже почти нигде нет, потому что отрасли уже давно сложились и что-то там новое придумать по сути все тяжелее и тяжелее. Остается небольшая личная инициатива или можно просто хорошо работать к чему я и призываю! А там глядишь и Амосовы и Федоровы из кого-нибудь получатся...

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

PD>Перекодирование строки из файла из 866 в 1251.

PD>Все что я нашел, сводится к

PD>public string MyDecoder(string str)
PD>{
PD> byte[] b = Encoding.GetEncoding(866).GetBytes(str);
PD> str = Encoding.GetEncoding(1251).GetString(b);
PD> return str;
PD>}

PD>или вариациям на эту тему

Код некорректен: строка (string) в .NET состоит из символов юникода и к ней не применимо понятие кодировки, поэтому вышеприведенный код просто напросто коверкает строку, т.к.
byte[] b = Encoding.GetEncoding(866).GetBytes(str); // получили текст из строки в массив байт в кодировке 866
str = Encoding.GetEncoding(1251).GetString(b); // интерпретировали каждый байт из b в кодировке 1251 — в результате в str одни крякозяблы

Фактически, если необходимо записать строку в кодировке 1251 то это делается просто:
byte[] b = Encoding.GetEncoding(1251).GetBytes(str);

Если же надо преобразовать кодировку массива байт, то не надо предварительно преобразовывать массив в строку:
public byte[] MyDecoder( byte[] byte866 )
{
byte[] byte1251 = Encoding.Convert( Encoding.GetEncoding(866), Encoding.GetEncoding(1251), byte866 );
return byte1251;
}

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

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

pp2>Но "закрытое" коммерческое программирование действительно становится больше рутиной, чем творчеством, с этим Вы согласны?

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

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

E>Зачем же подобные советы давать (вот еще один: Re: Об эффективности программ

Автор: Nickolay Ch
Дата: 06.10.05

).
В догонку — с mrozov я как раз не согласен. Я нигде не говорил что деньги определяют все. Я лишь посетовал, что увы все больше (в массовом коммерческом программировании)... Писать _только ради денег_ — это крайний случай и как любая крайность — не самый лучший выход. Но увы так многие поступают. А я такого совета никогда не давал. Все что я советовал — это действуйте сообразно обстоятельствам и работайте хорошо.

Вот мои слова:
"работу надо стараться делать хорошо, потому что плохо оно само получится."
и еще одни
"Надо писать соответственно текущему уровню развития отрасли."

Может Вы меня с кем-то путаете? :-)

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

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

pp2>>Но "закрытое" коммерческое программирование действительно становится больше рутиной, чем творчеством, с этим Вы согласны?

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

Если софт открытый или не на продажу — то да, возможны варианты. Хотя общая тенденция на лицо.