По идее в результате развития программизма как вида деятельности/науки мы (т.е. a software developer) должны иметь возможность
создавать всё более сложные системы. Ну т.е. если следовать хотя бы закону Мура то за час рабочего времени сейчас я должен по идее в разы более сложный или продуктивный код писать чем за тот же час но десять лет назад.
Но чего-то как-то не замечаю я в окружении себя такого прогресса. Во всяком случае в разы.
Есть ли надежды на какие-то технологии, приемы которые смогут если не экспоненциально то хотя бы в разы повысить выхлоп от программизма?
Скажем .NET или Java, теоретически managed системы позволяют создавать более сложные системы за счет
уменьшения проблем связанности больших систем (подсчет ссылок например). Но сам код-то приходится создавать все так же — руками, и оперировать приходится примерно теми же сущностями что и десять лет назад. Ну т.е. задача которая десять лет назад делалалсь на каком-нибудь FoxPro будет делаться (разрабатываться) примерно за тоже же время сейчас на, скажем, Java или C#.
Здравствуйте, 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#.
Здравствуйте, Cyberax, Вы писали:
CS>>Или я как-то это все упрощаю? C>Посмотри как работают в современных IDE для Java и C#. Реально код пишется где-то на порядок быстрее, чем на чистом С++. Рефакторинги, скорость компиляции, статические проверки и т.п.
Ну давай возьмем какую-нибудь задачу, скажем "Бухгалтерия малого преприятия". В FoxPro ты бы её писал тогда примерно столько же времени что и на Java сейчас. И скорость компиляции FoxPro или того же Clipper реально не сильно медленнее была. И оперировал ты все теми же сущностями, нет? Тогда я пользовался Multiedit который как IDE был уж точно не хуже чем VS или Eclipse.
Здравствуйте, c-smile, Вы писали:
CS>Ну давай возьмем какую-нибудь задачу, скажем "Бухгалтерия малого преприятия". В 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 из требований, то мы имеем конкретное опережение закона Мура по требованиям Т.о. софт является драйвером роста производительности систем.
Если руки золотые, не важно из какого места они растут.
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>Ну т.е. если следовать хотя бы закону Мура то за час рабочего времени сейчас я должен по идее в разы более сложный или продуктивный код писать чем за тот же час но десять лет назад.
К примеру, менее известный «второй закон Мура», введённый в 1998 году Юджином Мейераном, который гласит, что стоимость фабрик по производству микросхем экспоненциально возрастает с усложнением производимых микросхем. Так, стоимость фабрики, на которой корпорация Intel производила микросхемы динамической памяти ёмкостью 1 Кбит, составляла 4 млн. $, а оборудование по производству микропроцессора Pentium по 0,6-микронной технологии c 5,5 млн. транзисторов обошлось в 2 млрд. $. Стоимость же Fab32, завода по производству процессоров на базе 45-нм техпроцесса, составила 3 млрд. $
Здравствуйте, c-smile, Вы писали:
CS>Или я как-то это все упрощаю?
На мой взгляд, процесс идет, хоть и не в экспотенциальном смысле. Экспотенциальности мешает человек. Второй моск не вставишь, третью руку не присобачишь.
А вообще, развитие больше идет в специализации. Чем использовать FoxPro, бухгалтерию проще делать в 1С. Выйгрыш будет экспотенциальным, если еще найдешь нужные примеры/компоненты.(1С программированием ни занимался ни разу). Точно также лучше адаптировать ERP, чем тратить миллионы человекодней самоистязание.
Основное торможение — в человеке. Процесс специализации людёв — сильно тормозится.
Здравствуйте, c-smile, Вы писали:
CS>Скажем .NET или Java, теоретически managed системы позволяют создавать более сложные системы за счет CS>уменьшения проблем связанности больших систем (подсчет ссылок например). Но сам код-то приходится создавать все так же — руками, и оперировать приходится примерно теми же сущностями что и десять лет назад. Ну т.е. задача которая десять лет назад делалалсь на каком-нибудь FoxPro будет делаться (разрабатываться) примерно за тоже же время сейчас на, скажем, Java или C#.
Просто есть код и код.
Есть код, написание которого можно упростить путем всяких автоматических генераторов, решарперов, подсчета ссылок и прочего. Например, доступ к БД.
А есть код, написание которого таким образом упростить нельзя. Например, те же бухгалтерские формулы. Как там ни крути, а их не сгенерируешь автоматически, их придется выдирать из каких-то положений и директивных документов и вбивать вручную.
Ну а уж если речь идет о серьезных алгоритмах — то и тем более. Сомневаюсь, что какой-то автоматический генератор сгенерирует мне, допустим, код для распознавания образов. Тут не решарпер нужен, а математические алгоритмы и библиотеки. И писать придется самому, долго и упорно.
Так что все зависит от соотношения того или другого кода в проекте.
Здравствуйте, 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 раза больше кушает.
Так что в итоге считать прогрессом софта? Если сложность не является критерием, это кстати противоречит закону Мура. Ибо чем больше транзисторов, тем больше логики туда впихано, а объем логики это сложность и есть.
Если руки золотые, не важно из какого места они растут.
Здравствуйте, c-smile, Вы писали:
CS>Чего-то вот подумалось...
CS>По идее в результате развития программизма как вида деятельности/науки мы (т.е. a software developer) должны иметь возможность CS>создавать всё более сложные системы. Ну т.е. если следовать хотя бы закону Мура то за час рабочего времени сейчас я должен по идее в разы более сложный или продуктивный код писать чем за тот же час но десять лет назад.
Не обязательно. Я бы поставил на первое место надежность и эффективность ПО как главную цель прогресса. Я согласен ждать выхода продукта дольше, если получу софт, не вызывающий проблем.
CS>Но чего-то как-то не замечаю я в окружении себя такого прогресса. Во всяком случае в разы.
Не скажу за 10 лет. Но для меня переход от C к C++ позволяет работать продуктивней где-то в >=2 раза.
После С++ пока ничего существенно лучшего не придумали (если не считать С++11, но это не x2 а на 10-20 %).
CS>Есть ли надежды на какие-то технологии, приемы которые смогут если не экспоненциально то хотя бы в разы повысить выхлоп от программизма?
Нет, и вот почему. Софт существует в 2 видах. Исходный код и реализация (то, что образуется в результате компиляции/сборки). Эффективность языка программирования можно грубо оценить
его сжимающей способностью, т.е. отношением размера выхода к размеру входу. Т.е. более эффективный язык позволяет меньшим числом строк кода получить тот же по объёму ассемблерный выход.
Понятно, почему скажем С++ хорош -- в первую очередь из-за шаблонов.
Т.е. прогресс в языкостроении -- это прогресс в ужимании (точнее, в алгоритмах ужимания). А он не может быть Муровским. Кроме того, появление "верхних этажей" затрудняет использование языка -- требует больше ума от программиста. Фактически, мы уже С++ом переполнили буфер у среднестатистического индуса.
CS>Скажем .NET или Java, теоретически managed системы позволяют создавать более сложные системы за счет CS>уменьшения проблем связанности больших систем (подсчет ссылок например).
Нет, не позволяют. Управление памятью ортогонально "связности системы".
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, c-smile, Вы писали:
CS>>Ну т.е. если следовать хотя бы закону Мура то за час рабочего времени сейчас я должен по идее в разы более сложный или продуктивный код писать чем за тот же час но десять лет назад.
Т>
К примеру, менее известный «второй закон Мура», введённый в 1998 году Юджином Мейераном, который гласит, что стоимость фабрик по производству микросхем экспоненциально возрастает с усложнением производимых микросхем. Так, стоимость фабрики, на которой корпорация Intel производила микросхемы динамической памяти ёмкостью 1 Кбит, составляла 4 млн. $, а оборудование по производству микропроцессора Pentium по 0,6-микронной технологии c 5,5 млн. транзисторов обошлось в 2 млрд. $. Стоимость же Fab32, завода по производству процессоров на базе 45-нм техпроцесса, составила 3 млрд. $
