Здравствуйте, JavaBean, Вы писали:

JB>вот тут можно поподробней? не очень монял что была за задача и вчем неудобство ее решения
Согласен с astral_marine, в Java, пожалуй, этого действительно не хватает. С другой стороны, есть волна о том, чтобы в JSE7 включили замыкания, думаю, это решит подобные проблемы. Если же повторяемость кода "горизонтальная" (то есть в отношении вертикальной иерархии наследования объектов), с этим отлично уже сейчас справляется дополняющий ООП — АОП, который в Java представлен в виде AspectJ.

JB>Дженерик в яве достаточно простой, плюс пердоставляет дополнительные проверки типов при компилации. соответсвенно убираются ненужные конструции на проверку типа в коде.
Я бы даже сказал — слишком простой, а хотелось бы как в .NET, то есть runtime generics.

Здравствуйте, Glоbus, Вы писали:

G>Если бы все было так, то весь мир был уже писал на жабе: шутка ли — сократить сроки разработки в 3 раза.

Дык, оно так уже и есть

Здравствуйте, flashinc, Вы писали:

F>Вы знаете, я все-так много слышу про синтаксис. И еще много "генерализации", типа "много библиотек", "устоявшийся фреймворк"... А таки можно конекртное услышать?
F>Интересует вообще не сервер и не "бизнес". Каких библиотек? Чем Java фреймворк лучше
F>тех же скажем VCL? Чем он "устоявшееся"? Или лучше, чем какая-нибудь Crt, MFC, WTL, Qt, Stl, boost?

Тут нет (имхо) какого-то одного-двух супер ответов. Нет ничего такого, чтобы это узнать/выучить — и сразу "да, с++ отстой, на нем работать нельзя". Да очень даже можно. Просто есть 1001 мелочь, которые, складываясь вместе, дают выигрыш в скорости работы в разы (не всем).

Обработка исключений в с++ например — печальная история. Ведь исключением может быть что угодно, включая число/строку. У каждой библиотеки есть свой базовый класс. В java — базовый класс один и это здорово. Сколько усилий нужно предпринять в сях для получения стека вызова при исключении и насколько это легко в java. Я на сях без специализированной, построенной на макросах, библиотеки обработки исключений программировать попросту не сяду — а тут она есть и на блюдечке, причем на другом качественном уровне.

Работа с памятью — да, постоянно используя врапперы, соблюдая дисциплину кодирования и заучив десяток правил, ты сведешь проблемы к минимуму. А в Java для того, чтобы такие проблемы возникли, нужно очень постараться. Это освобождает ресурсы головного мозга для более важных вещей.

Про более грамотные среды разработки тут упомянули не просто так. В силу простоты языка распознавание конструкций, рефакторинг и поиск синтаксических ошибок в реальном времени делаются намного проще и качественней. Это мелочь, но без этой мелочи мне уже как-то жить некомфортно... Ну вот недавно мне нужно было написать switch по большому enum-у — а средство рефакторинга любезно сделало это за меня, съэкономив мне несколько минут тупого кодирования — для сей что-то такое сделать очень сложно.

Рефлекшн недооценивать не стоит. Это и Hibernate и Spring и JUnit и log4... все эти примеры особенно хороши потому, что хотя порты на с++ и существуют, но их возможности и удобство использования сильно ниже. Очень сильно.

Вот этот список можно продолжать очень долго. Ничего особенно убойного в нем нет — иначе все давным-давно на с++ забили. Но он большой и вкусный Это не значит, что у с++ нет сильных сторон и своей области применения — есть. Но для мэйнстрима, особенно корпоративного, он уже не является лучшим выбором. как когда-то.

У меня знакомый, который после трех лет разработки на плюсах (парень серьезный, сетевым программированием занимется, линукс патчит), страуструпа иногда с собой носил — говорит перечитывает.
Я был немного удивлен — в отличие от С++ Java почти на интуитивном уровне понятна.
Я сейчас тоже книжки по яве с собой ношу, но это книжки по фреймворкам, либо по различным стандартам, но никак не по синтаксису языка.

Здравствуйте, CreatorCray, Вы писали:

CC>Угу, помницца я как то работал в одной веселой конторе, там писали на жабе систему документооборота. Так вот проблема памяти там стояла очень остро. Потому как система непрерывно хавала память, когда она физически кончалась запускался GC — становилось полегче и так по кругу. На девелоперских машинах это было почти незаметно. Трабл вылез только когда начали ставить систему заказчику — вот тогда геморроя было хоть отбавляй...
Есть ведь методики устранения избыточного выделения памяти без сильного рефакторинга на основе гибких, слабых, мнимых ссылок — и это намного проще, нежели отследить все выделения памяти, за которыми забыл прибрать.

Мне интересно, насколько будут приведены реальные примеры,
насколько реальность отличается от обещаний.

Потенциал — не всегда работает в реальности. Тому много причин.
Ferrari, Porche — в потенциале очень и очень быстры. У них есть потенциал и большая мощь двигателя. Немножко отъезжаем за москву. Ставим Ferrari на проселочную дорогу... Вот и всё.
Понятно, что незачем так делать. Однако, в случае с java везде заявляется абстрактный потенциал. А мне нужна грубая проселочная дорога "реалий".

hibernate, reflection — это механизмы повышения абстракции. (программисты занимаюстся в основе своей повышением абстракции). я не вижу ни в hibernate, ни в возможности reflection чего-то такого, что невозможно было бы выполнить на других платформах.

касаемо приведенного примера с reflection и созданием объектов из XML...
Ну хорошо, допустим есть у нас такой механизм — воссоздается run-time структура объектов (скорее всего дерево?). А чем оно полезно, что вы будете делать с каждым новым объектом который создался из нового XML-описания? Каждый новый объект требует новой функциональности, не той что уже есть в приложении. Согласитесь, Вам ее необходимо написать.

И тут я на данном этапе не вижу разницы, как создавать конечную функциональность, описав в неведомом XML файле новый объект для того чобы он загружался с помощью рефлексии, или описав новый c++ класс, или дописав c++ код с тем чтобы он понимал новые ветки XML документа.

Здравствуйте, Дмитрий В, Вы писали:

ДВ>Здравствуйте, flashinc, Вы писали:

F>>Здравствуйте,
F>>мне хотелось бы услышать ответ, чем именно разработка на десктопной Java (SE) быстрее разработки на C++ ??
F>>Для конкретики возьмем, скажем, Microsoft Visual C++. Вопрос не про язык, именно про скорость разработки, про утилиты, библиотеки, методики итд..
F>>Говорят что разработка на java быстрее и дешевле. Так ли это?

F>>большая просьба! Не устраивать неинформативный флейм Java vs C++ !!!

Гыгы, автору темы его же сообщение процитировал
Ну кто ж знал что у него уже есть на этот счет определенное мнение?

Здравствуйте, Дмитрий В, Вы писали:

ДВ>У меня знакомый, который после трех лет разработки на плюсах (парень серьезный, сетевым программированием занимется, линукс патчит), страуструпа иногда с собой носил — говорит перечитывает.
ДВ>Я был немного удивлен — в отличие от С++ Java почти на интуитивном уровне понятна.
ДВ>Я сейчас тоже книжки по яве с собой ношу, но это книжки по фреймворкам, либо по различным стандартам, но никак не по синтаксису языка.

Если бы ты его читал, то знал бы, что там не только про синтаксис

зы: сам не читал, но представление имею

Здравствуйте, rsn81, Вы писали:

R>Есть ведь методики устранения избыточного выделения памяти без сильного рефакторинга на основе гибких, слабых, мнимых ссылок — и это намного проще, нежели отследить все выделения памяти, за которыми забыл прибрать.
Прибрать? В жабе?

_>Да, стандарт С++ более свободен и открыт для изменений. Любой разработчик компиляторов может вводить свои локальные вкусности. И это дает свободу выбора: хочеш пиши межплатформенный код для разных компиляторов, хочеш пиши код с жесткой привязкой к операционной системе, юзая все возможности ее без ограничений. Скажем, спрятать приложение в SystemTray в С++ это сущий пустяк, а вот в Java надо уже заморачиватся. Без гимора там не поюзаеш специфичиские для платформы вещие, а в С++ это делается легко и непренужденно.
Холивар разводите? В Java SE 6 есть поддержка System Tray. Но это так, к слову. Все сказанное вами не имеет отношения к скорости разработки, а есть предмет отдельного разговора. Универсальных платформ для разработки не существует, поэтому вполне естественно, что есть задачи, для которых С++ подходит лучше всего. Под конкретную задачу должна выбираться конкретная платформа.

_>Вот еще в Java нет макросов, мне приходилось писать кучу повторяющегося кода вместо нескольких десятков строчек кода с макросами.
_>Java прост, прост до примитивности, в этом ему до С++ действительно далеко. А хорошо ли это? Если задачи простые — то да! А вот если сложные, то тут можно уже поспорить, хотя бы взять ту ситуацию с макросами, что я описал выше. Пару строчек сложно кода бывают лучше чем пару сотен строчек примитивного кода.

Давайте тихо замнем тему с макросами, пока не набежал народ. Если вы под сложной задачей подразумеваете написание мозгодробительного выражения — пожалуйста, сколько угодно. На этом, правда, сложно заработать. Работодатели и заказчики больше любят понятный, легко поддерживаемый и гибкий код, написанный в рамках сроков и бюджета, и на 100% соответствующий поставленной задаче. "Понятный" в данном случае означает, что код может быть прочитан и понят любым разработчиком знакомым с синтаксисом языка, без необходимости долго разбирать, что намутил его предшественник. "Поддерживаемый" означает, что время устранения ошибки должно быть минимально. А для этого код должен быть отлаживаемым и хорошо структурированным. Ваши хваленые макросы в эту концепцию не вписываются, уж извините. То же касается и гибкости: инкапсуляция, полиморфизм и наследование нам даны для того, чтобы всегда иметь возможность сделать с кодом что-то, что не планировалось изначально. Случай из моей практики: некая компания пишет софт для обработки трафика с коммутаторов сотовой связи. Софт для коммутатора А и коммутатора Б отличается процессом сборки. Если определен макрос С, то у метода Foo::bar() компилируется одна ветка, если не определён, то другая. Представьте себе мой "восторг", когда меня попросили написать программу, которая работает с обоими типами коммутаторов. Объем кода был около десятка мегабайт.

_>Информация о типе во время выполнения — это зло, так считаю я и многие специалисты, которые занимаются рефакторингом. Информация о типе нарушает принцыпи объектно ориентрированного программирования — инкапсуляцию.
Мне кажется вы недостаточно хорошо владеете ООП. В общем случае инкапсуляция — это сокрытие информации о внутренней структуре некоторой сущности. Это никак не противоречит возможности во время выполнения получить информацию о внешнем интерфейсе этой сущности. Привет "специалистам, которые занимаются рефакторингом" (это в С++, видимо, нужно быть специалистом, чтобы заниматься рефакторингом?).

_>А в С++ этого нет? Вы, видимо, полохо знаете С++. STL, boost, wxWidgets, Qt, lib**** — это только начальный список межплатформенных бибиотек. А вот сколько есть межплатформенный библиотек для работы с XML, базами данных, сетью, потоками уже не перечесть.
ANSI С++ я знаю хорошо, так же как и многие библиотеки Qt, MFC и им подобные функционально проигрывают Eclipse RCP/EMF/GEF. Работой с XML или сетью вы никого не удивите, потому что в Java это входит в стандарт уже очень давно. Про работу с базой данных будете рассказывать, когда на С++ появится ORM уровня Hibernate.

_>На вкус и цвет приятеля нет. Я считаю, что Visual Studio куда намного удобней Eclipse и Intellij IDEA. Это ваше утверждение очень спорно.
Это ВАШЕ утверждение спорно. Речь идет не о личных предпочтениях, а о возможностях, которые IDE предоставляет разработчикам. Я-то как раз привел примеры функциональности, в которых упомянутые мной IDE сильно выигрывают.

Здравствуйте, Дмитрий В, Вы писали:

ДВ>...страуструпа иногда с собой носил — говорит перечитывает.
ДВ>Я был немного удивлен — в отличие от С++ Java почти на интуитивном уровне понятна.

Эээ? А ты читал Страуструпа?
Я его как-то перечитывал даже после того, как полностью на .NET перешел. Там ведь очень много интересного и полезного по ООП и вообще разработке и архитектуре.

Еще там много по stl. Что характерно — часто с пояснениями, почему сделано именно так и чем это хорошо.
Но по синтаксису языка??? Да там его и нет почти.

Здравствуйте, flashinc, Вы писали:

F>Мне интересно, насколько будут приведены реальные примеры,
F>насколько реальность отличается от обещаний.

У меня была возможнось сравнить на одной задаче скорость работы Java программистов и C++
Задача: реализация некоторого простого UI в браузере, 2004 год.
С одной стороны: Applet, AWT, JBuilder (т.е. наихудшее для Java разработки сочетание)
два программиста сделали за 2 месяца, работает быстро и надежно.
С другой стороны: ActiveX + IE, MS VS
два программиста делали три месяца, результат работает быстро, но в зависимости от
версии IE и погоды на марсе падает.

Общая зарплата у сишной группы была чуть больше, так что реальная эффективность — где-то 2 к 1.

Второй пример.
Задача: довольно сложный UI и требование "программа должна смотреться профессионально", 2006 год
1 группа: 2 C++ программиста, MS VS (опыт работы с VS в разработке интерфейсов — более года)
Через три месяца есть отдельные окошки, все вместе смотрится ужасно, возможности быстро добавлять логику — нет.
2 группа: 2 Java программиста (один, правда, segnor), Eclipse RCP (опыт работы с RCP — 0)
Через три недели реализована вся функциональность, сделанная первой группой, приложение легко модифицируется,
выглядит вполне профессионально.

Зарплаты обеих групп (в месяц) одинаковы. Реальная эффективность — где-то 5 к 1 в пользу Java,
по результатам опыта было принято решение закрыть разработку на VC и продолжать на Java.
Так как Eclipse RCP использует нативные компоненты, скорость работы приложений одинаковая (эклипс даже побыстрее).

==============
Конечно, тут есть тонкости — тот же Eclipse RCP позволяет очень быстро делать многое, но если хочется
экзотики — то увы, ее делать будет очень дорого, не дешевле C++
Время разработки аналогичного функционала на Swing будет больше, месяца два ушло бы (с использованием
дополнительных библиотек, понятное дело), но зато можно делать все. Ну и скорость работы может быть заметна для пользователей.

Здравствуйте, Дмитрий В, Вы писали:

ДВ>А в этом сообщении вопрос Java vs C++ переведен на более осязаемое понятие, а именно — деньги:
ДВ>http://rsdn.ru/forum/message/2510299.1.aspx

Автор: flashinc
Дата: 01.06.07

...

...некоторое время находился в полном ступоре, увидев здесь полный пост, который я делал
в другую тему, в другом RSDN форуме (всмысле до того как модератор перенес темы). были подозрения на глюк форума, затем на какой-то подвох с вашей стороны )))))))

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, Glоbus, Вы писали:

G>>Если бы все было так, то весь мир был уже писал на жабе: шутка ли — сократить сроки разработки в 3 раза.

L>Дык, оно так уже и есть

Индия еще не весь мир

Здравствуйте, Glоbus, Вы писали:

L>>Дык, оно так уже и есть

G>Индия еще не весь мир

Это вопрос времени.

B>>2. Простота языка и наличие множества типовых решений. Средства автоматического управления памятью (в Java утечки памяти связаны исключительно с ошибками в архитектуре; в C++ труднообнаружимая утечка может стать следствием невнимательности).
G>Не понимаю, как средства автоматического управления памятью помогут в написании десктопных аппликух.
JFYI, в Swing у компонентов нет даже методов dispose. Окошко закрылось — все почистилось самостоятельно. Рисков попасть не в ту область памяти — ноль.

B>>3. Есть мощное API для получения информации о типе во время исполнения (Reflection), к тому же усиленное введением в Java 5 аннотаций. С учетом возможностей по кодогенерации и созданию новых типов во время исполения программы, может сильно экономить время на написание кода.
G>А к десктопным аппликухам как это относится? Я вот на плюсах пишу ни один год и мне пока еще ни разу не требовалось во время исполнения создавать новые типы.
Я думаю, вам и в космос не приходилось летать. Задачи-то разные бывают. Например, есть у вас приложение для построения отчетов и есть ERP-система, с которой это приложение взаимодействует. Хранить в приложении объектную модель, аналогичную ERP, смысла нет никакого. Проще предоставить ему интерфейсы объектов: приложение сгенерирует на их основе прокси для удаленного вызова геттеров и всё. Соответствующие технологии в Java есть, ничего придумывать не надо, кода писать — минимум.

B>>4. Огромное количество библиотек и мощных фреймворков. Они быстро плодятся и развиваются, т.к. редко возникает необходимость в портировании (платформно-зависимый код встречается нечасто).
G>А что, qt какой-нить на плюсах уже отминили?
А вы сравните его с Eclipse RCP/EMF/GEF и т.п.

B>>6. Возможно, что-то забыл. Во всяком случае, я наблюдал, как коллеги пересаживались с С++ (с многолетним опытом) на Java и их производительность увеличивалась в разы.
G>В разы это во сколько — 2, 3, 4? Что, реально при переходе на жабу проект вместо 12 месяцев делался за 4 или за 3? Полная фигня.
Многие задачи реально в разы быстрее делаются. Например инструменты для редактирования иерархических моделей данных. Полчаса на генерацию прототипа из XML-схемы (модель данных, command layer, иерархическое представление в GUI и визуальный редактор свойств), три месяца на бизнес-логику (merge tool для групповой работы, валидация, генераторы документов) и юзабилити (мастера, иконки и т.д.). На плюсах то же самое делается за год.

G>З.Ы. На самом деле, языки типа С++, жабы, дотнета и т.п. — это просто гаечные ключи, которые применяются при решении задач — все эти ключи умеют крутить гайки. при том одни лучше крутят одни гайки, другие лучше крутят другие, плюсы например хорошо крутят все гайки, но для пользования этим ключам нужно иметь может чуть более высокую квалификацию, чем для других. И все эти разговоры типа "производительность после перехода с плюсов на жабу повысилась в разы" — профанация чистейшей воды. Если бы все было так, то весь мир был уже писал на жабе: шутка ли — сократить сроки разработки в 3 раза.
Я знаю как минимум одну крупную международную компанию, всерьез рассматривающую переход с Qt на Eclipse RCP. Так что смотрите, не проснитесь слишком поздно.

Здравствуйте, CreatorCray, Вы писали:

CC>Прибрать? В жабе?
Да. А что вас удивляет? Сборщик мусора не решает все проблемы.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, rsn81, Вы писали:

R>>Есть ведь методики устранения избыточного выделения памяти без сильного рефакторинга на основе гибких, слабых, мнимых ссылок — и это намного проще, нежели отследить все выделения памяти, за которыми забыл прибрать.
CC>Прибрать? В жабе?

Да. Утечки памяти случаются, если у разработчиков руки через одно место растут. Тривиальный пример — синглтон, у которого есть непрерывно пополняемая коллекция. Если по какой-то причине объекты из коллекции не уходят, это приводит (иногда через весьма длительный срок) к OutOfMemoryError.

Здравствуйте, Sinclair, Вы писали:

S>Я даже список стандартов привести затрудняюсь.

Вот он:
http://jcp.org/en/jsr/all

Здравствуйте, DPH, Вы писали:

DPH>Общая зарплата у сишной группы была чуть больше, так что реальная эффективность — где-то 2 к 1.

Java программисты — это тяжелая артиллерия, закаленная в разработке корпоративных проектов