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

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

_>Вот еще в Java нет макросов, мне приходилось писать кучу повторяющегося кода вместо нескольких десятков строчек кода с макросами.
Текстовые макросы в топку.
А в Java есть аннтоации и постпроцессинг (в купе с рефлекшином) это дает возможности реализовать вещи (типа AOP) которые в C++ не реализуемы (или очень сложно с кучей условностей).

_>Информация о типе во время выполнения — это зло, так считаю я и многие специалисты, которые занимаются рефакторингом.
Примерчик бы... что то не очень понятно. Возможно Вы не умеете его готовить. Рефлекшн ведь разный бывает.
1. чистый invoke в коде — зло
2. автоматизированный invoke на базе аннтоаций — добро (например декларативные транзакции или тот же AOP) и к рефакторингу не имеет никакого отношения
3. если очень не хватает макросов — можно создавать классы в рантайме (плохо, но иногда очень надо) или инструментировать байткод — но это тоже зло

_>На вкус и цвет приятеля нет. Я считаю, что Visual Studio куда намного удобней Eclipse и Intellij IDEA. Это ваше утверждение очень спорно.
Тут не "вкус/цвет", а простой количественный подсчет. Хочу поглядеть на поддержку для C++ (у Idea много и других плюшек): http://www.jetbrains.com/idea/features/code_analysis.html

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

В свое время я редактор некоторого XML описания бизнес процессов написал за полтора-два месяца. Писалось все с помощью elcipse RCP, потому что в бизнес процессе был java код и шаблоны velocity (для их редактирования соответственно использовались встроенные плагины еклипса). Рисовалка там тоже была, но я её с нуля писал, потому что про GEF не слышал
Когда же затем встала задача опять реализовать редактор некоторого xml формата, я стал писать это все таки на свинге Eclipse это конечно круто, но.. иногда это слишком круто и не совсем надо геммороя с ним хватает

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

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

ДВ>В свое время я редактор некоторого XML описания бизнес процессов написал за полтора-два месяца. Писалось все с помощью elcipse RCP, потому что в бизнес процессе был java код и шаблоны velocity (для их редактирования соответственно использовались встроенные плагины еклипса). Рисовалка там тоже была, но я её с нуля писал, потому что про GEF не слышал
ДВ>Когда же затем встала задача опять реализовать редактор некоторого xml формата, я стал писать это все таки на свинге Eclipse это конечно круто, но.. иногда это слишком круто и не совсем надо геммороя с ним хватает


Но если проект большой и разработчиков несколько, то лучше все таки Eclipse RCP наверное использовать — потому как у программиста будет меньше возможностей придумывать велосипеды, чтобы потом все с ними разбирались

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

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

R>>Сокращение времени разработки (за счет большего времени на функционал, нежели борьбу с хитрым компилятором) и отладки (проблемы работы с памятью в Java тоже имеют место, но носят не такой критический характер, как в неуправляемых языках).
CC>Угу, помницца я как то работал в одной веселой конторе, там писали на жабе систему документооборота...

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

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

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

_>>Информация о типе во время выполнения — это зло, так считаю я и многие специалисты, которые занимаются рефакторингом.
A>Примерчик бы... что то не очень понятно. Возможно Вы не умеете его готовить. Рефлекшн ведь разный бывает.

Достаточно вспомнить что большинство движков сериализаций и маппингов XML и ORM работают именно через reflection. Реализации использующие другой механизм (на сколько я знаю JiBX и что-то из JDO) зачастую от этого и страдают.

S>И практически для каждого есть открытая reference реализация и несколько штук коммерческих. А это означает, что ты не должен мучиться и выбирать, к примеру, какого криптопровайдера использовать, а просто опираешься на стандарт. И потом выбираешь одного из десятка взаимозаменяемых провайдеров, принимая решение на основе всяческих разных требований. Плюсам такая роскошь не снилась и в эротическом сне. Библиотеки слабо совместимы между собой, а уж взаимозаменяемости ты не найдешь.

Хорошо кстати. А... нельзя ли озвучить примерный алгоритм поиска необходимой библиотеки и реализации? Реестр есть? Если нет, по каким ресурсам ходить, на что смотреть.

p.s.
всегда хотел спросить, почему Sinclair, не Amiga например или C64? ;-)

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

S>И практически для каждого есть открытая reference реализация и несколько штук коммерческих.
Это, к сожалению, не совсем так. Спецификациий с множеством реализаций не так уж и много, это те которые отосятся к JEE, XML и persistence. Много спецификаций базирующихся на одной единственной реализации. Иногда даже если реализаций несколько то бывает что есть одна которая является бесспорным лидером и смотреть на остальные смысла нет. Но.
Есть такой нюанс что в качестве альтернативы отдельно взятой спецификации очень часто можно найти opensource решение которое будет ничем не хуже. Например, Hibernate в свое время был альтернативой спецификации JDO, спецификацию под хибер разработали позже. А Spring, в свою очередь, во многом рулит по сравнению с EJB.

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

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

CC>>Прибрать? В жабе?
R>Да. А что вас удивляет?
Мне интересно как вы собираетесь делать "приборку". В моем понимании "прибрать" = вернуть все запрошенные ресурсы назад здесь и сейчас.
Писалось тогда все на свинге + crystal reports + elixir reports + еще куча всякого такого

R>Сборщик мусора не решает все проблемы.
Разумеется.

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

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

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

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

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

Не ясна квалификация с++ и джава девелоперов. AX и IE сами по себе глючные

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

опять же вопрос про квалификацию остается открытым.

Здравствуйте, Константин Л., Вы писали:

КЛ>Не ясна квалификация с++ и джава девелоперов. AX и IE сами по себе глючные

Вот это-то и расстраивает. Я всего месяц работаю с удаленной .NET командой и уже раза 3 слышал от них что во всех бедах виноват MS. Кто-нибудь слышал чтобы Java девелопер жаловался что программа глючит, потому что у Sun глючная JVM? Да и другие решения. вроде серверов приложений. Они стабильнее того же IIS.

КЛ>опять же вопрос про квалификацию остается открытым.
Вопрос про квалификацию не остается открытым. Более квалифицированые разработчики трубуют больше финансовых затрат.

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

F>Хорошо кстати. А... нельзя ли озвучить примерный алгоритм поиска необходимой библиотеки и реализации? Реестр есть? Если нет, по каким ресурсам ходить, на что смотреть.

Для начала это гугл. Здесь

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

камрад ссылок уже накидал.
Есть ещё такой сайт http://java-source.net, но даже там нет многих полезных решений.
Потом навыки поиска приходят с опытом. И ты просто будешь знать где какой framework заюзать и какие у него есть альтернативы.

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

S>>И практически для каждого есть открытая reference реализация и несколько штук коммерческих. А это означает, что ты не должен мучиться и выбирать, к примеру, какого криптопровайдера использовать, а просто опираешься на стандарт. И потом выбираешь одного из десятка взаимозаменяемых провайдеров, принимая решение на основе всяческих разных требований. Плюсам такая роскошь не снилась и в эротическом сне. Библиотеки слабо совместимы между собой, а уж взаимозаменяемости ты не найдешь.

F>Хорошо кстати. А... нельзя ли озвучить примерный алгоритм поиска необходимой библиотеки и реализации? Реестр есть? Если нет, по каким ресурсам ходить, на что смотреть.

F>p.s.
F> всегда хотел спросить, почему Sinclair, не Amiga например или C64?

Реестр самих библиотек есть http://repo1.maven.org/maven2/
Там еще частенько исходники есть.
Описания там нет, искать надо отдельно.

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

B>Вот это-то и расстраивает. Я всего месяц работаю с удаленной .NET командой и уже раза 3 слышал от них что во всех бедах виноват MS.

Не обращай внимание. Это традиция — винить во всех бедах микрософт.

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

F>>Ну вот пример — если нужно сляпать формочку с полем ввода и кнопкой то чем java будет быстрее чем взять visual basic или delphi?
R>Ничем. С начальными условиями: не знаю Java, не знаю Delphi — эту задачу быстрее решить на Delphi. Я серьезно.

Только с появлением Matisse в NetBeans 5.0 эту задачу стало так же легко сваять в яве.
В NetBeans 6 будет поддержка Java Beans Binding которая позволит так же как в делфи легко связать твою форму с базой данных.
Вообще последнее время Sun достаточно много внимания уделяет разработке GUI приложений

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

B>Для начала это гугл. Здесь

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

камрад ссылок уже накидал.
B>Есть ещё такой сайт http://java-source.net, но даже там нет многих полезных решений.
B>Потом навыки поиска приходят с опытом. И ты просто будешь знать где какой framework заюзать и какие у него есть альтернативы.

Хотел бы еще добавить
http://www.koders.com/
http://www.docjar.com/

Оба ресурса имеют плагин для еклипсы

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

B>Здравствуйте, Константин Л., Вы писали:

КЛ>>Не ясна квалификация с++ и джава девелоперов. AX и IE сами по себе глючные

B>Вот это-то и расстраивает. Я всего месяц работаю с удаленной .NET командой и уже раза 3 слышал от них что во всех бедах виноват MS. Кто-нибудь слышал чтобы Java девелопер жаловался что программа глючит, потому что у Sun глючная JVM? Да и другие решения. вроде серверов приложений. Они стабильнее того же IIS.

они обосновали хоть?

КЛ>>опять же вопрос про квалификацию остается открытым.
B>Вопрос про квалификацию не остается открытым. Более квалифицированые разработчики трубуют больше финансовых затрат.

все вы хотите и рыбку съесть и кое-куда сесть

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

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

Мдя... Макросы в C++...

После Лиспа и Nemerle ЭТО даже макросами называть противно.

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

R>PS И вообще, пакость это — рефлексия, по-моему.

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

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

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

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

IT>Например, форма подписывается на события от какого-либо объекта, который живёт дольше формы. Если форму не отписать от событий объекта, когда она уже не нужна, то она будет болтаться в памяти пока не умрёт объект. А с ней вместе будут жить и объекты, которые она использует. Типичная и довольно трудно уловимая ошибка, которую можно поймать только если ты вообще в курсе о такой проблеме.

Да, вот и весь автоматический memory management.... Остальные "приколы" можно найти на sun bug parade по поиску "leak".

Вообще, во многом восприятие той или иной "фичи" базируется на психологии. Смотря как подать. Memory-management в Java подан как friendly, safe, и т.д..

Но может быть и такая точка зрения, что "Java — это платформа с постоянно текущей памятью, где memory leak узаконен. Просто периодически специальный механизм устраняет эти утечки." И согласитесь, ничто не мешает быть этой точке зрения законной, здравой.



Дискуссия в конечном итоге свалиается в обсуждение языковых или платформенных фич.
Приводятся примеры вида "взяли" N java программистов и M c++ программистов. У N Все работало, в то время как у M все падало итд.. Это хорошо, но не является доказательством чего-либо. Все это не то.

Хочется услышать мнение касаемо именно технологии Java. Неоспоримые факты. Я хочу узнать правду, сильные и слабые стороны — насчет скорости и стоимости разработки итд.

Формулировка должна звучать так — "разработка на Java будет более быстра, и более дешева если использовать там и там разработчиков одинаково низкого уровня". А если взять там и там профессионалов в своей области?

Это не Holy War. Хочу четко знать сильные стороны Java. Помогите мне в этом.
Пока что (вследствие бедноты знаний) могу перечислить только слабые стороны платформы.

Проприетарность платформы (доказаная судебными притязаниями)
Очень медленное и слабое развитие (более 10 лет уже минуло) — причем развитие было инициировано и произведено в 99% случаев community, а не Sun.
Невозможность контролировать политику использования памяти и отсюда — Ненормальные (оторваные от жизни) требования к памяти.
Низкая производительность (compared to...)
Наличие только одной парадигмы программирования — OO
Высокий уровень абстракции и как следствие изолированность от нижележащеего слоя абстракции (платформы/OS).
Низкая полиморфность данных/вызовов (плата за safety).
Существуют и другие провалы в других областях, обещаных, но не реализованых. Так например, провал апплетов и "Internet applications" во многом обеспечен самой sun — отсутствие механизмов взаимодействия апплетов с браузером/os и отсюда функционирования апплетов только в качестве бесполезных визуальных "игрушек". Это отчасти покрыто в java 5,6. Но когда?

Некоторые плюсы мне рассказали (стандартизация), но там не все так радужно.
В осное своей это не проблемно-ориентированные frameworks. Куча всего, но реально, в большинстве случаев, это абстрактный run-time "сахар", россыпь классов. Его использоввание не решает конечную проблему, как это принято в среде c++.