> Компания пишет продукты, которые позволяют запускать .NET под JVM (возможно, и наоборот - не помню), без разницы в производительности. Такие дела.

Ни хера они не пишут. JVM в .NET можно транслировать без потерь (см IKVM.NET), а вот .NET в JVM транслировать невозможно, потому как:

a) Нет поддержки хвостовых вызовов b) Есть ограничения на размер классов и методов

c) Отсутствуют value types

d) Отсутствует арифметика указателей

Так что транслировать можно только некое жалкое подмножество C#. То, которое с Java более-менее совпадает. Произвольный .NET код транслировать невозможно в принципе.

> Java - отличный язык. Его недостатки с лихвой компенсируются легким рефакторингом.

Ты так говоришь, потому что ты не знаешь никаких других языков. Учись, студент, подрастешь - поймешь, что Жаба примитивный, ограниченный, убогий язык.

> Что, CLR даже multiple-inheritance поддерживает?

А кто тебя заставляет реализовывать ООП на уровне классов CLR? В .NET хотя бы есть выбор.

Всяк кулик свое болото хвалит... Ясно одно, что в ближайшем будущем программист Java будет более ценен чем программист .NET из за богатства поддерживаемых платформ...

А пока Вы тут спорите о всякой фигне, индусы тихим сапом завоевывают рынок, лабая проекты на джава и пользуясь огромной популярностью у столпов IT индустрии...

> Не нужно.

А я не про это спрашивал. Ты (или другой анонимус) сказал, что .NET годится для любых языков. А я вот что-то не помню, чтобы C++ (под который куева туча строк кода) можно было скомпилировать в .NET. Выходит, CLR - всего лишь ограниченный закос под JVM?

faustus (11.02.2010 15:02:41)

> Ясно одно, что в ближайшем будущем программист Java будет более ценен чем программист .NET из за богатства поддерживаемых платформ...

Онолитеги на лоре - такие онолитеги. Смешно.

> А я вот что-то не помню, чтобы C++ (под который куева туча строк кода) можно было скомпилировать в .NET

Managed C++ видел?

> Выходит, CLR - всего лишь ограниченный закос под JVM?

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

> А пока Вы тут спорите о всякой фигне, индусы тихим сапом завоевывают рынок,

О, он собрался с индусами за миску риса конкурировать. Ну, если ты сам так свой уровень оцениваешь - вперед, с песнями, лабай на Жабе.

> Онолитеги на лоре - такие онолитеги. Смешно.

Смешно, не смешно, а .Net держится только в вин среде и более он нах никому не нужен. Студентам еще, преподу показать как они круто могут на C# ЧМ считать.

> Смешно, не смешно, а .Net держится только в вин среде и более он нах никому не нужен

Дурак, такой дурак. Неграмотный, неумный, малолетний - но зато с понтами. Презираю таких.

Про MonoTouch слышал? Гигантских размеров рынок. ASP.NET сейчас очень много где на unix/mono хостится. Ещё более гигантский рынок.

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

> Managed C++ видел?

Видел, и что?

faustus (11.02.2010 15:14:59)

> Гигантских размеров рынок. ASP.NET

Повторяй это 3 раза в день перед едой. Смешной пример, ага.

> 1. НЕНАВИЖУ динамическую типизацию, ибо, кладес ошибок.

прикол в том, что для тупой JVM вполне статическая типизация продвинутого языка (типа скалы) может транслироваться в код, требующий "динамических" инструкций

www_linux_org_ru (11.02.2010 16:04:23)

Да они даже такой весь статический по природе Hibernate умудряются делать на рефлексии. У жабистов вообще мозги очень странно работают.

> Ясно одно, что в ближайшем будущем программист BASIC будет более ценен чем программист .NET из за богатства поддерживаемых платформ...

Fixed во имя банка Империал и всемирной истории.

queen3 (11.02.2010 16:23:12)

>Да они даже такой весь статический по природе Hibernate умудряются делать на рефлексии.

В каком месте он статический?

r (11.02.2010 17:16:00)

> В каком месте он статический?

Схема БД известна во время компиляции. Типы объектов, которые в неё мапятся, тоже известны. Можно генерить статический код. Но вместо этого дрючат тормозную рефлексию. Глупо.

> Это не лишняя сущность, это контроль. В JVM escape analysis ни хера не работает, кроме как в самых тривиальных случаях.

А какие случаи могут быть "нетривиальные"? Хм-хм... И есть какие-то бенчмарки по этому поводу?

> В .NET же можно сколь угодно сложные ситуации разруливать через стек. Совершенно рациональное решение.

"Сложные ситуации", которые bottleneck и которые один раз на тысячу, было бы разумнее, имхо, выражать через хинты виртуальной машине, т.е. через обычные атрибуты к определению класса.

> А какие случаи могут быть "нетривиальные"?

Первый же виртуальный вызов всё обломает.

> Хм-хм... И есть какие-то бенчмарки по этому поводу?

По поводу сравнения скорости выделения на стеке и на куче? Полно.

> "Сложные ситуации", которые bottleneck и которые один раз на тысячу, было бы разумнее, имхо, выражать через хинты виртуальной машине, т.е. через обычные атрибуты к определению класса.

Нелепо. VM не должна быть настолько сложной (и, соответственно, тормозной).

Вообще не понимаю причины претензий к структурам в .NET. Удобно же!

> > Хм-хм... И есть какие-то бенчмарки по этому поводу?

> По поводу сравнения скорости выделения на стеке и на куче? Полно.

Не, по поводу того, искейп-анализит ли ява конкретный данный случай, или нет. Ну не бенчмарки, а ммм... слово вылетело из головы, нутыпонел.

> Вообще не понимаю причины претензий к структурам в .NET. Удобно же!

Ну по сути к структурам как к части CLR претензий нет -- мало ли какие языки придётся молоть. Скорее у меня претензии к сишарпу, потому как противоречит замыслу -- управление памяти, дескать, берёт на себя язычок/платформа, и в то же время мы явно указываем -- в стеке или в куче работать. Если так идти, то можно было бы и разрешить явно указывать когда мы хотим освободить память (т.е. опционально вырубать GC) и прочие плюшки.

>> А какие случаи могут быть "нетривиальные"?

> Первый же виртуальный вызов всё обломает.

Не могу понять сходу, что не так с ними?

> Не, по поводу того, искейп-анализит ли ява конкретный данный случай, или нет.

Ну, как бы, совершенно очевидно, что не анализит.

> противоречит замыслу

Не очень. C# позиционируется не как Java, все же.

> Не могу понять сходу, что не так с ними?

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

А есть mono для android?

Нет

Может, всё-таки C ?

dotbg (11.02.2010 19:42:28)

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

гы. прикольно.

а я воспринимал структуры только с точки зрения программиста -- семантика value types как-то более привычна например в математике.

www_linux_org_ru (11.02.2010 21:22:00)

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

А где бы вообще почитать такие краткие и емкие сравнения языков/вирт. машин? В википедии java vs. этого нет (хотя много другого интересного). А то у меня терпения и времени не хватает спецификации читать.

Да и вообще сжатую инфу по c#, в таком вот стиле.

www_linux_org_ru (11.02.2010 21:27:11)

* java vs. c#

www_linux_org_ru (11.02.2010 21:27:39)

NВИМ.

tailgunner (11.02.2010 23:20:11)

+

LamerOk (11.02.2010 23:30:02)

>Схема БД известна во время компиляции. Типы объектов, которые в неё мапятся, тоже известны. Можно генерить статический код. Но вместо этого дрючат тормозную рефлексию. Глупо.

Дык - в этом смысле и XML парсить универсальными парсерами глупо.

r (11.02.2010 23:48:07)

Можно дотнет помацать Microsoft .NET Framework 4 RC
http://download.microsoft.com/download/0/1/1/011F8F7B-18F7-4AFD-A0C9-BD5AEDEF...

Karapuz (11.02.2010 23:49:21)

> Но вместо этого дрючат тормозную рефлексию. Глупо.

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

Korwin (11.02.2010 23:51:05)

>Компания пишет продукты, которые позволяют запускать .NET под JVM (возможно, и наоборот - не помню), без разницы в производительности. Такие дела. Так что (ну ты понял)

linux.org.ru/news/java/1988216

Karapuz (11.02.2010 23:51:17)

> в этом смысле и XML парсить универсальными парсерами глупо.

А какими надо?

LamerOk (11.02.2010 23:53:49)

> А какими надо?

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

r (12.02.2010 0:01:46)

>У кого-нибудь IDEA завелась на Java7?

Чтобы завелась, надо в idea.properties добавить idea.no.jdk.check=true

Karapuz (12.02.2010 0:03:01)

А, понял мысль.

LamerOk (12.02.2010 0:06:01)

thepiratebay.org/torrent/5352678/

Karapuz (12.02.2010 0:12:17)

Тут говорили, что Sun купил Oracle, а как же получается, что Sun продолжает разрабатывать Niagara 3? http://arstechnica.com/business/news/2010/02/two-billion-transistor-beasts-po...

static.arstechnica.com/uptime/niagara-3.png

static.arstechnica.com/power7_ars.jpg

Karapuz (12.02.2010 0:16:35)

>Но то, что тот же F# под .NET генерит гораздо более шустрый код, чем Scala под JVM - это показательно

Какие ваши доказательства?

Karapuz (12.02.2010 0:32:32)

vsl?

Karapuz (12.02.2010 0:38:40)

>CLR - это намного больше, чем JVM

О, да. Намного больше. dotNetFx 3.5 SP1 230Мб весит. Против 40Мб jre7ea

Karapuz (12.02.2010 0:47:57)

Читай, включив показ удалённых.

LamerOk (12.02.2010 0:48:04)

>чего греха таить, ява говно по сравнению с шарпом.

Блин, давно мечтаю эту фразу услышать не от анонимуса. Но пока смелости тока анонимусам и хватает.

По сабжу: инъекции интерфейсов свойственны динамическим языкам (например питону, в котором это есть). Но у динамических языков есть общий недостаток - они медленные. Срвсем недавно на ЛОРе, кажется при обсуждении луа, срач стоял на эту тему.

А теперь правильный вопрос: че жаба реализнув такие инъекции будет более тормознутая чем раньше?!

k0valenk0_igor (12.02.2010 2:33:43)

> реализовать динамический вызов метода без указания типов аргументов

> и инъекцию интерфейсов, которая позволит «на лету» добавлять в класс новые методы

Жаждут успеха Питона, который это умеет уже лет 10?

pythonist (12.02.2010 2:36:08)

>Жаждут успеха Питона, который это умеет уже лет 10?

Это как раз и нужно для успешной реализации питона и тому подобного.

r (12.02.2010 5:11:07)

>Жаждут успеха Питона, который это умеет уже лет 10?
Грешно смеяться над умирающим питоном.

grim (12.02.2010 5:17:23)

>А теперь правильный вопрос: че жаба реализнув такие инъекции будет более тормознутая чем раньше?!

А это собираются именно в жабку тащить, а не в JVM? В 7-ке и сейчас нет поддержки invokedynamic, хотя в JVM уже пол года присутствует, если не более.

yyk (12.02.2010 9:43:50)

>> CLR - это намного больше, чем JVM

> О, да. Намного больше. dotNetFx 3.5 SP1 230Мб весит. Против 40Мб jre7ea

Картинки и видео там же не может быть. Стало быть, там один код. Вот это действительно дотнет намного больше чем ЖВМ :\ Дотнет действительно как большая такая часть десктопного ОС, в то время как ЖВМ - небольшой костыль для запуска пары серверных приложений гыгы.

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

Karapuz (12.02.2010 12:51:00)

Не, это не он. Стиль речи другой.

LamerOk (12.02.2010 12:55:09)

>Не, это не он. Стиль речи другой.

Судя по тому, что он писал лисп для JVM, а сейчас кучу времени инвестировал в .NET - может и он.

Absurd (12.02.2010 13:22:20)