Поддержка динамических языков в Java 7

> Компания пишет продукты, которые позволяют запускать .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?

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

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

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

Managed C++ видел?

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

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

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

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

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

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

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

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

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

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

> Managed C++ видел?

Видел, и что?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А есть mono для android?

Нет

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

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

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

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

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

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

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

* java vs. c#

NВИМ.

+

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

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

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

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

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

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

linux.org.ru/news/java/1988216

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

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

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

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

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

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

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

thepiratebay.org/torrent/5352678/

Тут говорили, что 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

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

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

vsl?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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