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

>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, именно о связке. А вы пытаетесь сравнить несравнимое.

2Sun-ch:

>кто не освоит Common Lisp в течении месяца, пускай нах пишут заявления.

Злой ты .... :)

>> Комментарий был о том, что 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.