GammiBearНеплохого дельфиста монжно в принципе найти за $400-500 / месяц.
более-мене адекватный жаба-программер будет стоить $700 - $1000 / месяц.

Я бы отметил другой факт. Производительность этого жаба-программера в жанре корпоративной БД будет раза в три меньше.

VortexCorbaДельфи уже отстал. На нем пишут школьники. И воаще не сравнивай Жаву и Дельфи. Это как небо и земля.
Безусловно - разные вещи.

VortexCorbaДельфи: ....Не устойчивый. Например если в DBGrid загрузить много инфы, прога просто молчит, зависает, и не только прога, а вес виндоус
Не соответствует действительности. В DBGrid физически невозможно загрузить много информации - он является виртуальным окном над датасетом, и информации в нем ровно столько, сколько строк помещается на экране.

Я верю, что Вы как-то добились этого эффекта. Но - полагаю, то что выше уже показывает, насколько серьезно Вы этим занимались. А закона кривых рук еще никто не отменял.

VortexCorbaПод Дос у него идет паскаль, что то похожее, херня короче.
Дельфа не идет под ДОС :) Но как язык, Object Pascal продвинутей Java - это мое личное мнение, которое, если хочется, можно обсудить отдельно.

VortexCorbaВ Net технологоиях отстает Жавы на миллион км.
Да, собственно, и не предназначался для них.

VortexCorbaПроги написанные на Дельфи весят очень много.
"Очень много" - сложный вопрос. Дистрибутив проги на дельфе весит много меньше дистрибутива проги на джаве.

VortexCorbaМожно и на блокноте писать, лиж бы ЖДК был.
Как и в дельфе. Соответственно, не вижу смысла относить это к плюсам в сравнении.

VortexCorbaБэт сайт: Ну даже не знаю,
Хм. Бэт сайт: нормальное клиентское приложение на нем.. я пока не видел. Дико тяжелые, дико тормозные. Можно, конечно, сказать, что Borland и Oracle не умеют писать на Java - комментировать не буду.

Бэт сайт: JDK - плохо проработанный продукт как минимум в части оконного интерфейса. Очень мощный, но с соответствующим количеством недоделок и неудачных решений.

Особенно неприятно, что он неконтролируемый. Типа - вывалил printStackTrace() и продолжает работать; с точки зрения пользователя - при нажатии на кнопку просто ничего не произошло.

Бэт сайт: глупости в языке и библиотеке. Например, отсутствие enumeration. Например, возврат функции необходимо проверять на null, на length = 0 итп - и при этом помнить, что из нее запросто может вылететь exception, хотя никакого throws у нее не объявлено. Вообще, много всего по мелочи.

Бэт сайт: очень громоздкий код. Обратная сторона мощности - но тем не менее, большой минус. Практически эквивалентный код на дельфе выглядит вдвое, если не втрое короче.

Резюме: главное достоинство Java - очень мощное api, а также VM, приспособленная к решению сетевых задач (ClassLoader-ы итп). Главное достоинство дельфы - возможность быстрой разработки качественного кода в широком спектре клиентских приложений. Области практически не пересекаются - хотя борландеры и пытаются лезть в веб.

fyndaПричем есть IMHO #2, что в java на эти грабли наступают не сильно реже.
Я когда-то смотрел, как это делать в java. Google - выдал, разумеется, кучу ссылок, из которых на первой странице на разные лады повторялся примерно одинаковый код заполнения DefaultTableModel из ResultSet-а - само собой, с fetch all. То есть - не было даже автоматизации модели с fetch all; модели без fetch all я вообще не нашел (P.S. Речь идет о JDK 1.3 - потом, может быть, и появилась).

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

NotGonnaGetUsЕсли не понимать как работает решение, это не значит, что оно неудачное.
Swing'и великолепно проработаны. Где там "соответствующее кол-во недоделок", мне лично не понятно.
Не напомнишь, в какой версии JDK появилась такая крайне сложная и необычная процедура, как "максимизировать окно"?

Великолепно проработаны - пока не начинаешь использовать. Скажем, тривиальная такая задачка: имея строку "A / B / C", сгенерировать cоответствующий пункт меню (то есть - найти/создать подменю A, в нем найти/создать подменю B, в нем создать пункт C). Посмотри для интереса - сколько идиотских действий при этом нужно совершить.

NotGonnaGetUsЕсли программист решил не обработать Exception, а вывалить его в консоль или отдать эту функцию VM - это проблемы программиста, а не Java. В java API этим не балуются.
Если бы так.. exception while event dispatching - и стек в консоль. Помню, видел не раз.

При этом - стоит помнить, что исключение запросто выпадает даже из подпрограмм, в которых никаких throws нет. А потому, практически единственный путь защититься - писать безусловный catch в каждой функции.

NotGonnaGetUsА кстати, вариант повиснуть/выпасть лучше? :)
Лучше - предусмотреть разумную реакцию по умолчанию (выдавать окно с сообщением) и дать программисту изменить эту реакцию на ту, которую хочет он.

NotGonnaGetUs
Бэт сайт: глупости в языке и библиотеке. Например, отсутствие enumeration.

Есть.
Значит, невнимательно слежу за развитием. Ссылочку можно - типа, ключевое слово? Может, и break-и в switch-е уже не нужны?

NotGonnaGetUsя тут чуть не упал вместе с коллегами.
Рад за ваш моцион.

NotGonnaGetUsНе обработанные самой функцией RuntimeException's и Error's - это ошибки программиста.
Факт. Вопрос только - какого программиста. Если из класса JDK вылетает что-нибудь типа NullPointerException - я знаю, какого программиста это ошибка.

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

NotGonnaGetUsИмхо, эти мелочи следствие не понимания языка, используемых в нём паттернов.
В чем-то, наверняка так. Странно, однако, что я пользовался как минимум десятком языков, разумеется, далеко не все детально изучал - и только джава создала такое впечатление.

NotGonnaGetUsCкриптовые языки требуют ещё меньше места, это же не вовод всё бросить и писать на них? :)
Не повод. Но это именно один из факторов, который влияет на выбор. Грубо говоря, есть область, в которой разумно применять скриптовые языки и есть область, в которой разумно применять джаву.

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

NotGonnaGetUsНо даже если это так, то этот параметр имеет значение только для маленьких приложений. Как только скелет приложения определён (ой как грубо), размер уже не имеет значения.
Не соглашусь. Размер и сложность кода прямо влияет на читаемость и все вытекающие из нее параметры - количество мелких ошибок, сложность отладки и сопровождения.

NotGonnaGetUs Разработка/доработка/поддержка - это уже игра вокруг классов, все рефакторинги которых автоматизированны (почти все, IDEA). Работать со множествно небольших методов (всумме занимающих в 2 раза больше строчек, чем один большой) на порядок удобнее чем с одним большим.
Хм. Я как-то написал выражение, которое на Java требовало 14 открывающих и закрывающих скобок. На дельфе аналогичное потребовало бы четырех. Это уже не имеет отношения к рефакторингу :)

Да, в итоге, само собой, я переписал это выражение в виде присваиваний двум или трем промежуточным переменным. Так оно стало более понятно, нежели в оригинальном виде - и осталось менее понятно, чем то же в простом виде.

Что касается рефакторинга - сам по себе он хорош. Но от того, что это выражение можно выделить в отдельную функцию (не имеющую абсолютно никакого самостоятельного смысла), большого выигрыша нет. Да и маленького тоже.

NotGonnaGetUs Короче, не вижу бед сайт.
Не удивлен. Каждый из нас смотрит сквозь призму своих задач - а задачи подбираются под используемый инструмент :)

NotGonnaGetUs Учитывая, что клиентские приложения в основном мальнькие прилепки к БД или серверам, так оно и есть.
Это крайне сильное утверждение. Впрочем, учитывая убогость веб-интерфейса, его источники вполне понятны.

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


Почему я обязан писать что-то типа (Throwable t), если мне совершенно неинтересен этот t?

Или каким паттерном объясняется, что код


работает, а код


не компилится?

Anatoly KПо правилам Java вызов конструктора базового класса должен быть первым предложением в описании конструктора производного класса. А почему - ... его знает. Где-то прочитал, чтобы не было возможности перехватывать исключения, возбуждаемые в базовом классе в конструкторе производного класса. Короче - нельзя так делать.
Что нельзя - я в курсе.

Обратите внимание: два описанных фрагмента - эквивалентны (если не считать дополнительной области видимости переменной). И первый из них - нормально работает, допустим и не вызывает ни проблем, ни вопросов.

То есть - вместо действительного, разумного критерия, определяемого реализацией, проверяется чисто формальный критерий, не имеющий физического смысла ("первая строка").

Вот именно это я и называю глупостями языка. И просил привести "паттерн", которого я при этом не понимаю. Само по себе требование вызывать super до остального - скажем так, в случае java я не вижу в этом однозначной необходимости, но не более того.

Anatoly KЭто бы и в C++ и в C# не скомпилировалось
В "идеологичном" C++ такое нельзя написать синтаксически (поскольку родительские конструкторы вызываются отдельно), и тому есть причина - проблемы реализации множественного наследования. Да, туда добавили вариант синтаксиса с конструкторами после "{" - в рамках всегдашней сишной необходимости примирять плохо совместимые реализации. Не более того.

В джаве это - не обусловлено совершенно ничем.

funikovyuriТак что ясно - C++ и java и C# - неправильные языки - правильный - это конечно pascal...
Нечего сказать, поэтому начинаешь ерничать. Достойно и красиво.

funikovyuriпро Throwable не понял...
Раз уж тебе нравится идея "правильности"...

В дельфе при желании я могу написать:


То есть - обработать все возможные ошибки одним универсальным обработчиком.

В джаве - я обязан при этом писать лишние слова, то есть просто


не компилируется. Опять же - мелкая раздражающая деталь, необходимости в которой нет совершенно никакой. И таких деталей - мягко говоря, хватает.

Гости SoftwarerВ джаве - я обязан при этом писать лишние слова, то есть просто
не понял, а если вот так:
Говорю же: обязан писать лишние слова. И, кстати, не Exception, а Throwable - через написанное Вами куча исключений отлично провалится.

Это, кстати, очень показательный момент, поскольку повсеместная ошибка программирования на Java. Случается следующее: пользователь нажимает кнопку, в обработчике происходит что-нибудь типа VerifyError, NullPointer итп, оно проваливается сквозь такой catch - и в результате с точки зрения пользователя "программа молча ничего не сделала, словно и не нажимал", а где-нибудь в stdout появляется сообщение об ошибке. Это - почти худший из возможных вариантов поведения программы в такой ситуации. Хуже только "молча падать".

ГостиЗапарили уже засирать языки.
Хм. С моей точки, "засирать" - это начать обсуждение "на дельфе не писал, но DBGrid виснет". Безусловно, любые темы сравнения флеймовы, но при корректном подходе в них можно найти пользу - и я стараюсь удерживаться именно в этих рамках.

Гости Каждый пишет на том на чем нравится.
Я бы сказал - на том, что требуется исходя из задачи.