Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, c-smile, Вы писали:
CS>>Ну т.е. если следовать хотя бы закону Мура то за час рабочего времени сейчас я должен по идее в разы более сложный или продуктивный код писать чем за тот же час но десять лет назад.
Т>
К примеру, менее известный «второй закон Мура», введённый в 1998 году Юджином Мейераном, который гласит, что стоимость фабрик по производству микросхем экспоненциально возрастает с усложнением производимых микросхем. Так, стоимость фабрики, на которой корпорация Intel производила микросхемы динамической памяти ёмкостью 1 Кбит, составляла 4 млн. $, а оборудование по производству микропроцессора Pentium по 0,6-микронной технологии c 5,5 млн. транзисторов обошлось в 2 млрд. $. Стоимость же Fab32, завода по производству процессоров на базе 45-нм техпроцесса, составила 3 млрд. $
Здравствуйте, c-smile, Вы писали:
CS>Чего-то вот подумалось...
CS>По идее в результате развития программизма как вида деятельности/науки мы (т.е. a software developer) должны иметь возможность CS>создавать всё более сложные системы. Ну т.е. если следовать хотя бы закону Мура то за час рабочего времени сейчас я должен по идее в разы более сложный или продуктивный код писать чем за тот же час но десять лет назад.
CS>Но чего-то как-то не замечаю я в окружении себя такого прогресса. Во всяком случае в разы.
Двадцать лет назад написание текстового редактора уровня "блокнот" считалось подвигом. Над этим НИИ работали.
Десять лет назад — вполне нормальной задачей для среднего программиста.
Сейчас это неделя работы в режиме "час перед сном".
Написание — это именно написание. Понятно, что можно готовый компонент взять.
Так что прогресс идет. Конечно не с такой скоростью как в аппараткре.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, matumba, Вы писали: M>>НАДЕЖДЫ НЕТ. M>>Пока что П(рограмминг) настолько молод (как это ни странно звучит)
FR>Ни фига он не молод, скоро в страческий маразм начнет впадать FR>Он уже больше 50 лет существует. За такой же срок автомобилестроение и авиастроение стали вполне FR>конвеерно-индустриальными, программазму это и через 50 лет не грозит.
Я настаиваю на формулировке "молод", т.к. П только-только отошёл от маразматических идей 60-ых (всякие Лиспы, прологи, ПЛ/1...).
Сейчас идёт некоторая стагнация — тусуются библиотеки, опробываются всякие многоядерности, но уже хотя бы очерчены контуры модулей и их функции.
Хочется верить, что Жаба.НЕТ таки загнётся и выкатят что-то компилябельное и вразумительное. Например, D.
Здравствуйте, Шахтер, Вы писали:
Ш>Здравствуйте, alpha21264, Вы писали:
A>>Здравствуйте, c-smile, Вы писали:
CS>>>Чего-то вот подумалось...
CS>>>По идее в результате развития программизма как вида деятельности/науки мы (т.е. a software developer) должны иметь возможность CS>>>создавать всё более сложные системы. Ну т.е. если следовать хотя бы закону Мура то за час рабочего времени сейчас я должен по идее в разы более сложный или продуктивный код писать чем за тот же час но десять лет назад.
CS>>>Но чего-то как-то не замечаю я в окружении себя такого прогресса. Во всяком случае в разы.
A>>Двадцать лет назад написание текстового редактора уровня "блокнот" считалось подвигом.
Ш>Кем считалось?
Угадай.
A>>Над этим НИИ работали.
Ш>Бабло пилили.
Щаз.
Напиши-ка мне вьюношь аналог Ворда или Студии. Слабо? Бабло пилишь.
Через 20 лет тебе так и скажут.
По идее в результате развития программизма как вида деятельности/науки мы (т.е. a software developer) должны иметь возможность
создавать всё более сложные системы. Ну т.е. если следовать хотя бы закону Мура то за час рабочего времени сейчас я должен по идее в разы более сложный или продуктивный код писать чем за тот же час но десять лет назад.
Но чего-то как-то не замечаю я в окружении себя такого прогресса. Во всяком случае в разы.
Есть ли надежды на какие-то технологии, приемы которые смогут если не экспоненциально то хотя бы в разы повысить выхлоп от программизма?
Скажем .NET или Java, теоретически managed системы позволяют создавать более сложные системы за счет
уменьшения проблем связанности больших систем (подсчет ссылок например). Но сам код-то приходится создавать все так же — руками, и оперировать приходится примерно теми же сущностями что и десять лет назад. Ну т.е. задача которая десять лет назад делалалсь на каком-нибудь FoxPro будет делаться (разрабатываться) примерно за тоже же время сейчас на, скажем, Java или C#.
Здравствуйте, c-smile, Вы писали:
CS>Скажем .NET или Java, теоретически managed системы позволяют создавать более сложные системы за счет CS>уменьшения проблем связанности больших систем (подсчет ссылок например). Но сам код-то приходится создавать все так же — руками, и оперировать приходится примерно теми же сущностями что и десять лет назад. Ну т.е. задача которая десять лет назад делалалсь на каком-нибудь FoxPro будет делаться (разрабатываться) примерно за тоже же время сейчас на, скажем, Java или C#.
Просто есть код и код.
Есть код, написание которого можно упростить путем всяких автоматических генераторов, решарперов, подсчета ссылок и прочего. Например, доступ к БД.
А есть код, написание которого таким образом упростить нельзя. Например, те же бухгалтерские формулы. Как там ни крути, а их не сгенерируешь автоматически, их придется выдирать из каких-то положений и директивных документов и вбивать вручную.
Ну а уж если речь идет о серьезных алгоритмах — то и тем более. Сомневаюсь, что какой-то автоматический генератор сгенерирует мне, допустим, код для распознавания образов. Тут не решарпер нужен, а математические алгоритмы и библиотеки. И писать придется самому, долго и упорно.
Так что все зависит от соотношения того или другого кода в проекте.
Cyberax wrote:
> назад. Ну т.е. задача которая десять лет назад делалалсь на каком-нибудь > FoxPro будет делаться (разрабатываться) примерно за тоже же время сейчас > на, скажем, Java или C#.
На FoxPro кстати побыстрее будет. Язык всё-таки высокоуровневый, 4GL.
> CS>Или я как-то это все упрощаю? > Посмотри как работают в современных IDE для Java и C#. Реально код > пишется где-то на порядок быстрее, чем на чистом С++. Рефакторинги, > скорость компиляции, статические проверки и т.п.
Я вот в свете этих достижений IDE совсем о другом думаю.
На Java код пишется полуавтоматически или автоматически.
Так спрашивается, на кой фиг делать было тупой до ужаса язык,
чтобы потом писать автомат, его парсящий и крючащий, который
на этом язцыке писать будет ?
Не лучше ли было более интеллектуальный язык создавать ?
Те же бины взять. Их надо писать руками. Но можно нажать кнопарь
в IDE -- всё будет автоматом. А не лучше ли было ВСТРОИТЬ ЭТО В
ЯЗЫК ? (в C# конечно встоили).
Ну и что код пишется на порядок быстрее на Java я бы не сказал.
Там столько лабуды "в нагрузку" приходится писать, чтобы до
сути дописаться -- ужас.
Cyberax wrote:
> FoxPro — это 4GL, он специально заточен был "под бухгалтерии". И то что > на Java можно будет писать с такой же скоростью — это уже достижение > немалое.
И когда же такое будет ? Что Java по скорости разработки с FoxPro сравнится ?
> Сравни это с C++ и прямым использованием WinAPI для GUI, к примеру. Лет > 10 назад это было достаточно обычная ситуация.
C++ лучше Java, хотя хуже конечно FoxPro в этом аспекте.
С++ имеет средства расширения языка и создания DSL-ей.
(определение своих типов и переопределение операций, наконец макросы).
Jav-у ну хоть убей не расширишь. Максимум что она предлагает --
вызовы фунций, пусть и объектных. Это уровень развития IT
вообще-то 1960-70-х годов.
Здравствуйте, c-smile, Вы писали:
CS>... то за час рабочего времени сейчас я должен по идее в разы более сложный или продуктивный код писать чем за тот же час но десять лет назад. CS>Но чего-то как-то не замечаю я в окружении себя такого прогресса. Во всяком случае в разы. CS>Есть ли надежды на какие-то технологии, приемы которые смогут если не экспоненциально то хотя бы в разы повысить выхлоп от программизма?
НАДЕЖДЫ НЕТ.
Пока что П(рограмминг) настолько молод (как это ни странно звучит), что текущая ситуация в нём напоминает строительство времён изобретения цемента. Т.е. уже понятно, что круглые кирпичи и треугольные дома не канают, что цемент — наше всё, но вот мощных строительных блоков пока не сделали — возимся потихоньку с кирпичами.
Ситуацию, однако, мутят всякие уроды (мелкомягкие в т.ч.), завлекая на строительство шалашей, плотов и качелей (FP, MVC, WCF, WPF и прочая муйня). Отдельным фронтом идут любители рыть пещеры в песке(линупсисты) и закидывать себя сверху листьями (web). Верить в оздоровление сферы хочется, но не можется — "доктора" все куплены. Так что продолжаем делать навесы, жадно ловя бамбук, любовно отполированный фирмами.
П отражает те же самые тенденции, что и в остальном буржуйском мире — никто не заинтересован делать ХОРОШО. А делать хорошие инструменты — тем более. В результате получаем стотыщную вариацию доступа к БД, мильённую попытку сделать самый лучший ГУЙ, очередной клубок многонитевости (предыдущие были не того цвета) и как награда — раскраска синтаксиса. Люди 22 века будут уссыкиваться на музей программазма, где за 30 лет так и не научились даже тривиальному ORM.
Здравствуйте, c-smile, Вы писали:
CS>Ну т.е. если следовать хотя бы закону Мура то за час рабочего времени сейчас я должен по идее в разы более сложный или продуктивный код писать чем за тот же час но десять лет назад.
К примеру, менее известный «второй закон Мура», введённый в 1998 году Юджином Мейераном, который гласит, что стоимость фабрик по производству микросхем экспоненциально возрастает с усложнением производимых микросхем. Так, стоимость фабрики, на которой корпорация Intel производила микросхемы динамической памяти ёмкостью 1 Кбит, составляла 4 млн. $, а оборудование по производству микропроцессора Pentium по 0,6-микронной технологии c 5,5 млн. транзисторов обошлось в 2 млрд. $. Стоимость же Fab32, завода по производству процессоров на базе 45-нм техпроцесса, составила 3 млрд. $
Здравствуйте, c-smile, Вы писали:
CS>Чего-то вот подумалось...
CS>По идее в результате развития программизма как вида деятельности/науки мы (т.е. a software developer) должны иметь возможность CS>создавать всё более сложные системы. Ну т.е. если следовать хотя бы закону Мура то за час рабочего времени сейчас я должен по идее в разы более сложный или продуктивный код писать чем за тот же час но десять лет назад.
Не обязательно. Я бы поставил на первое место надежность и эффективность ПО как главную цель прогресса. Я согласен ждать выхода продукта дольше, если получу софт, не вызывающий проблем.
CS>Но чего-то как-то не замечаю я в окружении себя такого прогресса. Во всяком случае в разы.
Не скажу за 10 лет. Но для меня переход от C к C++ позволяет работать продуктивней где-то в >=2 раза.
После С++ пока ничего существенно лучшего не придумали (если не считать С++11, но это не x2 а на 10-20 %).
CS>Есть ли надежды на какие-то технологии, приемы которые смогут если не экспоненциально то хотя бы в разы повысить выхлоп от программизма?
Нет, и вот почему. Софт существует в 2 видах. Исходный код и реализация (то, что образуется в результате компиляции/сборки). Эффективность языка программирования можно грубо оценить
его сжимающей способностью, т.е. отношением размера выхода к размеру входу. Т.е. более эффективный язык позволяет меньшим числом строк кода получить тот же по объёму ассемблерный выход.
Понятно, почему скажем С++ хорош -- в первую очередь из-за шаблонов.
Т.е. прогресс в языкостроении -- это прогресс в ужимании (точнее, в алгоритмах ужимания). А он не может быть Муровским. Кроме того, появление "верхних этажей" затрудняет использование языка -- требует больше ума от программиста. Фактически, мы уже С++ом переполнили буфер у среднестатистического индуса.
CS>Скажем .NET или Java, теоретически managed системы позволяют создавать более сложные системы за счет CS>уменьшения проблем связанности больших систем (подсчет ссылок например).
Нет, не позволяют. Управление памятью ортогонально "связности системы".
Здравствуйте, Cyberax, Вы писали:
CS>>Или я как-то это все упрощаю? C>Посмотри как работают в современных IDE для Java и C#. Реально код пишется где-то на порядок быстрее, чем на чистом С++. Рефакторинги, скорость компиляции, статические проверки и т.п.
Ну давай возьмем какую-нибудь задачу, скажем "Бухгалтерия малого преприятия". В FoxPro ты бы её писал тогда примерно столько же времени что и на Java сейчас. И скорость компиляции FoxPro или того же Clipper реально не сильно медленнее была. И оперировал ты все теми же сущностями, нет? Тогда я пользовался Multiedit который как IDE был уж точно не хуже чем VS или Eclipse.
Здравствуйте, c-smile, Вы писали:
CS>Чего-то вот подумалось...
CS>По идее в результате развития программизма как вида деятельности/науки мы (т.е. a software developer) должны иметь возможность CS>создавать всё более сложные системы. Ну т.е. если следовать хотя бы закону Мура то за час рабочего времени сейчас я должен по идее в разы более сложный или продуктивный код писать чем за тот же час но десять лет назад.
CS>Но чего-то как-то не замечаю я в окружении себя такого прогресса. Во всяком случае в разы. CS>Есть ли надежды на какие-то технологии, приемы которые смогут если не экспоненциально то хотя бы в разы повысить выхлоп от программизма?
CS>Скажем .NET или Java, теоретически managed системы позволяют создавать более сложные системы за счет CS>уменьшения проблем связанности больших систем (подсчет ссылок например). Но сам код-то приходится создавать все так же — руками, и оперировать приходится примерно теми же сущностями что и десять лет назад. Ну т.е. задача которая десять лет назад делалалсь на каком-нибудь FoxPro будет делаться (разрабатываться) примерно за тоже же время сейчас на, скажем, Java или C#.
CS>Или я как-то это все упрощаю?
не забывайте, что закон Мура о числе транзисторов в процессоре, а вовсе не о скоростях и производительности
Здравствуйте, ilnar, Вы писали:
CS>>Или я как-то это все упрощаю?
I>не забывайте, что закон Мура о числе транзисторов в процессоре, а вовсе не о скоростях и производительности
Опередил ты меня
Прогресс софта можно, например, так отследить:
— количество кода, исполняемого в единицу времени;
— количество отжираемой памяти;
— количество объектов, с которыми оперирует программа;
— количество потоков в процессе;
и т.д.
А если посмотреть на требования к современным играм (игры тоже софт) и сложить транзисторы всех CPU и GPU из требований, то мы имеем конкретное опережение закона Мура по требованиям Т.о. софт является драйвером роста производительности систем.
Если руки золотые, не важно из какого места они растут.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, servancho, Вы писали: PD>Самая прогрессивная программа по этому критерию. PD>main () PD>{ PD>while(true); // ну какое-нибудь окончание придумать PD>} S>>- количество отжираемой памяти; PD>Самая прогрессивная программа по этому критерию PD>char a[1000000000]; PD>main() {} PD>Это все не критерии прогресса софта, а критерии в лучшем случае его сложности, а в худшем — разгильдяйства в обращении с ресурсами при его написании.
А если не утрировать и посмотреть правде в глаза? Возьмем виртуальный срез, скажем, студии, посмотрим сколько там тредов молотит, сколько спин локов, что легко вырождается в while(true) Sleep(зависит_от).
А char a[1000000000], да это тьфу, та же студия в 2 раза больше кушает.
Так что в итоге считать прогрессом софта? Если сложность не является критерием, это кстати противоречит закону Мура. Ибо чем больше транзисторов, тем больше логики туда впихано, а объем логики это сложность и есть.
Если руки золотые, не важно из какого места они растут.
Здравствуйте, alpha21264, Вы писали:
A>Здравствуйте, c-smile, Вы писали:
CS>>Чего-то вот подумалось...
CS>>По идее в результате развития программизма как вида деятельности/науки мы (т.е. a software developer) должны иметь возможность CS>>создавать всё более сложные системы. Ну т.е. если следовать хотя бы закону Мура то за час рабочего времени сейчас я должен по идее в разы более сложный или продуктивный код писать чем за тот же час но десять лет назад.
CS>>Но чего-то как-то не замечаю я в окружении себя такого прогресса. Во всяком случае в разы.
A>Двадцать лет назад написание текстового редактора уровня "блокнот" считалось подвигом.
Здравствуйте, SV., Вы писали:
SV.>Даже как-то неловко рассказывать нашему Кармаку, но... Закон Мура в софтостроении — открытое Гейтсом применение — забей на оптимизацию, делай быстрее, на следующем цикле обновления софта апгрейд железа даст тот же результат.
Кстати, если посмотреть не рукопедию, а в википедию (http://en.wikipedia.org/wiki/Moore%27s_law), то там даже термин соответствующий приводится: The Great Moore's Law Compensator (TGMLC).
Что касается сложности софта. Она нарастает, и это очевидно. Страшно подумать, какие дьявольские силы задействуются, чтобы вывести строку текста посредством нынешнего WPF, особенно со включенной "размазюкой". Но зато субпиксельная точность (оставим вопрос о полезности приобретения в сторонке). Но зато тени и прочие спецэффекты. Десять лет назад — такое, у среднего программиста? Ха!
Здравствуйте, Шахтер, Вы писали:
SV.>>Что касается сложности софта. Она нарастает, и это очевидно. Страшно подумать, какие дьявольские силы задействуются, чтобы вывести строку текста посредством нынешнего WPF, особенно со включенной "размазюкой". Но зато субпиксельная точность (оставим вопрос о полезности приобретения в сторонке). Но зато тени и прочие спецэффекты. Десять лет назад — такое, у среднего программиста? Ха!
Ш>Такие вещи и сейчас не средние программисты пишут. Используют -- да, а вот самому написать все алгоритмы -- принципиально это займет столько же времени.
Это не имеет отношения к вопросу о сложности софта. Средняя программа сегодня сложнее, чем десять лет назад. И одна из причин — собственный код программиста складывается со все возрастающим кодом библиотек.
Здравствуйте, LaPerouse, Вы писали:
FR>>Были уже попытки и стандартизации и полного копирования всех процессов из того же автомобилестроения в разработку FR>>программ, провалились со страшным треском гуглить "japan software factories"
LP>Стандартизация — это всегда хорошо. Хуже от этого не может стать по определению.
Конечно стандартизация это хорошо, плохо то что ее тянут из отраслей которые по сути ничего общего с программированием
не имеют, ну и получают результат как у японцев.
Здравствуйте, c-smile, Вы писали:
CS>Скажем .NET или Java, теоретически managed системы позволяют создавать более сложные системы за счет CS>уменьшения проблем связанности больших систем (подсчет ссылок например). Но сам код-то приходится создавать все так же — руками, и оперировать приходится примерно теми же сущностями что и десять лет назад. Ну т.е. задача которая десять лет назад делалалсь на каком-нибудь FoxPro будет делаться (разрабатываться) примерно за тоже же время сейчас на, скажем, Java или C#. CS>Или я как-то это все упрощаю?
Посмотри как работают в современных IDE для Java и C#. Реально код пишется где-то на порядок быстрее, чем на чистом С++. Рефакторинги, скорость компиляции, статические проверки и т.п.
Здравствуйте, c-smile, Вы писали:
CS>По идее в результате развития программизма как вида деятельности/науки мы (т.е. a software developer) должны иметь возможность CS>создавать всё более сложные системы. Ну т.е. если следовать хотя бы закону Мура то за час рабочего времени сейчас я должен по идее в разы более сложный или продуктивный код писать чем за тот же час но десять лет назад.
Если бы Интел до сих пор клепала процессоры на той же технологии что и 8086...
CS>Скажем .NET или Java, теоретически managed системы позволяют создавать более сложные системы за счет CS>уменьшения проблем связанности больших систем (подсчет ссылок например). Но сам код-то приходится создавать все так же — руками, и оперировать приходится примерно теми же сущностями что и десять лет назад.
Другие сущности. Более высокого уровня. В дотнет раньше были простые коллекции, дубовые паттерны, а сейчас одной строчкой заменяются вагоны кода.
>Ну т.е. задача которая десять лет назад делалалсь на каком-нибудь FoxPro будет делаться (разрабатываться) примерно за тоже же время сейчас на, скажем, Java или C#.
Здравствуйте, c-smile, Вы писали:
CS>Ну давай возьмем какую-нибудь задачу, скажем "Бухгалтерия малого преприятия". В FoxPro ты бы её писал тогда примерно столько же времени что и на Java сейчас. И скорость компиляции FoxPro или того же Clipper реально не сильно медленнее была. И оперировал ты все теми же сущностями, нет? Тогда я пользовался Multiedit который как IDE был уж точно не хуже чем VS или Eclipse.
Тогда бухгалтерия и сейчас бухгалтерия это разные по масштабу приложения.
Нынешнюю бухгалтерию на том старом Фоксе-Клиппере да в Мультиэдит уже не осилить.
C>Посмотри как работают в современных IDE для Java и C#. Реально код пишется где-то на порядок быстрее, чем на чистом С++. Рефакторинги, скорость компиляции, статические проверки и т.п.
Есть и другой вариант — выразительные языки, кода нужно писать намного меньше, но ни там ни там я не вижу роста производительности программирования (не набора кода) на порядок в сравнении с С++ десятилетней давности. В разы да возможно, но опять зависит от того кто и как пишет.
Здравствуйте, c-smile, Вы писали:
CS>Ну давай возьмем какую-нибудь задачу, скажем "Бухгалтерия малого преприятия". В FoxPro ты бы её писал тогда примерно столько же времени что и на Java сейчас. И скорость компиляции FoxPro или того же Clipper реально не сильно медленнее была. И оперировал ты все теми же сущностями, нет? Тогда я пользовался Multiedit который как IDE был уж точно не хуже чем VS или Eclipse.
Уверен что на фоксе "Бухгалтерия малого преприятия" реализуется на порядок быстрее чем на Java или С#. Потому что фокс это специализированный инструмент для решения таких задач , а Java и C# универсальные. Закон Мура сработал в обратную сторону получается
Здравствуйте, c-smile, Вы писали:
CS>>>Или я как-то это все упрощаю? C>>Посмотри как работают в современных IDE для Java и C#. Реально код пишется где-то на порядок быстрее, чем на чистом С++. Рефакторинги, скорость компиляции, статические проверки и т.п. CS>Ну давай возьмем какую-нибудь задачу, скажем "Бухгалтерия малого преприятия". В FoxPro ты бы её писал тогда примерно столько же времени что и на Java сейчас. И скорость компиляции FoxPro или того же Clipper реально не сильно медленнее была.
FoxPro — это 4GL, он специально заточен был "под бухгалтерии". И то что на Java можно будет писать с такой же скоростью — это уже достижение немалое.
Сравни это с C++ и прямым использованием WinAPI для GUI, к примеру. Лет 10 назад это было достаточно обычная ситуация.
CS>И оперировал ты все теми же сущностями, нет? Тогда я пользовался Multiedit который как IDE был уж точно не хуже чем VS или Eclipse.
Хуже, однозначно хуже. IDEA несравнимо круче любого текстового редактора, так как работает с программой не как с простым текстом.
Здравствуйте, c-smile, Вы писали:
CS>Ну давай возьмем какую-нибудь задачу, скажем "Бухгалтерия малого преприятия". В FoxPro ты бы её писал тогда примерно столько же времени что и на Java сейчас.
FoxPro в 2-х/3-х звенке? С возможным веб-гуем? С выводом отчётов в html/pdf/doc/xcl/odt/не дай бог TeX? И прочее/прочее/прочее... И только бухгалтерия нужна действительно для "малого предприятия" — когда все остальные задачи помещаются в голове директора, ну максимум ещё 2-х — 3-х человек. В противному случае нужна не просто бухгалтерия. А там уже недалеко до разных "техпроцессов", "документооборота" и прочей фигни. И без возможности "[динамически] генерировать произвольные абстракции и описывать их взаимодействие" становится так скучно, что необходимость описывать половину из этого в xml-простынях, часть аннотациями а часть просто кодом (пусть даже страшным, как анонимные классы по 1.5к строк) уже не кажется таким уж исчадием ада...
Здравствуйте, c-smile, Вы писали:
CS>Или я как-то это все упрощаю?
На мой взгляд, процесс идет, хоть и не в экспотенциальном смысле. Экспотенциальности мешает человек. Второй моск не вставишь, третью руку не присобачишь.
А вообще, развитие больше идет в специализации. Чем использовать FoxPro, бухгалтерию проще делать в 1С. Выйгрыш будет экспотенциальным, если еще найдешь нужные примеры/компоненты.(1С программированием ни занимался ни разу). Точно также лучше адаптировать ERP, чем тратить миллионы человекодней самоистязание.
Основное торможение — в человеке. Процесс специализации людёв — сильно тормозится.
Здравствуйте, alpha21264, Вы писали:
A>Двадцать лет назад написание текстового редактора уровня "блокнот" считалось подвигом. Над этим НИИ работали. A>Десять лет назад — вполне нормальной задачей для среднего программиста. A>Сейчас это неделя работы в режиме "час перед сном".
Здравствуйте, c-smile, Вы писали:
CS>Но чего-то как-то не замечаю я в окружении себя такого прогресса. Во всяком случае в разы. CS>Есть ли надежды на какие-то технологии, приемы которые смогут если не экспоненциально то хотя бы в разы повысить выхлоп от программизма?
Что значит, сложные системы? Сложность можно измерять по разному. Если говорить о размере кода, требованиях к памяти, то современное ПО на порядки сложнее старого. А можно и как ты, поставить акцент на решаемые задачи с точки зрения конечного потребителя. Но за последние 10-15 лет решаемые задачи не очень то изменлись Но если раньше эта доля составлла 90% работы в проекте, то теперь эта цифра очень сильно упала. Много времени тратится на реализацию некритичного функционала (всякие интеграции, GUI, навороченные отчеты и т. п.) Вообще, прогресс в софтотоении больше шел в следующих направлениях (1) увеличение комфорта для пользотеля (GUI, внешний вид отчетов) (2) уменьшение порога вхождения пользователя в систему (все более-менее однотипно) (3) уменьшение порога вхождения для программистов (пару кликов мыши и готов тот же текстовый редактор).
Здравствуйте, c-smile, Вы писали:
CS>Чего-то вот подумалось...
... CS>Или я как-то это все упрощаю?
Даже как-то неловко рассказывать нашему Кармаку, но... Закон Мура в софтостроении — открытое Гейтсом применение — забей на оптимизацию, делай быстрее, на следующем цикле обновления софта апгрейд железа даст тот же результат.
Здравствуйте, Don Reba, Вы писали:
DR>Здравствуйте, alpha21264, Вы писали:
A>>Двадцать лет назад написание текстового редактора уровня "блокнот" считалось подвигом. Над этим НИИ работали. A>>Десять лет назад — вполне нормальной задачей для среднего программиста. A>>Сейчас это неделя работы в режиме "час перед сном".
DR>Тридцать лет назад писали Emacs, двадцать — Vim.
Здравствуйте, Don Reba, Вы писали:
DR>Здравствуйте, alpha21264, Вы писали:
DR>>>Тридцать лет назад писали Emacs, двадцать — Vim.
A>>Это ты к чему?
DR>К тому, что тогда писали далеко не текстовые редакторы уровня блокнот. Сейчас редакторы того же уровня, вроде Notepad++, пишутся совсем не за неделю.
Понимаешь... Emacs и Vim это не редактор уровня "блокнот". Это вообще не редакторы.
Если этими двумя сущностями может пользоваться всего 3% населения, то это не редакторы, а что-то другое.
Программу ведь тоже можно в hex-editor-е писать. Только мало кто на это способен.
По этому hex-editor и IDE — это разные сущности.
A>Понимаешь... Emacs и Vim это не редактор уровня "блокнот". Это вообще не редакторы. A>Если этими двумя сущностями может пользоваться всего 3% населения, то это не редакторы, а что-то другое.
Редактор уровня блокнот 15 лет назад используя какой-нибудь OWL можно было сделать практически так же просто как сейчас.
Используя Smalltalk можно было его написать и 20 лет назад.
Здравствуйте, SV., Вы писали:
SV.>Здравствуйте, SV., Вы писали:
SV.>>Даже как-то неловко рассказывать нашему Кармаку, но... Закон Мура в софтостроении — открытое Гейтсом применение — забей на оптимизацию, делай быстрее, на следующем цикле обновления софта апгрейд железа даст тот же результат.
SV.>Кстати, если посмотреть не рукопедию, а в википедию (http://en.wikipedia.org/wiki/Moore%27s_law), то там даже термин соответствующий приводится: The Great Moore's Law Compensator (TGMLC).
SV.>Что касается сложности софта. Она нарастает, и это очевидно. Страшно подумать, какие дьявольские силы задействуются, чтобы вывести строку текста посредством нынешнего WPF, особенно со включенной "размазюкой". Но зато субпиксельная точность (оставим вопрос о полезности приобретения в сторонке). Но зато тени и прочие спецэффекты. Десять лет назад — такое, у среднего программиста? Ха!
Такие вещи и сейчас не средние программисты пишут. Используют -- да, а вот самому написать все алгоритмы -- принципиально это займет столько же времени.
Здравствуйте, SV., Вы писали:
SV.>Здравствуйте, Шахтер, Вы писали:
SV.>>>Что касается сложности софта. Она нарастает, и это очевидно. Страшно подумать, какие дьявольские силы задействуются, чтобы вывести строку текста посредством нынешнего WPF, особенно со включенной "размазюкой". Но зато субпиксельная точность (оставим вопрос о полезности приобретения в сторонке). Но зато тени и прочие спецэффекты. Десять лет назад — такое, у среднего программиста? Ха!
Ш>>Такие вещи и сейчас не средние программисты пишут. Используют -- да, а вот самому написать все алгоритмы -- принципиально это займет столько же времени.
SV.>Это не имеет отношения к вопросу о сложности софта. Средняя программа сегодня сложнее, чем десять лет назад. И одна из причин — собственный код программиста складывается со все возрастающим кодом библиотек.
Здравствуйте, Шахтер, Вы писали:
SV.>>Это не имеет отношения к вопросу о сложности софта. Средняя программа сегодня сложнее, чем десять лет назад. И одна из причин — собственный код программиста складывается со все возрастающим кодом библиотек.
Ш>Не сложнее, а объёмнее.
Что такое, по-вашему, сложность и за счет чего повышается объем?
M>НАДЕЖДЫ НЕТ. M>Пока что П(рограмминг) настолько молод (как это ни странно звучит)
Ни фига он не молод, скоро в страческий маразм начнет впадать
Он уже больше 50 лет существует. За такой же срок автомобилестроение и авиастроение стали вполне
конвеерно-индустриальными, программазму это и через 50 лет не грозит.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, matumba, Вы писали: FR>Он уже больше 50 лет существует. За такой же срок автомобилестроение и авиастроение стали вполне FR>конвеерно-индустриальными, программазму это и через 50 лет не грозит.
Ты знаешь, что гайкой М6 ГОСТ №xxxxxxx можно прикрутить головку блока двигателя ВАЗ 2106 и клеммы аккумулятора любой Волги? Ключевое слово — ГОСТ. Проблема программной индустрии в том, что отсутствуют стандартизованные интерфейсы. Сколько существует в мире текстэдитов и сколько из них имеют одинаковые интерфейсы?
Так почему же автомобилестроение смогло выработать общепринятые стандарты, а программная индустрия — нет? Есть три причины, почему это происходит (то, что мне пришло пока в голову).
1. В машиностроении несовместимость интерфейсов обходиться значительно дороже, чем в программной индустрии. Паттерн "Адаптер" все знают. И этот баян тоже:
Kotyabrа:
— Как все в природе мудро устроено!
Заметили? Ведь дырочки на шкурке у кошки именно там, где у кошки глазки!
Torin:
-Если б кошку писали программисты, глаза были бы на жопе, под кожей, а для передачи изображения использовалась бы система зеркал!
В машиностроении подобная "система зеркал" либо съест кучу материала, энергии, трудовых ресурсов, либо будет неприемлема в силу того, что требуемые характеристики изделия не будут обеспечены, либо это вообще невозможно сделать. Нет, в ИТ оверхед безусловно тоже присутствует (падение производительности как минимум), но он просто несопоставим.
2. Вариативность интерфейсов. Сколькими способами можно скрепить узлы А и Б в единый узел С? Сколькими способами они могут взаимодействовать друг с другом, обеспечивая функциональность узла С? Вне зависимости от типа узлов, это число будет на порядки меньше количества возможных вариантов интерфейса простейшего текстэдита, которые можно набросать на салфетке за час.
3. Отсутствие четких границ программных компонентов — в противоположность машинным узлам, чьи границы зачастую четко очерчены фундаментальными ограничениями (как правило физического характера). Разделение ответственностей между компонентами можно провести тысячами разных способов, каждый имеет свои преимущества и недостатки. Смотри каким толстым получился интерфейс нашего текстэдита, может перекинем вот эту парочку методов фонтрендереру? А может вынесем в отдельную компоненту? И т.п.
Решение проблемы существует. Оно простое — если нужны стандарты, нужно их создать. Одна известная платформа устойчиво следует по пути открытых стандартов. Это — дорога в будущее. Но это тема отдельного разговора.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>Ты знаешь, что гайкой М6 ГОСТ №xxxxxxx можно прикрутить головку блока двигателя ВАЗ 2106 и клеммы аккумулятора любой Волги? Ключевое слово — ГОСТ. Проблема программной индустрии в том, что отсутствуют стандартизованные интерфейсы. Сколько существует в мире текстэдитов и сколько из них имеют одинаковые интерфейсы?
А знаешь ли что дюймовая гайка фиг подойдет к метрической?
LP>Так почему же автомобилестроение смогло выработать общепринятые стандарты, а программная индустрия — нет? Есть три причины, почему это происходит (то, что мне пришло пока в голову).
LP>1. В машиностроении несовместимость интерфейсов обходиться значительно дороже, чем в программной индустрии. Паттерн "Адаптер" все знают. И этот баян тоже:
LP>
Kotyabrа:
LP>- Как все в природе мудро устроено!
LP>Заметили? Ведь дырочки на шкурке у кошки именно там, где у кошки глазки!
LP>Torin:
LP>-Если б кошку писали программисты, глаза были бы на жопе, под кожей, а для передачи изображения использовалась бы система зеркал!
Профессионалы (Герман Гельмгольц) считают что херовато все сделано:
Если бы мне Господь бог поручил сделать глаза, я бы сделал их гораздо лучше, чем он.
LP>В машиностроении подобная "система зеркал" либо съест кучу материала, энергии, трудовых ресурсов, либо будет неприемлема в силу того, что требуемые характеристики изделия не будут обеспечены, либо это вообще невозможно сделать. Нет, в ИТ оверхед безусловно тоже присутствует (падение производительности как минимум), но он просто несопоставим.
LP>2. Вариативность интерфейсов. Сколькими способами можно скрепить узлы А и Б в единый узел С? Сколькими способами они могут взаимодействовать друг с другом, обеспечивая функциональность узла С? Вне зависимости от типа узлов, это число будет на порядки меньше количества возможных вариантов интерфейса простейшего текстэдита, которые можно набросать на салфетке за час.
LP>3. Отсутствие четких границ программных компонентов — в противоположность машинным узлам, чьи границы зачастую четко очерчены фундаментальными ограничениями (как правило физического характера). Разделение ответственностей между компонентами можно провести тысячами разных способов, каждый имеет свои преимущества и недостатки. Смотри каким толстым получился интерфейс нашего текстэдита, может перекинем вот эту парочку методов фонтрендереру? А может вынесем в отдельную компоненту? И т.п.
Вот поэтому и не проходят способы из материальной индустрии в софтовой, слишком материалы не сопоставимы.
LP>Решение проблемы существует. Оно простое — если нужны стандарты, нужно их создать. Одна известная платформа устойчиво следует по пути открытых стандартов. Это — дорога в будущее. Но это тема отдельного разговора.
И по этой дороге фирма создавшая эту платформу пришла прямиком к банкротству, ладно хоть другая ее купила
Были уже попытки и стандартизации и полного копирования всех процессов из того же автомобилестроения в разработку
программ, провалились со страшным треском гуглить "japan software factories"
Здравствуйте, FR, Вы писали:
FR>Профессионалы (Герман Гельмгольц) считают что херовато все сделано: FR>
FR>Если бы мне Господь бог поручил сделать глаза, я бы сделал их гораздо лучше, чем он.
Мы сравниваем с машиностроением, а не природой. То, что из бога хреновый инженер и так всем понятно.
FR>Вот поэтому и не проходят способы из материальной индустрии в софтовой, слишком материалы не сопоставимы.
Все работает, если основательно подходить к стандартизации.
LP>>Решение проблемы существует. Оно простое — если нужны стандарты, нужно их создать. Одна известная платформа устойчиво следует по пути открытых стандартов. Это — дорога в будущее. Но это тема отдельного разговора. FR>И по этой дороге фирма создавшая эту платформу пришла прямиком к банкротству, ладно хоть другая ее купила
Сан в момент банкротства имела минимальное отношение к java.
FR>Были уже попытки и стандартизации и полного копирования всех процессов из того же автомобилестроения в разработку FR>программ, провалились со страшным треском гуглить "japan software factories"
Стандартизация — это всегда хорошо. Хуже от этого не может стать по определению.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, FR, Вы писали: FR>Конечно стандартизация это хорошо, плохо то что ее тянут из отраслей которые по сути ничего общего с программированием FR>не имеют, ну и получают результат как у японцев.
Так не надо ее "тянуть из отраслей которые по сути ничего общего с программированием не имеют". Есть ведь много успешных примеров из IT.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>Так не надо ее "тянуть из отраслей которые по сути ничего общего с программированием не имеют". Есть ведь много успешных примеров из IT.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, LaPerouse, Вы писали:
LP>>Так не надо ее "тянуть из отраслей которые по сути ничего общего с программированием не имеют". Есть ведь много успешных примеров из IT. FR>Так ведь тянут, и будут тянуть в том числе и IT'шники, и в IT это тоже уже пустило корни, в параллельной ветке хорошая попытка объяснить почему http://www.rsdn.ru/forum/philosophy/3808250.1.aspx
