Pitbull terrier(по постам перечислить?)


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

А общие замечания из отряда: "нужно просто вкурить" - мне не интересны в принципе.

Уже год "курю" тонны мануалов по J2EE и не только, но пока - только общее резюме:

"Все это, конечно, замечательно (Factory, Lifecycle, Bundle и прочие Observer-ы), но:

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

--

Вот и попробуйте, возразить, по существу (хотя я более уверен, что в очередной раз получу лишь гробовое молчание в ответ).

mv
Однако, с нововведениями Java Tiger не сравнить.
Дженериков там еще нет,
(но зато есть Variant (с) - grexide )


А, "вы про это" (c).

Ок. Действительно, очень ценное языковое нововведение. Милионы программистов нервно курят в сторонке, как же это они без универсальных (???? sic) - (generic - родовой, характерный) типов живут.

Действительно, просто кошмар, вся жизнь прожита зря.

Привели бы хоть один реальный пример, в которых без этих generic-ов жить - ну просто нельзя.

--

Кстати, mv, ты то хоть бы не начинал, впрочем... и так - всяк полезно муравейник во вражеском стане пошевелить ;))

Но и считать отсуствие generic в native Delphi (Object Pascal).... честно говоря, не велика потеря. В конце концов, не тащить же в рот всякую дрянь, подобранную с полу ?

Тем более, что нам сулят "тиаратики" ?

- readability ?
- performance ?
- compile time error detection ?

"И не убедительно вовсе" (с)

Pitbull terrierТороплюсь
буду краток (с)

Напрасно, даже с точки зрения - народной мудрости (всего двух ситуациях, в которой спешка имеет смысл).

Pitbull terrier
grexhideТо, что в Delphi делается спиномозговыми кликами - в Java библиотеках - требует натужного ручного кодирования.

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

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



Pitbull terrier
grexhideТы вынужден привязываться к конкретному поставщику IDE и инфраструктуры (App серверов).

Про IDE - в корне неверно.

С каких это пор ? Прям таки - без проблем переносятся проекты между JDeveloper, NetBeans, Eclipse, IDEA и пр. ? И проблем даже с поддержкой даже Swing-овских UI дизайнеров не возникает ?

Не надо врать, молодой человек.

Pitbull terrier
Про App серверы - если вы имеете в виду JEE серверы, то дело ограничиватся vendor-specific дескриптором поставки, который поставляется отдельным файлом и к структуре приложения отношения не имеет. Если речь о натурально серверах приложений, со своим специфическим функционалом и API - то претензия несколько странная, на каком основании требовать от всех совместимости?

Гениально. Браво ! Просто "супер".

Я то грешным делом считал, что спецификации несут как минимум роль стандартов, как максимум - средств обеспечения совместимости. А тут вона как - вовсе даже и не несут, а просто так, и вообще, все решается через "vendor-scepific дескриптор поставки"....

Хорошее средство самоубеждения (или самообмана ?), не спорю.

Pitbull terrier
grexhideДа ничего в Java хорошего нет, кроме уровня зарплат.
no comments

В смысле, молчание знак согласия ?
Напрасно, мы вроде как преимущества обсуждаем (вернее, пока - их отсутствие).

Pitbull terrier
grexhideсостояние "вечной недоделанности"
Где?
В thidr-party тулзах? так, может, это их девелоперов проблема? Почему вы сюда это написали?
Попробуйте завалиться к ним на форум и высказаться в том духе, что, мол, какого хрена у вас тут все вечно недоделано. Узнаете о себо много старого и неинтересного.

Зачем мне их отвлекать от увлекательного процесса построения собственных виртуальных миров ?
Это может быть по меньшей мере - опасно и грешно (для здоровья последних )


Pitbull terrier
grexhideвчерашние J2EE спецификации.
Вы много спецификаций знаете? Сдали хоть один тест хотя бы по одной версии? Или для вас откровением является то, что J2EE спецификация постоянно развивается?

Отлично. И куда она, позвольте спросить, развивается ? И с обратной совместимостью тоже, никаких проблем не возникает ?
--
Тезис про тестирование - забавно, право. Переходим к активному нападению методов "взять на понты ?". Говорите по существу, пожалуйста. Эмоции - не добавляют Вам объективности.

Pitbull terrier
grexhideТем более если говорить про разворачиваемость (и обслуживаемость) - Java просто отдыхает (в современном состоянии App серверов, да и установочных танцев/бубнов с JRE).

Это не так. Только вот надо знать, что делаешь.
Кстати, пример танца с бубном именно с JRE в студию.

Да кто бы сомневался, что нужно знать, что делаешь.
И что, уже не нужно с собой возить с собой эти самые JRE строго определенной версии ?
Постоянно отхватывая проблемы с поддержкой на тех самых любимых Unix/Linux ?


Pitbull terrier
Hibernate - далеко не "новая технология".

Да ну ? Есть что то поновее, со большей степенью маразматичности чем HQL ?

Pitbull terrier
Bitter Java - это не описание "преимуществ" (в кавычках) java, ваша ирония была неуместной.

Каждый видит материал под своим углом зрения. Может быть вы читали ее как-то "поперек" ?

Pitbull terrier
Вы говорите о вещах, о которых имеете поверхностное представление.

Да, это так. Но вполне достаточное, чтобы иметь возможность сравнить с теми вещами, с которыми я имею вовсе не поверхностное представление.

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


Про желаемый эффект я написал выше. Мне хочется получить достаточно весомые и внятные аргументы в пользу "перехода на Java".

Пока таких аргументов не получено, в отличии от аргументов "нужно просто вкурить".
Получается забавный эффект. Высокомерие а-ля "все Delphi-ты - ламо есть", а вот аргументов - нет ;)

mv
А введут дженерики, так и будем явистам тыкать - вот мол, "...и у нас тоже".


Да нет. Проблема не так уж и и велика, как кажется на первый взгляд.
Опять же, посуди сам - когда тебе это было самому нужно (хоть раз?)

Fundamentals - это уже вопрос десятый, именно своей отвлечённой от реальных жизней теоретической зашоренностью.

Опять же, не идейно. Для прикладных целей - полезность genericoв - практически нулевая, а для компонентно/инструментальных - тем более (в виду того, что практически беспроблемная переносимость Delphiйских приложений/компонент (адаптируемость последних) в редакициях Delphi4/5/6/7/10 - это слишком большой плюс, чтобы оправдывать применение подобных чудо конструкций).

Тем более, "фича" так же спорна, как и перегрузка операторов (свежесодранная с C++) даже по такому параметру, как читабельность кода.

mv
Пардон, что-то список не пропечатался.
Еще раз:
mv

Смотрим, модуль cDictionaries.pas. Реализация ассоциативных массивов.




Ну и ? чем тебе - не variant ?

Или же - какой более "дубовый"

Опять же, включая такие вещи, как оптимизация выравнивания данных границе 8 байтового слова (реалии мира Win32 и x86 архитектуры ?)
---

Тем более, все познаётся в "сравнении" - с эффективностью (затраты на управление памятью, поддержку "счетчиков и пр" явовских "мегачудо" классов вроде Integer, Double, и пр) ?

Pitbull terriergrexhide, я не собираюсь уговаривать вас переходить на java
это как минимум скучно.
Я просто указываю вам на несостоятельность ваших претензий.


Читается как: "Я просто "уговаривать" вам на несостоятельность ваших претензий." ?
-
Расслабьтесь, "слив давно засчитан"

mvОднако, обещали как-то Борландовичи. Дай-то бог.
Ну.. сделают, и ладно. Тогда и посмотрим.

mv
grexhide
Fundamentals - это уже вопрос десятый, именно своей отвлечённой от реальных
жизней теоретической зашоренностью.

Тебе не нужны быстрые и надежные Associative Arrays, Linked Lists, Arrays as
classes, Linked Lists,
Sparse Arrays, *Trees, Hashing Functions, *Caches,...,...,...?
Тогда да - "теоретическая зашоренность", ничего более.
"Гаити, Гаити...TStringList в зубы - и понеслась..." (c)

Ты таки прозорлив ;))

Ок, давай все же отделим мух от котлет. Мы говорим о скучных нудных бизнес приложениях ?
Ты предлагаешь какие остатки по складу через хешированные ассоциативные массивы считать ?

Опять же, все эти фундаментальности - вполне представлены и довольно успешно на компонентном уровне, там где они, конечно, нужны.

mv
Совместимость снизу вверх останется, а сверху вниз - пофиг.
Ты же вот почему-то не упомянул в своем списке "4/5/6/7/10" версии "1/2/3"?
Тем более что вранье про беспроблемную переносимость в версиях "4..10". В
обе стороны.

Да ладно тебе про вранье заливать то. Нормальные компоненты - вполне себе компилируются под весь этот зоопарк.

А про Delphi1... ну ты бы еще про VBX вспомнил ;)

Опять же, живой пример - сейчас я вполне обхожусь 10-кой для разработки, 7-кой для компиляции в продакшн (и то, подумываю забить на это). При этом - практически без каких либо проблем переходил между 1->3->4->6->7->9 (кхм, IDE там была ужасна)->10.

Единственный вопрос был - именно поправить какие сторонние компоненты (по мелочам, в основном - в директивах компилятора и в фундаментальных типах... кстати)

А вот теперь - все познается в сравненнии - возможно ли такое в JRE1.5 и JRE1.4 (1.3) ? Хоть снизу вверх, хоть сверху вниз ?

Опять же, живой нарицательный пример - Oracle-овские инструменты. Чет у них ну никак не получается какие свои маргинальные IAS-ы и прочие JDeveloper-ы свободно на предмет JRE даже обновлять. И ламо-чайниками назвать их - довольно трудно.

mv
"Фичи" совершенно разные. В том числе и по читабельности кода.


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


mv
Может, и интерфейсы не нужны? Обходились же раньше. /* Некоторые коллеги
ввобще считают, что интерфейсы - это выдумка Microsoft. ;) */


А разве не Microsoft ? ;))))

Впрочем, не будем, наверное, о грустном (в виду особенностей реализации _AddRef and _Release)

Pitbull terrier Вам, наверное, трудно это понять, но окошко с тулзами для клепания форм - это еще не IDE, и трубить о непереносимости проекта в целом глупо.

Да уж, очень даже глупо. Иметь IDE без нормального дизайнера форм.

Pitbull terrier
>>Постоянно отхватывая проблемы с поддержкой на тех самых любимых Unix/Linux ?
Примеры в студию.

Поработайте c Oracle OUI (и не только), вполне себе поймете, о чем идет речь.

Pitbull terrier
Где проблемы с переносимостью приложения?

Да никаких проблем нет. Кроме тех, что реально какой ADF и TopLink работают только на iAS (строго определенных версий).
А про прочих - можете и сами почитать периодику.


Pitbull terrier
>>Да ну ? Есть что то поновее, со большей степенью маразматичности чем HQL ?

Как в мире много неизведанного, да?

Ага. А глупости - еще больше. Особенно, когда понимаешь отличие CBO и аналитических функций от "уровня" HQL ;)

Pitbull terrier
>>Каждый видит материал под своим углом зрения. Может быть вы читали ее как-то "поперек" ?
С вашего угла зрения не видно различий между понятиями "антипаттерн" и "недостаток технологии в целом"?

И что дальше ? Я часто не вижу общего с понятиями "реалии жизни" и "паттерны проектирования".
Может быть - просто не те задачи решаю ?

Pitbull terrier
>>Но вполне достаточное, чтобы иметь возможность сравнить с теми вещами, с которыми я имею вовсе не поверхностное представление.

Вы не сравниваете. Вернее, сравниваете, но с какими-то артефактами из глубин своей головы. Вот проблема.


Угум. Проблема только в том, что мне куда больше хотелось бы посмотреть в "глубины сознания" людей, писавших "классически правильный" Toy Store.

---

И в целом, чего Вы так нервничаете то ? Покажите лучше пример показательной реализации сабжевых задач (автоматизация торговых операций) на Java.

Со сравнительным анализом (даже по сугубо техническим моментам) с конкурентными решениями (более приближенных к реалиям, к примеру, 1C-ок, не говоря уже про всякие SAP-ы, Axaptы, OEBS-ы или какие Seibel-и c Amdocs-ами)


Опять же, еще и в таком аспекте, как согласуются реальная практика J2EE технологических решений (к примеру - Oracle AF) от этих компаний-титанов с тем (pure JCP и прочие tutorial-ы минимум на 5000 страниц), что назидательно скармливается миллионам леммингов в виде "истинного пути" (в кучах "правильных" книг и прочих свободно доступных средств)

B т.ч. - и с реалиями тех вопросов, которые придётся решать вопрошающему.

Зашедший
В JRE такое возможно без проблем. Можно исходники 1.5 компилить с таргет-платформой 1.3 и оно будет работать на 1.3.
З.Ы. Надо бы хоть знать основные возможности платформы, которую пытаешься критиковать. А то получается "не читал, но осуждаю".

Может быть и так, спорить - не буду. А как, реально работает ?