В случае, когда для некоторых видов исключений есть общие действия, а потом rethrow, я предпочитаю использовать boolean-переменную, а блок обработки выносить в finally. Ибо очень не люблю дублирование кода, даже если это один вызов метода и следующий за ним rethrow.
В Java так повелось из-за JavaBeans. А теперь уже настолько распространено, что без следования этому стандарту с тебой ни один framework дружить не будет :-)
Кстати, дружить с чем-либо = уметь правильно использовать.
В Java для mutable-строк и подобных выкрутасов есть StringBuilder. Так что если проигнорировать синтаксический сахар, который дает перегрузка operator+() в плюсах — возможности идентичные.
Думаю, нужно еще добавить ошибки программирования. Которые иногда вносятся в результате объединения кода, написанного двумя разными людьми. По-отдельности все бы работало, а вместе — логическая бомба.
Как Java-программист, который начинал с C и C++, напишу свое впечатление.
Java хорош для знакомства с концепциями ООП. Также его проще начать использовать «на полную», чем C++. В первую очередь это обусловлено не сложностью C++, а тем, что для Java имеется довольно большая стандартная библиотека с подробнейшими JavaDOC. И тем, что не нужно напрямую работать с указателями и памятью.
Прискорбно, но факт: научить говнокодера на Java гораздо проще, чем на C++, и ошибок на выходе будет сравнительно меньше. Среди начинающих программистов имеется тенденция «сначала сделать, потом подумать». И Java лучше этому соответствует. А затраты на подобных «специалистов» сравнительно маленькие, т.к. профессионал за такие копейки никогда не возьмется работать.
У Java-библиотек на текущий момент есть весомый плюс — подробное документирование. Любой framework либо имеет свою подробную документацию, tutorial'ы, start guide'ы и примеры, либо является имплементацией одного из стандартных API (а для Java их немало, те же J2EE API). Кстати, в свое время я именно поэтому выбрал Java, т.к. сложность поиска документации для библиотек C++ и последующих попыток использования была сравнительно выше.
Напротив, сложность C++ компенсируется его мощнейшими возможностями, например, полноценными шаблонами и мета-шаблонами. Их так не хватает в Java! Generic'и спасают только для простых случаев, а когда хочется по-максимому обобщить небольшой framework, вырастают гиганты, такие, что Generic'и уже не работают.
Для Java-программистов: при использовании конструкции вида A<B, T extends A<B, T>> возникает очень много проблем, которые при полноценных шаблонах просто не возникли бы.
Про сборщики мусора: все очень удобно, но до той поры, пока не начнутся утечки памяти. И тогда приходится так же снимать дампы, анализировать. А если из-за расточительного использования памяти начинаются несвоевременные вызовы full GC, то время отклика приложения может выйти за допустимые пределы. Так что голову никто не отменял, она нужна все зависимости от языка программирования.
Также нельзя забывать про то, что в наше время есть много профессиональных программистов как на C++, так и на Java. Быстро переучиться с одного на другое не получится, потребуются существенные затраты времени. И ошибки также будут неизбежны на первых порах. Так что команды программистов на C++ и на Java еще долгое время сосуществовать, хотя бы из-за этого фактора.
Кто победит в итоге? Думаю, что ни C++ и ни Java. На текущий момент наблюдается тендекция к объединению различных парадигм (функциональная, логическая, процедурная). Так что, скорее всего, в итоге останется несколько таких мультипарадигменных языков, а какие именно — сильно зависит от того, кто и как будет их продвигать.
Попробуйте поискать «Компьютерное граблеведение» (с).
Кстати, дружить с чем-либо = уметь правильно использовать.
«Существуют только два вида языков: невыносимые и неиспользуемые».
Насколько же это верно… Медаль автору )
Java хорош для знакомства с концепциями ООП. Также его проще начать использовать «на полную», чем C++. В первую очередь это обусловлено не сложностью C++, а тем, что для Java имеется довольно большая стандартная библиотека с подробнейшими JavaDOC. И тем, что не нужно напрямую работать с указателями и памятью.
Прискорбно, но факт: научить говнокодера на Java гораздо проще, чем на C++, и ошибок на выходе будет сравнительно меньше. Среди начинающих программистов имеется тенденция «сначала сделать, потом подумать». И Java лучше этому соответствует. А затраты на подобных «специалистов» сравнительно маленькие, т.к. профессионал за такие копейки никогда не возьмется работать.
У Java-библиотек на текущий момент есть весомый плюс — подробное документирование. Любой framework либо имеет свою подробную документацию, tutorial'ы, start guide'ы и примеры, либо является имплементацией одного из стандартных API (а для Java их немало, те же J2EE API). Кстати, в свое время я именно поэтому выбрал Java, т.к. сложность поиска документации для библиотек C++ и последующих попыток использования была сравнительно выше.
Напротив, сложность C++ компенсируется его мощнейшими возможностями, например, полноценными шаблонами и мета-шаблонами. Их так не хватает в Java! Generic'и спасают только для простых случаев, а когда хочется по-максимому обобщить небольшой framework, вырастают гиганты, такие, что Generic'и уже не работают.
Для Java-программистов: при использовании конструкции вида A<B, T extends A<B, T>> возникает очень много проблем, которые при полноценных шаблонах просто не возникли бы.
Про сборщики мусора: все очень удобно, но до той поры, пока не начнутся утечки памяти. И тогда приходится так же снимать дампы, анализировать. А если из-за расточительного использования памяти начинаются несвоевременные вызовы full GC, то время отклика приложения может выйти за допустимые пределы. Так что голову никто не отменял, она нужна все зависимости от языка программирования.
Также нельзя забывать про то, что в наше время есть много профессиональных программистов как на C++, так и на Java. Быстро переучиться с одного на другое не получится, потребуются существенные затраты времени. И ошибки также будут неизбежны на первых порах. Так что команды программистов на C++ и на Java еще долгое время сосуществовать, хотя бы из-за этого фактора.
Кто победит в итоге? Думаю, что ни C++ и ни Java. На текущий момент наблюдается тендекция к объединению различных парадигм (функциональная, логическая, процедурная). Так что, скорее всего, в итоге останется несколько таких мультипарадигменных языков, а какие именно — сильно зависит от того, кто и как будет их продвигать.