Я не спец,а простой юзер разных торговых платформ.
Могу сказать,что написанные на java самые неудачные.
Из западных брокеров самый яркий пример это IB-вечная проблема с софтом.Софт на java.
Альтернативы сейчас просто нет. И в ближайшее время не предвидится. Ведь нужно поддержать и разные платформы. Не только Win, но и Мас и разные семейства Nix .
А учитывая, что с Вистой MS пролетела как фанера на Парижем, и с семеркой вопрос покамест открытый – кроссплатформенность сейчас актуальна как никогда.
Да и другие конкурентные оси появились…
Что касается «неудачности» приложений написанных на java – вопрос ненадежности софта в общем. А кроссплатформеных решений особенно.
Ну а если нужно максимально надежное приложение(но и соответственно значительно более дорогое) – используем С/С++. Ведь это тоже кроссплатформенный язык, и в общем если не использовать ASM вставки(не привязываться к архитектуре) и придерживаться стандартов, то основной функционал должен без проблем компилиться под любую платформу…
vito, хватит рассуждать о том в чем вообще не разбираешься.
GC.Collect у тебя не работает? Как ты узнал что он не работает? Запустил а он не сказал что все сделал?
Это не молоток, это чуть более чем сложный механзм, и говорить о том что он "не работает" можно только после того как изучишь что он должен делать и как он должен работать.
У меня почему-то все везде работает, при том что я GC.Collect вообще не юзаю.
vito, хватит рассуждать о том в чем вообще не разбираешься.
GC.Collect у тебя не работает? Как ты узнал что он не работает? Запустил а он не сказал что все сделал?
Есть такая вещь как отладчик. Советую познакомиться.
Или просто создать динамически N объектов и попробовать их принудительно уничтожить.
А потом посмотреть, после какого же числа объектов действительно начнется очистка. И как это связано с ресурсами системы.
Это не молоток, это чуть более чем сложный механзм, и говорить о том что он "не работает" можно только после того как изучишь что он должен делать и как он должен работать.
Да, это не молоток. Крайне точное замечание.
Принудительная очистка ресурсов – должна освобождать ресурсы принудительно. Не так ли? На то она и принудительная.
Для подобных виртуальных систем это крайний случай. А не ставить их в очередь очистки, которое произойдет на усмотрение системы. А может и не произойдет.
А как он должен работать, это один вопрос. Другой вопрос что так как он работает (точнее не работает) – считается что так он и должен работать.
И неплохо сравнить как принудительная очистка работает в Java.
А уже потом рассуждать, о подобных вещах…
У меня почему-то все везде работает, при том что я GC.Collect вообще не юзаю.
И правильно, толку от него…
Насчет «все и везде» мои поздравления. Первый раз такое слышу, от программиста.
Холивар и вправду пора заканчивать.
Потому как конструктива все меньше, и начинается рвание тельняшек на груди.
От множественного наследования, например, просто отказались.
Множественное наследование никогда и не входило в стандарт на язык C#.
Время создания несколько разные. Когда была создана Java, и когда «первый» NET язык?
Действительно, когда создавали жабу, никто и не слыхивал про unsigned-типы, enumы и прочие мудреные вещи, которые даже в Си были четверть века назад.
студии с непостижимой быстротой выпускает
Раз в 2 года - офигеть непостижимость.
Работа сборщика у джавы несравнимо совершеннее
Утверждение о том, что жаба сама по себе быстрее сишарпа ты уже слил. Пример, где гц жавы рвет дотнетный всухую в студию.
Претензии не ко мне, а к исследователям.
Претензии именно к тебе, потому что ты преднамеренно исказил данные этих самых исследователей. Которые, кстати, показывают только то, что в период жабного бума индусами было написано на ней дофига говнософта, но не относятся к нынешнему положению вещей.
Множественное наследование никогда и не входило в стандарт на язык C#.
И смысл этого предложения?
С# был стандартизирован позднее, чем был создан. А отказ от множественного наследования – просто специфика Майкрософт, которая привыкла к интерфейсам.
Наплевать им на стандарты. Было. До сих пор.
Пока не пролетели с Вистой. А теперь у их новейшей семерки, новый облом.- «черный экран смерти». Репутация мелкософта никогда еще не была так высока…
Действительно, когда создавали жабу, никто и не слыхивал про unsigned-типы, enumы и прочие мудреные вещи, которые даже в Си были четверть века назад.
Джава никогда не претендовал на нишу Си.
Раз в 2 года - офигеть непостижимость.
Обновлять – хоть каждый месяц. А выпускать новый продукт… Ведь это новый продукт, если носит другое название и продается отдельно??? – это перебор.
Цикл разработки серьезного ПО больше двух лет. И ни один серьезный производитель не будет писать под столь бурно мутирующую среду как Дырка- нЭт.
Утверждение о том, что жаба сама по себе быстрее сишарпа ты уже слил. Пример, где гц жавы рвет дотнетный всухую в студию.
Примеры в гугле.
Ну а если сможете ответить на вопрос, каким образом на слабеньких смартфончиках работают джава приложения ничем не уступающие аналогичным (причем часто написанным на родном коде) для КПК поход в гугл не понадобится.
Претензии именно к тебе, потому что ты ПРЕДНАМЕРЕННО исказил данные этих самых исследователей.
Телепат однако?
Которые, кстати, показывают только то, что в период жабного бума индусами было написано на ней дофига говнософта, но не относятся к нынешнему положению вещей.
Говнософт он потому что написан на джаве или потому что индусами или потому что много?
Ну а может индусы по определению тупее, потому как пишут только «говнософт» в невероятных количествах на презренной джаве, и только благодоря столь бездарной "говнополитике" Индия смогла стать крупнейшим производителем софта?
Никто ничего не искажал. Каждый видит, то что хочет. И приведенная статистика означает лишь одно.
1. На сегодня Java самое популярное в мире средство разработки.
2. С# не конкурент джаве. Я бы сказал, что на снижение джавы более всего сказался рост популярности РНР.
3. С# вытесняет Дельфи – это их ниша. За счет этого в основном и рост популярности С#.
Ты утверждал, что отсутствие мультинаследования в C# противоречит стандарту. Но оно не противоречит стандарту на язык C#.
С# был стандартизирован позднее, чем был создан.
Пример обратного в студию.
А отказ от множественного наследования – просто специфика Майкрософт
А в жабе, значит, мультинаследование есть?
Джава никогда не претендовал на нишу Си.
При чем здесь ниша или не ниша? Во всех нормальных императивных языках есть циклы, условия, массивы и богатый набор встроенных типов.
Обновлять – хоть каждый месяц.
Распространение заведомо ложной информации. Сервис-паки к студиям выходят очень редко.
И ни один серьезный производитель не будет писать под столь бурно мутирующую среду как Дырка- нЭт.
Почитай про Java 1.7, увидишь, что мутирует, а что логично развивается.
Примеры в гугле.
Слив защитан.
каким образом на слабеньких смартфончиках работают джава приложения ничем не уступающие аналогичным
Ну по потреблению памяти и проца точно не уступают.
Телепат однако?
Конечно, цифры сами изменились, пока ты их копировал. Это всегда такое бывает с буфером обмена - очень уж он любит привирать в пользу жабы.
Говнософт он потому что написан на джаве или потому что индусами или потому что много?
Первое и второе.
Индия смогла стать крупнейшим производителем софта?
Индия не крупнейший производитель софта, а крупнейший аутсорсер. Вообще-то большая разница.
Делпхи давно мертв, C# вытесняет жабу: из веба, из гуи, из внутреннего софта, а с развитием платформы Windows Mobile начнет вытеснять и из мобильных устройств.
Да, это не молоток. Крайне точное замечание.
Принудительная очистка ресурсов – должна освобождать ресурсы принудительно. Не так ли? На то она и принудительная.
Для подобных виртуальных систем это крайний случай. А не ставить их в очередь очистки, которое произойдет на усмотрение системы. А может и не произойдет.
Сборка мусора, запущеная принудительно, не сможет сделать больше чем сборка мусора, запущеная системой автоматически.
Более того, сборка мусора, запущеная принудительно, с большой вероятностью только ухудшит показатели приложения.
Смотрим пример. Создаем 100 миллионов объектов
staticvoid DoWork()
{
for (int i = 0; i < 100000000; i++)
{
SomeClass obj = new SomeClass();
}
}
Первое предположение, из-за того что нигде не запускается принудительная сборка мусора, приложение займет много памяти. Однако если запустить, можно убедиться что Working Set не выходит за пределы 12МБ.
Как видишь, нигде явно я не даю команд очищать память, не освобождаю ссылки и не запускаю сборщик мусора.
Делаем принудительный заупск сборщика мусора на каждые 1000 объектов
staticvoid DoWork()
{
for (int i = 0; i < 100000000; i++)
{
SomeClass obj = new SomeClass();
if (i % 1000 == 0)
GC.Collect();
}
}
Итог - Working Set не поднимается выше 10 МБ (против 12 в автоматическом режиме, разница в 2 МБ несуществена), время работы выросло в 4 раза.
Второй пример.
Объекты не просто создаем, но еще и добавляем в локальный список.
staticvoid DoWork()
{
List<SomeClass> list = new List<SomeClass>();
for (int i = 0; i < 100000000; i++)
{
SomeClass obj = new SomeClass();
list.Add(obj);
}
}
Запуск - приложение занимает 3.2 ГБ памяти. Что вполне ожидаемо.
Вариант с принудительной сборкой мусора:
staticvoid DoWork()
{
List<SomeClass> list = new List<SomeClass>(100000000);
for (int i = 0; i < 100000000; i++)
{
SomeClass obj = new SomeClass();
list.Add(obj);
if (i % 1000000 == 0)
{
GC.Collect();
Console.WriteLine(i);
}
}
}
Итог - потребление памяти не изменилось, время работы увеличилось в 6 раз (до 2 с лишним минут). При этом обрати внимание насколько редко пришлось запускать сборку мусора, иначе я бы просто не дождался результатов.
Чтоб понимать почему в том или ином случае получаем такой результат, нужно ознакомиться с механизмом работы сборщика мусора.
А не кричать что GC.Collect не работает, не имея не малейшего понятия о ссылках, поколениях, куче, стеке, финализации, управляемых/неуправляемых ресурсах и прочих страшных вещах.
Если тема интересна, можешь в общих чертах ознакомиться (http://rsdn.ru/article/dotnet/GC.xml). Если нет, хватит писать глупости о том о чем понятия не имеешь.
Хорош чморить яву, желающим пропупыриться предлогаю написать подобие мобильного агента типа маил.ру, но для митуе и не на яве естессно, и чтоб работал на мобиле
Smith, никто не станет писать мобильного агента, потому что это совершенно ненужная программа. И весь сервис тоже. А вот миниопера 5 заставляет восхититься собой)
Winand я всё прекрасно понимаю, Sharp тоже надеюсь всё правильно понял.
Ато "Разработчиков" умных много, а агента до сих пор нет!
Нехочу, чтоб хаили язык, на котором пишут такие вещи как миниопера в том числе.
Еслиб не ява и не опера какбы я общался на любимом митуе?
Правильно, за дорого общалсябы
Первое предположение, из-за того что нигде не запускается принудительная сборка мусора, приложение займет много памяти. Однако если запустить, можно убедиться что Working Set не выходит за пределы 12МБ.
Итог - Working Set не поднимается выше 10 МБ (против 12 в автоматическом режиме, разница в 2 МБ несуществена), время работы выросло в 4 раза.
Запуск - приложение занимает 3.2 ГБ памяти. Что вполне ожидаемо.
Итог - потребление памяти не изменилось, время работы увеличилось в 6 раз (до 2 с лишним минут). При этом обрати внимание насколько редко пришлось запускать сборку мусора, иначе я бы просто не дождался результатов.
Это все проходил, еще на первом Фреймворке. Факт во времени – заметили как сильно тормозит приложение принудительная сборка мусора?
Проблема изначально была порождена тем, что все первые Фреймворки были надстройками на родными АПИ. И предполагали работу от 9х систем и выше.
Что бы как – то «разогнать» приложения(скорость их работы вызывала скептицизм при анонсах, что вполне понятно, учитывая "вытеснющую тормознутость" виндовс осей), разработчики пошли вполне "логичным" путем.
Они стали держать объекты в памяти. Без всякой очистки. Которая начиналась лишь при нехватке ресурсов. Какие тормоза выдает сборка – пример привели. И что самое неприятное – эффект от нее незначительный (и кстати какой Фреймворк?).
Джава изначально создавалась для кодирования различных микросистем. Т.е. систем с очень слабыми и ограниченными ресурсами.
И там такой подход был просто невозможен. Поэтому очистка реализована принципиально по другому.
У меня сейчас нет под рукой, Джавы. Но насколько помню, сборка происходила быстро и однозначно (если конечно не было хронических багов для конкретной платформы – потому как не забывайте, джава стоит на просто невероятном количестве платформ – даже телефоны разных марок одного производителя – уже разные платформы, а сколько производителей??? осей для ПК и т.д. ).
Автосборка работает четко – без всяких удерживаний объектов в памяти, на всякий случай, пока ресурсы позволяют…
И принудительная также.
Чтоб понимать почему в том или ином случае получаем такой результат, нужно ознакомиться с механизмом работы сборщика мусора.
А не кричать что GC.Collect не работает, не имея не малейшего понятия о ссылках, поколениях, куче, стеке, финализации, управляемых/неуправляемых ресурсах и прочих страшных вещах.
Неужели еще один телепат? Откуда Вам известно, о чем имею понятия, а о чем нет?
Если нет, хватит писать глупости о том о чем понятия не имеешь.
Ты утверждал, что отсутствие мультинаследования в C# противоречит стандарту. Но оно не противоречит стандарту на язык C#.
MS решил что создал великолепный язык, и провел его стандартизацию. Свою.
Ну и на каком месте, сие творение?
Пример обратного в студию.
Пример чего? Как пропихивается новый стандарт?
Стандартизация языка, стандартам не отвечающего – прецедент довольно интересный.
А в жабе, значит, мультинаследование есть?
Но он и не стандартизирован. Хотя учитывая популярность – просто должен быть.
При чем здесь ниша или не ниша? Во всех нормальных императивных языках есть циклы, условия, массивы и богатый набор встроенных типов.
А что циклов и т.д. в джаве нет? Вот – те на…
Богатейший не стоит путать с излишним….
Распространение заведомо ложной информации. Сервис-паки к студиям выходят очень редко.
Зато очень часто выходят новые студии…
У 2005 кажись 3 пака было… А четвертый назвали VS2008
Почитай про Java 1.7, увидишь, что мутирует, а что логично развивается.
Это сугубо ИМХО каждого.
Слив защитан.
Вам кажись примеры привели с той же оперой? Вы хотели посмотреть как она «рвет» нет – убедитесь.
А все эти сравнительные тесты, все равно легко оспорить. А тут уж факт…
Ну по потреблению памяти и проца точно не уступают.
Когда же появится долгожданный IE написанный на Си шарп для КПК?
Конечно, цифры сами изменились, пока ты их копировал. Это всегда такое бывает с буфером обмена - очень уж он любит привирать в пользу жабы.
Хватит бредить. Просто источники разные.
Тупо в гугле набил, и первое попавшееся скопипастил. И ничего сильно отличного от приведенного Вами там нет.
Что лишь подтверждает верность исследований.
Первое и второе.
А если индусы завалят рынок софтом на С#, он будет говнософтом или нет…?
Хотя сильно сомневаюсь, кому он нафинг сдался, этот С#.
Индия не крупнейший производитель софта, а крупнейший аутсорсер. Вообще-то большая разница.
Аутсорсинг – по русски кооперация. И если окончательную «сборку» проводят в USA, то это принципиально ничего не меняет… Хотя. Зачем вынуждать подрядчиков писать на таком отстойном языке?
Только вот не нужно про тупость индусов. И их неспособность освоить «высокие материи».
Если бы Вы хоть чуть думали, то понимали – что все решает спрос.
А спрос говорит – Джава рулит.
Просто большинство наших кодеров по прежнему пишут для внутрикорпоративного потребления(НЕТ, раньше Делфи). Джава язык несколько другого уровня.
Да…и пользователю глубоко наплевать, где и на чем написан софт.
Они стали держать объекты в памяти. Без всякой очистки. Которая начиналась лишь при нехватке ресурсов. Какие тормоза выдает сборка – пример привели.
Так и должно быть. Какой смысл делать дорогую сборку мусора, если памяти хватает? Расход памяти, пока он не начинает мешать другим программам, никого не интересует, зато интересует скорость.
Джава изначально создавалась для кодирования различных микросистем.
То, что жабе смогли отрезать все, что только можно, и засунуть получившееся в JME, который удалось запустить на довольно сильных современных мобильных устройствах, не значит, что она создавалась для кодирования различных микросистем. Более того, J2ME появилась лет эдак через 5 после выхода первой Java.
Откуда Вам известно, о чем имею понятия, а о чем нет?
Лектору по матану расскажешь, что он телепат, когда он тебе двойку поставит. Твои ответы говорят сами за себя.
провел его стандартизацию. Свою.
Какая разница, кто и когда провел стандартизацию? Если на что-то есть стандарт, у производителей есть гарантия, что придерживаясь его, они создадут совместимый продукт, а у потребителей - что этот продукт не поменяется радикально, разрушив все то, на чем они делали свою работу.
Хотя учитывая популярность – просто должен быть.
В жабе мультинаследования классов нет и не будет, как по идеологическим причинам, так и из-за ее архитектуры.
не стоит путать с излишним
Ага, натуральные числа и ноль это офигеть какие излишние числа.
У 2005 кажись 3 пака было
Распространение заведомо ложной информации. У студий 2003, 2005 и 2008 по одному сервис-паку.
Это сугубо ИМХО каждого.
Т.е. ты даже не читал?
Вам кажись примеры привели с той же оперой?
Пример преимущества гц жабы, а не пример любой программы на жабе. Я видел программы на жабе - у меня TopCoder Arena установлена. Ее уже лет 10 вылизывают и все никак не могут убрать баги и тормоза, потому что жаба.
Просто источники разные.
Источники не могут быть разные, есть только одна компания TIOBE, которая занимается рейтингами языков. Просто кое-кто любит цифры приукрасить.
А если индусы завалят рынок софтом на С#, он будет говнософтом или нет…?
Индусы на любом языке напишут говно.
окончательную «сборку» проводят в USA
Аутсорсинг это передача определенных бизнес-процессов (в данном случае - разработки некритичного к качеству ПО) другой компании, цель которой - экономия денег.
Только вот не нужно про тупость индусов. И их неспособность освоить «высокие материи».
Практика Code Jam показала, что в таких странах как Россия или Китай один финалист приходится на 30-40 человек, а в Индии - на 500. Причины тому вполне объективные: отсутствие качественного образования вкупе с наличием государственных курсов жабы, освоив которые любой полуграмотный индус, еще вчера стиравший одежду в Ганге, может стать аутсорсером.
все решает спрос. А спрос говорит – Джава рулит
Спрос на низкоквалифицированную рабочую силу есть всегда. Чистая случайность, что индийский госпроект по поддержке аутсорсинга пришелся на пик популярности жабы.
Да…и пользователю глубоко наплевать, где и на чем написан софт.
Только в том случае, если софт не глючит, не тормозит, и выполняет поставленную задачу, из чего жабе худо-бедно можно приписать только третий пункт.