>Как хорошо в Жабе после Це...

Жаба не отличила char от int

Ага, хорошо, да.

А мне С# больше нравится.

C# - посыпанная синтаксическим сахарком ява, или есть ещё различия?

После Си везде хорошо...

Иклипс разбирает вводимый код на лету, сразу видно опечатки

Эклипс делает ровно то же самое и для Си.

Одобряю этот пост!

> Про освобождение памяти вообще не думаю.

Авторы многого современного софта думают так же, к сожалению, даже если речь идёт о си.

>Как хорошо в Жабе после Це...

Весьма спорно. Смотря для каких задачек :)

Про освобождение памяти вообще не думаю.

Хмммм, правильно, RAM нынче дешёвая, 4Gb на машинку каждый себе позволить может.

Язык на первый взгляд проще C++ и мощнее С.

Он просто другой, Язык :) (запятые ???)

Жаба не отличила char от int

А я, всё время, думал что это работа программиста. Оказывается нет.

есть.

стоит сначала разобраться в вопросе, а потом говорить.

Восторженный кэп ворвался в тред, неся очевидность на право и на лево!

http://www.eclipse.org/cdt/

> Единственный момент, немного взбесивший меня - Жаба не отличила char от int, т.е. в контексте сравнения двух char можно было написать 0 и '0', и это компилятор проглотил, даже не выдав предупреждения...

надо не быдлокодить, а изучать спецификации языка, с которым работаешь, не важно - C или Java

Единственный момент

Единственный? Возможно просто мало времени прошло, а чтобы недостатки узнать надо поближе познакомится.

Чтобы понять примерно чего не хватает в яве можно здесь сравнение посмотреть:

Comparison of C Sharp and Java

Конечно в этом сравнении не все правильно, некоторые вещи просто пропущены, некоторые преувеличены, но можно его использовать как отправную точку.

Про освобождение памяти вообще не думаю.

Ну это до определенного момента. А как создашь какой-нибудь глобальный кэш - придется очень сильно подумать о памяти. И вдруг выяснится, что стандартные объекты сильно прожорливы до памяти.

На самом деле, целевая платформа моих хелловорлдов - Андроид. (Предчувствую гневные выкрики из зала «Это был не нескафэ!!!»... в смысле «не Жаба»)

Что касается быдлокодинга, IMHO с методической т.з. теорию лучше сопровождать практикой, а ещё лучше начинать с практики (особенно в условиях катастрофической нехватки времени), и по ходу дела обращаться к теории. Тем более что есть реальное устройство под рукой.

Тем более, что Жаба помогает быдлокодеру, а не мешает, как в C.
Так почему же не побыть (хоть бы на некоторое время) быдлокодером, ведь это так просто...
Не вижу ничего зазорного в быдлокодинге. А вы? В конце концов, мои хелловорлды ядерными реакторами не управляют, да и вообще никого из людей не обслуживают, ни на платной, ни на бесплатной основе.


P.S. «Неконтроль» за расходом ресурса в С в лучшем случае наказывается неудачами системных вызовов и libc, а в худшем (хотя это ещё вопрос, который из них действительно худший!), тем самым сбоем сегментирования. В принципе, всё это выявляется грамотным тестирование, хотя, наверное, бывают исключения... Жаба же в худшем случае выдаст читабельный трейс. Случаев безбожного падения самой VM я пока не видел, и надеюсь, что не увижу.

Все базовые утилиты под рукой, никакой суходрочки с консолью.

Что плохого в консоли? Написание небольших скриптов значительно упрощает ряд вещей. Даже не знаю, как можно без этого эффективно программировать. У меня например скрипт на баше обновляет приложение на сервере секунд за 5. При этом рядом сидит мышевоз, который на каждое обновление лезет в админ консоль, чего то там аплоадит, в общем долго это у него, минут 5 каждое обновление.

Единственный момент, немного взбесивший меня - Жаба не отличила char от int, т.е. в контексте сравнения двух char можно было написать 0 и '0', и это компилятор проглотил, даже не выдав предупреждения...

Часто это удобно. Хотя мне вообще не нравится то, как устроены символы и строки почти во всех языках. Строки должны быть в UTF-8, а символы 32-битные, но при этом конвертация из символа в его код исключительно явной.

>надо не быдлокодить, а изучать спецификации языка, с которым работаешь, не важно - C или Java

Спецификации - это так пошло и скучно... Мы хотим хлеба и зрелищ!

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

Жаба в худшем случае жрёт память. И в худшем жрёт не настолько много, чтобы это быстро проявилось, но и не настолько мало, чтобы на это можно было забить.

Правда отлаживать это несравненно проще, чем косяки с памятью в С. Сдампил память, и анализируй тулзами, какой там у тебя объект сколько памяти сожрал и кто на него ссылается.

>Правда отлаживать это несравненно проще, чем косяки с памятью в С. Сдампил память, и анализируй тулзами, какой там у тебя объект сколько памяти сожрал и кто на него ссылается.

В С тоже можно убить процесс, разрешив перед этим писать core dump. Ещё есть Valgrind (только тормозит, гадина, безбожно и стабильно). Видимо, основное отличие С от Java заключается в планировании управления ресурсами. В С лучше писать сразу правильно, в Java быдлокодер может отсрочить грядущие проблемы до наступления часа Х. IMHO cущественное преимущество Жабы в данном случае проявляется в случае мелких и средних проектов, потому что Жаба как более высокоуровневый язык позволяет гораздо быстрее получить работающий прототип системы и отладить всю логику, не соприкасаясь с сугубо техническими аспектами языка. Можно назвать такой подход быдлокодерством, я не против.


P.S. Жду-не-дождусь полноценного Жаба-процессора, чтобы непосредственно выполнял команды JVM.

>http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java

Both are __(primarily) statically, strongly and explicitly typed__

Да-а... надо думать, ключевое слово здесь «primarily».

>Жду-не-дождусь полноценного Жаба-процессора

Таненбаум в одной из книжек пишет, что это плохая идея и не будет реализована.

>Single-root (unified) type system   Java:No C#:Yes

>Таненбаум в одной из книжек пишет, что это плохая идея и не будет реализована.

Надо будет почитать его и проработать данный вопрос... Хотя вот в ARM так не посчитали и сделали Jazzle. Хотя там, если не ошибаюсь, инструкции JVM интерпретируются в рамках обычных команд ARM.

кроме отсутствия библиотек - никакой ;)

Главное для десктопа не пиши.

В Емаксе на лиспе целый день ваяешь, всё отладил, закоммитил, молодец. А на утро оказывается, что код не работает, ибо отладил его интерактивно со старой версией какой-нибудь функции, а новый вариант забыл перекомилить. И он вообще синтаксически неправильный.

Поэтому на пост-коммитном хуке висит скрипт, пересобирающий всю фигню и шлющий отчётым мылом. Мол, вот ты какой негодяй - сломал всё, поганец.

Впрочем, в лиспворксе чуваки той же проблемой страдают. Не могу сказать, что это прям болезнь, но иногда вылезает. Причём, у всех.

>P.S. Жду-не-дождусь полноценного Жаба-процессора, чтобы непосредственно выполнял команды JVM.

К сожалению,полноценного сделать сейчас экономически не оправданно.

>P.S. Жду-не-дождусь полноценного Жаба-процессора, чтобы непосредственно выполнял команды JVM.
Совсе полноценный вряд ли сделают. Но есть пока ARM с технологией Jazelle.

Суть топика

вообще не думаю

Этому треду не хватает лиспотроллей =)

Ты просто не юзал нормальных сред для C++ :3 и кстати, говорят для явы IntelliJ IDEA подходит в разы лучше эклипса. Правда она платная.

> В Емаксе на лиспе целый день ваяешь, всё отладил, закоммитил, молодец. А на утро оказывается, что код не работает, ибо отладил его интерактивно со старой версией какой-нибудь функции, а новый вариант забыл перекомилить.

Интерактивная разработка и образ системы рулят.

Энжой ёр динамическая типизация. Мыло от скрипта хотя-бы за вменяемое время приходит?

А С++ не отличил отсутствие delete a; от того что я имел ввиду! Виновата жаба, стопудов )))

Неа, Java+Delphi+а.зонд=C#

Стоит к жабке добавить С через JNI, и падение JVM станет постоянством. Ну пока баги все не исправите. А их ВСЕ тяжело исправить

IMHO cущественное преимущество Жабы в данном случае проявляется в случае мелких и средних проектов

Абсолютно противоположно. Основной профит в ГРОМАДНЕЙШИХ проектах

Жду-не-дождусь полноценного Жаба-процессора, чтобы непосредственно выполнял команды JVM.

Jazelle

>А С++ не отличил отсутствие delete a; от того что я имел ввиду! Виновата жаба, стопудов )))

Конечно жаба.

Энжой ёр динамическая типизация.

Дык, REPL. В каком-нибудь ML-образном со вменяемым REPL'ом то же самое будет.

Мыло от скрипта хотя-бы за вменяемое время приходит?

Через пару минут.

Интерактивная разработка и образ системы рулят.

Определённо. Но отрицательные моменты всё равно есть.

для явы IntelliJ IDEA подходит в разы лучше эклипса. Правда она платная

Бесплатная

Community Edition же сильно урезанная, разве нет?

Урезанная, да. В плане поддержки J2EE и DB plugins

В конце концов, мои хелловорлды ядерными реакторами не управляют ...

Как раз сегодня читал, как создать правильный Hello world на разных языках программирования в журнале ACCU Overload, October 2010. Как оказалось, это совершенно нетривиальная задача. Ведь простейший «Hello world», который везде приводится как пример, неправильно обрабатывает ошибки ввода-вывода.

Жаба же в худшем случае выдаст читабельный трейс.

Бывают случаи, когда трейс не выдается. Если исключения генерируются очень быстро то, для оптимизации, заполнение стэк трейса может пропускаться. Получишь «просто ошибку неизвестно где».

Или, что встречается гораздо чаще, кто-нибудь напишет catch (Exception ex) { /* do nothing */ }

Или, что гораздо хуже, кто-нибудь сделает finally { return 1; /* ignore all exceptions in tricky way */ }

Как вариант, исключение может быть обработано в недрах swing и молчаливо проглочено.

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

А я видел. OutOfMemory, PermGenSpace, исчерпание коннектов к базе на аппликейшен сервере из-за утечек коннектов, чудовищное падение производительности из-за большого количества утекших глобальных листенеров на клиенте и т.д. А надо понимать, что в некоторых случаях падением производительности равносильно отказу. Про Jini выше уже написали. Если учесть, что в стандартной яве отсутсвуют простейшие вещи, которые иногда нужны при разработке - вызов dll с возможностью динамического создания трамплинов для callback, чтение из реестра, работа с последовательным портом, работа c USB, работа с COM объектами в Win32, Win64 - то получим ситуацию более грустную, чем ту, которую рисуют маркетологи.

Сам я разрабатываю на Яве, и не отговариваю от ее использования. Но следует понимать, что Ява сама по себе не значит ничего, она не может спасти от ошибок проектирования и реализации. Это просто еще один язык программирования.

Строки должны быть в UTF-8, а символы 32-битные, но при этом конвертация из символа в его код исключительно явной.

Совершенно согласен - должна остаться только одна кодировка UTF-8. То, что внутри используется UTF-16 приводит к тому, что для ASCII текста объем раздувается вдвое.

К, сожалению, в Java исправить это уже никак невозможно. String везде жестко прибит гвоздями ко всему. И хотя имеется интерфейс CharSequence - он практически не имеет смысла по причине неиспользования в стандартных библиотеках.

Про 32-битные символы - интересная идея.

>> Про освобождение памяти вообще не думаю.

Это пока хеллоуворды пишешь. А потом придется еще и разобраться с алгоритмом работы сборщика мусора.

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

Ц++ тоже недолюбливаю (по сравнению с жабой). Но это личное)))

Вот-вот