А что вообще есть .NET?

← →
vuk (2002-08-08 22:14) [40]

>Делают то они фактически тоже самое.
Не совсем. VM выполняет код, а не транслирует его в машинный. В Java есть обе технологии, а в .net - только JIT.

>Но идея с промежуточныи кодом была всё-таки впервые предложена
>Sun-ом в Java(хотя кто знает.
Идея промежуточного кода стара как мир.
Цитата из http://www.bytemag.ru/Article.asp?ID=60
_____________
Вообще говоря, идея преобразования исходного кода в компактный промежуточный внутренний код была реализована еще в 60-х гг. для ускорения выполнения Basic-программ в режиме интерпретации. Спустя примерно десять лет было предложено использовать промежуточный P-код (P — Portable или Pascal) для создания "Виртуального Паскаля" с целью минимизации затрат при разработке компиляторов Pascal для разных платформ. В середине 90-х гг. именно этот подход был реализован в технологии Java для обеспечения платформенной независимости.
_____________

← →
iZEN (2002-08-08 22:22) [41]

UCSD-Pascal был с p-кодом.

← →
vuk (2002-08-08 22:25) [42]

to iZEN:
Вот-вот, и я про то...

← →
Suntechnic (2002-08-08 22:28) [43]

>vuk © (08.08.02 22:14)
>Не совсем. VM выполняет код, а не транслирует его в машинный. В Java есть обе технологии, а в .net - только JIT.
Согласен.

Ну а то что идея не нова это очевидно. Я просто имел ввиду, что широкое распространение она получила именно с Java

← →
Malder (2002-08-09 00:17) [44]

Где можно прочитать без заумностей про технологию .NET ?

← →
iZEN (2002-08-09 00:59) [45]

/**Suntechnic © (08.08.02 21:32):
<..>Но господа! Для чего же придумали языки программирования типа Object Pascal, С++, Java? Для того чтобы скрыть всё это! Ведь на самом то деле всё равно всё будет оттранслированно в машинные коды, а ООП процессоров пока никто не придумал.<...>
*/

Отстали вы от жизни, друг мой.
ООП-процессоры были раньше и есть сейчас, работают они с байт-кодом также как и виртуальные машины с JIT-ом и имеют полное представление, с чем именно они работают (объекты, ссылки, виртуальные таблицы, методы, поля и т.д.). Кроме того, такие процессоры, как правило, обеспечивают низкоуровневую поддержку выполнения байт-кода (дополнительная система команд, легально "подмешанная" компилятором в сам байт-код).

Пример: http://www.ajile.com/ -- aJileSystems, разработчик встраиваемых устройств на основе java-микропроцессоров.

У Sun есть Java-ядро, которое лицензируется сторонними разработчиками микропроцессоров для использования в КПК.

← →
Suntechnic (2002-08-09 05:35) [46]

>iZEN (09.08.02 00:59)
Отстали вы от жизни, друг мой.
ООП-процессоры были раньше и есть сейчас, работают они с байт-кодом также как и виртуальные машины с JIT-ом и имеют полное представление, с чем именно они работают (объекты, ссылки, виртуальные таблицы, методы, поля и т.д.). Кроме того, такие процессоры, как правило, обеспечивают низкоуровневую поддержку выполнения байт-кода (дополнительная система команд, легально "подмешанная" компилятором в сам байт-код).

Пример: http://www.ajile.com/ -- aJileSystems, разработчик встраиваемых устройств на основе java-микропроцессоров.

У Sun есть Java-ядро, которое лицензируется сторонними разработчиками микропроцессоров для использования в КПК.

Да, наверное отстал. У вас наверное на ПК такой же ООП процессор стоит? Вот когда такой процессор будет стоять у вас на машине, а не на мифическом встраиваемом устройстве, заточенном под определённую цель, тогда и вернёмся к этому вопросу.

← →
shiva1 (2002-08-09 11:12) [47]

www.dotsite.ru
Все вопросы - туда......
И спорьте о вкусе апельсинов с теми, кто их ел..

← →
DiamondShark (2002-08-09 15:23) [48]

Да хрен с ними объектами, с поцессорами etc.

Вот что такое .НЕТ пока что мало кто сможет объяснить популярно, зато цели ее появления предельно прозрачны:

1. Раскрутить по-новой лохотрон ВЕБ-приложений
2. Снять очередной слой капусты с разработчиков, доверившихся мелкософту, в первую очередь с работающих на VC, как самых многочисленных. VB-шников тоже окучат.
3. Полностью изгнать жабу с винды.

Так что "Пролетарии всех стран! Соединяйтесь!"

← →
Пролетарий (2002-08-09 15:44) [49]

2DiamondShark ©
Но пасаран! :-)

← →
Malder (2002-08-09 18:48) [50]

Получается эта ваша .NET типа псевдокода на вижуал басике ? И какие плюсы ? То, что код будет занимать меньше места ? Зато он будет дольше выполнятся... В мелкософте считают, что скорость процессоров растет быстрее, чес емкость жестких дисков ?

← →
Anatoly Podgoretsky (2002-08-09 19:17) [51]

Не получается, технология тоньше
Язык Программирования -->
компилятор в в IL язык -->
оптимизирующий компилятор IL языка, привязанный к типу процессора и "операционной системе", запускаемый на этой платформе -->
native код (exe, elf, ...)

Так что при наличии компилятора и рантайм получаем независимость от ОС и типа процессора, тебе даже не надо знать где это будет запускаться.

Плюс единая среда разработки Visual Studio Net - для Дельфи будет выпущена в следующем года, сейчас есть для C#, VB, Cobol ну и еще где то три языка.

Ха счет большого рантайм приложения получается очень очень маленькие, Hello World менее 3 кб, что упращает загрузку их через Интернет, не зря же в технология называется .NET

Конечно это не все и возможно не все верно, пишу только на основе скудной, случайной информации, так что прошу строго не судить.

← →
Malder (2002-08-09 20:22) [52]

Все равно будет трансляция кода .NET в исполняемый код... а это по любому +время. Значит программы под .NET будут работать медленее. А насчет меньшего объема... неужели .NET будет НАСТОЛЬКО универсальной, что не надо для нее апдетов качать ?

← →
Suntechnic (2002-08-09 20:40) [53]

>Все равно будет трансляция кода .NET в исполняемый код... а это по любому +время. Значит программы под .NET будут работать медленее.

Когда-то во времена перехода с DOS на различные Windows тоже так говорили. Паралель конечно не прямая, но что-то в этом есть. Но парадокс заключается в том, что при нынешнем развити железа ты эту разницу просто не заметишь. Трансляция кода из IL в native код происходит только один раз: при запуске приложения. А дальше это обычный исполняемый модуль.

← →
Malder (2002-08-09 21:52) [54]

Неужели все это надо только из-за уменьшения размеров ???

Просто ахинея. Программы заметно меньше не станут, окромя "Привет, мир". Ведь в каждой серьезной программе куча своих, ИНДИВИДУАЛЬНЫХ ДАННЫХ. Ну вы правда хотите сказать, что откомпилив PHOTOSHOP (ну допустим он написан на DELPHI) его размер сильно уменьшится ? Да не фига. Весь VCL будет 1/100 частью от объема. Все остальное как поинмаете индивидуальные данные.

← →
Anatoly Podgoretsky (2002-08-09 22:17) [55]

Ну не приемлешь ы эту технологию, ну и что, ты сам по себе она сама по себе.

← →
vuk (2002-08-09 22:36) [56]

>Значит программы под .NET будут работать медленее.
Стартуют дольше. Потом скорость работы нормальная.

to Suntechnic:
>парадокс заключается в том, что при нынешнем развити железа ты
>эту разницу просто не заметишь
Тем не менее заметно.

>Трансляция кода из IL в native код происходит только один раз:
>при запуске приложения.
Трансляция из IL в код происходит по мере надобности непосредственно перед вызовом кода. То есть если, например, метод объекта в процессе работы ни разу не был вызван, то и транслирован в код он не будет. Подробнее об этом писали в MSDN Magazine.

to Malder:
>Неужели все это надо только из-за уменьшения размеров
Размер, если честно, здесь вообще ни при чем. Это будет справедливо только для небольших программ. Основное же назначение - инфраструктура выполнения управляемого кода и общая runtime библиотека...

Хотя... Смотрел тут демонстрационные приложения от .net компонентов производства DevExpress. Так вот, приложение, демонстрирующее работу компонента, по возможностям примерно эквивалентного QuantumGrid весит 45 килобайт, а весь каталог с демками (43 исполняемых файла, демонстрирующие 5 наборов компонентов)- чуть больше 2 мегабайт. Плюс к этому 2 с небольшим мегабайта dll-ок с самим кодом компонентов.

← →
y-soft (2002-08-09 22:51) [57]

Что-то много шума, а на конкретный вопрос человека никто так и не ответил

Вот небольшая обзорная статья:

http://www.ixbt.com/editorial/jini-vs-net.shtml

← →
y-soft (2002-08-09 23:00) [58]

А вот несколько лекций (в формате PowerPoint)

http://www.dotsite.spb.ru/Lectures/

← →
Suntechnic (2002-08-09 23:27) [59]

Трансляция из IL в код происходит по мере надобности непосредственно перед вызовом кода. То есть если, например, метод объекта в процессе работы ни разу не был вызван, то и транслирован в код он не будет. Подробнее об этом писали в MSDN Magazine.

Истории о том как это будет выполнятся я слышу начиная с бетта версии. Никто официально об этом пока не объявлял(может и объявлял, но мне встречать не удавалось). MSDN Magazine конечно авторитетный журнал, но хотелось бы всё-таки видеть ссылочку на официальный источник. Это не попытка развести флейм, просто естественное любопытство.

← →
Suntechnic (2002-08-09 23:33) [60]

>vuk © (09.08.02 22:36)
>>парадокс заключается в том, что при нынешнем развити железа ты
>>эту разницу просто не заметишь
>Тем не менее заметно.
Если вам приходилось наблюдать за тем как стартует Win 3.1 на 386-ом, то вы наверняка поймёте о чём это я...
Тем более, что к тому моменту как .NET приобретёт хоть мало-мальски вид сформировавшегося продукта мы скорее всего будем общаться здесь с помощью каких нибудь Pentium 6. Так что я бы на такую подробность внимания не обращал.

← →
vuk (2002-08-10 00:52) [61]

>MSDN Magazine конечно авторитетный журнал, но хотелось бы всё-
>таки видеть ссылочку на официальный источник.
Ну не знаю. Верить или не верить MSDN - Ваше личное дело. :o) Но я думаю, что на данный момент информации лучше этой по данному вопросу Вы не найдете, как-никак официальный источник информации от Microsoft...
Хотите - вот Вам ссылка на статью:
http://msdn.microsoft.com/msdnmag/issues/02/07/SharedSourceCLI/default.asp

В ней рассматривается работа SharedSource CLI. CLR работает похожим образом. Как происходит исполнение управляемого кода рассматривается в разделе Executing Managed Code. На Русском языке эта же статья есть в русской редакции MSDN Magazine.

>Если вам приходилось наблюдать за тем как стартует Win 3.1 на
>386-ом
Даже хуже. 3.0 на 286 и 2.0 на PIII :o)

← →
iZEN (2002-08-10 21:57) [62]

Для vuk © (09.08.02 22:36)

>>Значит программы под .NET будут работать медленее.
>Стартуют дольше. Потом скорость работы нормальная.

Аналогия с Java Runtime Environment: NetBeans IDE стартует за такое же время, что и Delphi6, но работает (меню, редактор) заметно быстрее.

>to Suntechnic:
>>парадокс заключается в том, что при нынешнем развити железа ты
>>эту разницу просто не заметишь
>Тем не менее заметно.

Иногда незаметно. В целом -- задержки заметны невооружённым глазом на слабых компах.

>>Трансляция кода из IL в native код происходит только один раз:
>>при запуске приложения.
>Трансляция из IL в код происходит по мере надобности
>непосредственно перед вызовом кода. То есть если, например, метод
>объекта в процессе работы ни разу не был вызван, то и
>транслирован в код он не будет. Подробнее об этом писали в MSDN
>Magazine.

В Java JIT работает над классом лишь тогда, когда он понадобится приложению.

>to Malder:
>>Неужели все это надо только из-за уменьшения размеров
>Размер, если честно, здесь вообще ни при чем. Это будет
>справедливо только для небольших программ. Основное же назначение
>- инфраструктура выполнения управляемого кода и общая runtime >библиотека...

Размер приложений будет меньше, так как среда исполнения богата библиотеками -- самому меньше придумывать. :))

>Хотя... Смотрел тут демонстрационные приложения от .net
>компонентов производства DevExpress. Так вот, приложение,
>демонстрирующее работу компонента, по возможностям примерно
>эквивалентного QuantumGrid весит 45 килобайт, а весь каталог с
>демками (43 исполняемых файла, демонстрирующие 5 наборов
>компонентов)- чуть больше 2 мегабайт. Плюс к этому 2 с небольшим
>мегабайта dll-ок с самим кодом компонентов.

Ну, это -- .Net.
Я для Java2 смотрел демки (из Sun J2SDK v.1.4.0):
\javasoft\jdk\demo\jfc\SwingSet2\SwingSet2.jar ~1.27Мбайт, показывает возможности Swing-наворотов;
\javasoft\jdk\demo\jfc\Java2D\Java2D.jar ~397кбайт, показывает возможности обработки 2D-графики в Java2, нехило.

Итоги.

Для Java2.
Средсва программирования и среда исполнения занимают от 100 до 150 МБайт на жёстком диске.
На собственном опыте:
-- необходимый минимум железа для разработчика -- PII/300МГц/128МбRAM/SVGA256;
-- необходимый минимум железа для пользователя -- PII/350МГц/64МбRAM/SVGA256;

Для .Net.
http://msdn.microsoft.com/netframework/productinfo/sysreq.asp
Средсва программирования и среда исполнения занимают от 370 до 600 МБайт на жёстком диске, кроме того, нужна система не ниже Windows2000, IE5.01(обязательно!), Microsoft Data Access Components 2.6(обязательно!);
-- необходимый минимум железа для разработчика -- PII/300МГц/256МбRAM/SVGA256;
-- необходимый минимум железа для пользователя -- Pentium 133/128МбRAM/SVGA256; :)) НЕ ВЕРЮ!

← →
vuk (2002-08-11 01:40) [63]

to iZEN:
>Для vuk
Мне это можете не рассказывать. Я и так в курсе, что технологии во многом концептуально похожи. :o) А размеры демонстрашек я приводил исключительно для того, чтобы можно было хотя бы примерно оценить размер приложений, которые активно используют возможности, которые не встроены в runtime библиотеки. Ведь здесь как раз и спрашивали насчет объема программ в .net

Если честно, то у .NET есть одина черта которая мне нравится - вся инфраструктура не нацелена, в отличие от Java, на один язык. Это дает возможность интегрировать в эту среду унаследованный код.

А про минимальные требования к железу у пользователя... Я даже не знаю как это и проверить... Ну нет под рукой такого железа... :o)

И еще. Я ни в коем разе не агитирую ни за .net ни против него, у меня его сейчас даже попинать путем времени нет. Это все просто размышления по поводу... :o)

А что вообще есть .NET? Найти похожие ветки