Borland объявил о намерении продать свой IDE бизнес

> га, т.е. то, что чисто как язык, OP для нижнего уровня подходит - выяснили. Теперь остаётся только сообразить, что при наличии развитой библиотеки классов, оно и для верхнего уровня подойдёт. Можно, конечно ставить вопрос - а какой ценой будет её создание, но ведь она уже еть.

По сравнению с Java'ской библиотеку Delphi сложно назвать развитой. А то, что в OP есть только один единственный полиморфный контейнер объектов - массивы переменной длины, так ведь на Delphi не пишут программы, которым нужны оперировать сложными структурами данных? А layout manager's в VCL есть? А уж компоненты для работы с БД - ущербны.

> Фактически, вопли ортодоксов, что Delphi - "гуилабалка" мы уже слышали, надо только на годик-два в архив залезть...

А вопли пионеров, о том, что OP - высокоуровненый язык, который годится для написаний прикладных приложений, чем у Hello World! мы слышым до сих пор.

> А layout manager's в VCL есть?

Вообще-то есть, но как и компоненты для работы с БД - ущербны.

>А то, что в OP есть только один единственный полиморфный контейнер объектов - массивы переменной длины,

Ну это неправда, колекции есть, примерно как в яве (<= 1.5) Вот это Delphi6 компилирует (вспомнил институт =))

procedure TForm1.FormActivate(Sender: TObject); var list,listAnother: TList; stack: TStack;

begin list := TList.Create; listAnother := TList.Create; stack := TStack.Create;

list.Add(listAnother); list.Add(stack); end;

или Вы что-то другое имели в виду?

Я имел ввиду, как в STL, ML, Haskell - в вашем примере информация о типе элемента теряется (во время компиляции).

> в вашем примере информация о типе элемента теряется (во время компиляции).

Не совсем. При компиляции можно выкинуть бОльшую часть ран-тайм проверок, а можно и оставить. Да и мощность rtti в OP позволяет налету узнать о классе практически всё. А уж сериализация даже самостоятельно на коленке делается моментально.

> А то, что в OP есть только один единственный полиморфный контейнер объектов - массивы переменной длины

Нефиг всё в язык тащить. Такие вещи хорошо и в RTL держаться. Благо не php, интерпритируемый.

> так ведь на Delphi не пишут программы, которым нужны оперировать сложными структурами данных?

Кто тебе это сказал? Пишут, просто не всегда афишируют. Вот, например (http://astronomy.swin.edu.au/~pbourke/modelling/voxelworld/) - воксельный ландшафтный генератор, для MojoWorld. Написан на FreePascal. Жаль у него страничка на редизайне, там покрасивее были.

> А layout manager's в VCL есть?

Есть. Наверное, похуже явовского. Впрочем Delphi 2005 я не смотрел, там, вроде улучшали.

> А уж компоненты для работы с БД - ущербны.

Это от рук зависит. Теже пару лет назат толпа орала, что Delphi только и пригоден для лабания баз данных. А тут вдруг выясняется что и на это не годится. Где ты тогда был?

> А вопли пионеров, о том, что OP

Ок, вопли пионеров. Правда - не вижу где. Я, вроде, не ору. Кроме того, не смотря на мнение кульхацкеров, народ пишет себе и горя не знает:

http://delphi.wikicities.com/wiki/Good_Quality_Applications_Built_With_Delphi

> Нефиг всё в язык тащить. Такие вещи хорошо и в RTL держаться. Благо не php, интерпритируемый.

Полноценный аналог std::map на OP привести не слабо?

Кто-нибудь из "профессионалов" скажет наконец, на чем можно написать интерфейс к БД??? Или способны только кричать, что Delphi плох, потому что не устраивает язык ObjectPascal??? Какой мощный аргумент - "не нравится язык"!!! Вот уж действительно детство!!! /* Для справки. Главное в Delphi - не язык, а VCL */

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

Итак! Господа профи! На чем можно реально создать интерфейс к БД /* Oracle, PostgeSQL, MS SQL, FB/IB и т.д. и т.п. */.

ЧЕРТ ВОЗЬМИ! Назовите реальную альтернативу Delphi/C++ Builder!

/* Либо, как тут, у профессионалов, выражаются, "слив будет засчитан" всем, кто тут мнит себя таковым профи */

Вы о Java слышали? А о Scala? О Nemerle, Mondrian, F#?

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

Это вы о чем? О пых-пых? Так его здесь (вроде) никто не вспоминал.

> * Для справки. Главное в Delphi - не язык, а VCL */

Для справки: язык определяет интерфейс библиотек, которые на нем написаны. Не напишите вы на Делпхи ничего подобного boost.

> Полноценный аналог std::map на OP привести не слабо?

Если надо именно в одном флаконе, то одна из двух датасетов в памяти. Не помню, как они называются. Надо в хелп к JVCL смотреть.

Если требуется что-то менее извращённое, но для более распространённых случаев, то для ключ - число есть TList, TStrings, Для ключ - строка в JCL - JclStrHashMap. В FPC есть для того же - THash.

Если ну прямо точно как в сях хочется, то смотреть в сторону DeCAL (http://www.delphikingdom.ru/asp/viewitem.asp?catalogid=891).

> ЧЕРТ ВОЗЬМИ! Назовите реальную альтернативу Delphi/C++ Builder!

Хорошо, конечно, только почему это МНЕ сказно?

> Для справки: язык определяет интерфейс библиотек, которые на нем написаны. Не напишите вы на Делпхи ничего подобного boost.

На фетиш наступили? Да, таки определяет. Только зачем мне в точности boost? Если нужна библиотека, предоставляющая некоторые нужные возможности, то такая и берётся. Или считаешь, что больших библиотек из серии All-in-one для Delphi нет?

> Кто-нибудь из "профессионалов" скажет наконец, на чем можно написать интерфейс к БД???

На Java. На Tcl. На Питоне. На Перле.

> Какой мощный аргумент - "не нравится язык"!!!

Конечно мощный. На языке, знаете ли, кодят. А не только мышой формочки лепят.

> Для справки. Главное в Delphi - не язык, а VCL

Эта убогонькая библиотечка? Да кому она нужна такая кривая, неполная и хреново структурированная?

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

Детский сад!

> Или считаешь, что больших библиотек из серии All-in-one для Delphi нет?

Конечно же их нет. Где для делпхы аналог Boost/Spirit?

Восхитительно. То есть, для каждой структуры данных - свой класс. Обобщённых операций над множествами нет. Получается, что делпхи - низкоуровневый язык, не далеко от ассемблера ушел.

> Кто-нибудь из "профессионалов" скажет наконец, на чем можно написать интерфейс к БД???

Я профи себя не считаю, но если речь о GUI, то проще на Qt писать. Если для Web - то на PHP. Если пакетная обработка - то Perl или Python. Всё от задачи зависит.

> Только не надо мне парить про веб-интерфейс!

А никто не парит. Вот будете делать распределённый сбор данных - тогда узнаете преимущества веб-интерфейса. А что, "НИАСИЛИЛ"?

> На чем можно реально создать интерфейс к БД /* Oracle, PostgeSQL, MS SQL, FB/IB и т.д. и т.п. */.

Тык у Oracle был продукт WebDB (ныне Application Server). И не надо геморроя самопального - на PL/SQL замечательно для Web пишутся приложения.

> Назовите реальную альтернативу Delphi/C++ Builder!

Вам под какой операционкой? Если под Windows - MS VS.NET, если под Linux - KDevelop.

Есть скажем функция

void foo(const std::map<A, B>& x)
{
  // чёй-то делаит
}

и на OP:

procedure foo(THash x);
begin
  // но тут мы не знаем - и компилятор не может проверить,
  // что ключами x являются объекты типа A, а начениями - 
  // объекты типа B. Этой процедуре можно подсунуть совершенной 
  // производльный объект типа THash. Поэтому нужно проверять типы
  // во время выполнения программы.
end;

> Я профи себя не считаю, но если речь о GUI, то проще на Qt писать.

На PyGtk тож очень неплохо.

> Вам под какой операционкой? Если под Windows - MS VS.NET, если под Linux - KDevelop.

Про Eclipse еще вспомним, и про NetBeans. Вообще как IDE Delphi не дотягивает до связки {glade/чего там для qt}+emacs+ecb+(svn/cvs/darcs/на выбор).

Да и еще, пжалста, аналог Parsec на Delphi представьте, если не слабо.

Да и boost отнють не монолит:

$ apt-cache search libboost                                                                                                                1:41 pts/1
libboost-python1.33.0 - Boost.Python Library
libboost-date-time1.33.0 - set of date-time libraries based on generic programming concepts
libboost-filesystem1.33.0 - filesystem operations (portable paths, iteration over directories, etc) in C++
libboost-graph1.33.0 - generic graph components and algorithms in C++
libboost-program-options1.33.0 - program options library for C++
libboost-regex1.33.0 - regular expression library for C++
libboost-signals1.33.0 - managed signals and slots library for C++
libboost-test1.33.0 - components for writing and executing test suites
libboost-thread1.33.0 - portable C++ multi-threading
libboost-dev - Boost C++ Libraries development files
libboost-python-dev - Boost.Python Library development files
libboost-python1.33.1 - Boost.Python Library
libboost-date-time-dev - set of date-time libraries based on generic programming concepts
libboost-date-time1.33.1 - set of date-time libraries based on generic programming concepts
libboost-dbg - Boost C++ Libraries with debug symbols
libboost-doc - Boost.org libraries documentation
libboost-filesystem-dev - filesystem operations (portable paths, iteration over directories, etc) in C++
libboost-filesystem1.33.1 - filesystem operations (portable paths, iteration over directories, etc) in C++
libboost-graph-dev - generic graph components and algorithms in C++
libboost-graph1.33.1 - generic graph components and algorithms in C++
libboost-iostreams-dev - Boost.Iostreams Library development files
libboost-iostreams1.33.1 - Boost.Iostreams Library
libboost-program-options-dev - program options library for C++
libboost-program-options1.33.1 - program options library for C++
libboost-regex-dev - regular expression library for C++
libboost-regex1.33.1 - regular expression library for C++
libboost-serialization-dev - serialization library for C++
libboost-signals-dev - managed signals and slots library for C++
libboost-signals1.33.1 - managed signals and slots library for C++
libboost-test-dev - components for writing and executing test suites
libboost-test1.33.1 - components for writing and executing test suites
libboost-thread-dev - portable C++ multi-threading
libboost-thread1.33.1 - portable C++ multi-threading
libboost-wave-dev - C99/C++ preprocessor library

> Поэтому нужно проверять типы во время выполнения программы.

Э... Классно. Смешали ООП и процедуры. :) В данном случае проще сделать потомка от класса, задав ему нужные типы жёско. Благо - создать потомка, перекрыв у него пару методов - это довольно легко.

Собственно, вполне юзабельно и не обременительно, особенно если пишется прикладное приложение, а не сверхуниверсальная библиотека.

> Да и еще, пжалста, аналог Parsec на Delphi представьте, если не слабо.

Может и не слабо, намекни - что это. Гугль ничего убедительного не выдал. Надеюсь, ты не ждёшь, что оно будет так же называться?

> Да и boost отнють не монолит:

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

> Я профи себя не считаю, но если речь о GUI, то проще на Qt писать.

Я смотрел на Qt, как ни странно оставила приятные впечатления, именно в свете VCL. :)

> Про Eclipse еще вспомним, и про NetBeans.

Чего про него (Eclipse) вспоминать, его пользовать надо. :) Конечно, для паскаля он не обязателен, но есть много других языков. :)

> Вообще как IDE Delphi не дотягивает до связки {glade/чего там для qt}+emacs+ecb+(svn/cvs/darcs/на выбор).

Видишь ли, ты опять перегибаешь. Говоришь Delphi IDE, а упоминаешь _связку_. IDE, надо по идее с KDevelop сравнивать, только по честному, не нынешний с Delphi2, а с Delphi 2005. :) А связку с cvs/svn никто не запрещает. Под Delphi, кстати был эксперт cvs. Только мне такие решения не очень нравятся. Предпочитаю внешние. Под Win - TortioiseSVN, под Lin - eSvn.

> Я профи себя не считаю, но если речь о GUI, то проще на Qt писать. Если для Web - то на PHP. Если пакетная обработка - то Perl или Python. Всё от задачи зависит.

Я именно о GUI! Проблем с пакетной обработкой и вебом не возникает... Но написать качественный GUI интерфейс на предлагавшихся тут инструментах... Нда... Есть такая профессия - оператор, это те люди, которые вколачивают массу данных в разного рода БД...

Ко всем! Господа! Заставлять людей, проводящих весь рабочий день за вколачиванием данных, пользоваться тормозным и убогим интерфейсом, наклёпанным на джаве, это садизм! Да и нормального представления данных на джаве не сделать - убогие там виджеты.

Итак! Уточняем задачу! Дано - "фронтэнд" приложение для ввода данных в БД (пресловутое товародвижение - приход/расход товара). На чем, кроме Delphi/C++ Builder, это реально сделать столь же качественно???

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

> Э... Классно. Смешали ООП и процедуры. :) В данном случае проще сделать потомка от класса, задав ему нужные типы жёско. Благо - создать потомка, перекрыв у него пару методов - это довольно легко.

Ничего не смешал. THash будет содержат всякие там TInteger, TDouble - но проверку типов нужно будет осуществлять в run-time'е.

> Может и не слабо, намекни - что это. Гугль ничего убедительного не выдал. Надеюсь, ты не ждёшь, что оно будет так же называться?

http://www.cs.uu.nl/~daan/parsec.html

> Говоришь Delphi IDE, а упоминаешь _связку_

Но эта связка хорошо интегрируется. Вот в чем дело.

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

> Но написать качественный GUI интерфейс на предлагавшихся тут инструментах...

Так конкретные аргументы против Qt/KDE и даже GTK+ будут? :)

> Да и нормального представления данных на джаве не сделать - убогие там виджеты.

Надо же! Вы аплеты Lotus Domino выидели при работе с сервером через Web?

> Дано - "фронтэнд" приложение для ввода данных в БД (пресловутое товародвижение - приход/расход товара). На чем, кроме Delphi/C++ Builder, это реально сделать столь же качественно???

Qt designer (да и Glade) уделывают Delphi/C++ Builder только так. :) Сравним?

>Qt designer (да и Glade) уделывают Delphi/C++ Builder только так. :) Сравним?

А ты не подскажешь, как сделать в Glade свой собственный виджет? И где библиотеки виджетов для Glade от сторонних разработчиков?

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

Потом всё было переписано на Swing. Жить стало лучше. Жить стало веселей.

Да, есть только одна вещь, которую я ненавижу сильнее чем морды на делпхи. Это веб-морды! И AJAX ничуть ситуацию не улучшил.

> Это веб-морды! И AJAX ничуть ситуацию не улучшил.

Плата за универсальность. Зато не надо никакого дополнительного софта.

Меня не волнует универсальность. Я 8 часов в сутки ввожу тупо данные с бумажек. Мне всё равно, как легко или сложно было программахерам программахить это. Они все равно потратили все вместе меньше времени и нервов чем все операторы пользующиеся их продуктом. Они обязаны думать только об удобстве оператора, о его зрении и о том чтобы тот нажимал не больше кнопок чем надо и не использовал бы мышку совсем. А сами пусть хоть на ассемблере кодерят!

Glade - это построитель GUI на основе gtk+. Сделать там свой виджет нельзя (точно также как нельзя смонтировать фильм в текстовом релакторе). Это не его задача. А как писать виджеты gtk+ - STFW, а затем RTFS.

> Ничего не смешал.

Да нет, именно смешал. У тебя объекты, которые ты поручаешь обрабатывать процедуре! OP позволяет использовать и такой способ, но, разумеется, на его реализацию требуются дополнительные накладные расходы.

> http://www.cs.uu.nl/~daan/parsec.html

Ага, да видел я его, но не подумал, что ты о нём. :) Значится парсеры как таковые, конечно есть, только их помнить надо. Это не мой профиль. С задачами парсинга текста я уже давно не сталкивался. Сейчас xml больше, а языки сам, увы не разрабатываю. Раньше - видел и отдельные и в составе интерпритаторов.

P.S. Кстати, parsec на хаскеле написан. :) Тоже не самый популярный язык... ;-)

> Но эта связка хорошо интегрируется. Вот в чем дело.

Ну это... На вкус и цвет - товарищей нет. Кону охота - интегрирует, Delphi IDE сто лет как расширяемая...

> У тебя объекты, которые ты поручаешь обрабатывать процедуре!

У пионера каша в голове.

Это может быть и не процедура, а метод. Суть от этого не меняется.

Разница только в одном: во время компиляции чётко известно, какого типа ключи и значения в хэше будут, и код генерится с учётом этого знания. Никаких левых значений там не будет гарантированно. А в OP во время компиляции никаких гарантий нет, и код должен во время исполнения проверять каждый (!) ключ и каждое (!) значение, используя не то чтобы очень шустрое RTTI.

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

Это вот и есть первейший признак пионеристости.

> используя не то чтобы очень шустрое RTTI

Да тут дело не только в шустрости - ряд программ, корректиных в OP, в Haskell, ML, C++ не будут правильно типизированными (well typed).

> Ага, да видел я его, но не подумал, что ты о нём. :) Значится парсеры как таковые, конечно есть, только их помнить надо. Это не мой профиль. С задачами парсинга текста я уже давно не сталкивался. Сейчас xml больше, а языки сам, увы не разрабатываю. Раньше - видел и отдельные и в составе интерпритаторов.

Угу, вот только такую _библиотеку_ на OP не написать, препроцессор нужен. Или DSL, как например, yacc для C.

Да вот boost::spirit тоже не OP не реализовать.

> P.S. Кстати, parsec на хаскеле написан. :) Тоже не самый популярный язык... ;-)

Я о популярности не говорил. Я просто приводил примеры из C++ как довольно известного языка.

> Так конкретные аргументы против Qt/KDE и даже GTK+ будут? :)

Будут. Нормальный функциональный grid я там не видел. Этого достаточно...

> Надо же! Вы аплеты Lotus Domino выидели при работе с сервером через Web?

О да!!! Вы очень удачно наступили мне на мозоль! Тормозное чудище! А Lotus Notes видели? Работать с ЭТИМ людей можно только ЗАСТАВИТЬ НАСИЛЬНО!

> Qt designer (да и Glade) уделывают Delphi/C++ Builder только так. :) Сравним?

Delphi/C++ Builder уделывают Qt designer (да и Glade) только так. :) Сравнили?

Люди! Я вовсе не стремлюсь спровацировать флейм. Мне действительно хочется узнать/попробовать хороший инструмент для написания междумордий к БД. Но реальных альтернатив для борландовских продуктов я не видел. Спорить же о лучше/хуже нет никакого желания.

И уж вовсе не хотел утверждать, что все написаное на борланде, есть хорошо. Хорошо в нем то, что его использование исключает массу рутины и заключает в себе много качественного готового иструментария. /* Любителей кодить в vim на "чистом" C прошу не разводить словоблудие о "настоящих" программистах */

Комментарий был о том, что Qt и Glade его уделывают Delphi в разработке фронтэндов. Это не так - в Delphi компоненты можно было делать с помощью Dephi. В Glade такое невозможно. Так что со своей задачей (разработка морд) Delphi справляется лучше. Об этом же свидетельствует отсуствие сторонних библиотек виджетов для Glade и россыпи компонентовм для Delphi. Я не любитель Delphi, а Object Pascal - довольно корявый язык, но со своей задачей они справлялись хорошо.

>> Так конкретные аргументы против Qt/KDE и даже GTK+ будут? :)

>Будут. Нормальный функциональный grid я там не видел. Этого достаточно...

Вот нарыл в сети: http://gtkextra.sourceforge.net/ Там вроде есть.

> Комментарий был о том, что Qt и Glade его уделывают Delphi в разработке фронтэндов.

Я говорил о связке glade+emacs+ecb+svn, именно о связке. А вы пытаетесь сравнить несравнимое.

>> Комментарий был о том, что Qt и Glade его уделывают Delphi в разработке фронтэндов.

>Я говорил о связке glade+emacs+ecb+svn, именно о связке. А вы пытаетесь сравнить несравнимое.

Да нет же... Я хочу, чтобы с помощью визуального средства разработки GUI можно было создавать новые элементы GUI, которые потом это же средство использует. Упрощенно - нарисовать новый виджет и поместить его на палитру элементов. Delphi это позволяет, Glade - нет. Поэтому как средство разработки GUI Delphi мощнее.

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

> Да тут дело не только в шустрости - ряд программ, корректиных в OP

Т.е. опять, ссылаемся на то, что OP плох, или не годится, потому что любимый способ написания программ там не применим или применим с ограничениями? ;-)

> Угу, вот только такую _библиотеку_ на OP не написать, препроцессор нужен.

Мдя... Собственно, на этом можно и закончить. Пожалуйста, если тебе так хочеться - _верь_, что нельзя. Если честно, мне просто лениво тратить уйму времени доказывая, что можно. Может точно такую - один-в-один - нельзя, а делающую то же самое - можно. Тем более, что лично я с этого ничего не имею.

Впрочем, специально для тех, кто не мыслит языка без препроцессора, в FPC начали его добавлять. Так что я не удивлюсь, если через годик туда начнут портировать STL... Я к этому отношуть достаточно нейтрально. Мне-то что, я-то C++ знаю. Пусть не в совершенстве (нет постоянной практики), но STL понимаю.

А одновременно, приходится признать, что многие, всю жизнь просидевшие в C/C++ просто не представляют, что препроцессор далеко не обязательная часть языка. Можно даже сказать, навеска. Потому и раздаются возгласы - а вот это есть? Нет? У... Всё, тогда такие-то вещи там НИ КАК не сделать... Гы, лол! ;-)

> Я о популярности не говорил. Я просто приводил примеры из C++ как довольно известного языка.

Дык! Наверное я чего-то глобально непонимаю, но моё имхо приходит в ужас от "пример из C++", написанный на Haskel! ;-)))

>Люди! Я вовсе не стремлюсь спровацировать флейм. Мне действительно хочется узнать/попробовать хороший инструмент для написания междумордий к БД. Но реальных альтернатив для борландовских продуктов я не видел. Спорить же о лучше/хуже нет никакого желания.

Простой пример http://www.informit.com/articles/printerfriendly.asp?p=30649

> Т.е. опять, ссылаемся на то, что OP плох, или не годится, потому что любимый способ написания программ там не применим или применим с ограничениями? ;-)

Тчоно также можно доказывать, что brainfuck - хороший язык. Или whitespace. Конечно же, ОП - алгоритмически полный язык и на нем можно реализовать произвольный алгоритм.

> Мдя... Собственно, на этом можно и закончить. Пожалуйста, если тебе так хочеться - _верь_, что нельзя.

В ОП уже появились параметрическая система типов, классы типов, замыкания и частиное применение функций? Если этого нет, то аналог parsec не написать (boost::spirit использует шаблоны и перегрузку операторов).

> Если честно, мне просто лениво тратить уйму времени доказывая, что можно. Может точно такую - один-в-один - нельзя, а делающую то же самое - можно.

Библиотека комбинаторов в ОП не может быть реализована из-за отстутсвия в нем замыкания функций. А для имитации нужны шаблоны как в С++ (см. boost).

> А одновременно, приходится признать, что многие, всю жизнь просидевшие в C/C++ просто не представляют, что препроцессор далеко не обязательная часть языка. Можно даже сказать, навеска. Потому и раздаются возгласы - а вот это есть? Нет? У... Всё, тогда такие-то вещи там НИ КАК не сделать... Гы, лол! ;-)

Да правда что ли? Я приводил примеры в которых препроцессор не используется. А то, что в ОП аналогичесные библиотеки нельзя реализовать без препроцесора - это недостаток ОП. В _нормальных_ языках препроцессор не нужен. В _современном_ С++ можно свести использование препроцессора к #include и стажам влючения. В Haskell он используется только для условной компиляции.

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

> Впрочем, специально для тех, кто не мыслит языка без препроцессора, в FPC начали его добавлять. Так что я не удивлюсь, если через годик туда начнут портировать STL... Я к этому отношуть достаточно нейтрально. Мне-то что, я-то C++ знаю. Пусть не в совершенстве (нет постоянной практики), но STL понимаю.

Что-то мне подсказывает, что вы не представляете как STL реализована. И тем более не представляете как реализованана boost.

> А ты не подскажешь, как сделать в Glade свой собственный виджет?

GTK+ Дополнительные - Пользовательский эл. управления (с синей буквой C) в glade-2.

> Нормальный функциональный grid я там (Qt/KDE и даже GTK+) не видел. Этого достаточно...

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

> О да!!! Вы очень удачно наступили мне на мозоль! Тормозное чудище! А Lotus Notes видели? Работать с ЭТИМ людей можно только ЗАСТАВИТЬ НАСИЛЬНО!

1. Через веб-интерфейс к Domino работает вполне шустро. То же самое можно сказать и про нативный клиент.
2. Lotus Notes - и есть инфраструктура, где Domino - сервер. Вы не знали?
3. Тем не менее, позиции LN достаточно сильны. Если вы не смогли осилить, то это не говорит о том, что на нём нет решений.

> Delphi/C++ Builder уделывают Qt designer (да и Glade) только так. :) Сравнили?

Аргументов нет. Слив засчитан?

> Но реальных альтернатив для борландовских продуктов я не видел.

Думаю, вы просто не смогли отвыкнуть от Дельфи/C++ Билдера и не попытались разораться с альтернативными решениями. Ваш юношеский (?) максимализм (про Lotus Notes) явно не показывает вас с хорошей стороны. Постарайтесь быть более аргументированным. Здесь не подростки сидят. :)

> Об этом же свидетельствует отсуствие сторонних библиотек виджетов для Glade и россыпи компонентовм для Delphi. Я не любитель Delphi, а Object Pascal - довольно корявый язык, но со своей задачей они справлялись хорошо.

А вы не задумывались, что в грамотном тулките может быть достаточно собственных виджетов чтобы не задумываться про поиск сторонних компонентов? Кстати, и Qt designer незаслуженно обойдён вниманием.

> Да правда что ли? Я приводил примеры в которых препроцессор не используется.

Сдаётся мне что тот пионер относит и темплейты к "препроцессору". На то он и пионер.

> Тчоно также можно доказывать, что brainfuck - хороший язык.

Вряд ли. Я видел пишущих на нём. Практически все поголовно используют препроцессор-транслятор. :)

> Если этого нет, то аналог parsec не написать (boost::spirit использует шаблоны и перегрузку операторов).

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

> Приходится признать, что некоторые не представляют языков с полиморфной системой типов, замыканиями функций и отложенными вычислениями.

Будем устраивать экзамен online? ;-)

> И твердят, что на ОП можно все написать - да, можно, но нужно ли?

Да не нужно. Я сам могу назвать кучу задач, для которых OP не стоит использовать. Так ведь твердят, что для него вообще нет подходящих задач! :)

Кстати, вышеупомянутый Haskel тоже не "всёядный", я читал, что у него gc встроенный. А это не годятся для некоторых задач.

> При этом эти люди гордатся, своим нежелением изучать что либо кроме ОП.

Это о ком? Не надо путать нежелание и симпатии. Кстати, легко повернуть наоборот. :)

P.S. Интересный разговор получился, хотя и на повышенный тонах. Haskel, в качестве следующего детально изучаемого языка я уже рассматривал. А тут ещё дополнительная агитация. :) Только есть одно но - не назовёщь его сколько нибудь используемым языком. На sf сейчас зарегистрировано 47 проектов... :-( На Forth и Lua - больше! А уж на фоне C и C++...

> Здесь не подростки сидят. :)

Боюсь - 4.2 будет... ;-)

> Ну расскажи, что помимо боксов, таблицы, привязки по направлениям и пружин ещё надо?

> Постарайтесь быть более аргументированным

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

> Qt designer (да и Glade) уделывают Delphi/C++ Builder только так. :) Сравним?

Аргументы совершенно неоспоримые! Посему я Вам и ответил:

> Delphi/C++ Builder уделывают Qt designer (да и Glade) только так. :) Сравнили?

С точно такой же аргументацией! (читатайте внимательней)

Я понимаю, что для Вас главное - самоутвердиться, а не отвечать собеседнику. Тут и обвинение в юношеском максимализме и словечки вроде "не осилил". Охотно верю, что Вы уже не подросток, скорее всего Вы уже вполне самостоятельная половая единица, но все же, Ваше желание "повыпендриваться" дает мне основание предположить, что Вам вряд ли "далеко за двадцать" :о)

Что же до LN/Domino - представьте себе, знаком! И не понаслышке! Согласен, в отношении сего "продукта" был излишне эмоционален, но извиняет меня как раз то, что приходится иметь с ним дело... Впечатления самые отвратительные. С Вашим утверждением

> Через веб-интерфейс к Domino работает вполне шустро. То же самое можно сказать и про нативный клиент.

согласиться, к сожалению, не могу. Это - не "вполне шустро", это - "раздражающе тормознуто".

> Тем не менее, позиции LN достаточно сильны. Если вы не смогли осилить, то это не говорит о том, что на нём нет решений.

Да-да, кстати о решениях. Именно с ними и имею дело. Кстати, разработка этих решений мало отличается от разработки на Delphi. Скажу больше, этот разработка на лотусе скорее уж сродни MS Access, так что предположение о моей малограмотности было уж слишком смелым.

Кстати, о наших баранах, я ведь спрашивал о средствах разработки интерфейса к БД. К чему тут LN? Или в качестве БД предполагается использование таблиц сервера Domino? Даже не смешно - вы еще текстовые файлы предложите! Или DB2? Да уж, универсальный иструмент разработки получается! Или Вы про ODBC? Знаете, тогда с тем же успехом можно в качестве средства разработки интерфейса и MS Excel, например, использовать.

Так что, прошу Вас иногда думать, прежде чем ответить. (Как альтернативу, могу предложить Вам выбрать иную "жертву" для самоутверждения).

Нда... Пока сплошные разочарования... Просил "сидящих тут не подростков" подсказать реальную альтернаиву Delphi для КОНКРЕТНОГО применения. В ответ же получил заверения "не пожростков" в их "крутости" и ничего более.

Народ! Очень прошу ответить на изначальный вопрос - на чем можно разрабатывать интерфейс к БД стольже эффективно, сколь и на Delphi.

Чем вас не устраивает, например, MS Access?
Или Microsoft Visual Basic?
Иными словами, какие у вас критерии эффективности "разработки интерфейса к БД"?

> Во-первых, Вы уж определитесь, на "ты" мы или на "вы".

А как хотите? Давайте на "Вы". :)

> Во-вторых, раз уж от грида Вам ничего больше не надо и Вы не видели библиотеку EhLib

Похоже, у нас разное понимание что есть "Grid". В терминологии Qt "grid" - термин для менеджеров компоновки (к примеру, класс QGrid). То, что вы называете "grid" - это виджет работы с базой данных. См. http://doc.trolltech.com/3.3/sql.html#8

> В-третьих, по-поводу аргументирования - это не Ваша фраза?

Моя. Поэтому я и хотел услышать аргументы, а услышал лишь неизвестное (IMHO, даже надуманное) применение термина. Хотя... сила привычки.

> С точно такой же аргументацией! (читатайте внимательней)

Я и читаю. Только я предложил сравнить (несовершённое время - призыв к действию), а вы выдали лозунг и глагол совершённого вида. Ну и куда нам с такими аргументами? :)

> Я понимаю, что для Вас главное - самоутвердиться, а не отвечать собеседнику. Тут и обвинение в юношеском максимализме и словечки вроде "не осилил".

Неужели? Если меня задевают лозунги и нежелание собеседника разобраться в альтернативных технологиях, то я не могу уже серьёзно относится к разговору. Почему у нас (KDEшников) с локализаторами и разработчиками Gnome находится общий язык? Отвечу: для нас не зазорно почитать документацию по альтернативным решениям. Даже хотя бы для того, чтобы понять термины в толковании именно на целевой платформе. У вас этого нет. :(

> я ведь спрашивал о средствах разработки интерфейса к БД. К чему тут LN?

Ваша цитата: "Да и нормального представления данных на джаве не сделать - убогие там виджеты" требовала внести пример хороших виджетов на Java. Вот я LN и привёл в качестве примера. Можно было бы и eSuite от IBM привести.

> Или в качестве БД предполагается использование таблиц сервера Domino?

Ели работали с Lotus Domino, то уж про DECS должны были знать. :) Хотя это оффтопик и LN приводился лишь в пику утверждения о некрасивости виджетов Java. :)

> Очень прошу ответить на изначальный вопрос - на чем можно разрабатывать интерфейс к БД стольже эффективно, сколь и на Delphi.

Qt+Qt Designer+KDevelop. Вам уже указали, но вы предпочли не заметить. Ссылка с примерами - чуть выше в моём посте. :)

P.S. Не надо обижаться: LOR прежде всего - площадка для трёпа. Соответственно, если хотите серьёзного обсуждения без подколов и прочего - идите на linuxforum.ru. Здесь всё слишком несерьёзно воспринимается. Если обидел - прошу прощения. Мысли самоутвердится не было и в помине (я уже давно не являюсь гиком и удовольствия от подкалывания снобствующих ламеров особого не испытываю). Но вы сами подставляетесь. :)

> Чем вас не устраивает, например, MS Access?

Нууу, батенька (матушка)... Так можно далеко зайти... Например, мне не нравится работать с БД через ODBC - это, мягко говоря, не очень эффективно. Уж на то пошло, если будет такая необходимость - ODBC и ничего кроме, уж лучше взять MS Visual FoxPro.

Эффективность разработки, на мой взгляд, - наличие удобного API для работы с БД (вернее, компонентов использующих нативное API, например - ZeosDBO) и наличие удобных и многофункциональных средств визуализации/редактирования данных. Например - EhLib (кто использовал, очень хорошо меня поймет). И, в конечном итоге, скрость разработки. Ведь все можно писать и на "чистом" С с использованием нативного API сервера и OS. Только, простите, кому это надо? Разве что хакерам голливудского розлива :о)

Гаспода, дамы и определяющиеся! :о) Ну не вижу я пока столь же удобного, универсального и эффективного средства для разработки интерфейса для БД (и не только для этого, что тоже немаловажно), как Delphi/C++ Builder. Кстати, прошу заметить, что выбор между Delphi или C++ Builder не принципиален и является делом вкуса, поскольку оба инструмента предполагают одинаковую идеологию и технологию разработки. Поэтому и вопрос к присутствующим не о выборе языка (выбор языка - это проблема тех, кто только начал "открывать для себя мир"), а о выборе инструмента, что есть гораздо больше чем язык (тех, кто этого не понимает, прошу не беспокоиться).

> То, что вы называете "grid" - это виджет работы с базой данных.

Вообще-то речь шла как раз о работе с БД.

> Отвечу: для нас не зазорно почитать документацию по альтернативным решениям.

Я б тоже почитал! Именно для того и прошу назвать альтернативу! :о)

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

Если Вы такой знаток русского языка, могли б и заметить вопросительный знак после указанного глагола. Я лишь вспомнил бородатый анекдот, про то, что армяне лучше, чем грузины. (На резонный вопрос - "чем?", следует ответ - "чем грузины").

Впрочем, Вы правы - глупо было рассчитывать на реальные ответы.

> Qt+Qt Designer+KDevelop.

Все это работает на той же платформе, что и Delphi? ;о)

> LN приводился лишь в пику утверждения о некрасивости виджетов Java.

Вообще-то, я о скрости... Красивости LN не занимать, как и нестандартности тоже.

> P.S. Не надо обижаться: LOR прежде всего - площадка для трёпа. Соответственно, если хотите серьёзного обсуждения без подколов и прочего - идите на linuxforum.ru. Здесь всё слишком несерьёзно воспринимается. Если обидел - прошу прощения. Мысли самоутвердится не было и в помине (я уже давно не являюсь гиком и удовольствия от подкалывания снобствующих ламеров особого не испытываю). Но вы сами подставляетесь. :)

Попросить прощения и тут же обгадить повторно! Ну Вы мастер! Я оценил! :о)))

> выбор языка - это проблема тех, кто только начал "открывать для себя мир"

О том, что язык вибирается под задачу, Вы кончено же не слышали?

Инструмент! А не язык! Будете спорить, что реинкарнации того же C++ от MS и Borland есть разные весчи?

Вот язык это типа не инструмент уже. Смешно!

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

Понимаете, товарищ... Как бы повежливее объяснить?

В общем, вы - ламер. Полный. Безграмотность через край переливается при каждом взбульке. Данное ваше очевидное свойство никак не должно сочетаться с принятым вами менторским самоуверенным тоном. Ферштейн?

Возвращайтесь после того как посмотрите на Perl (со всем доступным инструментарием с CPAN), Python и Tcl. Вовзращайтесь к дискуссии когда поймёте, что язык это важнейшая составляющая инструмента разработки, что языков универсальных не бывает вообще, все языки под разные задачи точены, что API это мелочь и что в плохом языке не может быть хорошего API.

> В общем, вы - ламер. Полный. Безграмотность через край переливается при каждом взбульке. Данное ваше очевидное свойство никак не должно сочетаться с принятым вами менторским самоуверенным тоном. Ферштейн?

Спасибо, что раскрыли мне глаза на мою гнилую сущность.

> Возвращайтесь после того как посмотрите на Perl (со всем доступным инструментарием с CPAN), Python и Tcl. Вовзращайтесь к дискуссии когда поймёте, что язык это важнейшая составляющая инструмента разработки, что языков универсальных не бывает вообще, все языки под разные задачи точены, что API это мелочь и что в плохом языке не может быть хорошего API.

Если "API это мелочь", то вряд ли вы написали что-то серьезнее, чем "HELLO WORLD". Наверное, printf/puts - "Ваше все". (если вы занимаетесь разработкой драйверов, то прошу извинить :о))))

Я уже понял, что Вы не относитесь, к категории читателей. Вы - писатель. Иначе, удосужились бы прочесть мой вопрос (там же содержится описание КОНКРЕТНОЙ задачи):

> на чем можно разрабатывать интерфейс к БД столь же эффективно, сколь и на Delphi.

>Возвращайтесь после того как посмотрите на Perl (со всем доступным инструментарием с CPAN), Python и Tcl.

Представьте! Я знаю Perl! Такой вот я забавный зверек (с) Змей Горыныч. (не верится?). Только не пойму, как он может являться альтернативой Delphi? (если пошла песня про веб-интерфейс, то это уже становится скучно)

Повторю в последний раз свой вопрос. Альтернатива Delphi/C++ Builder для создания фронт-энд приложений для работы с БД (Postgres, FB/IB, Oracle итд).

Задавая вопрос, я не хочу заниматься вопросами сравнения "крутости". Мне интересно УЗНАТЬ.

Тем, кто считает, что интерфейс - дело десятое. Удачи вам в занятии искусством ради искусства.

> Вот язык это типа не инструмент уже. Смешно!

Обхохочешься. Язык вообще-то - вещь академическая. Меня же интересуют конкретные реализации того или иного языка (компилятор/IDE/библиотеки) для решения указанной мной задачи, как реальная альтернатива DELPHI.

Не знаете вы perl, ламер. Иначе знали бы, насколько с Perl/Tk быстрее и эффективнее можно морды к БД разрабатывать, чем с делпхи в котором даже layout manager-а нет.

А API это несущественная мелочь по причине FFI и unix way, но вам, снобствующему ламеру, этого не понять. Ума, увы, не хватит.

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

> Например - EhLib (кто использовал, очень хорошо меня поймет)

Что-то мне подсказывает, что эхлиб не поставляется вместе с делфи... Я прав?

> Не знаете вы perl, ламер. Иначе знали бы, насколько с Perl/Tk быстрее и эффективнее можно морды к БД разрабатывать, чем с делпхи в котором даже layout manager-а нет.

Чего нет в Delphi??????? На..я козе баян???????? :0))))))))))))))))))))))))))

Вот уж кто действительно ламер - так это Вы! Беретесь спорить о том, чего не знаете. Вы на Delphi, кроме лабораторных работ что-нибудь писали? Или "унверситетов не кончали" вообще?

Кстати, Вы не из детей пророка будете? Уж больно фанатизмом попахивает от Ваших постов.

Желаю Вам добраться unix way'ем куда-нибудь подальше от десктопов :о)

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

> Что-то мне подсказывает, что эхлиб не поставляется вместе с делфи... Я прав?

Вполне! Но ни для чего другого он не поставляется тоже :о)

Так так, из ламера снобизм продолжает выпирать.

На ..я козе баян? А на такое вот ..я, что юзер слепенький, шрифтик побольше поставить хочет. Или результат запроса из базы оказался немножко не того размера, строчка длинная в label попала.

Вам, ламер, ответили на вопрос. Конкретно. Perl, Tk, DBI. Или аналогичная связка с Python. Или с Tcl. Все это в десятки раз более эффективно чем ламерский ничтожный делпхи для вами же поставленной задачи (крайне по ламерски сформулированной, ну это простительно, откуда пионеру знать, какие вообще интерфейсы у БД бывают и что такое БД вообще).

>> Что-то мне подсказывает, что эхлиб не поставляется вместе с делфи... Я прав?

>Вполне! Но ни для чего другого он не поставляется тоже :о)

Имелось ввиду, что это... гм.. "сторонняя разработка"?

> На ..я козе баян? А на такое вот ..я, что юзер слепенький, шрифтик побольше поставить хочет. Или результат запроса из базы оказался немножко не того размера, строчка длинная в label попала.

Что доказывает Ваше полное незнание Delphi.

> Конкретно. Perl, Tk, DBI.

DBI? Ну, продолжайте... Вы точно писатель, а не читатель, я уже высказывал свое мнение об универсальных интерфейсах...

Что же до моего незнания БД. Вам виднее, о Великий. Вы только не злитесь так - язву наживете.

Я все понял, Delphi - плохо, Windows - плохо и популярны они по недоразумению, а не потому что у unix way большинство апологетов подобны Вам - творцу, сидящему в башне из слоновой кости и до общения с простыми смертными не опускающемуся. Только слюной не надо брызгать - Вы мне экран весь заляпали.

> Имелось ввиду, что это... гм.. "сторонняя разработка"?

Империя готовит ответный удар? :о))))

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

уважаемый, хватит вилять, говорите прямо - поставляется он вместе с дельпи, или его надо с инета тянуть?

тогда уж откройте еще одну маленькую тайну: какие классы дельфи НЕ ЯВЛЯЮТСЯ наследниками TObject?

> уважаемый, хватит вилять, говорите прямо - поставляется он вместе с дельпи, или его надо с инета тянуть?

Не продолжайте. Вам сюда http://www.lib.ru/SHUKSHIN/srezal.txt

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

Только вот на путь истинный что-то меня никак никто не наставит. Видно слабо...

> тогда уж откройте еще одну маленькую тайну: какие классы дельфи НЕ ЯВЛЯЮТСЯ наследниками TObject?

Вам бы на митингах выступать (с) М.А. Булгаков.

EhLib лишь расширяют функциональность Data Controls.

я задал 1,5 простых вопроса. Трудно ответить "да"/"нет"?

Вам действительно интересно УЗНАТЬ?? или хотите овец заблудших наставить на путь истинный?

> Вам действительно интересно УЗНАТЬ?? или хотите овец заблудших наставить на путь истинный?

ДА!!! Мне интересно узнать... И вовсе не собираюсь никого призывать использовать Delphi! И сам бы хотел попробовать что-то иное. Только что?

(Давайте, скажите все, что думаете о Delphi! Я вижу, Вас распирает! Вперед, не стесняйтесь)

Да? Хотим узнать? Или наглядно продемонстрировать, что нет среды кроме дельпи? Попробуем еще раз. Итак...

эхлиб входит в типовую поставку делфи? (нужное отметить) [ ] да [ ] нет [ ] я не собираюсь доказывать такую очевидые вещь как незаменимость делфи принаписании интерфейсов к базам данных таким ламерам которые и дельфи в глаза не видели и если кто не назовет мне прямщас что может быть круче тот сам ламер и красноглазик а кто будет спорить тот по определению фанатик пингвиновод.

) жду.

Все, Вы меня "срезали" (c) Шукшин В.М.

Ехлиб не входит в поставку дельфи (не пойму, почему Вы меня заставляете озвучить сей очевидный факт). Я ламер/красноглазик и тп. И ламер как раз потому, что вступил в полемику с подобными Вам. Спасибо Вам за все.

Вы добились огромных успехов в демагогии. Так держать.

Удовлетворены?

>Ехлиб не входит в поставку дельфи

уфффф... давно б так!

>(не пойму, почему Вы меня заставляете озвучить сей очевидный факт).

Да потому что сей факт (для меня) не очевиден! Да-да! Оказывается, есть люди которые не используют дельфи!)) (и, соответственно, не следят - что там добавилось из новых компонентов)

> Вообще-то речь шла как раз о работе с БД.

Это в вашем, дельфийском понимании. :)

> Я б тоже почитал! Именно для того и прошу назвать альтернативу! :о)

Qt. Без вариантов. :)

> Все это работает на той же платформе, что и Delphi? ;о)

Да. И не только: Microsoft Windows XP, 2000, NT 4, Me/98, Mac OS X, Linux, Solaris, HP-UX, IRIX, AIX, many other Unix variants... (взято с сайта trolltech.com) На этом зоопарке Дельфи работает? :)

> Тем, кто считает, что интерфейс - дело десятое. Удачи вам в занятии искусством ради искусства.

Нда, вы безнадёжно застряли в середине 90-х. Сейчас на первый план выходят компоненты бизнес-объектов и сервера приложений. А вы тут: интерфейс, интерфейс... :)

> Нет, всё же мой первоначальный вывод относительно испорченных делпхёй остаётся в силе.

Согласен. Ибо это люди воинственные (в отличие от остальной массы разработчиков). MonsterMan, кстати, прекрасный образец. :)

> Все это в десятки раз более эффективно чем ламерский ничтожный делпхи для вами же поставленной задачи

В принципе, можно было назвать Qt и успокоится. Как раз хорошая замена для подобных мигрантов. :)

>В принципе, можно было назвать Qt и успокоится. Как раз хорошая замена для подобных мигрантов. :)

Он не мигрант, имхо, он мессионер :)

> Qt

Или gtk+ для интерфейса + отдельные либы для работы с БД (я не знаю в каком состоянии gda находится) :-))

Да и вообще морды надо писать на скриптовых языках - для того они и есть (ну не только, конечно :-))

> Нда, вы безнадёжно застряли в середине 90-х. Сейчас на первый план выходят компоненты бизнес-объектов и сервера приложений. А вы тут: интерфейс, интерфейс... :)

Понимаю, что слишком мелко плаваю :о) Но все-таки, интересно узнать про те данные, которые перемалывают сервера (или все-таки серверы?) приложений - их кто-то должен вводить? :о)

Или придумали что-то новое, а я все про интерфейс? :о)

> Согласен. Ибо это люди воинственные (в отличие от остальной массы разработчиков). MonsterMan, кстати, прекрасный образец. :)

Не понимаю, зачем Вы мне приписываете то, чего нет? Тем более, мессионерство?

Думаете, не понимаю, что последние реинкарнации дельфи похожи скорее на агонию? Прекрасно понимаю. Не надо меня записывать в ортодоксы.

Все чего хотел - помощи в выборе инструмента. Именно инструмента, поскольку обленился, знаете ли. И молотить мегабайты текста в каком-нибудь vi (vim, gvim) (прикинте, тоже знаком :о)) мне прочему-то не улыбается. Упоминаная о vi, я утрирую, а вовсе не провоцирую на флейм. И вообще, мне не понятны причины вашей агрессии (в которой меня же обвиняют :о)))

> Да и вообще морды надо писать на скриптовых языках - для того они и есть (ну не только, конечно :-))

Фишка в том, что быстродействие нативных С/C++-приложений повыше будет. Хотя (как уже говорилось) - всё от задачи зависит. Кто-то и X-овый dialog использует для интерактивности своих скриптов. :)

> Или придумали что-то новое, а я все про интерфейс? :о)

Интерфейсы разными бывают. Зря вы пренебрежительно о веб-интерфейсах говорили. Да, для накладных торговой фирмы или POS-терминала они слабо подойдут. Но есть множество задач, где веб-интерфейс успешно используют. Тот же CRM.

Это не он, это я считаю Вас эдаким мессионером в этом топе. Основания? Извольте!

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

Именно потому, что вступил "в полемику" и на протяжение доброго десятка постов вертелся как вошь на гребешке и нес всякий религиозный бред. Это вместо того, чтобы на простой вопрос дать односложный ответ: "Ехлиб не входит в поставку дельфи"

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

Именно потому, что в Вашу светлую голову даже не заглянула мысль - можно поискать аналог либы для [кута]. А тем более - самостоятельно реализовать необходимый функционал. (Раз уж вы програмист со специализацией)

> Не понимаю, зачем Вы мне приписываете то, чего нет?

Уважаемый MonsterMan! Я в самом начале указал вам на Qt и GTK+. Но вы предпочитаете игнорировать мои посты о Qt. Поэтому я не сдержался и скатился на откровенное подкалывание.

> Все чего хотел - помощи в выборе инструмента. Именно инструмента, поскольку обленился, знаете ли.

Пять дней назад (11.02.2006 1:27:17) я вам уже написал про Qt. И что, вас этот ответ не устроил. Рекомендую запустить qtdemo и посмотреть что и как можно делать на Qt (в том числе и интерфейсы с БД).

> И молотить мегабайты текста в каком-нибудь vi (vim, gvim) (прикинте, тоже знаком :о)) мне прочему-то не улыбается.

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

> И вообще, мне не понятны причины вашей агрессии

Посмотрите на первый абзац этого моего ответа. Ещё раз суммирую: посмотрите Qt, поиграйтесь с qtdemo. На это время постарайтесь не писать на этот форум. Когда накопятся конкретные вопросы по Qt - приходите, обсудим. Сейчас вы игнорируете информацию, которую вам дали и ввязываетесь в обсуждение вашего любимого Дельфи. Такая "глухота" и провоцируют мою (и, наверно, не только мою) агрессию. :)

> Именно потому, что начал сравнивать штатный кутовский грид (или как он там правильно - хз) с какой-то левой тулзой. Из чего последовал "логичный" вывод: кут - ацтой! (почему бы уж не сравнить с TDBGrid, хотя бы??)

Вы сами выводы делаете и сами спорите - видно Вам так хочется. Не хочу я ничего сравнивать. Противоречий не находите в своих рассуждениях? Я с таким же успехом могу заявить, что Qt не входит в постаку gcc, занчит - левая тулза! (Абсолютно бредовое заявление, согласен! но оно подстать Вашим). За предложение реализовать необходимый мне функционал спасибо Вам огромное. Только я уж лучше воспользуюсь готовым - мне конкретные задачи надо решать. Специализация как раз была серьезной вехой на пути прогресса ;о)

> Это не он, это я считаю Вас эдаким мессионером в этом топе.

Я понял. Просто Ваша теологическая лексика сама подталкивает к выводам о Вашей религиозности в сугубо прикладном вопросе :о)

> Сейчас вы игнорируете информацию, которую вам дали и ввязываетесь в обсуждение вашего любимого Дельфи.

Зря Вы. Вовсе не пытался. Хватит уже клеймить меня - вполне достаточно. (Кстати, любви вот к Delphi совершенно не испытаваю, но о предпочтениях я лучше умолчу, а то опять всех повыпирает - это мое дело, личное :о))

Я на счет Qt уточнить хочу. Вы скажите - я Вам на слово поверю, вижу, Вы человек нормальный. Qt действительно лучше Delphi? Или тоже самое в профиль и лучше только тем, что не Delphi?

Если можно, капельку примеров. Кстати, остается неясным вопрос о компиляторе под оффтопичную (или оффтопную?) платформу.

> Qt действительно лучше Delphi? Или тоже самое в профиль и лучше только тем, что не Delphi?

Qt всё же лучше Delphi. Гораздо лучше реализована компоновка (помните я вам перечислял), отличные инструменты интернационализации, и есть почти всё что нужно (не надо качать левые библиотеки). Плюс платформ поддерживает гораздо больше, чем Дельфи.

> Кстати, остается неясным вопрос о компиляторе под оффтопичную (или оффтопную?) платформу.

От компилятора MSVC - до gcc:
cygwin-g++
win32-g++
win32-icc
win32-msvc
win32-msvc.net

Забыл добавить ссылку: http://www.trolltech.com/developer/faqs/index.html?catid=1853

Выбирай компилятор слева. :)

P.S. Я рад. что у нас началась конструктивная беседа. :)

> Фишка в том, что быстродействие нативных С/C++-приложений повыше будет.

Ну так кто же мешает написать performance-critical куски кода на тех же С++, ML, Haskell?

> Хотя (как уже говорилось) - всё от задачи зависит. Кто-то и X-овый dialog использует для интерактивности своих скриптов. :)

Ну а кто-то read... :-)))

> Why is there no support for Microsoft Visual Studio compilers in your Windows Open Source Edition? Answer:

> There are two main reasons. We want our Open Source Edition to support an Open Source compiler. The logical choice then is to support the Windows version of gcc, MinGW. The second reason is that we need to balance our need for sustainable business with our want to support Open Source. We are releasing the full Qt API and set of tools as Open Source on Windows, so there is no difference in the available product. All Open Source developers have access to MinGW. We believe that support for Microsoft compilers is one area where we can meaningfully differentiate between commercial and Open Source use.

Фигня однако получается... Я заповеди конечно помню... Но.

> Qt действительно лучше Delphi? Или тоже самое в профиль и лучше только тем, что не Delphi?

В данный момент я использую Python+Qt(pyQt)+QtDesigner+emacs. Как по мне - лучше Делфи. За исключением генератора отчетов. ФастРепорт самый удобный.

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

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

А мне дельфи/си-билдер нравятся. Не понимаю, чем они отличаются от Qt или той же явы в плане разработки интерфейсов. По моему, принципиально ничем...

Ламо, ты откуда выползло? Я уж не говорю о том, что ты сравнило _среду разработки_, _тулкит_ и _язык програмирования_. Различия в создании GUI средствами Qt Designer, редакторами интерфейсов SWING, Glade и Delphi тут уже были описаны - так что прочитай тред.

Ну а в приложении кроме интерфеса еще есть как ни странно логика обработки данных. А вот ее писать на ублюдочным быдлояычке ОП крайне неудобно.

Так что, ламо, ползи обратно в свое болото и доообразовывайся.

> В данный момент я использую Python+Qt(pyQt)+QtDesigner+emacs. Как по мне - лучше Делфи. За исключением генератора отчетов. ФастРепорт самый удобный.

Дело вкуса. Однако, поделитесь секретом, где Вы взяли заказчика, который согласился перейти на Linux (*BSD?) ?

> Чесно говоря не могу назвать Делфи специализированным инструментом. И, как по мне - проще написать набор своих либ, реализующих необходимую функциональность, чем работать в неуютной мне среде.

Я назвал конкретную либу специализированной. А "уют" - дело привычки и ничего более :о)

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

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

Сам имел библиотеки на С/ассемблере для использования на С в VAX/VMS - пошло прахом :о), потом на Turbo C, потом на Clipper, VFP итд... Надоело что-то...

А ты хам. Как раз из категории быдла.

> Ну а в приложении кроме интерфеса еще есть как ни странно логика обработки данных. А вот ее писать на ублюдочным быдлояычке ОП крайне неудобно.

Глубокая мысль! А вода мокрая, а небо синее. А данные на стороне сервера не пробовал обрабатывать?

> Дело вкуса. Однако, поделитесь секретом, где Вы взяли заказчика, который согласился перейти на Linux (*BSD?) ?

Я предпочитаю пользоваться дверьми, а не окнами. Потому уговорил начальство несколько некритичных машин перевести на Линукс, в виде эксперимента. Тем более, что питон и КуТе(под винду стоит денег) вещи кроссплатформенные. Некоторые проблемы в виде того, что GPL-ная версия pyQT не работает с базами данных, решилась (и на Виндовс-машинах в т.ч.) использованием тех библиотек, о которых я писал выше.

> Не согласен, пол-года - слишком долго. Не понял про параллельную разработку программы и библиотек.

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

> И, извините за крамолу, зачем изобретать велосирпеды, если они уже есть?

Причина проста. Когда доходит до сложных вещей, делфи перестает быть RAD. С моей точки зрения. Расшифрую:
1) Мне лениво прописывать какждое событие по много раз (в однотипных приложениях, которые, тем не менее, нельзя сделать копи/пасте). Слишко рутинно с моей точки зрения.
2) Мне не очевидна логика приложения, выраженная в инспекторе объектов. Я не вижу целой картины. Примеры: подключение справочников (на ключевое поле вешается другое Query) без написания кода, через инспектор; однажды, как только я начал практически использовать Делфи, мне доставило немало хлопот случайно установленное свойство в ИО.
3) Все равно надо покупать левые компоненты - EhLib, FIBPlus, FastReport, т.к. родные (за которые плачены деньги, между прочим) бледно выглядят на их фоне.
4) Пасаль. Что ни говори, а язык избыточный.
5) Отсуствие кроссплатформенности.
6) куча мелких претензий и глюков по ходу работы, которые и перечислять лениво.

ЗЫ Как писал Окуджава, "каждый пишет как он дышит, каждый слышит как он дышит".

Вдогонку.
> GPL-ная версия pyQT не работает с базами данных

Это только под Виндовс. Под Линукс все нормально. Это связано с тем, что нет официальной __бесплатной__ pyQT под Виндовс. Вытащенная из Линукс, и собранная под Винду pyQT не умеет работать с базами данных :-(

И еще. Бывают ситуации, когда вышеописанные недостатки перекрываются достоинствами

> Ну так кто же мешает написать performance-critical куски кода на тех же С++, ML, Haskell?

Тихо, тихо! Парень только-только начал приобщаться к разнообразному миру программирования под Unix. У него от скриптов крышу срывает, а если мы ему про сборную солянку из скриптов и Сишного кода будем рассказывать - растеряется... :)

> Не понимаю, чем они отличаются от Qt или той же явы в плане разработки интерфейсов. По моему, принципиально ничем...

Скажите, какие методы компоновки использует дизайнер Дельфи?

Qt: произвольное размещение, box'ы, таблицу. Добавим сюда пружины и политику изменения размеров.

P.S. Визуализация сигналов и слотов тоже в Qt сделано красиво.

А Unix и есть сборная солянка - пусть привыкает, что каждую задачу надо решать на том, что лучше подходит (логику на ФЯ, морду - на скриптовых языка). Заодно узнает про AF_UNIX сокеты :-))

> каждую задачу надо решать на том, что лучше подходит

Вообще-то принцип Unix - всё можно сделать несколькими путями. Хочет - на C++, но то же самое можно сделать и скриптами. Не надо выводить аксиому про морду на скриптовых языках, а уж тем более логику - на ФЯ (функциональные языки, я правильно понял?). На чём ЕМУ удобнее - пусть и пишет. Только без перегибов в виде Pascal или OCaml. :)

Я привел на чем МНЕ удобнее, ни в коем случае не аксиму. В Unix в принципе никто не мешает писать и большие монолитные приложения.

ЗЫ: а в чем Ocaml перегиб? Скорее уж недогиб :-)))))))

"Скажите, какие методы компоновки использует дизайнер Дельфи?

Qt: произвольное размещение, box'ы, таблицу. Добавим сюда пружины и политику изменения размеров.

P.S. Визуализация сигналов и слотов тоже в Qt сделано красиво"

Хм. По-моему, в дельфи-таки есть некоторые "методы компоновки" - анкеры и т.п., во-вторых, наверняка есть сторонние компоненты, а в-третьих, не вижу причин по которым невозможно за не такое уж большое время написмть свой собственный layout manager - по крайней на C++ это у меня заняло полторы недели с нуля. Конечно, если концентрироваться только на алгебраической системе типов и монадах, то такая сложная задача покажется безусловно неразрешимой :)

"Ламо, ты откуда выползло? Я уж не говорю о том, что ты сравнило _среду разработки_, _тулкит_ и _язык програмирования_."

Ути-пути, какие мы грозные... Наверное этот товарищ слюной весь монитор забрызгал, пока писал :) Успокойтесь уважаемый, без Вас я конечно же не разберусь в столь непростом вопросе.

"Так что, ламо, ползи обратно в свое болото и доообразовывайся."

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

> не вижу причин по которым невозможно за не такое уж большое время написмть свой собственный layout manager

Зачем изобретать велосипед? :)

"Зачем изобретать велосипед? :)"

Дык, зачем вообще программировать? Все, что надо до нас уже запрограммировали, а что не запрограммировали, то Begemoth на хаскеле напишет и будет всем счастье :)
Хотя нет, кроме хаскеля еще на ткл морду нарисует, вот тогда уж точно коммунизм настанет! :)

> Дык, зачем вообще программировать?

Ну утрируйте. Нормальный программист не будет заново изобретать мелочи, а сфокусируется на решении своей задачи. Вы про повторное использование кода разве не знали? :)

>Ну утрируйте. Нормальный программист не будет заново изобретать мелочи, а сфокусируется на решении своей задачи. Вы про повторное использование кода разве не знали? :)

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

> Что-то мне подсказывает, что эхлиб не поставляется вместе с делфи... Я прав?

Ты прав, не поставляется. Но широта ассортимента поставляемых компонентов, она вообще - поражает. Не, для 90% задач того, что идёт штатно хватает. Не надо изобретать велосипедов. С другой стороны, помню, на рубеже веков, участвтсовал я в одной разраьотке на MSVC, так там народ, когда им грид понадобился - первым делом купил FlexGrid. ;-)

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

Не, ты не понял что ли с кем решил говорить? Кто громче всех кричит "держи вора"? ;-) Правильно, вот тебе пионер с "той стороны". Я его уже давно лесом послал, да малчук всё никак не уёмётся, исправно комментит все мои посты. Вот и этот сейчас откомментит, считая себя жутко остроумным и оригинальным. :)

А его предложение - говорит само за себя. Perl/Tk! Когда конечным пользователем будут люди, уровня секретутки. (Сейчас, очевидно, в коммент попадёт сообщение, что такие пользователи должны сдохнуть... ;-) ) Я ещё мог бы подумать о чём-то, если бы указали Perl/Qt или Perl/Gtk... ;-)

Кто не видел Perl/Tk:

http://www.perl.com/1999/10/perltk/img011.gif

http://ptktools.sourceforge.net/img/tkrevdiff.png

:lol:

Загиб про FFI(Foreign Function Interface) - это вообще песец, он расписался в том, что предлагаемый им инструмент заведомо не может решить данную задачу или сделает это не эффективно... ;-)

Ну и нафига с убогим общаться? То, что грязью поливает? Так он не умеет по другому.

> Чего нет в Delphi???????

Layout Manager - это такая фиговина, что занимается определением размеров и местоположения виждетов на форме, их взаиморасположения и т.д., в зависимости от системных установок. Короче, кое-где это вынесено в отдельную сущьность, то, что в Delphi равномерно размазано по всему VCL и большей частью работает без вмешательства программера.

> тогда уж откройте еще одну маленькую тайну: какие классы дельфи НЕ ЯВЛЯЮТСЯ наследниками TObject?

Никаких. Только старые (TP7) объекты. Он имел ввиду, что тот грид не с нуля написан, а расширение стандартного.

> Как по мне - лучше Делфи. За исключением генератора отчетов. ФастРепорт самый удобный.

Если целевая платформа - Win, то по многочисленныйм пожеланиям пользователей, его в COM завернули. По крайней мере, когда я последний раз проверял состояние, то там тестовая версия была. :)

> Мне лениво прописывать какждое событие по много раз (в однотипных приложениях, которые, тем не менее, нельзя сделать копи/пасте).

Можно вопрос, если обработчик нельзя адаптировать копи/пасте, то что делать в том же Qt? Он сам делает интелектуальный рефакторинг кода? 8-() ;-)

P.S. TActionList смотреть не пробовал? На закладке Standard, между прочим... :) Или у тебя была настолько старая Delphi?

> Мне не очевидна логика приложения, выраженная в инспекторе объектов.

Точно, старый. Там этий инстекторов сейчас, как грязи. :)

> Все равно надо покупать левые компоненты

Интересно, а куда сразу встроен хороший генератор отчётов?

> Пасаль. Что ни говори, а язык избыточный.

5+!!! ;-))) Можно я это "засушу" и буду показывать всем, когда мне будут говорить про избыточность пасКаля? ;-)

> Отсуствие кроссплатформенности.

Да, это самый серьёзный недостаток. Kylix, увы не оправдал, оказанного ему выского доверия. Разве что рассматривать ответвление Delphi.NET, как альтернативу. Ну и доводки Lazarus до ума ждать.

> Скажите, какие методы компоновки использует дизайнер Дельфи?

> Qt: произвольное размещение, box'ы, таблицу. Добавим сюда пружины и политику изменения размеров.

Практически тоже самое. Только без таблиц. Но их можно легко имитировать. А так: свободное размещение, панели (как я понял - аналоги box), align - позволяет приклеиваться к нужному краю родителя, масштабирует компоненты, при необходимости. anchor - похож на align, предназначен для синхронного перемещения, при изменении размеров родителя, тащит компонент за указанными границами, не самштабируя сам компонент. Constraints - ограничители в меньшую сторону. Не позволяют сжимать/разжимать компонент меньше/больше, чем.

> P.S. Визуализация сигналов и слотов тоже в Qt сделано красиво.

Да, это есть. Хотя на 90% задач того, что даёт Delphi - хватает. Ну так Qt и позже появилась. :)

> Не хочешь повторно использовать стандартные возможности, найди сторонний компонент или напиши свой, в чем вопрос?

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

Программирование сплошь состоит из частностей. И тот, кто в эимх частностях облегчит жизнь программиста, и будет иметь успех. Для вас достаточно вложенных панелей и анкеров. Для меня лично это уже сильно недостаточно, поскольку ограничивает меня и забирает время на написание чего-то более ценного. То же самое с i18n/l10n. То же с сигналами/слотами...

И вообще, может сравним по размеру полученных программ на Delphi и Qt для небольшой задачи?

> И вообще, может сравним по размеру полученных программ на Delphi и Qt для небольшой задачи?

О, это завсегда. :) Только с маленьким условием - самодостаточность. ;-) Если начнётся разговор, что "у меня в дистре", типа, qt установлен, то у меня, на целевом компе, случаной, делфовые пекаджи заваляются... ;-)))

>cдохни, пидарас.

>Justifier (*) (18.02.2006 12:20:26)

Нда... Atrus, ты был прав... У местных кроме соплей пузырями и прыщей на лице искать него...

Даже за линукс обидно - такие апологеты "хорошие"!!!

> Нда... Atrus, ты был прав...

О, нет. Прав я был, когда заигнорил его. А сейчас - маленькая наглядная демонстрация, на грани приличй. Умный человек понял бы, что его провоцируют... :)

P.S. Подожди, сейчас вторую серию увидишь... =)

> О, это завсегда. :) Только с маленьким условием - самодостаточность.

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

Про программу я имел ввиду исходный код. Итак, с вас - задача попроще.

> Про программу я имел ввиду исходный код.

Ага, юлить начинаем. =) Типа, меня не так поняли... ;-)

> Итак, с вас - задача попроще.

1) Не я предлагал соревнование.

2) Любая работа - только за $$$. Иначе мне не выгодно. Что я с этого получу? В случае победы абстрактное её признание? Ты станешь писать на Delphi? (сомневаюсь :) ) И т.д...

>TActionList смотреть не пробовал? На закладке Standard, между прочим...

Знаю, использую. Но описывать такие обыденные вещи, как добавление в базу записи, ее удаление и пр. лениво. Лениво писать каждый раз код, отличающийся только запросом и набором параметров. Средств, для нормальной, с моей точки зрения, автоматизации всего этого не нашел. UpdateSQL, Lookup и подобное, чесно, не понравилось.

> Точно, старый. Там этий инстекторов сейчас, как грязи. :)
Не понял? Со времен 5-ки там уже несколько ИО? Перечислите, пожалуйста.

>> Пасаль. Что ни говори, а язык избыточный.
>5+!!! ;-))) Можно я это "засушу" и буду показывать всем, когда мне будут говорить про избыточность пасКаля? ;-)

Да наздоровье :-) Можете заодно сказать, что не удобный. По крайней мере по сравнению с Питон. Хотя, наверное, это я уже с жиру бесюсь :-)

> Ну и доводки Lazarus до ума ждать.
Зачем ждать? Помогайте проекту. Ведь вам надо :-)

> Ага, юлить начинаем. =) Типа, меня не так поняли... ;-)

Оспидя! :) Да мне без разницы. Хотите померяться размером статических бинарников? :)

> 1) Не я предлагал соревнование.

То есть вам "в ломы"? Так и запишем... :)

> 2) Любая работа - только за $$$. Иначе мне не выгодно. Что я с этого получу? В случае победы абстрактное её признание?

Я думал, вы хотите показать преимущества Delphi. А оказывается, у вас, кроме $$$ перед глазами ничего не стоит. Обидно. Ну что же, засчитываем слив Delphi. :)

> Я думал, вы хотите показать преимущества Delphi.

Гы! Можешь назвать хоть одну причину - зачем? Это хоть что-нибудь изменит? Вон, хаскель посимпатичнее плюсов, а как никто не использовал в серьёз, так и не использует.

>Ты прав, не поставляется.

>участвтсовал я в одной разраьотке на MSVC, так там народ, когда им грид понадобился - первым делом купил FlexGrid. ;-)

>Он имел ввиду, что тот грид не с нуля написан, а расширение стандартного

Надеюсь - мы поняли друг друг друга. ))

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

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

Хм... А по другому как? Если запрос один, а параметры разные, то понятно. Есть TCommand (или T<что используется>Command), с параметрами. Раз написал запрос, дальше присваивай параметры и дёргай вызов. А если запросы каждый раз разные? Что в этом плане предлагают другие инструменты?

К вопросу о написании - писать sql запросы руками не обязательно. Есть визуальные построители запросов. Как мощные, комерчесике (http://www.delphikingdom.com/asp/viewitem.asp?catalogid=1146), так и freeware (http://www.fastreport.ru/ru/download/download.php?BID=13). (Надеюсь это не сочтут рекламмой? ;-) )

> Не понял? Со времен 5-ки там уже несколько ИО? Перечислите, пожалуйста.

Ага, ты пятой пользовался. :) Понятно. Неплохая версия, для своего времени. Я вообще, начал подозревать, что у них нечётные - стабильные. :)

Перечислять здесь будет многовато, см. обзорные статьи. На русском: (http://www.delphikingdom.com/asp/viewitem.asp?catalogid=1091), на английском (там больше): (http://bdn.borland.com/article/0,1410,33289,00.html).

> Зачем ждать? Помогайте проекту. Ведь вам надо :-)

Да я пишу потихоньку, в свободное время... :)

Мне любопытно, а программы, написанные на Delphi хорошо интернациолизированы? UTF-8 поддерживают? Какие средства для XML парсинга? XPath?