Здравствуйте, Sharov, Вы писали:
S>Студия чем не идея, или студия с решарпером.
У студии от дотнета только морда. А идея вся на жабе.
S>Какое отношение хадуп,касандра и проч. имеют S>к сравнению языков и платформ. Это говорит о том, что на яве разработчиков больше, плюс давняя нелюбовь OSS S>сообщества к ms. Так сложилось...
Потому что тут все пишут про сахар, а я написал, что важнее не сладкий синтаксис, а технологии, разрабатываемые на языке, а тут дотнет явно не фаворит.
Здравствуйте, Бывалый, Вы писали:
Б>Здравствуйте, Sinix, Вы писали:
Б>А жабный у вас сколько выполняется? Ключи сервер ставили? Прогревали жвм? Это же всем давно известные факты.
Хе... проигрывать надо достойно. А не так уныло сливать.
Здравствуйте, ins-omnia, Вы писали:
IO>1. Это таки микробенчмарк. О производительности в реальных задачах по нему нельзя однозначно судить. IO>2. Непонятно почему Java настолько медленее в этом примере. IO>3. В реальной задаче подобного рода массив классов всё равно не будут использовать. IO>4. Правильным подбором примера можно показать, что Хаскел быстрее C.
IO>В целом Java вероятно хуже в таких низкоуровневых задачах, чем .NET. IO>Однако в каком-нибудь статистическом рассчете разница будет уже не заметна, я думаю.
Целью эксперимента было показать не какой язык быстрее, а пользу от value типов. Лучше всего она видна на примере .NET с использованием struct (value type) и class (reference type) для V3.
Во всех трёх случаях почти всё время уходит на инициализацию массива. Почему-то в Яве это занимает 15-40 секунд, с таким вот разбросом. Запускаю из Эклипса.
Работа с массивами векторов реально встречается на практике и .NET для неё подходит лучше. Всё ещё сильно уступает плюсам, конечно, но мне часто хватает.
Здравствуйте, dimaka, Вы писали:
D>Я думаю — им обоим кранты — победит язык АДА!
В одной известной статье язык Ада и в самом деле хвалили:
...К счастью, язык одобряемый Министерством Обороны, обладает достаточно интересными свойствами, которые делают его приемлемым — он невероятно сложен, включает в себя способы порчи операционной системы и перераспределения памяти...
предварительно поругав:
Кажется, что кто-то из высокопоставленных сосунков в Министерстве Обороны решил, что все оборонные программы должны быть написаны на некоем великом унифицированном языке ADA. Некоторое время казалось, что ADA была предназначена стать языком, который шел вразрез со всеми правилами настоящего программирования. Это язык со структурой, типами данных, строгим синтаксисом и точками с запятой. Короче, он был разработан для сдерживания творчества типичного настоящего программиста.
Заметим, что в Фортране операторы begin/end и { } отсутствуют. Точнее, end все-таки присутствует, это просто последний оператор в программе, и он ничего общего с begin/end в Паскале не имеет. Соответственно, вместо срачей споров "фигурные скобки vs begin/end" разработчики могут просто заниматься делом.
Здравствуйте, Steamus, Вы писали:
HTM>>Несерьезно. Если JavaFX полагается на некую "систему масштабирования" у Осаки, а не растрирует текст самостоятельно, это проблемы JavaFX, а не ее юзеров.
S>Да причём тут JavaFX? Смешались в кучу кони/люди... Человек что бы сделать снимки экрана с демоприложения, чем-то увеличил изображение. Чем он это делал, я не знаю. Но там какая-то грязь возле символов везде. Точки какие-то сверху... Я же просто "лупой" смотрел на то как шрифт нарисован — так вот нет там никаких случайных точек вокруг. Всё аккуратно. Дефекты, если какие и есть, то они не такого грубого уровня.
Что касается увеличенного варианта, возьмите обычную виндовую лупу и увеличьте в 4 раза. Для тех, кому делать лень, я так понимаю, второй скриншот и предназначался.
Вывод: у вас и у него текст рендерится по-разному, но только если вам поверить на слово, ибо гражданин свой скриншот представил, а вы — нет. Я бы сам проверил, но поганить
Здравствуйте, HTML5, Вы писали:
HTM>Вывод: у вас и у него текст рендерится по-разному, но только если вам поверить на слово, ибо гражданин свой скриншот представил, а вы — нет. Я бы сам проверил, но поганить
...свой компьютер ради одного скриншота не хочу, извините.
Здравствуйте, HTML5, Вы писали:
HTM>...свой компьютер ради одного скриншота не хочу, извините.
Да это понятно. Настоящие Джедаи — гордые, они только хатэмээля не опасаются.
E__>>На самом деле, простота языка — это тоже элемент "тортовости". Просто с другой стороны.
НС>А с какой стороны будет угребище под названием дженерики?
Со стороны недостатков, конечно. Иногда на совместимость ради значимых нововведений можно было бы и забивать.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Eugeny__, Вы писали:
E__>>На самом деле, простота языка — это тоже элемент "тортовости". Просто с другой стороны.
НС>А с какой стороны будет угребище под названием дженерики?
Я извиняюсь, но задам вопрос — а вы лично задумывались из-за чего Джава дженерики, как-бы, плохи? В чём кардинальное отличие от других дженериков? И почему был сделан такой баланс?
Здравствуйте, Steamus, Вы писали:
S>Я извиняюсь, но задам вопрос — а вы лично задумывались из-за чего Джава дженерики, как-бы, плохи? В чём кардинальное отличие от других дженериков? И почему был сделан такой баланс?
А это совершенно пофиг, что за тараканы были в голове у проектантов. Главное — результат совсем негодный.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Steamus, Вы писали:
S>>Я извиняюсь, но задам вопрос — а вы лично задумывались из-за чего Джава дженерики, как-бы, плохи? В чём кардинальное отличие от других дженериков? И почему был сделан такой баланс?
НС>А это совершенно пофиг, что за тараканы были в голове у проектантов. Главное — результат совсем негодный.
То есть, я так понимаю, вы не в курсе что, как и почему? Это не тараканы, это перестраховка. В целом, по факту и по прошествии лет, надо признать, решение было не лучшим. Отрицательная волна от людей, полагающих что проектировщики не знали какими должны быть "правильные" дженерики, перекрыла выбранный компромисс. Другими словами, большой процент народа не въехал из-за чего были ограничения и "затопал" подход ногами не въезжая в суть.
Здравствуйте, Steamus, Вы писали:
S>То есть, я так понимаю, вы не в курсе что, как и почему? Это не тараканы, это перестраховка. В целом, по факту и по прошествии лет, надо признать, решение было не лучшим. Отрицательная волна от людей, полагающих что проектировщики не знали какими должны быть "правильные" дженерики, перекрыла выбранный компромисс. Другими словами, большой процент народа не въехал из-за чего были ограничения и "затопал" подход ногами не въезжая в суть.
Ну, а из-за чего, собственно, должны были быть эти ограничения? Экономия размера кода? Проблемы с системой типов и недостаточностью полиморфизма? Честно говоря, я не могу придумать убедительного объяснения. Вот, плюсовые шаблоны какими убогими были в 90 году, и какие стали к выходу стандарта. Это поломало совместимость плюсового кода? Да скорее нет, а ведь это далеко не явка в виртуальной машине. Почему теперь вся платформа должна страдать из-за этого "былого решения" — или почему это решение не предусматривало возможности "сделать потом нормально" — чистой воды загадка.
Здравствуйте, b-3, Вы писали:
b-3>Ну, а из-за чего, собственно, должны были быть эти ограничения? Экономия размера кода? Проблемы с системой типов и недостаточностью полиморфизма? Честно говоря, я не могу придумать убедительного объяснения. Вот, плюсовые шаблоны какими убогими были в 90 году, и какие стали к выходу стандарта. Это поломало совместимость плюсового кода? Да скорее нет, а ведь это далеко не явка в виртуальной машине. Почему теперь вся платформа должна страдать из-за этого "былого решения" — или почему это решение не предусматривало возможности "сделать потом нормально" — чистой воды загадка.
Ребята решили не оставлять информацию о типе в байткоде. Любая параметризация с сохранением информации о типе предполагает создание в байткоде экзепляра параметризованного класса уже с конкретным типом данных, которым он был реально параметризован, скажем, в объявлении. Это и ресурс и, возможно, совместимость байткода. Параметризация порождает много сложных и путанных вещей. Несогласные, могут попытаться проработать учебник Джосаттиса по шаблонам C++ (сам недавно обозрел его, в память о своём давнем C++ прошлом — тяжело было. Реальный проект, написанный с использованием этих подходов во всей красе, способна сопровождать только крайне сработанная и технически сильная команда).
Парни приняли решение, что дженерики будут работать только на этапе компиляции (примерно как в раннем MS C++, где они были на define построены, если правильно помню). Отсюда и некоторые логические ограничения и противоречия. Решение было не самое плохое, ибо мир Джосатисса общая масса программистов не потянула бы. Но, видимо, сработал понтовый инстинкт "хочу казаться умным". И подход был признан в итоге неудачным. Оно и сейчас все топырят пальцы и говорят что Скала наша всё, но реальных коммерческих проектов там не много. Есть всё таки разница между ночными упражнениями на сложных языках и коммерчески работающим проектом, где за ошибки и сбои реально финансово бьют по пальцам. И бьют больно. И вот там как-то оно всё сразу упрощается... Джава не зря стала самым популярным языком.
S>Парни приняли решение, что дженерики будут работать только на этапе компиляции (примерно как в раннем MS C++, где они были на define построены, если правильно помню). Отсюда и некоторые логические ограничения и противоречия. Решение было не самое плохое, ибо мир Джосатисса общая масса программистов не потянула бы.
Вопрос стоит как "почему в яве не сделали генерики наподобие дотнета?", про шаблоны c++ речь не идёт. Общая масса программистов на c# спокойно тянет генерики, так что довод слегка не в тему
Здравствуйте, Don Reba, Вы писали:
IO>>Тут должна быть ссылка на сравнение производительности C# и Java для "обработки большех объёмов данных" на каком-нибудь иллюстративном примере. DR>
DR>
.NET/struct
1352 : 12522034.8692291
DR>
.NET/class
4521 : 12522034.8692291
DR>
Java
41119 : 1.2522034869229091E7
DR>
DR>
Java
Тест кривой чуть менее, чем полностью. Вот результат начального теста на моём ноуте:
~/some/test$ time java -cp . Test
9518 : 1.2522034869229091E7
Теперь делаем так — просто повторяем тест несколько раз:
public class Test {
public static void main(String[] args) {
test();
test();
test();
}
public static void test() {
Random rand = new Random(0);
long s = System.nanoTime();
V3[] mesh = new V3[1 << 24];
for (int i = 0; i != mesh.length; ++i)
mesh[i] = MakeRandVector(rand);
V3 dir = MakeRandVector(rand);
double sum = 0.0;
for (int i = 0; i != mesh.length; ++i)
sum += mesh[i].X * dir.X + mesh[i].Y * dir.Y + mesh[i].Z * dir.Z;
long f = System.nanoTime();
long milliseconds = (f - s) / 1000000;
System.out.println(milliseconds + " : " + sum);
}
private static V3 MakeRandVector(Random rand) {
return new V3(rand.nextFloat(), rand.nextFloat(), rand.nextFloat());
}
}
Итого, имеем разницу в скорости на порядок, просто играя ключами компиляции. И это я ещё не затрагивал тонкий тюнинг GC и HotSpot'а.
В реальных серверных приложениях Java работает сейчас быстрее, чем .NET — сказывается то, что в Sun работали на JVM намного дольше и имеют заметно больше опыта. В .NET реально выигрыш в скорости за счёт честных generic'ов не такой большой, если не рассматривать вырожденные случаи типа контейнера простых структур или примитивов.
Здравствуйте, Steamus, Вы писали:
S>Здравствуйте, HTML5, Вы писали:
HTM>>...свой компьютер ради одного скриншота не хочу, извините. S>Да это понятно. Настоящие Джедаи — гордые, они только хатэмээля не опасаются.
S>Вот смотрите:
S>пример 1 S>пример 2
Во-первых, непонятно, паразитируют ли они на виндовом рендеряторе (we've added the ability to use Windows-style LCD sub-pixel rendering). Windows-style — это закос или делегирование? Controls will be LCD-text enabled by default on Windows — а на линухах? Так пишут, черти, что не понять ничего. Недаром говорят, что в Оракуле на одного программиста 10 юристов. Теперь, вопрос в том, какой фонт на обеих их картинках. Выглядит как Courier New, но тот же ли это Курьер, что в студии Осаки? От этого зависят дальнейшие выводы (чем это отличается от WPF).
