Собственно, наверное, будет похоже на флейм, но что называется "музыкой" навеяло (по мотивам топика http://www.rsdn.ru/Forum/?mid=1419711

Автор: Pavel Dvorkin
Дата: 05.10.05

).
Помнится, в 1988-1993 годах работал я инженером-конструктором на одном очень крупном (не московском) машиностроительном заводе (как тогда говорили "флагмане социалистической индустрии"). По вузовской специальности я инженер-конструктор гидропневмоприводов. В отличие от большинства инженерных специальностей моя работа требовала довольно таки основательных знаний по физике, в частности по гидродинамике. Те, кто знаком с предметом, поймет меня: уравнения там мама не горюй Короче — это то, что называется МСС (механика сплошной среды). Кроме гидродинамики надо было хорошо знать (именно знать, а не иметь представление !) термодинамику и проч. инженерные дисциплины — сопромат, ТММ и т.п.
И вот надо было эти 3-х этажные уравнения решать (не аналитически, конечно). Метод решения в прикладных задачах "стандартный" — численное дифференцирование/интегрирование. Т.е. кроме собственно физики до черта было и математики и знаменитый университетский учебник Самарского по численным методам был, что называется, настольной книгой. Ну это преамбула.
Извечная проблема таких задач — не хилый (и это еще очень мягко сказано) объем вычислений. С обычным калькулятором и пачкой бумаги более-менее приближенный расчет средней сложности занимал несколько дней (и то, довольно грубо). Компьютеров, как вы понимаете, тогда не было. Ну не совсем, чтобы не было: где-то на заводе была служба АСУ со своим начальником и штатом, но попытка пробиться туда и озадачить их своей проблемой накрылась медным тазм (проще говоря, послали по всем известному адресу). Считать зарплату они кое-как считали (разумеется, с ошибками), даже организовали показушный автоматизированный склад, который вроде как работал (и только в случае приезда на экскурсию какого-нибудь высокого начальства), а остальные задачи — ни-ни !
И тут неведомо как нашему отделу выделяют программируемый микрокалькулятор (кажется, "Электроника МК-52"). Видимо высокое начальство не сообразило, как бы приспособить этот мудреный агрегат на личной даче, поэтому отдали нам. Он не просто считал, он был программируемым !!! Будучи молодым и наглым я как-то умудрился, чтобы этот калькулятор поручили осваивать мне. Пару месяцев я пытался научиться на нем программировать. Параметры каклькулятора (на память, точно не помню) были такие: 4 стековых регистра, 12 (или 15) обычных адресуемых регистров, около 100 ячеек памяти под программы и два вида адресации. Кажется, еще был и EEPROM. Ввод программы осуществлялся в машинных кодах. Полная аналогия с ископаемыми компьютерами конца 40-х, только штеккеров не было
Сейчас я сам себе не поверил бы, но тогда вышеупомянутые дифуры я таки на нем научился считать. По частям, конечно. Промежуточные результаты естественно, приходилось записывать, но зато теперь можно было прогонять расчеты на разных исходных данных и с приемлемой точностью. До такой степени я на нем насобачился, что через год, когда нас перевели на так называемый бригадный подряд (кто постарше — тот помнит), я даже считал на нем зарплату отдела (конечно, по одному человеку за раз, но все же считал, благо народу было всего человек 15).
Конечно, вспоминая все эти извраты, нельзя не признать, что это был примитив. Но это работало, а поскольку на тот момент единственной альтернативой была логарифмическая линейка, то прогресс был на лицо.
В общем я "заразился" программированием. Завод в конце-концов практически загнулся и свалил я в местный университет считать по договорам подряда (на СМ-4) всякие конструкции методом конечных элементов (тоже я вам скажу, математика там будь здоров). Правда, СМ-4 в отличие от "Электроники" настоящий гигант . Ну а потом повалили персоналки, что уже совсем не интересно
К чему я это все ? Да просто к тому, что можно писать эффективно и оптимально. Только думать надо много-много и прежде чем лапать клавиатуру, недурно было бы сначала поразмышлять, а уж потом подходить к компьютеру. Тогда перестанут массово рождаться монстрообразные уроды на мегабайты и гигабайты со смазливым графическим интерфейсом и жалким содержимым.
Вот такая вот история. Прав все-таки Н.Вирт — "Долой жирные программы". А старших слушаться надо

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

F>К чему я это все ? Да просто к тому, что можно писать эффективно и оптимально. Только думать надо много-много и прежде чем лапать клавиатуру, недурно было бы сначала поразмышлять, а уж потом подходить к компьютеру. Тогда перестанут массово рождаться монстрообразные уроды на мегабайты и гигабайты со смазливым графическим интерфейсом и жалким содержимым.
F>Вот такая вот история. Прав все-таки Н.Вирт — "Долой жирные программы". А старших слушаться надо

А нужно ли? Даешь "достаточно хорошее ПО"!

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

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

F>>К чему я это все ? Да просто к тому, что можно писать эффективно и оптимально. Только думать надо много-много и прежде чем лапать клавиатуру, недурно было бы сначала поразмышлять, а уж потом подходить к компьютеру. Тогда перестанут массово рождаться монстрообразные уроды на мегабайты и гигабайты со смазливым графическим интерфейсом и жалким содержимым.
F>>Вот такая вот история. Прав все-таки Н.Вирт — "Долой жирные программы". А старших слушаться надо

psg>А нужно ли? Даешь "достаточно хорошее ПО"!

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

А если уж смотреть на GUI больше нет сил — всегда можно заняться программированием микроконтроллеров — и снова будут машинные коды, 1-4 KB адресуемой памяти и красные светодиодные индикаторы вместо здоровенных мониторов

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

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

psg>А если уж смотреть на GUI больше нет сил — всегда можно заняться программированием микроконтроллеров — и снова будут машинные коды, 1-4 KB адресуемой памяти и красные светодиодные индикаторы вместо здоровенных мониторов

Т.е. Вы не возражаете против того, что за GUI зачастую прячется не такое уж богатое содержимое ?

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

F>К чему я это все ? Да просто к тому, что можно писать эффективно и оптимально. Только думать надо много-много и прежде чем лапать клавиатуру, недурно было бы сначала поразмышлять, а уж потом подходить к компьютеру. Тогда перестанут массово рождаться монстрообразные уроды на мегабайты и гигабайты со смазливым графическим интерфейсом и жалким содержимым.
F>Вот такая вот история. Прав все-таки Н.Вирт — "Долой жирные программы". А старших слушаться надо

Совершенно верно. А то для некоторых программирование означает "лапание"
клавиатуры. И поэтому появилось понятие "кодировщик".
А GUI или неGUI не имеет значения, во всех случаях сначала надо думать.

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

F>В общем я "заразился" программированием. Завод в конце-концов практически загнулся и свалил я в местный университет считать по договорам подряда (на СМ-4) всякие конструкции методом конечных элементов (тоже я вам скажу, математика там будь здоров). Правда, СМ-4 в отличие от "Электроники" настоящий гигант . Ну а потом повалили персоналки, что уже совсем не интересно

Да, метод конечных элементов -- это да! Сразу на воспоминания потянуло. Был у меня в университете мой звездный час, как раз связанный с расчетами методом конечных элементов. Итак, осень 1993-го, первый семестр четвертого курса, математический факультет, специальность 22.04 "ПО ВТ и АС", наша группа специализируется по кафедре Вычислительной Математики и Программирования. Нужно еще сказать, что переход на четвертый курс на нашем факультете -- это как переход в другую лигу, лигу бессмертных (вылететь с четвертого и пятого курсов нужно постараться). А вот к четвертому курсу отсев был довольно солидный. Например, на педагогическом потоке первые три курса было три группы, 75 человек, а на четвертом оставалось только две. Да и наша группа на первом курсе была 18 человек, а к четвертому -- только 12.

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

И вот в таких условиях начинается у нас новый спецкурс «Методы конечных элементов» (МКЭ). Читал нам его доцент, к.т.н. Быховцев Виктор Емельянович, который, наверное, лет двадцать рассчитывал этим методом ленточные фундаменты. Даже какую-то разновидность этого метода придумал. Собственно, в той математике, которая нам читалась, я совершенно ничего не понимал. Но все дело в том, что для получения оценки нашей группе совместными усилиями нужно было написать программу для расчета деформаций чего-то там МКЭ. Что-то типа прямоугольной области, которая покрывается сеткой треугольных элементов. Для отдельных узлов задаются значения нагрузки или параметры среды. Затем должен запускаться расчет. В идеале, должна была быть графическая интерпретация, но это уже как бонус.

Ну а мы решили, что все должно выглядеть по-другому. Что задавать исходные параметры в консоли в виде “Введите нагрузку для точки [3,7]: “ не только не удобно, но и некрасиво. Что графическая интерпретация должна быть обязательно. Ну и вообще, конфетку нужно сделать. К тому времени у меня и моего друга-сокурсника был уже небольшой опыт программирования под Windows. И мы уже не только понимали, что такое check button, а что такое edit-box, но и почувствовали, насколько это удобно. Так что какие-то ориентиры по внешнему виду и удобству использования программы у нас были.

Всю группу разбили на двойки и тройки (миникоманды). Каждой команде дали свою задачу. Кому-то запрограммировать аппроксимацию (или как оно там называлось), кому-то расчет СЛАУ, кому-то графическую интерпретацию и т.д. По «штатному расписанию» моей основной задачей было как раз решение получившейся в результате аппроксимации СЛАУ. Хотя делал я там еще много чего, но сначала нужно рассказать об этой системе уравнений.

Особенность СЛАУ в МКЭ был в том, что матрица СЛАУ была, во-первых, симметричной и, во-вторых, не нулевые значения содержались только в узкой ленте вдоль главной диагонали. А поскольку размерность матрицы была не маленькой, то хранить в ОП нужно было только т.н. полуленту – не нулевые элементы, лежащие выше главной диагонали. Ну хранить-то ладно, это не сложно. Основная проблема в том, что при работе с ней уже нельзя использовать обычные индексы [i,j] – они должны преобразовываться довольно хитрым образом. А если учесть, что формулы для аппроксимации совсем не маленькие (и там нет учета особенностей хранения матрицы СЛАУ), да и расчет СЛАУ активно индексы применяет, то браться за программирование всей этой бодяги было очень невесело. Да и преподаватель нас предупреждал, что при реализации МКЭ львиная доля ошибок как раз и связана с тем, что где-то какой-то индекс вычисляется неправильно.

Но к тому времени я уже хорошо представлял себе возможности C++. В частности, преимущества, предоставляемые перегрузкой операторов. Поэтому я решил избавиться от проблемы неверных индексов самым кардинальным образом – создав класс для матрицы и перегрузив для нее операторы []. Дел оказалось-то на день-два проектирования и на пару часов реализации. И все. Во всей сделанной нами программе не было ни одной ошибки, связанной с неверным вычислением индекса при обращении к хранящейся в памяти полуленте.

Ну а дальше уже дело техники . Была сделана библиотека для работы с мышью (на машинах, где мыши не было курсор мыши рисовался вручную и передвигался от клавиатуры), библиотека разных widget-ов (push button, check box, radio button, edit box), графическая интерпретация и даже экспорт/импорт начальных данных в/из текстовых файлов. Хотя с чем-то пришлось помучаться. Например, мне с моим штатным заданием, расчетом СЛАУ. Оказалось, что большинство элементов на главной диагонали были нулевыми, поэтому метод Гаусса не получилось применить. Метод квадратного корня не подошел т.к. часть элементов были отрицательными, метод итераций сходился очень долго (из-за большого объема матрицы). Единственный метод, которым удалось это СЛАУ разрешить – это метод Халецкого, хотя он и был самым расточительным по памяти. Но вот опробовать все эти методы мне удалось именно благодаря своему классу матрицы – программирование каждого метода было совсем не сложным занятием. В общем, потрудились мы на славу, получилась действительно конфетка. Вся кафедра была под впечатлением. Жалко screenshot-ов не осталось

Интересные последствия были у этой работы. Ну то, что репутация у нашей группы после этого выросла до заоблачных вершин, это само собой. Я за курс МКЭ получил оценку автоматом. В следующем семестре нам опять пришлось использовать МКЭ, но уже для расчета распределения температур по различным поверхностям (мне, например, досталась круглая поверхность, которую нужно было аппроксимировать треугольниками – интересная инженерная задачка, я даже по собственной воле с полярными координатами разобрался, т.к. в них она решалась гораздо проще ). У каждого из нас условия задачи и некоторые особенности были свои, но за основу всеми была взята сделанная нами раньше программа. По слухам, мы тогда стали чуть ли не единственной группой, которая реально рассчитывала свои задачи, говорят, что многие сдавали эту работу с помощью «пустышек» -- программ, которые реальных расчетов не проводили, а показывали только правдоподобную имитацию расчета. Для одного из моих сокурсников наша разработка стала основой для его последующих курсовых и диплома.

Года через два мне довелось поговорить с четверокурсниками, который проходили у того же Быховцева тот же курс МКЭ. И получили ту же самую задачу. Он им показал несколько фрагментов нашей программы, в частности, класс для работы с мышкой. Было забавно, как они обсуждали увиденный код, не зная, что я его автор. Помню, они удивлялись, как можно было создать класс для работы с мышью, объем которого был 5 или 6 страниц распечатки. А еще больше они удивились, когда я им поведал, что этот класс на самом деле умеет делать на машинах без мышки . А еще через пару лет сам Быховцев мне рассказал, как он показал нашу разработку на геологическом факультете, где тогда подобралась сильная группа студентов-программистов. Эти студенты не поверили Быховцеву, что программу написали такие студенты, как они, только математики. Сказали, что это он за деньги у какой-то конторы разработку заказывал. Приятно было такие вещи слушать, тем более, что круче нас эту задачу так никто и не решил.

Я же помню, как после этого курса я еще больше убедился в мощи языка C++. Это было, пожалуй, второе сильное впечатление от C++. Первое – это когда в C++ средствами самого языка оказалось можно сделать тип «множество» (которого мне после Паскаля в C и C++ очень не хватало).

Еще запомнилось впечатление от якобы командной разработки. Это только на бумаге у нас было четыре или пять миникоманд, и двенадцать разработчиков. На самом деле всю разработку тянули два человека – я и мой друг, с которым мы до этого под Windows упражнялись. Не то, чтобы никто ничего не делал. Совсем нет. Например, две наши девушки супер-математика всю аппроксимацию реализовали. Все что-то делали по чуть-чуть. Но все это было настолько разношерстным, что приходилось много чего доделывать, чтобы все вместе объединить. Как мне потом, после университета, в конструкторском бюро объяснили – это обычная практика совковых команд: в отделе 25 человек, из которых 3-4 реально все делают, а остальные на окладе сидят, массовость создают.

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

Но вот, что интересно. Техника тогда у нас в распоряжении была – i286, 640Kb, MS-DOS 5-й или 6-й уже не помню. Компилятор, кажется, Borland C++ 2.0 и библиотека BGI для графики. Т.е. сам бог велел об эффективности заботиться. Ан нет, не помню я, чтобы мы там байты или такты считали. Ведь даже метод Халецкого, если не ошибаюсь, требовал вдвое больше памяти, чем метод Гаусса. Для нас на первом месте функциональность была. Например, чтобы на машине без мышки можно было легко точки на сетке конечных элементов выбирать. Чтобы начальные данные можно было из заранее подготовленного файла загрузить. Чтобы при просмотре результатов между графическим и табличным представлением можно было переключаться. Эффективность там рассматривалась как составная часть функциональности. Задача должна была решаться в конкретных условиях. Она решалась. Поэтому больше мы об эффективности не заботились.

Конечно, это была учебная задача. Но отнюдь не тривиальная. А в следующем семестре, когда мы опять делали расчеты МКЭ, размерности матриц уже серьезно увеличились. Для того, чтобы выделить программе дополнительную память мы тогда сделали простое разделение одной программы на три – одна данные в диалоге запрашивает, затем их в файл записывает. Вторая из файла данные берет и расчет производит, а результаты во второй файл записывает. Третья из второго файла результаты считывает и графики рисует. Только одна программа находится в памяти. Вот такая не хитрая оптимизация.

Хотя, может мы тогда и не задумывались о таких вещах серьезно, поскольку молодые очень были. Да и программировали на C++, у которого проблем с эффективностью никогда и не было. Но мне кажется, что к эффективности нужно относиться как к функциональности: есть задачи (например, hard real-time), где эффективность – это краеугольный камень (наряду с предсказуемостью). А есть задачи (таких большинство), где эффективность – это одно из конкурентных преимуществ. Если есть заинтересованность в таком преимуществе, то эффективности уделяется внимание. Если нет – значит, нет. Долгие годы программирования на C++ и опыт участия в разработке real-time проектов лично меня сделали приверженцем эффективных решений. Но без фанатизма. Если мне сейчас нужно за короткое время написать сложную обработку гигабайтных логов, то я без угрызений совести делаю это на Ruby, т.к. проще это. А то, что Ruby скрипт будет считать в пять раз дольше, чем C++ программа… Ну и что? Где эта C++ программа? Нет ее, и не будет, т.к. писать ее слишком долго. Нет конкуренции, нет у эффективности и преимущества. Вот такие дела.

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

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

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

psg>>А если уж смотреть на GUI больше нет сил — всегда можно заняться программированием микроконтроллеров — и снова будут машинные коды, 1-4 KB адресуемой памяти и красные светодиодные индикаторы вместо здоровенных мониторов

F>Т.е. Вы не возражаете против того, что за GUI зачастую прячется не такое уж богатое содержимое ?

Я тоже начинал программировать на МК-52...

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

F>К чему я это все ? Да просто к тому, что можно писать эффективно и оптимально. Только думать надо много-много и прежде чем лапать клавиатуру, недурно было бы сначала поразмышлять, а уж потом подходить к компьютеру. Тогда перестанут массово рождаться монстрообразные уроды на мегабайты и гигабайты со смазливым графическим интерфейсом и жалким содержимым.
F>Вот такая вот история. Прав все-таки Н.Вирт — "Долой жирные программы". А старших слушаться надо

Н-да... МК-52, ностальгия. Я тоже с калькуляторов начинал.

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

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

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

N>Н-да... МК-52, ностальгия. Я тоже с калькуляторов начинал.

N>Вот только опус ваш сильно напоминает типичную историю программиста-шестидесятника: "Да я к ним пришёл, а у них расчет выполняется два часа! так я сел, и за два дня сделал такую оптимизацию, что оно за три минуты стало считать! потому что думать надо, прежде чем писать."

N>Цена машинному времени сейчас совсем другая. И мегабайтам — тоже. И часто намного важнее быстрее выпустить продукт на рынок, чем сделать из него "чистого слона"... Эффективность и оптимальность — это еще не все.
Ну я не шестидесятник. И не семидесятник. Более того — почти даже и не восьмидесятник И на кусок хлеба зарабатываю как и большинство — прикладным программированием. Поэтому я прекрасно понимаю, что такое стоимость времени разработки. Но (простите за странную аналогию) нынешнее программирование и технологии программирования в значительной степени напоминают приготовление еды из полуфабрикатов — всяческих "Магги", "Галин Бланки", "Быстров", "Гурманий", не говоря о "Роллтонах" и "Дошираках" — доверху напичканных всякими добавками и присадками (о них еще обычно на упаковках пишут "идентичные натуральным"). Т.е. что-то типа борща или плова, конечно, получится, но разве его можно сравнить с маминым или бабушкиным борщем и пловом
Вот иногда и хочется чего-то действительно вкусного, натурального, а не их "идентичных" заменителей (скорее — мистификаций).
Впрочем, я Вас прекрасно понимаю: плОтЮт вовсе не за это. А поскольку так, то приходится идти на компромисс

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

N>Вот только опус ваш сильно напоминает типичную историю программиста-шестидесятника: "Да я к ним пришёл, а у них расчет выполняется два часа! так я сел, и за два дня сделал такую оптимизацию, что оно за три минуты стало считать! потому что думать надо, прежде чем писать."
А думать надо всегда перед тем как что либо делать. Причем думать старательно. Иначе полная херня получится. А уж подумав начинать делать, и стараться изо всех сил делать хорошо. "Плохо — оно само получится." (С) Goblin

N>Цена машинному времени сейчас совсем другая. И мегабайтам — тоже. И часто намного важнее быстрее выпустить продукт на рынок, чем сделать из него "чистого слона"... Эффективность и оптимальность — это еще не все.

Пардон муа, лирическое отступление... Я сам бывает пишу неоптимальный код и "подпорки", когда надо чтоб быстро написать и работало... Но все в разумных пределах.
Поставил как то себе Paint Shop Pro X v11. До этого у меня стоял (и сейчас стоит) v8. Поставил и ужаснулся. При практически одинаковом функционале прога стала хавать больше и тормозить даже в интерфейсе!! Т.е. у меня он просто запущен, ничего в него не грузил и при хождении по менюшкам проц грузится на 100% и все ощутимо тормозит. Только не надо говорить что железо слабое: P4 2Gz, 512 RAM. Если эта версия тормозит даже в пользовательском интерфейсе а v8 (благо которую я еще не снес) не тормозит вообще да еще функционал практически одинаковый то такие проги надо сразу отправлять в топку. И программеров за ней следом в крематорий. Чтоб не успели расплодиться!

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

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

psg>А если уж смотреть на GUI больше нет сил — всегда можно заняться программированием микроконтроллеров — и снова будут машинные коды, 1-4 KB адресуемой памяти и красные светодиодные индикаторы вместо здоровенных мониторов
Нет сил смотреть на громоздкие и медленные программы. От интерфейса это не зависит.

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

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

psg>>К сожалению, не смог навскидку найти оригинальное сообщение, надеюсь, что автор мне простит безымянную цитату... Смысл в том, что у индустрии свои приоритеты, а у Вирта — как у матерого ученого — свои, поэтому выслушивать его конечно надо, но выполнять все его рекомендации — нет
IO>Смысл в том, что цель индустрии — заработать больше денег , а цель Вирта — пропагандировать написание хорошего ПО .
IO>И эти две цели очень часто взаимоисключающие.
IO>В индустрии доминирует тактика, а у Вирта — стратегия.
IO>Индустрия — это бизнес, а Вирт — это наука.
IO>И поти никогда фундаментальная наука не финансируется бизнесом.
IO>Зато бизнес всегда пользуется ее плодами.

ПРАВДА? А кем же тогда финансируется "фундаментальная наука"?

psg>>А если уж смотреть на GUI больше нет сил — всегда можно заняться программированием микроконтроллеров — и снова будут машинные коды, 1-4 KB адресуемой памяти и красные светодиодные индикаторы вместо здоровенных мониторов
IO>Нет сил смотреть на громоздкие и медленные программы. От интерфейса это не зависит.

Вас кто-то застравляет на них смотреть? Критерий качества ПО — удовлетворение потребителя

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

IO>>И поти никогда фундаментальная наука не финансируется бизнесом.
IO>>Зато бизнес всегда пользуется ее плодами.
psg>ПРАВДА? А кем же тогда финансируется "фундаментальная наука"?
Обычно государством.

psg>>>А если уж смотреть на GUI больше нет сил — всегда можно заняться программированием микроконтроллеров — и снова будут машинные коды, 1-4 KB адресуемой памяти и красные светодиодные индикаторы вместо здоровенных мониторов
IO>>Нет сил смотреть на громоздкие и медленные программы. От интерфейса это не зависит.
psg>Вас кто-то застравляет на них смотреть? Критерий качества ПО — удовлетворение потребителя
Заставляют.

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

IO>Смысл в том, что цель индустрии — заработать больше денег , а цель Вирта — пропагандировать написание хорошего ПО .
IO>И эти две цели очень часто взаимоисключающие.

Т.е. чтобы заработать больше денег нужно писать плохое ПО?

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

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

IO>>>И поти никогда фундаментальная наука не финансируется бизнесом.
IO>>>Зато бизнес всегда пользуется ее плодами.
psg>>ПРАВДА? А кем же тогда финансируется "фундаментальная наука"?
IO>Обычно государством.

А государство-то откуда берет $$$?

psg>>>>А если уж смотреть на GUI больше нет сил — всегда можно заняться программированием микроконтроллеров — и снова будут машинные коды, 1-4 KB адресуемой памяти и красные светодиодные индикаторы вместо здоровенных мониторов
IO>>>Нет сил смотреть на громоздкие и медленные программы. От интерфейса это не зависит.
psg>>Вас кто-то застравляет на них смотреть? Критерий качества ПО — удовлетворение потребителя
IO>Заставляют.

А вот это уже плохо...

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

IO>>Смысл в том, что цель индустрии — заработать больше денег , а цель Вирта — пропагандировать написание хорошего ПО .
IO>>И эти две цели очень часто взаимоисключающие.
IT>Т.е. чтобы заработать больше денег нужно писать плохое ПО?
Нет. Чтобы заработать больше денег нужно писать ПО, которое приносит больше денег. И если для этого надо пожертвовать качеством, то бизнес легко идет на это.

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

IO>Нет. Чтобы заработать больше денег нужно писать ПО, которое приносит больше денег. И если для этого надо пожертвовать качеством, то бизнес легко идет на это.

А в чем и как измеряется качество?

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

Минус за дурацкие аналогии

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

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

AVK>Минус за дурацкие аналогии
Ваше право

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

IO>>Нет. Чтобы заработать больше денег нужно писать ПО, которое приносит больше денег. И если для этого надо пожертвовать качеством, то бизнес легко идет на это.
AVK>А в чем и как измеряется качество?
Ну это всем известно.
Качественное ПО почти не имеет багов, работает оптимально по скорости и памяти, оптимально по своему размеру, не требует постоянного саппорта и онлайн-апдейтов, удобно для пользователя и т.д.