.
ANS>В том треде, говорится, что как появится Indigo и Avalon, то все будут просто писаться от счастья. Беглый поиск по гуглю не принёс мне понимания эти технологии уже вышли, до сих пор в разработке или их отменили? Проясните, плз.
Хотя вопрос не ко мне, рискну предположить, что это просто красивые названия API (и билиотек), которые уже частично вошли в состав Net Framework и на сегодняшний день имеют другие названия, состоящие в основном из трёх букв. Радости мало.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>В том треде, говорится, что как появится Indigo и Avalon, то все будут просто писаться от счастья. Беглый поиск по гуглю не принёс мне понимания эти технологии уже вышли, до сих пор в разработке или их отменили? Проясните, плз.
Точно не знаю. Вроде бы, Avalon превратился в WPF, а Indigo — в WCF, но запросто могу что-то перепутать.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
..... E>Если же продолжать фантазировать дальше, то получается, что .NET и JVM переходят в разряд современных универсальных ассемблеров. Т.е. программы уже пишутся не под конкретную аппаратную платформу, а под конкретную "прикладную" платформу. И уже не важно, на какой конкретно аппаратуре работает программа, лишь бы необходимые библиотеки были. Посему, такие вещи, как POSIX для большого количества приложений становятся анахронизмом.
E>Соответственно, разработчики аппаратных платформ будут поддерживать либо .NET, либо JVM, либо и то, и другое. А вот с ОС ситуация интереснее. С Windows-то все понятно. Так же как и с крупными Unix-системами. Там будет выбор "или-или". А вот что действительно интересно, так это будущее таких гибридов, как Mono. Ведь не видно, зачем это нужно Microsoft, т.к. им .NET нужен для продвижения Windows. Не понятно, зачем это нужно Unix-оидам, которые имеют изначально Unix-овую Java (*). Так что похоже, что Mono нужнен Microsoft-у чтобы потихоньку переманивать Unix-разработчиков на .NET, начала оставляя их в рамках привычного Unix-а, а затем, по мере роста потребностей, и в Windows. Соответственно, Microsoft не заинтересована в том, чтобы Mono становилась настолько же мощной, как "родной" .NET Framework.
....
В свете этих мыслей , что вы думаете о
1. Трансляторах из одного байт кода в другой
2. Трансляторах из байткода старой версии в байт код новой версии .
Меня ну очень этот вопрос последнее время интересует.
Да, но только по факту, многие из тех языков не языки для виртуальной машины. Одни являются интерпретаторами под JVM без взаимодействия с Java-объектами. Другие пытаются как-то взаимодействовать. И лишь немногие компилируются в байт-код и исполняются именно VM, а не прослойкой в виде ява-программы. Собсно, это почти что все языки, которые перечислены на страничке википедии.
Здравствуйте, Karabinos, Вы писали:
K>Я просто говорю, что профессионализм среднего java программиста выше, чем среднего C# программиста.
Странный вывод с учетом того, что стаж у среднего ява программиста (время знакомства с языком) больше чем у среднего .НЕТ программиста. Исторически так сложилось.
А то, что вопросов много стало, элементарных вопросов так это от того что мода пошла — проще спросить на форуме чем порыться в документации или интернет порыть — они же заняты, зачем терять вряемя... Вот это я понимаю рапид девелопмент. И прикол в том что под .НЕТ все едйствительно немудрено, то есть начать писать, войти, не сложно. Можно даже зачитываться фреймворком, так на синтаксис посмотрел и веред — ваять! Оттуда и вопрося типа "Как на шарпе понизить звук", "Как скачать файл из интернет", ... и прочее, плюс вопросы из серии "документацию читать лень" — то есть это не технические вопросы, не вопросы алгоритмического плана, или как повысить производительность а просто потому что фреймворк не знают и не хотят знать.
М-да...
Прикольно, оно так во многом и есть. Сама MS не собирается отказываться от нативной платформы, соответственно, основные ее продукты — нативные. Но вот сомну интеграторов и просто потребителей дан удобный и легкий в использовании инструмент для интеграции продуктов MS под свои нужды. Первоначальная "бесплатность" .Net выглядит вполне обоснованной при таком раскладе.
Тут уже правильно сказали, что это еще соревнование за умы, которые потом смогут обслуживать продукты Microsoft.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Сыр есть, а где мышеловка? ;) совместимость
Здравствуйте, minorlogic, Вы писали:
M>В свете этих мыслей , что вы думаете о
M>1. Трансляторах из одного байт кода в другой
M>2. Трансляторах из байткода старой версии в байт код новой версии .
M>Меня ну очень этот вопрос последнее время интересует.
К сожалению, ничего не смогу сказать, поскольку абсолютно не копенгаген в этих вопросах.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Трудно сказать, у IBM прибыль примерно поровну распределена между услугами, софтом и хардвером.
ГВ>Впрочем, судя по всему, если кто ей и "угрожает" по части серверов, так это HP, но никак не Sun. Вот, кстати, статейка по этому поводу.
Так и я о том, что эти заявления очень смахивают на моськин лай
ГВ>Пока что IBM весьма прилично вкладывается в тот же Linux, Java и SOA (в смысле интеграторства, не подумайте чего фундаментального).
Вроде и у Sun интеграционных продуктов хватает. Забавная ситуация: у обоих компаний (IBM, Sun) есть своё железо (и обе используют и чужое), обе поддерживают разные ОС (обе OS ), обе используют одну JVM (IBM от совей отказалась?), у обоих есть свои интеграционные и прочие коммерческие проекты. ВыводЖ кто бы не помер, JVM останется
ГВ>Первое, что они благополучно похоронили — здравый смысл не в меру экзальтированных пользователей. Ну что же, на войне, как на войне.
Здравствуйте, minorlogic, Вы писали:
M>В свете этих мыслей , что вы думаете о
M>1. Трансляторах из одного байт кода в другой
M>2. Трансляторах из байткода старой версии в байт код новой версии .
M>Меня ну очень этот вопрос последнее время интересует.
Здравствуйте, cl-user, Вы писали:
CU>Здравствуйте, iZEN, Вы писали: iZEN>>http://www.robert-tolksdorf.de/vmlanguages.html
CU>1. Как уже сказали — языков именно для JVM там очень не много. Но ладно — можно опустить CU>2. Часть ссылок нерабочая. Может просто урля поменялись, а может проекты "приказали долго жить"? CU>3. Это не СОТНИ. Это несколько десятков. Сотни где?
Посчитайте. Я первую попавшуюся поиском в гугле ссылку дал.
Большая масса языков — академические исследовательские проекты, которые были "подогрелись на сковородке шумихи вокруг Java". В практическом смысле они малопригодны для использования. Тем не менее, одна только ссылка указывает на значительно большее распространение поддержки байткода Java (трансляция, использование) в сторонних ЯП (исследовательских, некоммерческих, etc.), чем MSIL, не так ли? Больше ста таких ЯП наберётся? Я думаю — да.
cl-user wrote: > 1. Как уже сказали — языков именно для JVM там очень не много. Но ладно > — можно опустить
Для CLR их тоже не так уж много. Полезных тоже несколько десятков наберется.
> 3. Это не СОТНИ. Это несколько десятков. Сотни где?
Еще где-то в 2000-м году был обзор языков, насчитали действительно
сотни. Большей частью мелкие студенческие разработки и т.п.
Здравствуйте, Cyberax, Вы писали:
C>cl-user wrote: >> 1. Как уже сказали — языков именно для JVM там очень не много. Но ладно >> — можно опустить C>Для CLR их тоже не так уж много. Полезных тоже несколько десятков наберется.
>> 3. Это не СОТНИ. Это несколько десятков. Сотни где? C>Еще где-то в 2000-м году был обзор языков, насчитали действительно C>сотни. Большей частью мелкие студенческие разработки и т.п.
Господа, мне вот интересно — это действительно важный параметр для сравнения платформ?
Может лучше было бы число приложений для них сравнивать? Причём реально работающих, а не студенческие разработки
Здравствуйте, iZEN, Вы писали:
ZEN>Посчитайте. Я первую попавшуюся поиском в гугле ссылку дал.
Посчитал Да, чуть более 200. Просто страничка на столько мала, что в памяти никак не вязалась с описанием двухсот языков
Да это ссылка и самая полная, хотя часть ссылок на странице — битые, а кое-чего нет
ZEN>Большая масса языков — академические исследовательские проекты, которые были "подогрелись на сковородке шумихи вокруг Java". В практическом смысле они малопригодны для использования. Тем не менее, одна только ссылка указывает на значительно большее распространение поддержки байткода Java (трансляция, использование) в сторонних ЯП (исследовательских, некоммерческих, etc.), чем MSIL, не так ли? Больше ста таких ЯП наберётся? Я думаю — да.
ИМХО — использование в новом языке байткода JVM (как правило — компиляция) и использование Java (как правило — интерпретация) — "две большие разницы". Компиляторов там очень мало. Пойду изучать дальше
Здравствуйте, cl-user, Вы писали:
CU>Здравствуйте, Курилка, Вы писали:
К>>Может лучше было бы число приложений для них сравнивать? Причём реально работающих, а не студенческие разработки
CU>И для какой платформы, по-вашему, таких приложений больше (на данный момент)?
Я просто предложил более конструктивный критерий, конкретных цифр у меня на руках нет.
Да и лень, если честно
Есть только мысль по поводу того, что дотнет будет более распространён для десктопов и т.д. Тогда как явы будет больше среди серверов приложений (J2EE и пр.)
Здравствуйте, IT, Вы писали:
IT>И какое знание мне даст такое голосование? Я узнаю, что подавляющая часть российского бизнеса не может себе позволить купить сановскую технику? Так это я и так знаю. Может как раз в этом и проблема сана. Да и не нужен мне опрос общественного мнения. Я могу судить по тому, что видел и вижу своими глазами. Любой солидный Java shop закупает сановские железки вагонами. Правда со временем народ начинает понимать, что можно такое же по качеству железо купить гораздо дешевле и вот тут против сана начинает играть его же собственная Java.
А по мне так большое железо это вобще лохотрон еще тот.
Всеравно для обеспечения масштабируемости и надежности нужен кластер.
А раз всеравно делать кластер то какая разница на каком железе?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
