Linux-сообщество готовит ответ технологии Microsoft .NET

Смешно. Туфту очередную в новости запостили. Ну как может какой то ксимиан выпустить что нибудь подобное .Net ?

.NET еще по-моему в Микрософте не доработана до конца и ИМХО включает в себя говоря заумыми словами "программно-аппаратный комплекс", состоящий из множества вещей, в том числе и средств разработки.

Следует наверное почитать оригинальную статью,на ZDNet, в котором написано не "в понедельник выпустит проект Mono", а всего лишь его анонсирует.
http://www.zdnet.com/zdnn/stories/news/0,4586,5093689,00.html

Сейчас пойдет инфа с сайта Microsoft, прошу в мониторы не плеваться, они ваши:

Microsoft .NET включает:

Систему .NET Framework и инструментальные средства Visual Studio.NET √ средства, инструменты, спецификации и информационные материалы для построения и сопровождения гибких, надежных и масштабируемых деловых приложений, использующих Интернет/интранет/экстранет для взаимодействия с коллегами, клиентами и партнерами, обладающих привычными и понятными интерфейсами, способных работать с самыми различными устройствами. Используя Visual Studio.NET и Visual Studio for Applications, опираясь на .NET Framework и Windows.NET, можно самые сложные задачи решать быстрее, надежнее и эффективнее, чем когда-либо в прошлом.

Семейство корпоративных .NET серверов √ современная линейка корпоративных серверов, созданная, чтобы облегчить использование и интеграцию самого широкого круга деловых сервисов на основе веб-стандартов и технологий. Реализует самые современные представления об архитектуре информационных систем. Отвечает самым взыскательным запросам в области масштабирования, производительности, надежности и безопастности, удобства разработки и эксплуатации.

Службы .NET √ Building Block Services √ типовые "строительные блоки", позволяющие архитекторам корпоративных и общедоступных информационных сервисов сосредоточиться на своих специфических проблемах, а для решения стандартных задач (авторизация, персонализация и другие) использовать стандартные решения.

Программное обеспечение для устройств √ позволяет использовать для доступа в Интернет, связи с .NET-серверами и получения разнообразных услуг не только персональные компьютеры, но и сотовые телефоны и другие устройства.

Разнообразные рабочие среды √ на платформе .NET реализованы рабочие среды, являющиеся наиболее естественными и удобными для основных категорий пользователей:

информационные службы и сервисы MSN для самого широкого круга потребителей;


интегрированные деловые сервисы bCentral для предприятий малого и среднего бизнеса;


Office для работников компаний, учреждений и вообще для всех, кто создает и использует традиционные документы;


Visual Studio.NET для профессиональных разработчиков.

Где можно почитать описание .NET. Дайте кто-нибудь ссылку.

2 anonymous (*) (2001-07-06 17:39:06.0)

msdn.microsoft.com/net

Что-то уж больно много слов "стандартное решение". Любой здравомыслящий человек подумает и о другой стороне медальки:
РАЗ ЕСТЬ СТАНДАРТНОЕ РЕШЕНИЕ, ЗНАЧИТ И СПОСОБ ВЗЛОМА - СТАНДАРТНЫЙ.
Ха-Ха-Ха-ХА!!!!!
То бишь, любой "кул-хацкер", который слепит эксплойт для "программно-аппаратного комплекса .NET", мнгновенно становится абсолютным властителем информации всего мира...
А что? МНЕ НРАВИТСЯ!!! Так держать, макросаксные ублюдки!!!
Глядишь, я так и мировым диктатором стану! ;-))))

R00t - "Глядишь, я так и мировым диктатором стану! ;-))))", ага, и что ты будешь со всем этим добром делать? :)))

s/добром/дерьмом =)
так оно точнее будет.

Валек

> msdn.microsoft.com/net
Я кроме bla-bla-bla ничего там не нашел. Единственное определение:

"Microsoft .NET is an XML Web
services platform that will enable developers to create
programs that transcend device boundaries and fully
harness the connectivity of the Internet."

Ключевая фраза: that will enable developers to create programs
Точнее было бы: that will enable windoz developers to create programs
Что уже ближе к истине. Но поскольку других на msdn нет, то в-принципе все верно ;)

2anonymous (*) (2001-07-06 19:04:19.0)

Да не найти ничего про .Net на msdn... Пять с плюсом тебе.

Мелкософт со своей NET замкнут сам на себя, и сам-же себе противоречит. Типа, интеграция всего со всем, но имется в виду Windows + Windows. Вот только мир не только из Windows состоит. А для того чтобы интегрировать все со всем, существует технология CORBA и для GNOME она является родной. И технология, дествительно, позволяет соединить в одну кучу ранее несовметимое. Кстати, и виндовые приложения стороной не одойдены. Inprise в этой области много чего наделал, и брокеры у них под различные платформы имеются. А такая вещь как EJB от Sun чего стоит. Эта система вообще не зависит от платформы, и с CORBA дружит. Пусть себе мелкософт продолжает свою империю продвигать. Есть вполне реальные ей конкуренты, и очень сильные конкуренты, и не зашоренные форточками.

2vada: Если бы Вы прежде чем рассуждать на счет CORBA'ы еще бы и почитали по теме, глядишь узнали бы что DCOM не является чисто Виндосовской вещью и сузествует и для юникса (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvc60/html/...)

O, опять певец из хора появился. Где гамно - там и мухи.

> Да не найти ничего про .Net на msdn...
Так нашел же! Все верно написано: NET - это то, что позволит $M-программерам
писать сетевые программы. Куда уж ясней.

Опять Ogr показывает свою лезет со своими ссылками! Так ведь про CORBA никто ничего НЕ РАССУЖДАЛ. Так о чем базар?

Опять Ogr лезет со своими ссылками! Так ведь про CORBA никто ничего НЕ РАССУЖДАЛ. Так о чем базар?

2vada:
Твоя CORBA лесом идет, неудобная она , это вот и IBM признает,
а EJB действительно от платформы не зависят, но зависят от ЯЗЫКА , чтобы их прикрутить к проекту приходится всякие коннекты придумывать, задолбало, вот еще тут статью почитай:

http://www-106.ibm.com/developerworks/webservices/library/ws-arc3/

> Microsoft .NET включает... ...быстрее, надежнее и эффективнее, чем когда-либо в прошлом.
Я это с начала девяностых читаю:
ещё быстрее, надёжнее, эффективнее...;
ещё никогда не было так просто...;
теперь ещё проще...;
лучше чем когда либо...;

Надёжности от MS ждать глупо.
"Быстрота" падает, а требовательность к ресурсам растёт в геометрической прогрессии
эффективность? ну,ну :)
простота - "ну извините", что-то просто, что-то через Ж, остальное НИКАК

Ориентация на решения MS - удавка,
обрекать себя на дальнейшую несовместимость со стандартами
(напомню лишь некоторые "улучшения":
ASCII -> Windows-1251,
"расширения" HTML,
VBscript,
"дополнения к" Java,
Java-- + C-- = C#,
(MS) SQL, -- справедливости ради: расширениями к SQL грешат многие
// добавьте специй по вкусу
)

Можно, конечно, вспоинить десятки десятки (или сотни) войн проиграных MS
Но это тем более подтверждает тезис:
Ориентация на решения MS - есть зависимость, если хотите рабство
ну выучил ты VC, VBA, VB5 ... ВСЁ от MS - стал MSCE, MSxx_and_so_on
через год учись(покупай книги, решения, программы; сдавай небесплатные экзамены)
НАДО знать C#, VB.NET, получай какой-нибудь MSCE-2002...

Всё что связано с MS ассоциируется c: несовместимостью и ненадёжностью
и если бог не дал Вам способности учиться на чужих ошибках, Вперёд на грабли!

По теме:
зачем? Мигель сотоварищи...

2jellyfish: "ASCII -> Windows-1251"
Какое отношение CP1251 имеет к ASCII? KOI8 или там СP8666 понимаю, а ASCII нет. Или это просто для красного словца?
""расширения" HTML"
Не хуже чем тот же Нетскейп.
"VBscript"
Скрипт как скрипт или что perl в этом отношении что-то меняет?
"Java-- + C-- = C#"
Возьми книжку чтоль прочитай на счет C#, а потом будешь пытатся рассуждать...
"через год учись(покупай книги, решения, программы; сдавай небесплатные экзамены)"
Ааа понятно, один раз выучил, что 2+2=4, а дальше учить не чего не хочется. Кстати сдавать экзамены ни кто не заставляет.
"зачем? Мигель сотоварищи"
Чтоб пресса еще раз вспомнила по умирающему GNOME'у

Мне глядя на эту всю опенсорсную возню часто хочется сказать словами Крылова: "А вы, друзья, как не садитесь, все в музыканты не годитесь." Золотые слова. Самое интересное, что я пока не встречал линуксоида, который бы понимал во всей полноте, что такое .NET и насколько это глобальная штука. Вот и в Компьютерре бред какой-то написали. Написал им в форуме, что они бараны, удалили сообщение. Де Иказа тоже не понимает, т.к. начал какой-то бред нести насчет "ща мы тут быстро на коленке все налабаем на си и забодаем MS насмерть". Дот нет разрабатывается уже ТРИ С ПОЛОВИНОЙ ГОДА. Целенаправленно, упорно, под руководством умнейших людей в индустрии. А тут приходит Де Иказа и говорит, что типа он чиста пацан, а Microsoft против него сынки. Курям на смех.

Bluesman

ok. Так и обяъясни тогда нам, недостойным, что такое .NET, о светоч разума, блистающий в пустыне, Bluesman?

Привет, Ogr [доброе утро, или (где-то) вечер?]:
> ASCII -> Windows-1251
под ASCII, конечно, понималась cp866 от IBM, что в общем не совсем корректно,
ибо так именовалась самим Microsoft'ом ещё во времена 3.1 кодировка cp866
так что ASCII к Windows-1251 _никакого_ отношения не имеет.
Вопрос как раз в том что MS не стала соблюдать стандарты при переходе к Win 3.1,
наоборот сделала всё(на грани фола, но не более) для несовместимости DOS и Windows.
Последние 10-12 лет в Маркетинге(с большой буквы М) рынка ПО MS номер 1 без вопросов.
[Ближайшие тоже]

> Не хуже того же Нетскейп
раньше Нетскейп наверное хуже...
потом MS уж как-то сильно пытался "расширить"
и w3c пришлось со многим мириться - de facto, блин

> VBscript
конечно, не хуже/лучше JavaScript и не хуже/лучше PerlScript
но на тот момент JavaScript был тем самым "стандарт de facto"
MS хотела разрушить status quo (не слишком много латинского? )
не получилось, к счастью или нет.

> C#
в этом, согласен, не силён
очевидно, после разберательств c Sun, это замена Java(видимо вкупе с .Net)
но, как я понял, это C "без излишеств"[перевод релиза одним из журналов]
А книжку читать не хочу... зачем тратить НА это время

> Gnome, Meguel /etc
А что Gnome умирает?

resume:
"MS number one" в плане маркетинга, но зависить от кого либо - это дело вкуса, воспитания, цели в жизни
Но программы написаные 15-20 лет назад под Unix будут работать и через 20 лет
а написаные под Win98 под WinXP могут не работать...[3 года vs 30-40 лет]
выбор за Вами

2jellyfish: "наоборот сделала всё(на грани фола, но не более) для несовместимости DOS и Wind"
Мягко говоря MS во всей этой истории практически ни причем. Когда MS делал Windows она просто спросила девелопров из разных стран, а что Вы используете в качестве нац языковой раскладки, в случае с СССР это оказалась фирма ПараГРАФ, которая и дала эту кодировку.
"w3c пришлось со многим мириться - de facto"
Которые в свою очередь оказались не так уж и плохи. Вот скажем фирма Борланд в сове время ввело С++ ключевое слово protected и тоже на них ругались, а сейчас это полноценная часть языка.
"MS хотела разрушить status quo (не слишком много латинского? )
не получилось, к счастью или нет"
VBScript используется очень широко.
"очевидно, после разберательств c Sun, это замена Java(видимо вкупе с .Net) но, как я понял, это C "без излишеств"[перевод релиза одним из журналов] А книжку читать не хочу... зачем тратить НА это время"
Потому как в отличии от Java которая является собственностью САН'a, CLI является public domain cобственностью.
"А что Gnome умирает?"
Ну жизнью это называется, только весьма условно.
"Но программы написаные 15-20 лет назад под Unix будут работать и через 20 лет"
Те программы которыми *пользуются* живут от силы 5 лет. Что касается того же под виндовс, то программы для W3.11 перкрасно работают и в W2K, только с тех пор пользователям нужна куда большая функциональность.

Гыыы.. Огр :)))
>Те программы которыми *пользуются* живут от силы 5 лет.
Давно так не смеялся :))) Это наверное, под Windows так :))
В юниксах изменение программ идет эволюционным путем, а не как в Окнах, когда написанное сегоня не работает завтра :))

Кстати я долго ползал (еще пол года назад) по msdn, и так не нашел _внятного_ понятия "что такое .NET". Я понял что Майкрософт изобрела один (несколько?) новый язык, добавила средства для парсинга\работы с xml и еще кучу всяких протоколов. Но я не понимаю, почему такая шумиха вокруг .net? Точнее я понимаю.. все какрас для шумихи, вдолбить в мозги что .net это круто, и это супер-пупер новое.

Я тут читая постинги, вычитал что Bluesman знает, что такое .NET.
Если не трудно - объясни, чесное пионерское, хочеться узнать.

2Ogr (*) (2001-07-07 05:53:12.0):
>Вот скажем фирма Борланд в сове время ввело С++ ключевое слово
>protected и тоже на них ругались, а сейчас это полноценная часть языка.
Straustroupe давно читали в последний раз? У него это еще в авторском варианте было. И впредь попрошу изучать предварительно мптериал, о котором ведете рассуждение.

>VBScript используется очень широко
Где Вынь, то широко, но не более.
Он криво реализован на НЕвындовых платформах (если где и реализован), и поделом ему за это. JavaScript (не JScript) гораздо гармоничнее и понятнее (имхо).

>Те программы которыми *пользуются* живут от силы 5 лет.Тогда объясните эксплуатацию компьютеров и программ 30-летней давности до сих пор в том же MIT.

2 LogIN & others: Ладно, так уж и быть, поделюсь мудростью насчет дотнета. Итак господа, что же такое дот нет? Дотнет - это "зонтичный" термин, обьединяющий собой более 10 технологий. Для начала я их перечислю, с небольшими комментариями. Постараюсь попроще.
1. XML web services - позволяет сайтам предоставлять интерфейсы для использования приложениями или другими сайтами. Обмен данными идет по протоколу SOAP, сервисы описываются с помощью WSDL и регистрируются на UDDI (если хотите регистрировать, чтоб можно было найти).
2. Сервисы связи - позволяет приложениям не испытывать проблем общаясь друг с другом. Состоит из взаимно ортогональных вещей: каналов и форматеров. Каналы - это, собственно, каналы связи, как-то TCP, HTTP или DCOM (который по сути RPC). Форматеры - бинарный, XML, NDR (network data representation). Написать как новый канал, так и новый форматер - как два пальца об асфальт. Если вам нужно пускать межобъектные классификации через прокси, вы можете выбрать Binary over HTTP или XML over HTTP. Дальше додумывайте сами. Кстати, объекты могут себя передавать сами, вам на это напрягаться не надо (если писали сериализацию нормальную, когда разрабатывали классы).
3. Remoting - вводится 3 новых вида объектов:
 ╚Одноразовые╩ объекты √ те объекты, которые не хранят информации о состоянии (stateless) и вызываются лишь единожды. Хотелось бы подчеркнуть, что эти объекты не хранят состояния между вызовами объектов, поэтому для них легко организуется load balancing.
 Синглтоны (Singleton Objects) √ объекты, совместно используемые несколькими клиентами. Посему синглтоны должны хранить состояние между вызовами методов. Они используются тогда, когда необходимо совместно использовать данные между клиентами, или/и тогда вычислительные расходы на создание/удаление метода нежелательно высоки.
 Объекты активируемые клиентами √ механизм, очень похожий на COM. Клиент для создания объекта посылает запрос удаленному сервису (в COM таким сервисом является SCM), по которому на машине, где расположен сервер (компонент), создается объект указанного класса, а клиенту возвращается ссылка на удаленный объект. На клиенте создается прокси, через которую вызываются методы удаленного объекта. Объекты могут сохранять состояние между вызовами методов, но, в отличие от синглтонов, не предназначены для совместного использования своих данных между клиентами.
Это я из статьи своей копирую неопубликованной.

Мы продолжим после рекламной паузы.

Передача объектов. В .NET для передачи объектов между приложениями существует 3 метода:
 Передача объекта в качестве параметра метода
 Передача объекта в качестве возвращаемого значения
 Передача объекта при доступе к свойству объекта.
Передача может осуществляться как по значению (Marshal By Value), так и по ссылке (Marshal By Reference). В последнем случае в контексте приложения, куда передается объект, создается прокси, через который осуществляется доступ к свойствам и методам объекта, ссылка на который передана.
Время жизни. Помимо счета ссылок (как в COM) введено также понятие ╚длительности проката╩ (lease time). Длительность проката отсчитывается специальным счетчиком, при достижении которым нуля объект удаляется сборщиком мусора даже если на него еще есть ссылки. Длительность проката можно установить бесконечной, тогда все выглядит примерно как COM, т.е. объект удаляется (точнее, удаление объекта разрешается) при достижении нуля счетчиком ссылок. Счетчик ссылок, разумеется, имеет для сборщика мусора больший приоритет, чем lease time counter. Насколько я понял, понятие lease time применимо лишь к объектам, активируемым клиентами, потому что синглтоны не привязаны к клиенту, а одноразовые объекты помечаются на удаление сразу после использования (хотя я не вижу, почему бы не был возможен их пулинг; скорее всего, он и на самом деле будет возможен).
Хостинг удаленных объектов возможен тремя способами:
 Как .NET EXE или Managed Service.
 В рамках Internet Information Server, как web-сервисы. По умолчанию приложения, расположенные на IIS получают запросы через канал HTTP.
 В рамках компонентной инфраструктуры .NET, что позволяет использовать объектные сервисы COM+, как-то транзакции, пулинг и т.п.

Дальше поехали. В дотнет как интегральная часть входят 2 библиотеки компонентного программирования: Windows Forms и Web Forms. Windows forms позволяет легко и просто создавать эффективные приложения для windows пользуясь ЛЮБЫМ .net языком (о языках позже). Web Forms позволяет писать приложения для Web ровно таким же макаром, как пишутся RAD приложения для Windows, т.е. бросанием кнопок, назначением обработчиков событий, и, самое главное, написанием собственных компонентов. Код можно вставлять как в aspx файле, так и писать отдельно, в класс. Перед первым показом странички из нее создается .net assembly (понятие более широкое нежели exe или dll, т.к. может включать в себя НЕСКОЛЬКО файлов). Далее обращения на страничку переадресовываются сразу этой assembly, т.е. работает все со свирепой скоростью. Кроме того во всю эту петрушку встроены средства кэширования, позволяющие кэшировать целые куски страницы, вместо того, чтобы каждый раз генерировать их.

КОМПОНЕНТЫ. .NET упрощает и делает стандартным компонентное программирование под Windows. Т.е. даже те задачи, при решении которых ранее вы бы и не подумали о компонентах, теперь будут у вас такие мысли вызывать, что, безусловно, хорошо, ибо повышает code reuse. Справедливости ради следует сказать, что компонентное программирование и ранее широко использовалось под Windows, а Windows 2000 практически построена на COM, но написание COM компонентов было (и есть) занятием для сильных духом, т.к. у вас был выбор между простотой написания и размером и производительностью получаемых компонентов. Т.е. либо вы идете по пути с наименьшим сопротивлением (MFC, VB), и получаете слоноподобный компонент, либо используете ATL, которая практически ничего не упрощает в плане доступа к сервисам Windows, либо вообще используете чистый C++ и IDL. При этом вы получаете нерасширяемый конечным пользователем компонент, к которому еще нужно руководство по использованию, потому как другой tradeoff √ возможность эволюции компонента путем добавления новых интерфейсов √ чаще всего не вяжется с простотой использования и понимания. Пользователи зачастую просто ╚не видят леса за деревьями╩. Все эти проблемы решены введением поддержки компонентного программирования и грамотно написаными библиотеками.

Далее, мальчики и девочки.

COM.
Если вы думаете, что Microsoft теперь забудет о COM, то вы глубоко заблуждаетесь. В состав Visual Studio.NET войдут ATL 3.0 (местами в статьях и MSDN она называется ATL 7.0) и средства attributed programming, упрощающие написание COM компонентов (в частности, IDL файлы больше не нужны, все необходимые данные приводятся прямо в исходном коде с помощью атрибутов). Думается Windows будет и впредь строиться на COM, а средства .NET будут предоставлять (и уже предоставляют) удобные средства доступа к объектам COM. О том, насколько глубоко проник COM в Windows сейчас вы можете судить открыв вкладку Server Explorer в Visual Studio. Так, например, вы легко сможете узнать, какие процессы выполняются на удаленном компьютере и их параметры, причем смотреть вы их будете в окошке properties все того же VS, где вы устанавливаете свойства компонентов при визуальной разработке. Кроме того, сможете отсюда же посмотреть какие сервисы баз данных, web сервисы, ╚просто╩ сервисы доступны на машине. Доступна также такая вещь, как Management Data, о существовании которой я до VS.NET вообще ничего не слышал (SNMP не установлен). Эти данные содержат самую детальную информацию о компьютере и отдельных пользователях, которую вообще можно получить. Так, например, погрузившись на 6 или более уровней в глубину я узнал, что мой компьютер √ AT/AT compatible, что у меня не поддерживается infrared и что некий chassis bootup state равен 3.

⌠OPENSOURCE■
ILDASM, дизассемблер промежуточного языка, входящий в поставку .NET Framework позволяет вам получить полный (хотя и довольно низкоуровневый) доступ к коду приложений .NET. Вы видите, какие данные используются, какие методы и системные функции вызываются. Все это должно способствовать укреплению доверия к Closed Source ПО Microsoft и сторонних производителей. Впрочем, я думаю, что единственный выход для корпораций, продающих ПО с закрытым исходным кодом, состоит в учреждении независимых (возможно международных) аудирующих организаций и сертификации выпускаемого ими ПО в этих организациях на отсутствие разного рода бэкдоров и т.п. Здравомыслящему человеку, конечно, понятно, что корпорации вроде Microsoft абсолютно неинтересно встраивать в свое же ПО бэкдоры, т.к. помимо того, что этим можно безвозвратно испортить себе репутацию, их обнаружит первый же дотошный сетевой администратор со снифером, но в мире, как показывает опыт, не так много здравомыслящих людей, как принято считать.

LANGUAGE INTEROPERABILITY.
Тут Microsoft поступила как в истории с колумбовым яйцом (или гордиевым узлом, как кому больше нравится) создав некий промежуточный язык (Intermediate Language, IL), в который компилируют все .NET совместимые компиляторы. IL НИКОГДА не интерпретируется. Методы компилируются в машинный код под конкретный процессор по мере их вызова. Кроме того, можно компилировать Assemblies в машинный код при инсталляции на конкретную машину. На самом деле, основные assemblies устанавливаются уже прекомпилированными. Уже даже судя по скорости работы Visual Studio.NET на машине исполняется машинный код. Такая стратегия √ явный, и очень удачный выпад в сторону Java, в которой возможна лишь JIT компиляция и HotSpot оптимизация, что не может не замедлять (причем сильно, что бы там не говорили Java-biased тестеры) работы Java программ. В самом деле, зачем компилировать программу при каждой ее загрузке (да еще частями), если можно откомпилировать ее единожды при установке? Но даже в случае, если будет возможна только JIT компиляция, Microsoft будет в выигрыше, т.к. во-первых, IL специально предназначен для компиляции, а во-вторых, Java VM и JIT компилятор от Microsoft изначально славились своим быстродействием, а заимствования кода оттуда, я думаю, довольно значительны. Соль здесь, однако, не только в потенциальной независимости программ от железа (очевидна стратегия на создание ПО портабельного на не-Intel и 64-битные Intel процессоры), хотя это было бы, безусловно, major breakthrough . Соль в том, что всю информацию о типах данных .NET совместимые компиляторы берут из IL библиотек , что и является краеугольным камнем языковой прозрачности. Таким образом, разработчику, по большому счету, все равно на каком языке была изначально написана та или иная библиотека. Языковой overhead отсутствует. Пока я слышал о поддержке, как минимум, C++, C#, VisualBasic.NET (который-таки стал полноценным языком), Perl, Python, JScript, Eiffel, Smalltalk и COBOL (не улыбайтесь, кое-кто готов отдать большие деньги, чтобы мигрировать со старых мэйнфреймов с ПО на COBOL). В релизе заявлены около 30 поддерживаемых языков, но я не думаю, что все они будут идти в поставке. Большинство из этих 30 будет поддерживаться сторонними производителями .NET √ совместимых компиляторов. Microsoft же, по некоторым данным, ограничится VB.NET, C++, C# и JScript. Сомневаюсь, правда, что все языки будут в рамках этой модели обладать равными возможностями, но лично для меня это не критично, потому что MS создала новый язык, который должен устроить всех, начиная с новичков и заканчивая ╚монстрами╩. Язык этот √ C#.

C#.
Читается √ ╚си шарп╩. Язык весьма похож на Java, но присмотревшись, понимаешь, что от Java у него есть масса удобных и нужных отличий, причем некоторых из них в Java не могло быть уже даже из идеологических соображений.

Чем похоже на Java.
Вот уж что сразу бросается в глаза, так это синтаксис. Классы в C# объявляются очень похожим на Java образом. Кроме того, классы, как и в Java могут быть абстрактными и финальными (или sealed). Объект абстрактного класса нельзя создать, а от объекта финального класса нельзя наследовать. Есть также интерфейсы √ определения наборов абстрактных методов, которые наследующий класс должен реализовать. Так же как и в Java, булев тип напрямую не конвертируется в другие типы, а булевы значения являются ключевыми словами языка. Очень похож на Java класс Object √ базовый для всех прочих классов. Кроме того, от Java взяты сборка мусора (это общее требование для всех .NET языков) и неизменяемость (immutability) строк. Если чего забыл √ не обессудьте, я не великий специалист по Java. В общем, похожесть языка на Java и возможность использования некоторых возможностей C++ (см. ниже) должны переманить большое количество Java-разработчиков на C#, а обещаемая программа JUMP (Java User Migration Path), предполагающая средства конвертации Java-проектов должна сделать относительно безболезненным переход на технологии .NET для корпоративных пользователей. Они нынче очень хотят XML-based технологий и web-сервисов, а Microsoft здесь впереди планеты всей.

Чем похоже на C и C++.
Компилируемый язык (с оговорками, но об этом ниже). На выходе √ *.exe или *.dll. Есть структуры, но в отличие от C++ они не поддерживают наследование и отличаются от классов коренным образом. Объекты классов задаются ссылками (by reference), в то время как структуры данных √ значениями (by value). Так же они и передаются, скажем, в вызовы функций, либо при удаленном вызове методов. В то же время, структуры могут реализовывать интерфейсы.
Есть препроцессор, что позволяет выполнять условную компиляцию и прочие штучки, к которым привыкли C/C++ программисты, и я в их числе. Поддерживаются следующие директивы:
#define
#undef
#if, elif, else, endif
#warning
#error
#line
Обратите внимание, что директивы #include среди них нет. Кроме всего прочего возможна перегрузка некоторых операторов. Перегружать можно операторы:
Унарные: +, -, ++, --, !, ~, true, false
Бинарные: +, -, *, /, %, &, |, ==, !=, <<, >>, <, <=, >, >=
Оператор присваивания перегружать нельзя.

Что нового.
Нового очень много. Порой, читая некоторые из пунктов спецификации C# просто удивляешься, как это никому не пришло в голову ввести эти features в качестве стандартных в какой-нибудь другой язык. Итак, что же в C# нового?
Фундаментальные типы данных. C# предоставляет следующие фундаментальные типы данных: sbyte, short, int, long, byte, ushort, uint, ulong, float, double, bool, char, decimal. Нетрудно заметить, что для целочисленных типов имеются unsigned версии (какой, интересно, умник придумал, что их не должно быть в Java?). Char √ содержит 16 битный символ стандарта UNICODE. Совершенно новым является тип decimal, предназначенный главным образом для финансовых приложений. Переменная этого типа может содержать десятичное число, имеющее до 28 значащих разрядов. Строки, так же как и в Java, являются неизменяемыми (immutable), что означает, что при операциях над строками они не меняют ни свою длину, ни свое содержимое. Строки более не являются массивами символов, как в C++.
Широкое использование пространств имен. В C# использование namespace не является чем-то привнесенным, как в C++. Пространства имен являются интегральной и очень нужной составляющей языка. Кроме того, пространства имен являются иерархическими, и для них можно определять псевдонимы, чтобы удобнее было пользоваться. Этот механизм напоминает механизм пакетов Java.
Свойства. В ответ на введение этого хочется только сказать НАКОНЕЦ-ТО! То, что у Borland присутствует в качестве нестандартных расширений к стандартным языкам, теперь будет реализовано в стандартном языке, да причем на редкость элегантно.
Типичное определение свойства выглядит так:
public class Button: Control
{
private string caption;
public string Caption {
get {
return caption;
}
set {
caption = value;
Repaint();
}
}
}
Виртуальные методы и overriding. Прежде чем тот или иной метод можно будет переопределить, он должен быть объявлен как virtual, так же как в С++. Хорошее feature для исключения случайного переопределения методов. Замечу, что в Java ситуация обратная и методы по определению виртуальные, если не объявлены как final. Почему в Java было решено сделать так, я не понимаю. Виртуальные методы вызываются гораздо медленнее невиртуальных.
Делегирование. Делегирование, это типичный сценарий, когда один объект пользуется методами другого объекта для выполнения тех или иных задач, пользуясь ссылками (или, что примерно то же, указателями) на эти методы. Обратите внимание, что ссылки в этом случае именно на методы, а не на глобальные функции, иначе все было бы тривиально. Т.е. вызываться должны методы конкретного объекта, для работы с данными этого объекта. Делегирование чаще всего используется в компонентном программировании, чтобы избежать наследования. Типичное его применение √ реакция на события, возбуждаемые объектом. В C# возможно не просто делегирование, как, скажем, в Delphi или C++ Builder, но multicast делегирование, когда реакцией на вызов делегата будет вызов методов нескольких объектов, возможно разных классов. Класс объекта здесь не имеет абсолютно никакого значения. Ранее это было стандартной возможностью COM events, но я никогда не видел, чтобы ей кто-нибудь пользовался, и не знаю, насколько она была работоспособна.
События (Events). Построены на делегировании, а посему могут быть multicast. Красиво сделано ╚прицепление╩ обработчика события к тому или иному событию (делегату). Выполняется это оператором +=. Удаление из этого списка выполняется, как нетрудно догадаться, оператором -=. То, что программисту класса не нужно задумываться о том, есть ли у того или иного делегата обработчики, по-моему, прекрасно. В Delphi, например, если вы не хотели, чтобы то или иное событие впредь обрабатывалось тем или иным методом, вы должны были, во-первых, присвоить значение nil делегату, а во-вторых, при вызове делегата каждый раз проверять, не равен ли он nil.
Индексеры. Индексеры (indexers) схожи с properties, и, по сути, являются свойствами, выглядящими снаружи как массивы. В качестве индекса не обязательно выступают значения типа int, индексом может быть и, например, string, что должно облегчить и сделать более естественным программирование хэшей (вот за что я люблю PHP √ так это за хэши). Возможно назначение ╚индексера по умолчанию╩ для класса. Этот индексер используется, когда квадратные скобки доступа к массиву идут сразу за переменной, ссылающейся на объект класса, без указания конкретного индексера. Строго говоря, описание индексера по умолчанию не позволяет указать его иначе даже синтаксически.
Атрибуты. Атрибуты √ это свойства кода, доступные во время выполнения программы. В С# можно определять собственные атрибуты, например описания классов, или ссылки на файл либо URL онлайновой помощи. Думается, именно на этом механизме построена динамическая помощь в VisualStudio.NET. По мере набора вами исходного кода непрерывно обновляется информация в маленьком окошке динамической помощи. Там вы можете найти набор гиперссылок на документацию, относящихся к компоненту или классу, с которым вы в данный момент имеете дело. Кроме того, механизм атрибутов широко используется в ASP.NET.
Unsafe code. Тем, кто любит возможность выбора, понравится возможность использовать в C# арифметику указателей. В то же время введение такой возможности не будет создавать дополнительной головной боли, т.к. все участки, где используется unsafe код обязательно помечаются, а в противном случае просто не компилируются.

В отличие от Java язык С# сейчас проходит процедуру стандартизации, что не может не породить реализаций компилятора сторонними производителями. Стандартизацию проходит и Common Language Runtime, что при великолепном встроенном remoting позволяет надеяться не только на interhardware interoperability, но и на реализации совместимого ПО на других софтверных платформах (UNIX, VMS, Linux, КПК и, возможно, мэйнфреймы). Такие работы уже ведутся, в том числе и Open Source сообщества, правда у последнего они как всегда облечены в благородные рамки борьбы с Microsoft.

Тут был целый ряд картинок, но я думаю и без них будет понятно.

DLL HELL И VERSIONING.
Вам, наверное, знаком следующий сценарий: вы устанавливаете новую версию приложения и одно или несколько других приложений, установленных ранее, перестают работать. Это происходит (хотя, к счастью, довольно редко) потому, что новое приложение заменило более старую версию совместно используемой DLL более новой, бинарно не совместимой со старой. На настоящий момент не существует способа привязать ваше приложение к какой-либо конкретной версии DLL а также распознавать и хранить совместно разные версии одной и той же DLL. Не существует также возможности идентификации аутентичности DLL, ее цифровой подписи, и формального стандартного способа указания того, совместима данная конкретная DLL бинарно с более старой версией или нет. Все эти проблемы призвана решить .NET.
Разработчики .NET Framework исходили из 5 положений, а именно:
1. Приложения должны описывать сами себя (be self-describing), что устраняет зависимость от реестра и делает тривиальными инсталляцию и репликацию приложений.
2. Необходим жесткий, встроенный в систему механизм версий (versioning).
3. Приложения должны ╚помнить╩ последнюю рабочую конфигурацию, чтобы не возникало проблем при установке несовместимых компонентов или их сочетаний.
4. Должны быть возможны side-by-side инсталляции компонентов, а также возможность выбора конкретной версии компонента. На одной машине может быть установлено даже несколько версий самого framework.
5. Необходим механизм изоляции приложений, чтобы установленное приложение не могло быть повреждено установкой или работой другого приложения.
Для решения всех этих проблем были созданы assemblies (сборки). Именно из сборок, собственно, и состоит .NET Framework. Сборка состоит из dll или exe, содержащих, помимо кода, еще и метаданные сборки, а также других dll (модулей) и ресурсов. Все эти dll и ресурсы указаны в метаданных наряду с криптографическими хэшами их содержимого на момент сборки assembly, который проверяются при выполнении для того, чтобы удостовериться в целостности сборки. Кроме того, в сборках ╚зашита╩ информация о правах доступа, необходимых для их исполнения.
Довольно слов, возьмем любую сборку (BTW, приложения √ это тоже сборки) и проинспектируем ее с помощью ILDASM. Пусть это будет сборка System.XML.dll. В ILDASM она будет выглядеть следующим образом:

Обратите внимание на элемент MANIFEST. Манифест содержит в себе:
1. Идентифицирующую информацию (имя, номер версии, культуру).
2. Список файлов, составляющих сборку, с криптографическими хэшами, позволяющими верифицировать подлинность.
3. Список других сборок, от которых зависит текущая сборка, с номерами версий и криптографическими хэшами.
4. Список запрашиваемых привилегий, состоящий из 3 частей:
a. Привилегии, без которых сборка не работает вообще.
b. Привилегии, без которых сборка работает, но имеет ограниченную функциональность.
c. Привилегии, которые разработчик сборки запрещает ей давать.
Как выглядит развернутый манифест, можно посмотреть здесь.
Ниже полностью описываются типы данных, методы и данные классов, входящих в assembly. Полный дамп, например, сборки Microsoft.VisualStudio.VC.dll выглядит следующим образом. Это самый полный возможный дамп в ASCI формате. Формат дампа по умолчанию √ UTF-8. Как видите, ╚все по честному╩, вы видите все, что происходит в этой сборке. Это, правда, создает проблемы иного рода, ибо такая открытость делает тривиальным reverse engineering.
Рассмотрим теперь механизм версий и совместное использование сборок. С COM компонентами ситуация выглядела следующим образом. Компонент, устанавливаемый в систему, использовался совместно по умолчанию (ибо прописывался в реестр и через реестр же задействовался). Не было возможности иметь в системе несколько версий компонентов и привязывать приложение к определенной версии. Не было также возможности не использовать СОМ компонент совместно. В рамках .NET решение о том, использовать ли компонент совместно, принимаете вы сами. Мало того, для того, чтобы сборку можно было использовать совместно, она обязана удовлетворять дополнительным требованиям, как-то:
1. Допускать возможность мультиверсионной (side-by-side) инсталляции, чтобы в разных приложениях, или даже в контексте одного приложения, могли использоваться несколько разных версий одной и той же сборки.
2. Обладать глобально уникальным в рамках системы именем.
Таким образом, в .NET существует 2 вида сборок. Это сборки приложений (application-private assemblies), и совместно используемые (shared) сборки. С первыми все более или менее понятно. Находятся эти сборки в директории приложения или в поддиректории этой директории. CLR находит их с помощью процесса зондирования (probing) или, проще, нахождения файлов, которые указаны в манифесте приложения. Со вторыми же сложнее. Давайте представим себе следующий сценарий. Вы выпустили первую версию компонента Calculator. Как разработчик, вы хотели бы иметь гарантию от того, что какой-нибудь другой разработчик не сможет создать версию компонента, которая вашим приложением будет восприниматься как следующая версия вашего компонента. Для этого в .NET реализован механизм защиты имен, о котором чуть позже.
Совместно используемые сборки хранятся в хранилище сборок (assembly store). Установка сборки в хранилище выполняется только пользователем с административными правами. В хранилище сборок могут одновременно храниться несколько версий компонента. Чтобы не хранить там каждую подверсию в .NET принята специальная политика именования версий, о которой тоже чуть ниже. Т.к. у меня в assembly store находятся всего 3 (PreJit!) сборки, причем все с разными именами, приведу картинку из MSDN, говорящую сама за себя:


Рассмотрим теперь схему именования для публичных имен (она же защита имен). Эта схема реализована при помощи криптографии на публичных ключах (из манифеста похоже, что RSA). Защита имен преследует 3 цели:
1. Глобальная уникальность имен сборок.
2. Предотвращение установки в систему подложного компонента с тем же именем (name spoofing).
3. Идентификация поставщика сборки при ссылке на нее.
Для того чтобы решить все эти задачи, разработчик (или даже скорее вендор) генерирует пару ключей, и предоставляет всем желающим публичный ключ. Публичный ключ также записывается в манифесте сборки и является частью ее идентификационной информации. Этим обеспечивается глобальная уникальность имени. Совместно используемая сборка подписывается закрытым ключом.
При использовании сборки работает следующая двухшаговая схема. Электронная подпись проверяется при установке в хранилище сборок (можно, впрочем, проверить подпись и в ином случае). Это позволяет быть уверенным в том, что сборка не была изменена с момента подписи ее закрытым ключом. Далее, при задействовании сборки сравниваются между собой открытые ключи в манифесте, из которого на эту сборку была ссылка и в самой сборке. Если ключи совпадают, то сборка считается соответствующей приложению и загружается.
Обратимся теперь к политике именования версий. Как уже было сказано, в манифесте помимо имен сборок, используемых приложением или сборкой, указания вендоров и криптографических хэшей, указываются также номера версий сборок, используемые им (ей). Часто бывает необходимо привязать приложение к другой версии сборки (в которой, например, исправлены ошибки), либо запретить использование той или иной версии сборки вообще (в случае, например, если в этой сборке обнаружена ошибка, влияющая на безопасность). .NET Framework предоставляет гибкость в плане привязки к конкретным версиям сборок.
Номер версии .NET сборки состоит из четырех частей. Две старшие части представляют собой major и minor номера версий. Две младшие √ номера билда и ревизии. Сборка считается бинарно совместимой по умолчанию, если неизменны номера версий, т.е. 2 старших значения. Номера билда и ревизии меняются, например, у bugfix (или, как их называют в Microsoft QFE √ quick fix edition) релизов сборок. Таким образом, по умолчанию, если ваше приложение собрано с использованием assembly версии 1.0.0.0, а во время выполнения найдена версия 1.0.1.1, то будет использована именно она.
Рассмотрим теперь сценарий, когда приложение после установки исправлений отказывается работать. В этом случае вы можете переопределить политику QFE версий по умолчанию вашей собственной, либо вообще ее отключить, для какой-то определенной сборки. Для этого используется тэг <BindingPolicy> в конфигурационном файле. Кроме того, возможен ⌠Safe mode■ (⌠Run as built■) √ режим, при котором приложение использует только те версии сборок, с которыми оно слинковано.
Механизм политики версий при работе приложения работает в 4 шага:
1. Просмотреть файлы конфигурации приложения. Если, например, приложение слинковано со сборкой версии 1.0.0.1, а в конфигурационном файле явно указано работать со сборкой версии 2.1.4.32, то приложение будет работать именно с ней.
2. Исследовать директорию и поддиректории приложения на предмет нахождения подходящей сборки. ╚Подходящей╩, означает с совпадающими старшим и младшим номерами версии (если QFE политики не запрещены).
3. Вне зависимости от того, найдена или не найдена подходящая сборка, запрашивается глобальное хранилище сборок на предмет последней QFE сборки. Т.е. администратор может привязать приложения к тем bugfix сборкам, которые должны использовать они все.
4. Проверяется конфигурационный файл администратора, в котором можно переопределить любые пользовательские установки относительно того, какие версии сборок использовать.

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

Ну че, ребят, вам продолжить или хватит? Я забодался мальца. :0) Понимаете теперь, насколько смешно и глупо выглядит ДеИказа для тех, кто понимает о чем речь? Ба, да он целый КЛОН НОРТОН КОММАНДЕРА написал! Кул хацкер херов.

Bluesman

В первом моем постинге - межобъектные _коммуникации_. Нет, все-таки хорошее пивко Foster's!

Bluesman

To Bluesman:

Найди ка мне ссылочку, где Мигель хаял .Net? Наоборот, в одном из своих интервью он приветствовал .Net! Прежде чем хаять его сначала сделай хотя бы половину того, что сделал этот парень, а потом уж пиписькой меряйся. А то сидишь тут, попиваешь пиво, да копируешь через клипборд статьи из компьютерных журнальчиков.

А я говорил, что он его хаял? Не буду я писать половину нортон коммандера. Это, извините, сделано уже неоднократно, а потому писать еще один - интеллектуальная мастурбация.

Bluesman

2 alexros: Кстати, не из журнальчиков. Статья - моя. Нигде не опубликована. Можете заняться плагиатом, пока не поздно. Хотя буду преследовать по закону, однозначно. Интеллектуальная собственность вам - не хер собачий.

Bluesman

To Bluesman:

Наконец прочитал. И что ты этим хотел сказать? Ну ладно, только из уважения к потраченному тобой времени в форуме пользователей Linux, объясню где ты был не прав: 1. Ты начал с подробного описания низкоуровневых "новведений" .Net. Хотя по большей это есть в Java2EE.

2. Далее. Очень интересно твое восторженное описание поддержки COM в .Net. Я так понял, что до появления .Net технология COM можно было пользоваться с большим трудом - "написание COM компонентов было (и есть) занятием для сильных духом". Странно, технологии уже 3-4 года (на абсолютную точность не претендую), а до сих пор, оказывается, ей можно было пользоваться с большим трудом. И вот, наконец, не прошло и полвека и появляется .Net, который точно решит все ваши проблемы с COM. Кстати, точно такие высказывания были несколько лет назад, только вместо .Net использовали COM. Вообщем, в стиле мелкософта, вбросил сырую технологию, после массированной рекламной компании, а потом через пару лет говорит, что оказывается, чтобы этой технологией было удобно пользоваться, ждите другую технологию. И так можно до бесконечности - COM, COM+, .NET, .NET+ и т.д.

3. Глобальность. Технология .Net НЕ ЯВЛЯЕТСЯ глобальной, так как еще нигде не используется! Пока мелкософт ЗАЯВЛЯЕТ о том что .Net будет глобален. Но между "заявляет" и "является" огромная пропасть. А глобальной компонентной архитектурой для создания распределенных приложений является EJB. Является, потому что реально, а не на бумаге, существует и активно внедряется. Примеров тому не мало. Кстати, EJB нашла применение во многих компаниях из Fortune500, а .Net лишь только предстоит!

4. Меня порадовало большое количество слов "Java" в твоей статье, особено в самом конце. Значит Java, действительно, является гвоздем в заднице мелкософта. А С# всего лишь язык, не более. Подумаешь, Хейделберг засунул в него пару фитч, которых нет в Java. Кстати, Java эволюционизирует, доказательство - включение новых функциональностей в синтаксис языка, что было объявлено на JavaOne.

5. Ту часть статьи, где упоминается C# и очень большое употребление слова "Java", ты явно слямзил из мелкософтовских агиток. Так как явно, чтобы написать это требовалось знание Java, а ты явно в нем не силен.

Заключение: К сожалению компания мелкософт своей политикой породила огромное стадо баранов-последователей, которые смотрят мелкософту только в рот и послушно движутся только в определенном этой компанией направлении. Они не в состоянии посмотреть направо и налево, чтобы осознать, что "новейшие технологии" уже активно используются неподмелкософтовскими компаниями. Печально, но это реальный факт. Кстати, Bluesman, не смотря на всю предвзятость твоей неопубликованной статьи, по моему, у тебя еще есть шанс вырваться из этого стада баранов. Только подходи ко всему творчески: прежде чем превозносить .Net и С# изучи альтернативы. А они есть, поверь. Только надо вынуть из глаз мелкософтовские контактные линзы и повертеть головой по сторонам.

Хм... Впервые вижу описание архитектуры .NET не состоящее почти целиком из слов "лучший", "самый новый" и пр. ;) В целом выглядит не плохо, хотя сходу видны несколько мест, которые еще послужат причиной траха (особенно это относится к системе версионинга). В целом это может даже будет работать, хотя наверное не сразу, уж больно монстроидальная система. CORBA и Ко тоже монсторидальная. И вобще половина инфраструктуры .NET станет не нужна, если производители решатся распространять исходный код вместе с приложениями, а другая половина станет гораздо стройнее и логически чище (IMHO). Кроме того, современные UNIX системы вполне могут решать те же задачи что и .NET, не прибегая к бессмысленным наворотам. Pasha.K

> Понимаете теперь, насколько смешно и глупо
> выглядит ДеИказа для тех, кто понимает о чем речь?

Нет, мы теперь понимаем, в каких ужасных условиях приходилось работать
бедному программеру на винде. А сейчас ему будет много лучше. А уж сколько
дырищ в безопасности появится... Но за все надо платить ;)

Честно говоря, я так и не нашел ни одного преимущества/нововведения NET, которое
я не мог бы реализовать на perl ;) Poor me ;(

To Pasha.K

Ты в Ростове никогда не работал?

И почему NET так напоминает CORBA и J2EE? Может потому, ято чистым COM/DCOM пользоватся абсолютно невозможно? (В глобальных маштабах, а не в песочнице :).

Не думаю, что переход с оттестированой Java на недоделаный C#+.NET будет безболезненый.

Кроме того, змаменять надёжно работающие серваки под UNIX на недоделку в коорпорациях никто не станет (по крайней мере следующие 20 лет).

Короче, мне кажется, что .NET, это glide+CORBA+browser(понимающий CORBA и XML от glide), или Mozilla со своим XUI. По крайней мере XUI _уже_ работает (посмотри на игрушки на XUI на сайте Mozilla).

Люди вы видели, как работает java+tya? А java скомпилированая gcc?

Зачем нам c#?

Предлагаю, С# называть не "си шарп", а "тюремный си".

PS: данное определение распространяется под GPL.

2 alexros: Ну вот, пришел еще один баран, и начал мне тыкать. Уважаемый, я с ВАМИ брудершафта не пил. Так что называйте меня на "вы" в дальнейшем.

Теперь по делу.

Что из перечисленного есть в Java2EE? Единственно более-менее ASP.NET похож ПО КОНЦЕПЦИИ, да и то с огромной натяжкой. Синтаксис C# похож, но по возможностям язык скорее ближе к C++, чем к Java (перегрузка операторов, указатели, структуры, директивы препроцессора).

COM - вполне зрелая технология. И как любая технология она имеет свои сложности. Говоря о том, что COM трудно программировать я имел в виду лишь то, что в VS.NET распределенные приложения программировать проще на порядок. Мало того, COM и в дальнейшем будет использоваться. Вы бы сильно удивились если бы знали внутреннее название той части .NET, которая отвечает за межкомпонентное взаимодействие. Но я не скажу. :0)

Кстати, если вы не в курсе, то многие компании из Top 500 используют технологии Microsoft и COM/DCOM/COM+ в том числе. Так что я не думаю, что у MS будут проблемы с продвижением .NET.

И, пардон, я ниоткуда ничего не "лямзил". Мои знания о Java подчерпнуты из Thinking in Java Брюса Эккеля, которую я прочитал, чтобы написать эту статью.

Bluesman

Скопище скудоумных подонков.

2Bluesman: технологии интересны не своими баззвордами, а решениями определенных проблем. .net пытается решить уже давно решенные в мире юникса проблемы, флаг в руки, никто не спорит. Но попытка одновременно решить десятки, а то и сотни проблем, не оттестированными технологиями может с огромной вероятностью привести к краху. Чем глобальней предполагаемые изменения, чем меньше о них известно, тем не разумней кидаться в омут.

Что-то мне подсказывает, что большинство IT-шников займут выжидательную позицию. И перейдут в конце-концов на Линукс ;)), где все недостатки/преимущества технологий известны и существует общественный опыт на протяжении длительного периода их использования.

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