Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 151
здорово, очень интересно, особенно мнения о java и сравнение с c#. очень трудно найти человека, который знает одинаково хорошо и то и другое и может трезво их сравнивать
Кушик вообще маньяк, он смог поднять на Andriod-е Mono, после чего начал его зверски тестировать и сравнивать с Dalvik-ом, в итоге очень интересные результаты получились и в комментариях нешуточная война разгорелась :) У меня на очереди как раз перевод Dalvik vs Mono :)
В Java вливались разработки тысяч коммерческих и некоммерческих фирм. Надзор за архитектурой Java осуществляет комитет JCP.org.
Так что говорить о сравнении .NET (которую разработала и ведёт одна Microsoft) с Java (над которой работают сотни компаний), не совсем корректно. Да, архитектурные подходы отличаются в силу того, что кода на Java в тысячи раз больше, чем кода на C#, а его надо поддерживать и обеспечивать обратную совместимость.
Да, да, «обратная совместимость» в .NET обеспечивается полным набором фреймворков, тогда как в Java совместимость обеспечивается последней версией JRE/JDK.
Так что говорить о сравнении .NET (которую разработала и ведёт одна Microsoft) с Java (над которой работают сотни компаний), не совсем корректно. Да, архитектурные подходы отличаются в силу того, что кода на Java в тысячи раз больше, чем кода на C#, а его надо поддерживать и обеспечивать обратную совместимость.
Да, да, «обратная совместимость» в .NET обеспечивается полным набором фреймворков, тогда как в Java совместимость обеспечивается последней версией JRE/JDK.
Вы явно незнакомы с .NET Framework :)
Ибо такую чушь даже самые большие адепты Java не скажут.
Ибо такую чушь даже самые большие адепты Java не скажут.
Приведите.
Лично меня привело в шоковое состояние множество библиотек для одного и того же GUI.
И все совсем не state of art
Лично меня привело в шоковое состояние множество библиотек для одного и того же GUI.
И все совсем не state of art
>>А что, в дотнети их не множество? WinForms, WPF, GTK# — сиди выбирай.
Это плохо? -))))))))
А теперь слушаем минусы WPF ^__^
Это плохо? -))))))))
А теперь слушаем минусы WPF ^__^
Слизана-то, может и слизана, но не тупо, а с необходимыми дополнениями и улучшениями.
В чем-чем, а в разработке средств для разработки (извините за каламбур) Майкрософт не одну собаку съел. И тот же MSDN это просто рай для разработчика в сравнении с разрозненным чисто описаловом для Java.
Простой пример, использование итератора (его более удобного подобия на C#) есть на MSDN в его описании, использование того же в Java нет в описании, поэтому и существует куча сайтов, где приходится искать эти примеры.
В чем-чем, а в разработке средств для разработки (извините за каламбур) Майкрософт не одну собаку съел. И тот же MSDN это просто рай для разработчика в сравнении с разрозненным чисто описаловом для Java.
Простой пример, использование итератора (его более удобного подобия на C#) есть на MSDN в его описании, использование того же в Java нет в описании, поэтому и существует куча сайтов, где приходится искать эти примеры.
Просто дженерики в Java появились на год-полтора раньше таковых в C#, поэтому и показались неудобными.
я не эскперт, но у меня вызывает сомнения пункт «Ужасные ограничения вокруг имен пакетов/файлов/каталогов/классов».
Мне больше нравится, как в яве — каждый класс отдельный файл с совпадающим названием. Я хочу работать с логической моделью программ — классами и пакетами и не хочу чтобы меня при жтом зщаставляли управлять файлами.
Мне больше нравится, как в яве — каждый класс отдельный файл с совпадающим названием. Я хочу работать с логической моделью программ — классами и пакетами и не хочу чтобы меня при жтом зщаставляли управлять файлами.
А продукты Гугла вообще отличаются очень грамотным проектированием, что серьезно снижает в них количество потенциальных проблем в будущем. Это что-то вроде их фирменного стиля.
Можно было написать «Друзья, каждая платформа имеет недостатки, но WM и Android одинаково хороши». А то выходит автор написал сравнение языков и все.
не согласен, автор хорошо разложил проблемы одной и другой платформы
Ничего себе, одинаково хороши :) Мне кажется, Кушик далеко не только языки сравнивал, а опыт разработки под обе платформы. Просто так языки сравнивать — чистый holly war.
Кроме сравнений возможности java, все это всплывает за неделю попыток разработать продукт под Android. По крайней мере у меня так было.
А я вот скачивал Android SDK, гонял разные демки UI, много радовался и т.д., но до реальной разработки руки не доходили, так что когда эту статью прочитал, решил, что перевод никому не повредит. Человек всё-таки несколько месяцев вникал в Андроид, чтобы написать этот пост, не с бухты барахты написал что попало.
Да вы все правильно решили :)
Лично для меня понимание структуры приложений под android немного сложновато дались. Это была 0.8 и 0.9 версия. Не было хороших статей, единственная книга, которая только вышла рассматривала шуточную программу по перехвату смс и установкой веселой мелодии. Сейчас думаю дело обстоит иначе. Я постоянно гоняю эмулятор андроида, особенно сейчас, когда выходят первые livecd.
Лично для меня понимание структуры приложений под android немного сложновато дались. Это была 0.8 и 0.9 версия. Не было хороших статей, единственная книга, которая только вышла рассматривала шуточную программу по перехвату смс и установкой веселой мелодии. Сейчас думаю дело обстоит иначе. Я постоянно гоняю эмулятор андроида, особенно сейчас, когда выходят первые livecd.
Извините за придирку, но всё же не «синтетический сахар» а «синтАКСический сахар»
Мне уже в личке сообщили, поправил. Даже нашёл определение: en.wikipedia.org/wiki/Syntactic_sugar
У меня почему-то было стойкое убеждение, что оба термина чуть ли не синонимы :))) Я заблуждался.
У меня почему-то было стойкое убеждение, что оба термина чуть ли не синонимы :))) Я заблуждался.
На счет эклипса я согласен. Как хорошо что есть IDEA и плугин к ней.
Я тут писал себе под андроид на IDEA, и потом решил что все же следуюет подробней вникнуть в нативный гуи (я игры пишу, мне нативный гуи в целом не нужен), так как в идеи нет редакторая, решил переключиться на эклипс. Был сильно опечален.
Вот уже думаю что проще забить и составлять гуи динамически.
Я тут писал себе под андроид на IDEA, и потом решил что все же следуюет подробней вникнуть в нативный гуи (я игры пишу, мне нативный гуи в целом не нужен), так как в идеи нет редакторая, решил переключиться на эклипс. Был сильно опечален.
Вот уже думаю что проще забить и составлять гуи динамически.
Почитайте обзор Android 1.5 в четырёх частях на mobile-review.com:
mobile-review.com/pda/articles/android-15-review-p1.shtml
mobile-review.com/pda/articles/android-15-review-p2.shtml
mobile-review.com/pda/articles/android-15-review-p3.shtml
mobile-review.com/pda/articles/android-15-review-p4.shtml
В обзоре рассматривается не просто Android, а применительно к тому, что «допилил» HTC для своего HTC Hero.
Ещё «другой вариант» — это Palm Pre, но он пока не спешит.
Но с весов MS сбрасывать всё равно нельзя, я полагаю, что девелоперы WinMo7 сейчас просто из штанов выпрыгивают, потому что WM 6.5 выходит в качестве мертворождённого, никаких революций в нём нет.
С Android какая ещё беда есть — открытость платформы делает возможность «кому попало» выпускать устройства на Андроиде, но там не будет нормальной интеграции с гугловскими сервисами и т.д. Это может негативно сказаться на имидже платформы. Вот, почитайте внимательно, что гады вытворяют:
www.computerra.ru/terralab/mobilis/442691/
mobile-review.com/pda/articles/android-15-review-p1.shtml
mobile-review.com/pda/articles/android-15-review-p2.shtml
mobile-review.com/pda/articles/android-15-review-p3.shtml
mobile-review.com/pda/articles/android-15-review-p4.shtml
В обзоре рассматривается не просто Android, а применительно к тому, что «допилил» HTC для своего HTC Hero.
Ещё «другой вариант» — это Palm Pre, но он пока не спешит.
Но с весов MS сбрасывать всё равно нельзя, я полагаю, что девелоперы WinMo7 сейчас просто из штанов выпрыгивают, потому что WM 6.5 выходит в качестве мертворождённого, никаких революций в нём нет.
С Android какая ещё беда есть — открытость платформы делает возможность «кому попало» выпускать устройства на Андроиде, но там не будет нормальной интеграции с гугловскими сервисами и т.д. Это может негативно сказаться на имидже платформы. Вот, почитайте внимательно, что гады вытворяют:
www.computerra.ru/terralab/mobilis/442691/
> загонит в микроскопичную нишу
:) Однако эта микроскопичная ниша — ниша дорогих девайсов, в которой у M$ доля не большая.
Да и если сравнивать зарубежный рынок, где ПО покупается, то там доля Apple не маленькая, это у насвсе многие левыми виндами пользуются…
:) Однако эта микроскопичная ниша — ниша дорогих девайсов, в которой у M$ доля не большая.
Да и если сравнивать зарубежный рынок, где ПО покупается, то там доля Apple не маленькая, это у нас
А что мешает использовать J2ME-аппараты?
Почитайте «белые страницы» Sony-Ericsson и узнайте, на что способны современные камерофоны (от OpenGL (ES) до GPS-позиционирования и работы с видеокамерой/звуком).
Почитайте «белые страницы» Sony-Ericsson и узнайте, на что способны современные камерофоны (от OpenGL (ES) до GPS-позиционирования и работы с видеокамерой/звуком).
Интересно сколько недель у человека опыта использования javы ?")
судя по всему, сравнение писал человек, который 10 лет писал для Windows Mobile и 5 лет на C#, а потом 3 месяца на Java.
естественно, он ставит в минус синтаксические особенности языка. привычка далеко не лучший фактор оценки языка.
естественно, он ставит в минус синтаксические особенности языка. привычка далеко не лучший фактор оценки языка.
отсутствие делегатов меня удручает в джаве.
но это ведь не повод говорить «отстой»?
Вообще-то никто с ними ничего не отгребает, непонятно чем обоснованная фраза.
Тру-ооп настолько же полезен, как и любое другое 'тру'. Красивое слово, позволяющее самого себя загнать в рамки.
Тру-ооп настолько же полезен, как и любое другое 'тру'. Красивое слово, позволяющее самого себя загнать в рамки.
всё равно это проблемы только для компилятора.
в рантайме пофик.
в рантайме пофик.
var f = (a, b) => a & b;
Это спорный пример — ни один статически типизированный язык с ним не справится.
Вот такой пример:
var f = (int a, int b) => a & b;
реалистичнее, но он не намного короче правильного варианта
Func<int, int, int> f = (a, b) => a & b;
поэтому авторы языка сэкономили и не сделали Func неявным типом для такого случая.
Я согласен что это недоработка.
С другой стороны, самое главное использование лямбд — создание обобщённых алгоритмов которые затем легко параметризуются локальной информацией от этого не страдает, т.к. в самом Where или OrderBy записаны типы параметров.
Проблема в том что без closures people.Where(p => p.Age = age && p.Salary > salary) делается гораздо сложнее. new FilterByAgeAndSalary? and(withAge(age), withSalary(salary))? И то и то требует хитрой системы хелперов, а зачем?
Ладно, для одного Where for убедителен, но мне не кажется что в Java будет только чуть-чуть длиннее (без yield).
А сортировка .OrderBy(x => x.LastName).ThenBy(x => x.FirstName).ThenByDescending(x => x.Salary), например, уже так просто не получится — придётся ре-имплементировать весь алгоритм сортировки.
С джавой у меня, кажется, та же проблема что и у автора — ничего такой язык, понятно за что его любит enterprise, но он же скучный by design. Это было и в одной презентации про closures: Java не язык для экспериментов. Из-за этого приходится намного длиннее писать во многих случаях.
Если есть выбор, C# или, кстати, Javascript интереснее (хотя JavaGI рулит как концепт, если бы все архитекторы Java мыслили так же широко, было бы отлично).
Смущает что Google, который в остольном довольно инновационен, продвигает этот язык.
А сортировка .OrderBy(x => x.LastName).ThenBy(x => x.FirstName).ThenByDescending(x => x.Salary), например, уже так просто не получится — придётся ре-имплементировать весь алгоритм сортировки.
С джавой у меня, кажется, та же проблема что и у автора — ничего такой язык, понятно за что его любит enterprise, но он же скучный by design. Это было и в одной презентации про closures: Java не язык для экспериментов. Из-за этого приходится намного длиннее писать во многих случаях.
Если есть выбор, C# или, кстати, Javascript интереснее (хотя JavaGI рулит как концепт, если бы все архитекторы Java мыслили так же широко, было бы отлично).
Смущает что Google, который в остольном довольно инновационен, продвигает этот язык.
Спасибо, хотя так спорить не интересно, если оба человека слишком вменяемые. :)
Мне на самом деле нравятся все фреймворки (4-ый C# разочаровывает, это да), потому что хотя в WPF куча недостатков со стилями, это всё очень клёвая штука, а Linq спасает от кучи циклов и прочих мучений на пустом месте. На самом деле с выходом Linq C# стал удобнее и иногда короче, чем Perl, что я считаю большим достижением.
Для Javascript в Visual Studio есть отличный дебаггер (хотя, конечно, к Андроиду он не мог бы подсоединиться), и Firebug тоже ничего. Я бы не сказал чтто его так уж мучительно отлаживать. Плюс там прекрасное метапрограммирование.
Мне на самом деле нравятся все фреймворки (4-ый C# разочаровывает, это да), потому что хотя в WPF куча недостатков со стилями, это всё очень клёвая штука, а Linq спасает от кучи циклов и прочих мучений на пустом месте. На самом деле с выходом Linq C# стал удобнее и иногда короче, чем Perl, что я считаю большим достижением.
Для Javascript в Visual Studio есть отличный дебаггер (хотя, конечно, к Андроиду он не мог бы подсоединиться), и Firebug тоже ничего. Я бы не сказал чтто его так уж мучительно отлаживать. Плюс там прекрасное метапрограммирование.
var f = (a,b)=>a&b невозможен в принципе в статически-типизированных языках. Не забываем, что оператор может быть перегружен и т.п. Если внутри одной функции компилятор еще хоть как-то может выяснить тип параметров, то в случае, если фуктор выходит за пределы функции, это невозможно. Поэтому функторы и не выводятся.
если человеку так нехватает этих фич, мог бы писать на Scala, а не ныть.
не разводите холиваров, тем более по вопросам очевидным
Что касается языка и среды разработки: есть Scala/Groovy & IntelliJ IDEA. Все они прекрасно работают с Android, если Java+Eclipse не устраивает.
Насколько я понимаю для C# он использует Visual Studio, а для Java — Eclipse.
Если сравнить голую VS (без ReSharper) и IDEA, то сравнение будет настолько сильно не в пользу первой, что даже как-то неловко.
Ну и глупости из разряда «смешная имплементация перечислений». Вот где она смешная, так как это как раз в .NET.
Про геттеры/сеттеры тоже очень и очень спорный вопрос. Мне, например, больше нравится их явное наличие, чем использование через property.
В общем сплошная вкусовщина, которая заканчивается шедевральным «За исключением того, что C# позволяет вести разработку быстрее, эффективнее, изящнее». На что можно только посоветовать попробовать правильную IDE и понять что VS — не более чем продвинутый блокнот.
Если сравнить голую VS (без ReSharper) и IDEA, то сравнение будет настолько сильно не в пользу первой, что даже как-то неловко.
Ну и глупости из разряда «смешная имплементация перечислений». Вот где она смешная, так как это как раз в .NET.
Про геттеры/сеттеры тоже очень и очень спорный вопрос. Мне, например, больше нравится их явное наличие, чем использование через property.
В общем сплошная вкусовщина, которая заканчивается шедевральным «За исключением того, что C# позволяет вести разработку быстрее, эффективнее, изящнее». На что можно только посоветовать попробовать правильную IDE и понять что VS — не более чем продвинутый блокнот.
Ну, вы тоже перегибаете :) «Продвинутый блокнот» — это жестко. Я лично не имею опыта работы в эклипсе, про него не могу аргументированно спорить. Зато имею приличный опыт работы в XCode. До VS2005/2008 не дотягивает однозначно.
Автор оперировал прилагательными быстрее и эффективнее (про изящнее действительно спорно и тут я скорее соглашусь с автором) — и вот сравнивая самые правильные IDE для .NET и Java у VS нет ни одного шанса против IDEA. В смысле быстроты и эффективности.
В общем-то читать можно было прекратить после «наконец глупая и неинтуитивная расстановка скобок» :)
В общем-то читать можно было прекратить после «наконец глупая и неинтуитивная расстановка скобок» :)
не очень долго (до этого vs 2003 и 2005 с решарпером в сумме года 4)
насколько успел заметить в 2008 потырили фишек решарпера (ну точнее всего остального цивилизованного мира правильных сред :), реализовав их как-то корявенько на мой взгляд
после нескольких месяцев на vs 2008 ушел на idea/java, где пока 1,5 года
насколько успел заметить в 2008 потырили фишек решарпера (ну точнее всего остального цивилизованного мира правильных сред :), реализовав их как-то корявенько на мой взгляд
после нескольких месяцев на vs 2008 ушел на idea/java, где пока 1,5 года
Вообще-то есть Resharper ;)
А вообще, работал я в компании с купленным решарпером, а потом в другой без оного… Разница невелика…
Все эти плюшки не особо важны… равно как и неважен язык.
Я плевался на Перл, но писал на нём два года… Ибо платили и было интересно новое.
Я плююсь на Яву, но если будут платить и будет интересно — буду писать на Яве.
А вообще, работал я в компании с купленным решарпером, а потом в другой без оного… Разница невелика…
Все эти плюшки не особо важны… равно как и неважен язык.
Я плевался на Перл, но писал на нём два года… Ибо платили и было интересно новое.
Я плююсь на Яву, но если будут платить и будет интересно — буду писать на Яве.
Почему это бессмысленные комментарии? Я участвовал в проекте по написанию с нуля кроссплатформенного (Windows/Linux/Solaris) Foundation (CoreFoundation доступен в исходниках, но и его приходилось в некоторых местах дописывать и коммитить в Apple) с использованием ObjC, доступного в GCC (не-Mac версия), лично писал весь NSKeyValueCoding (аналог Reflection в objC), и многое другое.
Когда работаешь в отладчике из XCode, то без GDB вообще не обойтись, причём иногда плюёшь на всё и работаешь только в GDB, потому что половина фич, которые в VS существовали годами, в XCode появляться начали вот только что…
Про «остроумно подсказывал» — ну о чём тут говорить, так или иначе, от версии к версии в XCode пытаются добавлять фичи, которые как я писал выше, в VS существовали годами.
Когда работаешь в отладчике из XCode, то без GDB вообще не обойтись, причём иногда плюёшь на всё и работаешь только в GDB, потому что половина фич, которые в VS существовали годами, в XCode появляться начали вот только что…
Про «остроумно подсказывал» — ну о чём тут говорить, так или иначе, от версии к версии в XCode пытаются добавлять фичи, которые как я писал выше, в VS существовали годами.
>Но вопрос остаётся открытым — зачем изобретать новый байт-код, когда IL не защищён подобным лицензированием (это ECMA одобренный стандарт)?
если речь технологии от мс, то с ней все очевидно как раз. она изначально задумана с целью развязывания патентных войн. потому гугл решил банально не рисковать.
если речь технологии от мс, то с ней все очевидно как раз. она изначально задумана с целью развязывания патентных войн. потому гугл решил банально не рисковать.
>Почему Java отстой? Давайте посчитаем.
часть пунктов — неправда.
>Среда разработки
слава богу, плагин для IDEA активно фиксят и он вполне юзабелен, особенно в 9ке.
>Ещё один пример: в Android пока нет поддержки потокого видео через Media Player
в 1.1 оно уже точно было.
>Байт-код
тут тоже много неправды, кстати.
Итого: познавательно для тех, кто не писал под андроид, но совершенно бесполезно для тех, кто писал.
часть пунктов — неправда.
>Среда разработки
слава богу, плагин для IDEA активно фиксят и он вполне юзабелен, особенно в 9ке.
>Ещё один пример: в Android пока нет поддержки потокого видео через Media Player
в 1.1 оно уже точно было.
>Байт-код
тут тоже много неправды, кстати.
Итого: познавательно для тех, кто не писал под андроид, но совершенно бесполезно для тех, кто писал.
Да, я не скрываю, что не писал под андроид и мне действительно было познавательно :) Пока сам не попробуешь — своего мнения не получить. А данная статья хоть и частично холиварная (а как без этого, если субъективно что-то не нравится?), но интерес-то подогревает к разработке для Андроида. Автор же сам пишет — угадайте, для какой платформы мне интереснее сейчас программировать?
Умоотвлечённая мысль (не ради холивора, а для расширения просторов фантазии): представьте себе тот день, когда Gecko и Fennec портируют на все мобильные платформы, так что окромя Джавы и C# можно станет сочинять также и на джаваскрипте, программируя XPCOM-компоненты... кроссплатформенный код, одинаково хорошо работающий под Windows Mobile и под Android...
Да это вообще мечта, но от халявной кроссплатформенности ИМХО владалец каждой платформы отбивается, как может :) Тот же Flash Lite работает на куче платформ, но аццки тормозит. В итоге кайфа ноль от такой кроссплатформенности :(
Тоже самое кричали и кричат до сих пор любители веб приложений. Однако когда первый iphone был ими ограничен люди были не довольны и сейчас качают полноценные проги.
>Gecko и Fennec портируют на все мобильные платформы
Тогда XML преобразования на клиенте совсем умрут. (А с ними и мечты о светлом будущем и w3c стандартах)
>кроссплатформенный код, одинаково хорошо работающий под Windows Mobile и под Android
Ну так Mono уже научились под Android запускать (причём оно работает быстрее Delvik)
Итого: Windows, MacOS X, Linux, Windows Mobile, Android.
Тогда XML преобразования на клиенте совсем умрут. (А с ними и мечты о светлом будущем и w3c стандартах)
>кроссплатформенный код, одинаково хорошо работающий под Windows Mobile и под Android
Ну так Mono уже научились под Android запускать (причём оно работает быстрее Delvik)
Итого: Windows, MacOS X, Linux, Windows Mobile, Android.
На самом деле c Mono не всё так радужно, в том плане, что на Windows Mobile у нас Compact Framework, а Compact Mono не существует, плюс P/Invoke от WinMo очевидно не заработает на Android :) Но радует, что прогресс есть в этом направлении. Если когда-нибудь получится полноценно запускать mono на Android, т.е. с GUI и т.д. — будет классно :) Пока что там это только Proof of concept.
я например программирую на java уже лет, но вот случилось такое — мне пришлось работать в проекте на Cи.
Я конечно разобрался, все мы сделали как надо, сдали проект вовремя, получили премию.
Но угадайте, было ли мне удобно после эклипса работать в Visual Studio? было ли мне приятно писать на Си? Смог ли я в полной мере использовать все фишки языка с которым я не так знаком как с основным?
> оба языка могут делать всё, что вам нужно, просто в каждом языке это нужно делать по-своему
Вот эта фраза ключевая, как мне кажется.
Я конечно разобрался, все мы сделали как надо, сдали проект вовремя, получили премию.
Но угадайте, было ли мне удобно после эклипса работать в Visual Studio? было ли мне приятно писать на Си? Смог ли я в полной мере использовать все фишки языка с которым я не так знаком как с основным?
> оба языка могут делать всё, что вам нужно, просто в каждом языке это нужно делать по-своему
Вот эта фраза ключевая, как мне кажется.
самое интересное, что когда мне пришлось переходить с Java на C# — претензий к языку было тоже более чем достаточно ;)
так что данный раздел скорее вопрос привычки к какомуто языку/инструменту.
если не так, как привык — значит скорее всего это плохо…
не смотрел как в оригинале статьи, но категоричность утверждения «java отстой» надеюсь все таки «особенности перевода». Иначе на остальные мнения автора и смотреть не захочется — чересчур субьективно и категорично. фанатизмом попахивает.
примерно тоже самое относится к описанию eclipse.
Тот кто работал с эклипсом при переходе на студию в обязательном порядке поставит resharper, ибо штатный intellisence оставляет желать (по крайней мере в 2005 студии)
так что данный раздел скорее вопрос привычки к какомуто языку/инструменту.
если не так, как привык — значит скорее всего это плохо…
не смотрел как в оригинале статьи, но категоричность утверждения «java отстой» надеюсь все таки «особенности перевода». Иначе на остальные мнения автора и смотреть не захочется — чересчур субьективно и категорично. фанатизмом попахивает.
примерно тоже самое относится к описанию eclipse.
Тот кто работал с эклипсом при переходе на студию в обязательном порядке поставит resharper, ибо штатный intellisence оставляет желать (по крайней мере в 2005 студии)
сейчас уже сложновато припомнить — почти три года прошло
тем более к многим вещам после перехода привык и они перестали раздражать (именно этот термин я бы использовал вместо «отстой»)
из того что вспомню:
очень не нравилось отстуствие строгого следования системе пакетов как в java (т.е. если класс называется my.pkg.MyClass то он обязан лежать в каталоге my/pkg/) — до сих пор считаю этот метод правильным и следую ему.
не нравился синтаксис namespace в отличии от package.
не нравилось что нет соглашения по именованию пакетов, классов, методов как в java (пакет всегда с прописной, класс с заглавной, метод с прописной) — в .net в этом плане каша полная
есть некоторое «неприятие» partial class. однажды написанный кемто класс есть черный ящик с интерфейсом использования. и тут мы дописываем партиал — делаем дырку сбоку класса и чтото в нем меняем. хорошо если без последствий. нафига тогда вообще модификаторы доступа? все сделать публичным и пусть лазит куда душа пожелает…
да я знаю, что на данной методолгии построен ряд вещей (asp.net, ado.net ...) в которых без этого былобы тяжело, но всетаки приятно знать, что класс my.pkg.MyClass лежит в каталоге my/pkg/, а не в еще нескольких местах
ЗЫ претензия к тому что у свойств в Java нет методов get|set мягко говря странная — у java нет свойств. есть члены класса и методы доступа. хотя свойства мне со временем скорее понравились.
естесно все сказанное мое личное imho :)
тем более к многим вещам после перехода привык и они перестали раздражать (именно этот термин я бы использовал вместо «отстой»)
из того что вспомню:
очень не нравилось отстуствие строгого следования системе пакетов как в java (т.е. если класс называется my.pkg.MyClass то он обязан лежать в каталоге my/pkg/) — до сих пор считаю этот метод правильным и следую ему.
не нравился синтаксис namespace в отличии от package.
не нравилось что нет соглашения по именованию пакетов, классов, методов как в java (пакет всегда с прописной, класс с заглавной, метод с прописной) — в .net в этом плане каша полная
есть некоторое «неприятие» partial class. однажды написанный кемто класс есть черный ящик с интерфейсом использования. и тут мы дописываем партиал — делаем дырку сбоку класса и чтото в нем меняем. хорошо если без последствий. нафига тогда вообще модификаторы доступа? все сделать публичным и пусть лазит куда душа пожелает…
да я знаю, что на данной методолгии построен ряд вещей (asp.net, ado.net ...) в которых без этого былобы тяжело, но всетаки приятно знать, что класс my.pkg.MyClass лежит в каталоге my/pkg/, а не в еще нескольких местах
ЗЫ претензия к тому что у свойств в Java нет методов get|set мягко говря странная — у java нет свойств. есть члены класса и методы доступа. хотя свойства мне со временем скорее понравились.
естесно все сказанное мое личное imho :)
>А зачем строгое?
иногда приходится по тем или иным причинам открыть файл не в студии.
тогда возникает вопрос «а где собственно?».
просто удобно.
Java это не просто предлагает, а требует
соглашения есть, но если посмотреть что творится в библиотеках…
на тот момент мне это не нравилось. потом смирился :)
>partial
да. добавить. и своим методом порушить всю логику работы класса.
хотя конечно и при наследовании можно напортачить :)
НО! не будет неожиданного поведения класса изза того, что коллега решил «взломать» класс и чтото в нем править своим методом
я не спроста упомянул ado.net — в нем без партиал былобы совсем тоскливо (опять же в 2005). особенно когда нагенерил кучу кода работы с таблицами, а потом оказывается, что с транзакцию можно прикрутить только через это самое заднее крыльцо — partial
иногда приходится по тем или иным причинам открыть файл не в студии.
тогда возникает вопрос «а где собственно?».
просто удобно.
Java это не просто предлагает, а требует
соглашения есть, но если посмотреть что творится в библиотеках…
на тот момент мне это не нравилось. потом смирился :)
>partial
да. добавить. и своим методом порушить всю логику работы класса.
хотя конечно и при наследовании можно напортачить :)
НО! не будет неожиданного поведения класса изза того, что коллега решил «взломать» класс и чтото в нем править своим методом
я не спроста упомянул ado.net — в нем без партиал былобы совсем тоскливо (опять же в 2005). особенно когда нагенерил кучу кода работы с таблицами, а потом оказывается, что с транзакцию можно прикрутить только через это самое заднее крыльцо — partial
>>partial
>да. добавить. и своим методом порушить всю логику работы класса.
>хотя конечно и при наследовании можно напортачить :)
>НО! не будет неожиданного поведения класса изза того, что коллега решил «взломать» класс и чтото в нем править своим методом
Стоп. Может я конечно чего-то не понимаю, но по моему и ты и твой собеседник не понимаете что такое partial.
Partial — это просто способ разбить ТЕКСТ кода класса на два ФАЙЛА. Partial никак не отражается на скомпилированном коде (примерно. как если в С++ часть кода написать в .h файле, а потом сделать include).
>да. добавить. и своим методом порушить всю логику работы класса.
>хотя конечно и при наследовании можно напортачить :)
>НО! не будет неожиданного поведения класса изза того, что коллега решил «взломать» класс и чтото в нем править своим методом
Стоп. Может я конечно чего-то не понимаю, но по моему и ты и твой собеседник не понимаете что такое partial.
Partial — это просто способ разбить ТЕКСТ кода класса на два ФАЙЛА. Partial никак не отражается на скомпилированном коде (примерно. как если в С++ часть кода написать в .h файле, а потом сделать include).
ну отчего же не понимаю
прекрасно понимаю
и использовал
да, это связано исключительно с исходником.
но представьте большой проект над которым работают несколько человек.
и ктото в своем куске решил, что некий класс работает не вполне так, как хочется и делает «ход конем»
а вы смотрите в опредение класса в том месте, где его в свое время положили и ранее смотрели — все как было, а ведет себя класс странно…
в большинстве случаев пример гипотетический, но если ктото может чтото сделать неправильно, он это сделает ;)
прекрасно понимаю
и использовал
да, это связано исключительно с исходником.
но представьте большой проект над которым работают несколько человек.
и ктото в своем куске решил, что некий класс работает не вполне так, как хочется и делает «ход конем»
а вы смотрите в опредение класса в том месте, где его в свое время положили и ранее смотрели — все как было, а ведет себя класс странно…
в большинстве случаев пример гипотетический, но если ктото может чтото сделать неправильно, он это сделает ;)
Просто есть языки, в которых это возможно уже после компиляции (MixIn'ы и множественное наследование).
А от «ходов конём». мне кажется, ничего не спасёт.
А от «ходов конём». мне кажется, ничего не спасёт.
По моему скромному опыту, partial классы применяются очень редко. В принципе, он нужен только для автогенеренного кода — вот здесь без partial было бы очень плохо.
>Мы не можем ничего менять. Только добавлять новые члены.
Не можем.
Partial — всего лишь директива компилятора.
Не можем.
Partial — всего лишь директива компилятора.
А в objective c (который в macosx и iphone) есть такая фича у NSObject как poseAs, которая позволяет подменить любой класс своим — конструкторы и т.д. будут возвращать экземпляр подменённого класса везде… А вы тут на partial жалуетесь :)))
вообщето в Java такой финт тоже можно сделать применив свой classloader или просто положив свой класс в classpath раньше :)
я не то чтобы жалуюсь. я понимаю что в данном продукте (.net) без этого просто никак…
ну любит мс так делать — сначала создаем красивое, логичное здание, но чегото в нем нехватает для когото.
поэтому берется ломик и проделывается дыра в стене. некрасиво? да. зато можно быстро добраться к ящику пива, а не обходить вокруг здания к парадному входу (это я так прозрачно намекаю на «Нет доступа к unsafe-коду» — если нельзя, но очень хочется, то можно)
Опять же про этот unsafe код.
просто надо учитывать, что unsafe является платформозависимым, что не вписывается в концепции java как кроссплатформенного решения
я не то чтобы жалуюсь. я понимаю что в данном продукте (.net) без этого просто никак…
ну любит мс так делать — сначала создаем красивое, логичное здание, но чегото в нем нехватает для когото.
поэтому берется ломик и проделывается дыра в стене. некрасиво? да. зато можно быстро добраться к ящику пива, а не обходить вокруг здания к парадному входу (это я так прозрачно намекаю на «Нет доступа к unsafe-коду» — если нельзя, но очень хочется, то можно)
Опять же про этот unsafe код.
просто надо учитывать, что unsafe является платформозависимым, что не вписывается в концепции java как кроссплатформенного решения
>очень не нравилось отстуствие строгого
Обычно это называется «наличие гибкого»
>в .net в этом плане каша полная
Покажите пример. Между прочим, FxCop (встроенный в студию) на такие вещи ругается.
>однажды написанный кемто класс есть черный ящик с интерфейсом использования.
Не написанный, а скомпилированный. Так и есть.
>класс my.pkg.MyClass лежит в каталоге my/pkg/, а не в еще нескольких местах
Если это Ваш клас, так положите его куда хотите, а если он не ваш, так он и в Java лежит не так.
Обычно это называется «наличие гибкого»
>в .net в этом плане каша полная
Покажите пример. Между прочим, FxCop (встроенный в студию) на такие вещи ругается.
>однажды написанный кемто класс есть черный ящик с интерфейсом использования.
Не написанный, а скомпилированный. Так и есть.
>класс my.pkg.MyClass лежит в каталоге my/pkg/, а не в еще нескольких местах
Если это Ваш клас, так положите его куда хотите, а если он не ваш, так он и в Java лежит не так.
в Java он ВСЕГДА лежит именно так
будь это каталог classes или библиотечный архив (jar).
иначе рантайм его просто не найдет
FxCop в какой версии студии? в 2005 такого не помню. 2008 не пользовался
будь это каталог classes или библиотечный архив (jar).
иначе рантайм его просто не найдет
FxCop в какой версии студии? в 2005 такого не помню. 2008 не пользовался
>в Java он ВСЕГДА лежит именно так
>будь это каталог classes или библиотечный архив (jar).
>иначе рантайм его просто не найдет
Не совсем понимаю. Разве java не позволяет использовать jar архивы, лежащие, например, в папке программы? Думаю, что позволяет.
Далее, dll библиотека — это хоть и аналог package, но архивом не является (хотя иерархия классов в ней есть).
>FxCop в какой версии студии? в 2005 такого не помню. 2008 не пользовался
В 2005й он, вроде, был эддоном.
>будь это каталог classes или библиотечный архив (jar).
>иначе рантайм его просто не найдет
Не совсем понимаю. Разве java не позволяет использовать jar архивы, лежащие, например, в папке программы? Думаю, что позволяет.
Далее, dll библиотека — это хоть и аналог package, но архивом не является (хотя иерархия классов в ней есть).
>FxCop в какой версии студии? в 2005 такого не помню. 2008 не пользовался
В 2005й он, вроде, был эддоном.
jar можно положить куда угодно. главное чтобы в classpath попало
а внутри jar структура дерева полностью сохраняется
каталогов с исходниками, кстати, может тоже быть несколько. например если из каждого из деревьев собирается отдельная библиотека.
сделано это, для того чтобы свести к минимуму вероятность перекрытия классов с одинаковым именем (пакет+класс). но, как показывает практика, это спасает далеко не всегда. что приводит к неожиданным казусам, когда компилятор выдает ошибку на какойто метод, а в исходнике его и близко нет.
в моем случае это было с классом типа com.company.utils.Tool
если коллега дал распечатку какогото класса и там есть строки package и class вы достаточно быстро найдете где этот класс лежит.
на так давно довелось покопаться в С++ проекте.
когда нескоклько классов лежат в одном файле, да еще и класс называющийся например xmlparser лежит в файле xmpar.cpp который лежит в одном каталоге с сотней других файлов в формате 8.3 — чтото найти можно только полнотекстовым поиском или после индексации всего проекта в IDE
так что, с моей точки зрения, это просто удобно.
а внутри jar структура дерева полностью сохраняется
каталогов с исходниками, кстати, может тоже быть несколько. например если из каждого из деревьев собирается отдельная библиотека.
сделано это, для того чтобы свести к минимуму вероятность перекрытия классов с одинаковым именем (пакет+класс). но, как показывает практика, это спасает далеко не всегда. что приводит к неожиданным казусам, когда компилятор выдает ошибку на какойто метод, а в исходнике его и близко нет.
в моем случае это было с классом типа com.company.utils.Tool
если коллега дал распечатку какогото класса и там есть строки package и class вы достаточно быстро найдете где этот класс лежит.
на так давно довелось покопаться в С++ проекте.
когда нескоклько классов лежат в одном файле, да еще и класс называющийся например xmlparser лежит в файле xmpar.cpp который лежит в одном каталоге с сотней других файлов в формате 8.3 — чтото найти можно только полнотекстовым поиском или после индексации всего проекта в IDE
так что, с моей точки зрения, это просто удобно.
Полностью согласен.
Мне так же не понравились еще пара вещей: неудобная система внутренних классов(нет доступа к полям родителя, надо указывать родителя явно), нет анонимных классов.
Не понравился стиль именования свойств(с большой буквы): бывает, что название свойства полностью совпадает с названием получаемого класса.
Ну и, конечно, не удобная расстановка скобок =) хотя это просто вопрос привычки. Я на c++ писал скобки как в java, поэтому мне привычней она. Но в любом случае привыкаешь.
Но некоторых вещей в джаве действительно не хватает после шарпа. Тех же замыканий и делегатов…
Мне так же не понравились еще пара вещей: неудобная система внутренних классов(нет доступа к полям родителя, надо указывать родителя явно), нет анонимных классов.
Не понравился стиль именования свойств(с большой буквы): бывает, что название свойства полностью совпадает с названием получаемого класса.
Ну и, конечно, не удобная расстановка скобок =) хотя это просто вопрос привычки. Я на c++ писал скобки как в java, поэтому мне привычней она. Но в любом случае привыкаешь.
Но некоторых вещей в джаве действительно не хватает после шарпа. Тех же замыканий и делегатов…
Это вы ещё Ruby не видели…
Вообще — возможность расширять существующий поднятый класс, это мегафича, по моим наблюдениям…
Имею опыт несколько лет в C#, и совсем немного в Ruby, так вот фича расширения классов — самая замечательная.
Вообще — возможность расширять существующий поднятый класс, это мегафича, по моим наблюдениям…
Имею опыт несколько лет в C#, и совсем немного в Ruby, так вот фича расширения классов — самая замечательная.
Автор — фанат программирования для мобильных устройств. Не существует понятия «абсолютная истина», везде есть субъективизм. Напомню, человек долго программировал для Windows Mobile, перешёл на Android, хочет под него программировать и регулярно натыкается на «косяки» на его взгляд. Но ему всё равно нравится платформа и он под неё программирует.
В оригинале: «Java sucks». Я мог бы перевести дословно: «Java сосёт», но что «сосёт», что «отстой» — разница не велика.
Кстати, я лично от решарпера достаточно быстро устал и снёс, штатный intellisense для меня достаточно хорош.
В оригинале: «Java sucks». Я мог бы перевести дословно: «Java сосёт», но что «сосёт», что «отстой» — разница не велика.
Кстати, я лично от решарпера достаточно быстро устал и снёс, штатный intellisense для меня достаточно хорош.
>производительность
Дело в том, что написанное на коленке Mono оказалось быстрее хвалёного Dalvik.
Дело в том, что написанное на коленке Mono оказалось быстрее хвалёного Dalvik.
Я собираюсь перевести вот эту статью в ближайшее время: www.koushikdutta.com/2009/01/dalvik-vs-mono.html
Боюсь, правда, что комментарии, которые тоже крайне интересны, я могу все не осилить, хотя они важны :)
Тем не менее, вы можете и сейчас посмотреть бенчмарки и т.д.
Боюсь, правда, что комментарии, которые тоже крайне интересны, я могу все не осилить, хотя они важны :)
Тем не менее, вы можете и сейчас посмотреть бенчмарки и т.д.
было бы удивительно, если б Dalvik без JIT'а показал приличную скорость…
Да и потом, никто и не обещал космических скоростей от Dalvik'а…
Да и потом, никто и не обещал космических скоростей от Dalvik'а…
было бы удивительно, если б Dalvik без JIT'а показал приличную скорость…
Да и потом, никто и не обещал космических скоростей от Dalvik'а…
Да и потом, никто и не обещал космических скоростей от Dalvik'а…
Андрюха, молодец!
> За исключением того, что C# позволяет вести разработку быстрее, эффективнее, изящнее.[3]
Будут какие либо доводы касательно «быстрее и эффективнее»? («Изящнее» не рассматриваем совсем, как субъективное для каждого человека. Для многих это и минимализм же)
Будут какие либо доводы касательно «быстрее и эффективнее»? («Изящнее» не рассматриваем совсем, как субъективное для каждого человека. Для многих это и минимализм же)
Нет, IDEA действительно платная. Есть триал, вроде на месяц. Есть бесплатный варианты получения, но они не тривиальны, нужно доказать, что ты действительно подходишь по критериям.
да, платная.
но её цена (~250-300$) достаточно быстро окупается.
не хочется холиварить в этой теме, но по многим пунктам IDEA _значительно_ лучше Eclipse/Netbeans
но её цена (~250-300$) достаточно быстро окупается.
не хочется холиварить в этой теме, но по многим пунктам IDEA _значительно_ лучше Eclipse/Netbeans
А под Android можно писать нативные проги? То есть чтоб они уже были скопилированы в машинный код?
NDK вышел совсем недавно: developer.android.com/sdk/ndk/1.5_r1/index.html
Однако, целиком native программу нельзя будет сделать, можно только из Java вызывать «performance critical» методы, написанные на C/C++. Но ИМХО это нормально для Android.
Однако, целиком native программу нельзя будет сделать, можно только из Java вызывать «performance critical» методы, написанные на C/C++. Но ИМХО это нормально для Android.
холивары такие холивары
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Перевод: разработка для Android vs Windows Mobile