Swing используют 47% разработчиков

Druk, vi ochen otstali ot zhizni. Pochitaite zdes: http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-jw2...

Значит так.

По поводу тормознутости свинга :
Средняя машина в нашей конторе, это примерено :
2ГГц ЦПУ, nVidia-XXX-64МБ, 256МБ ОЗУ
JRE обязательно >= 1.5, т.к. свинг так _РЕАЛЬНО_ быстрее.
Приложения с довольно навороченым гуем
(таблицы : 1000-1500 строк за выборку + сложные рендереры и эдиторы, деревья : ~500-700 узлов, плюс различные диалоги)
работают _ОТЛИЧНО_ (читать : гуй - не тормозит)

Далие по поводу ненативности LAF :
Под виндой - лаф виндовый (вот это новость :)).
Под Линуксом - определяем Линукс - ставим Kunststroff Look And Feel,
кто не видел - обязательно посмотрите
(kunststroff.jar (GPL) ~40k, а внешний вид ИМХО абалденный)

Вывод : SWING имхо хороший, реально кросплатформенный тулкит,
как любая сложная система требует хорошего знания
своей архитектуры, тонких мест и особенностей программирования под него.
Короче читайте литературу, смотрите умные примеры
и конечно ковыряйте сорцы - благо они есть,
и самое главное, перед началом избавтесь от стереотипа : JAVA - тормоз.
Это было давно.

>Так, учиним пацанам порку.

JDBC na mnogo bistree chem ODBC pod Unix. V Hummingbirde narod hochet iz C++ ispolzovat JDBC driveri po etoi samoi prichine.

>> Together от Borland (на Swing + JGraph) - online code generation & reverse eneenering для c++/java/c#

>проблемка в том, что в работе использую только то что нормальным образом купил, или разноообразный freeware..

У Omodo есть бесплатная версия.

>Раз уж так хвалите together - подскажите цену на него - походу Borlnad & partners её тщательно скрывают ;-)

Я не занимаюсь закупками ;-)
Странно, что borland не называет цену, ты уверен что попал в borland? ;-)

http://www.borland.ru/together/index.html вроде как официальный локализованный сайт..далее ссылка на партнёров, у первых трёх можно только заказать, отдельным письмом, пояснив нахрена оно мне..и действительно - нахрена ;-)
 Я уже давно впринципе привык, что чем круче компания, тем больше чертей поламали лапки на сайте.
 Был просто поражён строгой простотой формы заказа - 
 "ваш email","текст заявки" <<Наши менеджеры с вами свяжутся>>

Это было лирическое отступление ;-)

Yilativs > У Omodo есть бесплатная версия. 

что/кто есть Omodo ? и откуда там бесплатная версия ??

>>Yilativs > У Omodo есть бесплатная версия.
>что/кто есть Omodo ? и откуда там бесплатная версия ??

приличный UML editor
http://www.omondo.com/

>Да ну, в линухе жабский ифейс жутко выглядит.

Ты можешь отличить отличишь SWT от GTK?
(подсказка, SWT под ляликом ресует через GTK ;-)

Yilativs, thanks ! гляну на досуге

Афигеть...

И это при том что важные и очевидные баги в Swing не фиксяться просто годами.

Я просто хрюкал и рыдал когда читал описание этого бага:

http://bugs.sun.com/bugdatabase/view_bug.do;:YfiG?bug_id=4263904

Хорошо хоть я узнал про него в НАЧАЛЕ проекта, и быстренько перешел на web интерфейс.

>Yilativs, thanks ! гляну на досуге

np

>Приложения с довольно навороченым гуем (таблицы : 1000-1500 строк за выборку + сложные рендереры и эдиторы, деревья : ~500-700 узлов, плюс различные диалоги) работают _ОТЛИЧНО_ (читать : гуй - не тормозит)

А что используется в качестве ORM? Или pure-JDBC? Какая БД, Oracle?

>Druk, vi ochen otstali ot zhizni. Pochitaite zdes: http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-jw2...

Дгуккк, (пардон, иногда делаю таки очепятки) насчет отстал от жизни, я вроде с девочками гуляю, и все такое, или Вы что имели ввиду? Я это читал, тогда, когда это вышло, т.к. мне приходит DveloperWork bulletin. Ну а если Вы несогласны что java отжирает конкретно пямяти, то это Ваши личные проблемы. Про всякие Escape analisis - выйдет мустанг - посмотрим. Хотя я уверен, что никогда java ( если Вы фанат - можете поставить сюда .net ) не сравнится по эффективности c C++. В этом природа GC. И если уж пошел обмен ссыклами, вот это будет интересно:

http://www.cs.umass.edu/~emery/pubs/04-17.pdf

з.ы. Ну, а прото, что jdbc "быстрее" odbc, спасибо, долго смеялись мы.

>http://www.cs.umass.edu/~emery/pubs/04-17.pdf

Vesma zamechatelnaya stateika. A vivod v tom chto GC ochen dazhe ne ploh po sravneniju s malloc. A s tsenami na pamiat' tak i voobsce, kak govoritsa, who cares :) Vot seichas napisal chat server, kotoriy rabotaet v klastere i skaliruetsa do 100,000 concurrent polzovatelei. Dalshe ne proverial :) mozhet i bolshe. I ja vnimatelno vibiral SW platformu na kotoroi pisat. Esli bi eto bila Java1.4 to ja bi vibral C++. A c 1.5 Javoi ochen dazhe nichego poluchilos. Ispolzoval JGroups, Hibernate i drugie vkusnosti kotorih v C++ netu (samomu pisat nado :( )

>з.ы. Ну, а прото, что jdbc "быстрее" odbc, спасибо, долго смеялись мы.

A vi bez smeha proverte, togda i posmejomsa :)

>Vesma zamechatelnaya stateika. A vivod v tom chto GC ochen dazhe ne ploh po sravneniju s malloc.

Еще в копилку: http://www.linux.org.ru/jump-message.jsp?msgid=1107862

>> А такой функцимональности как в Хибернейте нет ни в одном ОРМ ни для одного языка.

Одно маленькое добавление - TopLink все же кроет Hibernate как бык овцу.

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

Упс, vsl, с возвращением!

>(kunststroff.jar (GPL) ~40k, а внешний вид ИМХО абалденный)

Посмотрел на скриншоты (Alloy Look&Feel (commercial)), очень похоже на прибамбасы Intellij-Idea, видать идея именно это использует? Кто-нибудь точно знает?

================== з.ы. Ну, а прото, что jdbc "быстрее" odbc, спасибо, долго смеялись мы.

shut_up (*) (31.10.2005 21:36:23) ==================

Shut_up - читай внимательнее что чел пишет, а именно слова 'pod Unix.'.

Цитата: ================== JDBC na mnogo bistree chem ODBC pod Unix. ==================

И это так и есть.

>Тю..сравнивать языки по синтаксису - "нравится/не нравится"..

Истину глаголишь, сын мой. Сравнивать языки надо не по синтаксису, а по семантике.

>A vivod v tom chto GC ochen dazhe ne ploh po sravneniju s malloc.

Совершенно солидарен с Вами. Более того - GC по скорости аллокации (copying GC), уделывает malloc. Однако это скорость за счет потребляемой памяти. Вобщем то стандартная дилема. Однако, люди, которые пишут на С++ в честности, (я сам например) всегда для часто аллокируемых в хипе/удаляемых обьектов, используют custom allocator-ы, в частности pool аллокаторы, которые позволяют аллокировать и освобождать обьекты определенного размера примерно с такой же скоростью, как и настеке. Таким образом оптимизируя потребление ресурсов.

>A s tsenami na pamiat' tak i voobsce, kak govoritsa, who cares

Ну, если бы все упиралось в цены на память! При современном уровне развития техники и ОС, владеть большим куском памяти вредно, с точки зрения производительности. Уверен Вы конечно знаете об этом, только виду не подаете. Так что perfomance cares.

>A vi bez smeha proverte, togda i posmejomsa :)

Все зависит от того, насколько качественно вендор реализовал odbc драйвер и jdbc драйвер. Своим сарказмом я просто хотел сказать что не стоит обобщать. Если у кого то jdbc реализован лучше, то это не значит, что у всех так.

>Vot seichas napisal chat server, kotoriy rabotaet v klastere i kaliruetsa do 100,000 concurrent polzovatelei. Dalshe ne proverial :) ozhet i bolshe. I ja vnimatelno vibiral SW platformu na kotoroi pisat.Esli bi eto bila Java1.4 to ja bi vibral C++. A c 1.5

Ну, исследования показывают, что даже на скриптовом языке, можно реализовать скажем вэб сервер, который будет и работать быстрее и масштабироваться лучше, чем написанный на С++. Достаточно например просто в случае скриптового языка использовать AIO+poll, а в случае С++/C использовать потоки... Ну да Вы и сами все прекрасно знвете. Так что могли бы делать на С++. Аналогов JGroups полно, хотя аналогов Hibernate и нет, однако при небольшом кол-ве таблиц это не напрягает.

>читай внимательнее что чел пишет, а именно слова 'pod Unix.'.

AnyaSelivanova, человек вменяемый, написал бы читайТЕ. Чай не в борделе. Или никак не отвыкните?

>Цитата: ================== JDBC na mnogo bistree chem ODBC pod Unix. ================== И это так и есть.

Человек скорее всего неправильно выразился. Т.е. имел ввиду одно, а написал другое. Бывает со всеми, а Вам приятель, тупо повторять не к лицу.

>к MKuznetsov-у >> tclkit весит 2 Мб - весь дистрибутив tcl/tk с кучей полезностей вроде >> vfs; MegaWidgets - 200k

tclkit может весить (при правильной сборке, выкидывании лишнего и упаковке) -- мегабайт. Другое дело, что это не то что далеко не весь дистрибутив, это вообще НИЧТО. Это голый tclsh + tk.

> интересует именно вин-реализация,

http://activestate.com http://www.equi4.com.

Я бы посматривал постепенно в сторону второго -- тогда со временем дойдёт и до самосборных tclkit'ов.

> как там с интерфэйсами?

Нормальная морда интерфейса у него. С tile ещё красивей.

> например к БД...

tcl dbi?

> и насколько сложно прицеписься к железкам? > например к COM, LPT(через прокладки ессно)

Вот через прокладки и прицепляйся. Сами прокладки очень замечательно приклеиваются swig'ом (http://www.swig.org).

А будут вопросы возникать, заглядывай на http://wiki.tcl.tk.

> Tk. По сравнению с Tk всякие там свинги - говно кривейшее. > кабы там еще какое-нибудь подобие listview было, да было бы оно таки > отдельно от tcl..

Многоколоночный список? Он таки есть, хотя да, таки не очень...

> Tk - это убожество, уж лучше веб-интерфейс

Конечно. На основе tclhttpd и tkhtml.

> да плавали, знаем. только если делать все это на tcl, то с его семантикой и без объектов уж больно грустно. выход -- либо связываться с tcli (или как там оно), или строить бутерброд типа ruby + tk + tcl + MegaWidgets. грустно.

НЕ НАДО ВСЁ ДЕЛАТЬ НА TCL. То-есть надо конечно. Один раз в жизни. Ибо на ошибках учатся.

На TCL нельзя ничего хорошего сделать -- он не предназначен для этого. НЕ ПЫТАЙТЕСЬ НИЧЕГО ДЕЛАТЬ НА TCL. Он пригоден только для НЕБОЛЬШИХ или несложных, не знаю как более точно, программ -- в качестве "клея" для готовых компонентов.

Да TCL имеет различные ОО-расширения: incrtcl -- наиболее близкий по идеологии к C++ (будете пытаться -- рекомендую, по крайней мере отлаженное и проведенное годами решение), модный xotcl, tcl-only расширения вроде stooop... Всё tcl-only тормозное до жути. Отдельно нужно выделить т.н. megawidget system, вроде snit. Тоже, кстати, tcl-only. Ну тут не так критично. Вот последние может быть полезно, если вы пытаетесь делать сложный интерфейс.

НО Я В ЛЮБОМ СЛУЧАЕ НЕ СОВЕТУЮ ПЫТАТЬСЯ ДЕЛАТЬ *ВСЁ* НА TCL.

>> >> И отдельно от тикля его можно использовать. Боюсь, Вы просто не в курсе идеалогии и использования tcl/tk - главное направление scriptable environment так сказать..

>> с таким кривым синтаксисом ффтопку. для скриптования есть: librep, lua, python

> Тю..сравнивать языки по синтаксису - "нравится/не нравится".. > в Лиспе вон скобок много и ничего - живут ;-)

А у питона вместо скобочек -- пробелы. Минное поле усеянное граблями. И глазами-то не видно. Вот это да, синтаксис. brainfuck отдыхает.

> Лучший темизатор Tk : X-resources ;-) > *font Terminus 12 > *Frame.relief ridge

О да! Я второй год голову ломаю: почему дома у меня ни одна tk-шная программа по-дефолту русские буквы не выводит, всё бнопней. А на работе, из свежепоставленного дебиана, да вообще в любом другом линухе -- всё зашибись. Хоть дома дебиан переставляй. Нет, я понял, что шрифт. НО ГДЕ?

>> > Вы просто не в теме, я, например, на Perl'е (используя Tk) пишу программы, которые могут работать сразу и в linux'e и в win, и listview на cpan'e есть

> да в теме я, в теме. только вот какого объема рантайм нужен твоим > прожкам? не проще ли юзеру jre поставить? :-)

Вот про что и речь. Что tcl-овский без ничего умещается в мегабайт. Ну в два-три если с чем-то.

> Про БД : в tclkit входит Metakit - своеобразная БД, ко всем прочим можно найти обёртки у производителей БД и/или отдельные проекты. (в частности tclsqlite - часть дистрибутива sqlite)

Сейчас под БД понимают исключительно реляционные БД. Например, mysql.

>> > мингв уж очень тормозной компилятор. лучше MSVC+gtk. > ??!! >ты не прав.

Он абсолютно прав. Только не компилятор тормозной, а cygwin, который внутри этого mingw, вообще. В linux всё работает в разы быстрей. Даже банальный grep, cvs или find. Я не знаю почему...

fk0 : cygwin и mingw немного совсем разные вещи, и никто из них не сидит внутри другого ;-)

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

так как в Win всё совершенно кверху жопой, то все приложения собираются в основном статически, что естественно увеличивает и время сборки и время загрузки для исполнения.

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

MSVC работает быстрее за счёт активного использования множества мелких dll;к сожалению сделать много dll`ков из libc нереально ;(

>Так что могли бы делать на С++

Na C++ poluchilos bi dolshe v 1.5 - 2 raza. V moem konkretnom sluchae, t.k. dlia produkta nebilo spetsifikatsij i Hibernate pomog ne po detski.

> fk0 : cygwin и mingw немного совсем разные вещи, и никто из них не сидит внутри другого ;-)

Я про msys. Там внутри форк от цигвина.

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

А grep? Какая там, нафиг, линковка? Там коматозит, явно, именно файловая система. Win виноват или cygwin непонятно.

> так как в Win всё совершенно кверху жопой, то все приложения собираются в основном статически,

Если бы. DLL hell -- это про них.

> что естественно увеличивает и время сборки и время загрузки для исполнения.

Ну на счёт загрузки не уверен. Хотя, я плохо представляю в общем случае, как оно там загружается.

> MSVC работает быстрее за счёт активного использования множества мелких dll;к сожалению сделать много dll`ков из libc нереально ;(

В том и суть, что собранное mingw зависит от msvcrt а не от glibc.