Интерпретируемый код.
От: Ka3a4oK  
Дата: 13.03.05 12:08
Оценка: 3 (2) :)
ЭЭ... с чего бы начать.

Вот был Саддам Хусейн — народ Ирака был угнетен и несчастен. Американцы решили: Саддам — это sux, мы знаем что делать, мы сделаем мир более безопасным. Я не хочу сказать, что Саддам — это герой и ваще отец иракского народа, но ... К чему я все это? Microsoft решила: небезопасный код-это sux, мы знаем что делать, сделаем программирование более безопасным. Конкретный вопросм для адептов .NET — какие задачи решает .NET ? Вот чего не было в Мире раньше, что .NET — это революция и счастье народам мира ? Какие теперь можно писать невиданные программы, о которых раньше человечество могло только мечтать ?
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
Re: Интерпретируемый код.
От: Хитрик Денис Россия RSDN
Дата: 13.03.05 13:02
Оценка: +3


Для себя сделал вывод, что дело не в том, КАКИЕ программы можно написать, а в том, КАК я их буду писать. Пока получается быстрее и проще выразить мысль на C#, чем на былых Delphi и С++ (в инкарнации Builder'а).
Правила нашего с вами форума.
Как правильно задавать вопросы. © 2001 by Eric S. Raymond; перевод: © 2002 Валерий Кравчук.
Re: Интерпретируемый код.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 13.03.05 13:52
Оценка: 64 (10) +8
Здравствуйте, Ka3a4oK, Вы писали:

KK>Конкретный вопросм для адептов .NET — какие задачи решает .NET ? Вот чего не было в Мире раньше, что .NET — это революция и счастье народам мира ? Какие теперь можно писать невиданные программы, о которых раньше человечество могло только мечтать ?


Я не адепт .NET, более того, я даже не специалист в .NET. Но все же позволю себе высказать, так сказать, взгляд со стороны.

Имхо, .NET является симметричным ответом Майкрософта Сану с его Java. А вот почему Майкрософт посчитала Java угрозой и почему решила выпустить .NET? Для того, чтобы не отстать от поезда "управляемых" языков. Более того, для того, чтобы стать локомотивом этого поезда. Но зачем? Что такого в этих управляемых языках и средах?

Имхо, происходит это из-за того, что скорость разработки оказывается важнее скорости работы результирующего кода. А чтобы повысить скорость разработки, нужно по максимуму освободить разработчика от ошибок, поиск и устранение которых на неуправляемых языках (читай C и C++) занимает много времени -- ошибки с памятью, неверными, повисшими и забытыми указателями. C++ программист может потратить день, два, три на то, чтобы хотя бы найти место, в котором приложение ломается. В той же Java это место сразу же указывается stack trace-ом. Возьмем тот же сборщик мусора. В C++ нужно потратить массу времени на этапе проектирования для того, чтобы определить политику передачи прав владения указателем между модулями. Чтобы указатель, созданный в одном модуле был гарантировано удален один и только один раз, причем именно тогда, когда он больше не нужен. При наличии сборки мусора такого вопроса даже не возникает.

Еще одна сторона медали в требуемом уровне знаний/умений для программирования на языках типа C++. Язык сам по себе трудный для изучения, но необходимость тчательно и скурпулезно отслеживать работу с памятью делает программирование на C++ еще сложнее. Для того, чтобы с начала изучения C++ человек дошел до уровня граммотного специалиста требуется много времени. Возможно, слишком много в современных условиях. Поэтому снятие с программиста большой части забот при использовании управляемого языка делает обучение этого программиста более быстрым делом. А это позволяет более просто задействовать в проекте большее количество разработчиков с не очень высоким уровнем подготовки.

И еще одна сторона. Актуальная в большей степени в Java. Это единый SDK для всех платформ. При программировании на C++ с переходом с одной платформы на другую приходится адаптироваться к новому API. Создание эффективных прослоек для C++, вероятно, слишком дорогая задача. По крайней мере Sun для Java сумел выпустить такой SDK. И Microsoft для .NET это сделал. А в итоге все это играет на сокращение времени разработки.

Я специально не затрагивал тему межъязыкового взаимодейтсвия на .NET (когда компонент на C# без проблем общается с компонентом на VB или Python). Время покажет, окажется ли это широко востребованным или нет.

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

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

Так же, мне кажется произойдет таки фрагментация в области программирования. Многие задачи (скрываемые за емким термином "корпоративные системы") неизбежно станут вотчиной управляемых языков. Собственно Java сейчас в этом сегменте и процветает. Так же будут и другие области, в которых управляемые языки не смогут использоваться в чистом виде (а их урезанные варианты будут неотличимы от неуправляемых языков, как в случае с J2ME). Например, игровые платформы, встраиваемые системы, системы реального времени и т.д.

Более того, разные области будут требовать знаний в разных областях. Например, C# программисту, разрабатывающему банковские приложения нужно будет знать, к примеру, SQL, XML, XPath, SOAP, ... В тоже время C++ программисту в области систем реального времени в телекоммуникациях -- CORBA, GSM-страндарты, различные специфические отраслевые протоколы. И со временем переход разработчика из одного направления в другое (скажем с C++ в C# или Java) будет все сложнее и сложнее. Поскольку нужно будет сменить не только язык, но и предметную область.

Поэтому .NET и Java может означать не столько появление новых, ранее невиданных приложений (хотя я вот не знаю, был ли такой класс приложений как Web Application Server до появления Java), сколько еще большее фрагментирование понятия "программирование". Как со строительством (зданий, мостов, тунеллей) или машиностроения (тяжелого или легкого).
... << RSDN@Home 1.1.4 beta 3 rev. 185>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: Интерпретируемый код.
От: Dog  
Дата: 14.03.05 10:04
Оценка:
KK>Вот был Саддам Хусейн — народ Ирака был угнетен и несчастен. Американцы решили: Саддам — это sux, мы знаем что делать, мы сделаем мир более безопасным. Я не хочу сказать, что Саддам — это герой и ваще отец иракского народа, но ... К чему я все это?
Какая то у вас не та история
Вот был такой народ евреи (это видимо программисты) — и был у этого народа проводник Моисей (Страуструп) , который 40 лет водил их по пустыне. Но тут пришёл Мессия (.NET) и всех спас. Вобщем господь с вами. Пишите с миром
Где-то между собакой и богом.
Re: Интерпретируемый код.
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.03.05 10:11
Оценка: 18 (4) +2
Здравствуйте, Ka3a4oK, Вы писали:

KK>Вот был Саддам Хусейн — народ Ирака был угнетен и несчастен. Американцы решили: Саддам — это sux, мы знаем что делать, мы сделаем мир более безопасным. Я не хочу сказать, что Саддам — это герой и ваще отец иракского народа, но ... К чему я все это? Microsoft решила: небезопасный код-это sux, мы знаем что делать, сделаем программирование более безопасным. Конкретный вопросм для адептов .NET — какие задачи решает .NET ? Вот чего не было в Мире раньше, что .NET — это революция и счастье народам мира ? Какие теперь можно писать невиданные программы, о которых раньше человечество могло только мечтать?


Теоритически — инкаких. Так же как теоритически теоритически языки высого уровня (С, Паскаль, С++ и т.п.) ничего не привнесли в создание ПО. Все что можно на С++ можно и на ассемблере и на машинных кодах. Более того точно такие же вопросы задавались во времена когда народ переходил от ассемблера к языкам высокого уровня.

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

Говорить же о том где можно применять управляемый код очень тяжело. Реально намного проще сказать где его пока что применять нельзя:
1. Код работающий не в режиме пользователя (например, нулевое кольцо защиты в NT, т.е. ядро ОС и драйверы).
2. Задачи требующие оптимизации на уровне ассемблерыных инструкций.

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

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

Производительность управляемого кода довольно высокая. Еще никому не удалось создать пример в котором лучшие С++ компиляторы при использовании одной и той же алгоритмической базы показали бы более чем в 2 раза лучший резальтат. К тому же в основном отсование менеджед-кода упирается в качество оптимизации джит-компиляторов. Причем ведутся очень серьезные работы по улучшению джит/пре-дит-компиляторов. И в ближайшие годы разница между скоростью управляемого и обычного кода будет сведена к нулю. А учитывая, что многие задачи упираются в некие внешние ресурсы, как то дисковая подсистема, память, 3D-акселератор и т.п., то и сегодня применение управляемого кода не сильно сказывается на производительности конечных продуктов. По крайней мере я еще не видел случая когда в управляемых продуктах серьезно использовался бы неуправляемый код для повышения скорости. Хотя... воможно видел. Авалон — новая GUI-подсистема Лонгхорна использует анменеджед-код помещенный в отдельные ДЛЛ-и для создания абстрактного слоя между управляемыми классами Авалона и DirectX-ом. Возможно это делается для уменьшения влияния интеропа на общую скорость Авалона. А возможно просто так проще взаимодействовать с низкоуровневыми срещствами ОС.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Интерпретируемый код.
От: Ka3a4oK  
Дата: 14.03.05 18:25
Оценка:
VD>Если же учесть, что нет необходимости создавать польностью управляемый код, т.е. управляемый код может использовать небольшие участки неуправляемого, то становится понятным, что управляемый код может использоваться в 99% случаев.

Почему тогда все не перешли Java и прочие скриптовые языки ? С++ давно уже должен умереть.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
Re[3]: Интерпретируемый код.
От: prVovik Россия  
Дата: 14.03.05 23:20
Оценка: :))
Здравствуйте, Ka3a4oK, Вы писали:

KK>Почему тогда все не перешли Java и прочие скриптовые языки ? С++ давно уже должен умереть.


Потомучто Sun — это не Microsoft.
... << RSDN@Home 1.1.4 @@subversion >>
лэт ми спик фром май харт
Re[3]: Интерпретируемый код.
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.03.05 22:50
Оценка:
Здравствуйте, Ka3a4oK, Вы писали:

KK>Почему тогда все не перешли Java и прочие скриптовые языки ? С++ давно уже должен умереть.


Ява стала тем чем она является сейчас пару лет назад. Дотнету вообще 2 с гаком года от роду. Погоди немного... и все будет. Те то первый перепрыгнет на более продуктивные технологии сорвет пару раз базнк, а там остальным надоест деньги просерать и тоже присоеденятся.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Интерпретируемый код.
От: McSeem2 США http://www.antigrain.com
Дата: 16.03.05 15:42
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Еще никому не удалось создать пример в котором лучшие С++ компиляторы при использовании одной и той же алгоритмической базы показали бы более чем в 2 раза лучший резальтат.


"Поздравляю вас, гражданин соврамши" (конец цитаты). http://www.rsdn.ru/article/dotnet/templates.xml
Автор(ы): Максим Шеманарев
Дата: 29.03.2003

Тесты insertion_sort дают разницу ровно в 2 раза, причем не на "лучшем компиляторе", а на самом обычном VC++ 7.1 с опциями оптимизации по умолчанию. А там, где много числодробительных операций, разница действительно невелика.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[3]: Интерпретируемый код.
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.03.05 00:32
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>"Поздравляю вас, гражданин соврамши" (конец цитаты). http://www.rsdn.ru/article/dotnet/templates.xml
Автор(ы): Максим Шеманарев
Дата: 29.03.2003

MS>Тесты insertion_sort дают разницу ровно в 2 раза, причем не на "лучшем компиляторе", а на самом обычном VC++ 7.1 с опциями оптимизации по умолчанию.

Гы, VC 7.1 это как раз лучший компилятор. Ну, один из лучших. Вот полюбуйся как С++Builde первому Шарпу сливал http://gzip.rsdn.ru/article/devtools/perftest3.xml
Автор(ы): Владислав Чистяков
(Quick sort/Bubble sort). Кстати, VC 7.0 был не далек по резултатам
Автор(ы): Владислав Чистяков
.

MS>А там, где много числодробительных операций, разница действительно невелика.


А, ну, значит то, что VC и GCC вырвались на подсчете PI — это глюк.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Интерпретируемый код.
От: GlebZ Россия  
Дата: 17.03.05 14:05
Оценка:
Здравствуйте, Ka3a4oK, Вы писали:

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


KK>Почему тогда все не перешли Java и прочие скриптовые языки ? С++ давно уже должен умереть.

Потому что персональное железо только подошло к тому уровню когда разница между С++ и компилированным байт-кодом не заметна. Особенно в области количества оперативной памяти.

С уважением, Gleb.
Re[4]: Интерпретируемый код.
От: Ligen Украина http://zone-of-ambiguity.blogspot.com/
Дата: 18.03.05 22:07
Оценка: +2
Здравствуйте, VladD2, Вы писали:

VD>Те то первый перепрыгнет на более продуктивные технологии сорвет пару раз базнк, а там остальным надоест деньги просерать и тоже присоеденятся.


Или наоборот, потратят "первые" туеву хучу денег в погоне за модными технологиями, г-н Гейтс заработает на этих "первых" еще пару миллиардов, и все забудут про .Нет через 4-5 лет с появлением новой модной технологии от Великой МС ))))
Viva el Junta Militar! Viva el Presidente!
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.