MAKCim, понимаешь, какое дело. Уровень стандартной библиотеки Питона и уже упомянутого обрезка GWT вполне сопоставим. Тем не менее, ощущения от написания кода разительно отличаются. Ну ладно, оставим, это всё субъективизм махровый, хотя, уверен, найдутся те, кто меня поймут.

Все равно не могу понять, разве без прослойки в виде фрэймворка интеграция была бы не более тесной?

А была ли бы разработка столь же удобной без этой прослойки? Как обеспечить сборку мусора, reflection, CAS и прочая и прочая, без «прослойки»?

речь про интеграцию, а не про удобство   

MAKCim, разговор с тобой перманентно напоминает известный анекдот про суровых сибирских мужиков и пилу 

На кой ляд тогда интеграция без удобства? Нехай на C++ пишут, так что ли?

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

Hidrag, сборщик мусора можно запихнуть в нативный код с минимальным рантаймом (пример: OCaml), правда на язык при этом накладываются определённые ограничения. В C++09, насколько я помню, GC будет (если будет) всего лишь консервативный.

Дык так оно и есть  В Vista .NET 3.0 из коробки, на XP тоже вроде с Windows Update должен фреймворк приходить, в 2003 есть .NET 2.0, начиная с R2.

висту еще не видел, а вот в XP это все же не часть ОС, то есть я могу удалить дотнет и приложения дотнетовские запускаться не будут, я говорю о самодостаточности получаемых приложений  

То есть все что нужно для их работы уже было бы в ОС (имеется в виду то что есть в фрэймоврке сейчас). 

Честно говоря я этого и ожидал от "Longhorn", что в ОС до нее это будет в виде прослойки, чтобы мы уже сейчас начали писать приложения под будущую платформу, а в новой ОС это было бы стандартом де факто, то есть Delphi for win32, MFC шли бы лесом, сделали бы какойнить эмулятор для работы старого софта но новый бы уже писался по новому, но похоже виста все та же win32... 

это разные понятия
интеграция с неким компонентом подразумевает бОльшее использование возможностей этого компонента в другом компоненте
удобство же - это прежде всего легкость использования этих возможностей
из интеграции не вытекает повышение удобства

Exception, ты как-то слишком быстро забываешь о чем я говорил, и видишь только то что написано в этом конкретном посте, а все что было раньше забываешь напрочь  

Я писал, что Mono не создало ни одного крупного и достаточно широко используемого своего проекта. Все что они создали это или небольшие вспомогательные библиотеки (как Mono.Addins), или повторение того что уже реализованно МС (как Mono.Data).

Мне вообще не понятно, что такое Mono. Раньше я считал, что это свободная реализация .NET под платформы не поддерживаемые МС (ну заодно и под винду). Теперь же ты заявляешь, что это 

так что они пытаются сделать? Свою собственную .Mono Framework, частично совместимый с .NET Framework? А накой болт? Весь этот огород ради возможности писать C#?




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

ИМХО мнение, что программа всегда должна себя вести так как принято на данной платформе и ничем не выделяться среди стандартных приложений - полная ерунда. Удобство интерфейса и его близость к нативному никак не связанны. Близость к нативному интерфейсу разве что может повлиять на быстроту освоения, и то далеко не всегда.
Возьмем для примера Photoshop, его интерфейс вовсе не соответсвует каноническому интерфейсу для Windows. И тем не менее он весьма удобен, удобней многих других графических редакторов. Или например МС Офис 2007 и его ribbons, ранее такие штуки не применялись, и для всех пользователей это новый элемент интерфейса. Но тем не менее Офис 2007 продается весьма успешно.
Я уж не говорю про программы, которые пользуются скинами, тут вообще ничего общего с платформой по виду нет. Но тем не менее, это не мешает тому же Winamp или Firefox оставиться популярными.

Опять таки есть утилиты командной строки, у который и интерфейс один на всех платформах. И веб интерфейсы которые подделывать под платформу - просто бесполезно и бесмысленно.



1. June 30th: Mono 1.0 is released - 3,5 года это далеко не вчера появился.
2. Ориентироваться надо не на дату выхода реализации ASP.NET под Mono, а на дату выхода ASP.NET в версии от МС. Ведь это не собственная разработка Mono, а МС-овской разработки.
Собственно вопрос, в том почему никто из пользователей ASP.NET не захотел перейти на Linux+Mono.

P.S. А TortoiseSVN имеет быстро осваиваемый, но неудобный интерфейс. И возможности у него довольно скромные.

Меня просто таки убивает профессионализм подобных высказываний.

Где впервые проявился принцип ООП? Вот засада - остальные даже придумывать не стали своего собственного!....
А стали его использовать...

жуть.   

Меня таки добивают профессиональные дергальщики цитат. Выдернут фразу из контекста и радуются. Жуть!

Причина очень простая - надо продавать только Винду - а зачем тогда делать работу за конкурентов.

По поводу кроссплатформенности - клиентские приложения как раз мало пишут на Java - это факт. Подавляющее большинство пользователей сидят под Виндой и писать формочки с кнопочками на Java смысла нет.

Java очень хорошо работает как серверная платформа - я могу напсать код под Винду и оно все прекрасно поедет на Unix-машине без какой-либо переделки. Вообще. Проблемы масштабируемости и наращивания мощности нет совсем. 
Тот же Windows Server 2003 R2 Enterprise x64 Edition поддерживает до 8 процессоров, что для некоторых систем просто мало - под Unix есть системы где больше 1000 процессоров.
Таким образом заказчику по барабану, что там у него за машина будет - меняет на любую, которая его устраивает по производительности.

Очень важно отметить, что и многие библиотеки будут работать без пересборки - а это как раз бывает критично. Под Unix есть, а под Винду нет. И не собрать, и исходников нет.

В .NET тоже без пересборки работают, насколько я знаю.

Вообще говоря, в качестве серверной кроссплатформенной прослойки .NET не уступает Java(точнее уступает, но только из-за молодости .NET и её непопулярности в этой сфере[кроме ASP.NET]).
С тем же успехом ты можешь на .NET написать код, который прекрасно будет работать под Mono(в частности я писал, причём, даже не подозревая о том, что целевая платформа именно Mono - т.е. писал под виндами используя VS) - серверам же не нужны ни кнопочки, ни рюшечки.


Почему крупные проекты должно создавать Mono? Mono - это и есть проект. Все крупные и некрупные проекты создаются же не дотнетом, а под дотнет. Почему эти проекты не работают с Mono? Наверное из-за сырости данного порта и/или из-за сырости .NET - чтобы проделать некоторые вещи под .NET приходится прибегать к Win32API что напрочь убивает кроссплатформенность.