Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, WolfHound, Вы писали:

WH>>ЗЗЫ на дельфи еще дольше. Ибо ни чего этот язык не умеет.
WH>>ЗЗЗЫ а как ты думаешь почему С++ и жаба это промышленные стандарты?
AVK>Можно вопрос? А что умеет джава и не умеет Дельфи? И как быть с тем что умеет Дельфи и не умеет джава?

Можно я встряну?
Итак, чего не умеет Delphi и умеет Java (емеется ввиду возможности оригинальных/сторонних библиотек по тем или иным технологическим фичам):
— Delphi не умеет работать с полными состояниями объектов (сериализация как в Java), сохранение published-свойств наследников TComponent — жалкое подобие Java-сериализации — ничего кроме сохранения "внешнего" состояния, но не внутреннего не даёт;
— свои заморочки VCL по части работы с сокетами (приложения иногда просто "валятся" на элементарных операциях с сокетами);
— компонентный подход у обеих сред почти совпадает (наследники TComponent в Delphi; JavaBeans-парадигма в Java с наследованием от любого класса);
— в Delphi трудно программировать сложные многонитиевые приложения — много возни;
— в Delphi нет Layout-менеджеров размещения виджетов;
— в Delphi нет других стилей визуальных компонентов, кроме Window-ых (в Java есть одинаково выглядящие на любых платформах стили Swing, включающие Win/Motif/GTK/Metal/Mac);
— в Delphi нет фреймворка SecurityAPI чтобы быть независимым от MS-платформы;
— в Delphi нет понятия службы имён и каталогов для прозрачной конвергенции различных приложений как J2EE/JNDI, но есть, безусловно, доступ через (часто низкоуровневый) API к аналогичной ипостаси Windows/Registry&ActiveDirectory;
— в Delphi есть возможность создавать компоненты системы прикладного назначения: COM/DCOM/COM+ — похожее есть в J2SE (любой класс — аналог COM-компонента; RMI — почти аналог DCOM-технологии) и особенно в J2EE (EJB — расширенный аналог COM+, причём по ряду возможностей несравним);
— в Delphi нет такой фичи как самодокументирование кода и API (JavaDoc), хотя сторонние наработки есть, но они не совместимы;
— в Java больше настраиваешь, чем программируешь: байт-код один на всех платформах, но настроек всяких делаешь куда больше (я имею ввиду дескрипторы развёртывания, настройки JNDI, настройки RMI, J2EE);
— в Delphi невозможно "на лету" использовать какую-то другую технологию доступа к данным кроме системно-зависимых и проприетарных (закрытых) BDE/ADO/dbExpress;
— в Delphi возможно создание приложений только для Windows (о Kylix-технологии не будем говорить, так как всё равно код получается "не чистым").

Здравствуйте, DarkGray, Вы писали:
<...>
DG>Java стабильнее и не падает от "глупых" ошибок
Общий класс ошибок объектно-ориентированных языков — NullPointerException — обращение к несуществующему объекту.
Чаще встречается в Java из-за динамической природы языка.

ZEN>- в Delphi невозможно "на лету" использовать какую-то другую технологию доступа к данным кроме системно-зависимых и проприетарных (закрытых) BDE/ADO/dbExpress;

Беру свои вышеуказанные слова обратно взад.

Здравствуйте, iZEN, Вы писали:

ZEN>- Delphi не умеет работать с полными состояниями объектов (сериализация как в Java), сохранение published-свойств
ZEN> наследников TComponent — жалкое подобие Java-сериализации — ничего кроме сохранения "внешнего" состояния, но не внутреннего не даёт;

Следствие урезанности RTTI.

ZEN>- свои заморочки VCL по части работы с сокетами (приложения иногда просто "валятся" на элементарных операциях с сокетами);

Это проблемы библиотеки, а не языка.

ZEN>- в Delphi трудно программировать сложные многонитиевые приложения — много возни;

В Java меньше? Ты считаешь lock большим достижением? На самом деле простейшая синтаксическая обертка, полный аналог

Locker.EnterCriticalSection(obj);
try
{
...
}
finally
{
Locker.LeaveCriticalSection(obj);
}

ZEN>- в Delphi нет Layout-менеджеров размещения виджетов;

Это особенности библиотеки

ZEN>- в Delphi нет других стилей визуальных компонентов, кроме Window-ых (в Java есть одинаково выглядящие на любых платформах стили Swing, включающие Win/Motif/GTK/Metal/Mac);

Это особенности библиотеки

ZEN>- в Delphi нет фреймворка SecurityAPI чтобы быть независимым от MS-платформы;

Это особенности библиотеки

ZEN>- в Delphi нет понятия службы имён и каталогов для прозрачной конвергенции различных приложений как J2EE/JNDI, но есть, безусловно, доступ через (часто низкоуровневый) API к аналогичной ипостаси Windows/Registry&ActiveDirectory;

Это особенности библиотеки

ZEN>- в Delphi есть возможность создавать компоненты системы прикладного назначения: COM/DCOM/COM+ — похожее есть в J2SE (любой класс — аналог COM-компонента; RMI — почти аналог DCOM-технологии) и особенно в J2EE (EJB — расширенный аналог COM+, причём по ряду возможностей несравним);

Это особенности библиотеки

ZEN>- в Delphi нет такой фичи как самодокументирование кода и API (JavaDoc), хотя сторонние наработки есть, но они не совместимы;

Согласен

ZEN>- в Java больше настраиваешь, чем программируешь: байт-код один на всех платформах, но настроек всяких делаешь куда больше (я имею ввиду дескрипторы развёртывания, настройки JNDI, настройки RMI, J2EE);

Это какая то мутная философия. Неконкретно.

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

Это свойства не языка, а платформы.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, iZEN, Вы писали:

ZEN>>- Delphi не умеет работать с полными состояниями объектов (сериализация как в Java), сохранение published-свойств
ZEN>> наследников TComponent — жалкое подобие Java-сериализации — ничего кроме сохранения "внешнего" состояния, но не внутреннего не даёт;
AVK>Следствие урезанности RTTI.

Нифига подобного. Reflection (получение сигнатур методов) можно реализовать в Delphi, а значит и полную сериализацию.

ZEN>>- свои заморочки VCL по части работы с сокетами (приложения иногда просто "валятся" на элементарных операциях с сокетами);
AVK>Это проблемы библиотеки, а не языка.
Согласен.

ZEN>>- в Delphi трудно программировать сложные многонитиевые приложения — много возни;
AVK>В Java меньше? Ты считаешь lock большим достижением? На самом деле простейшая синтаксическая обертка, полный аналог
<...>
Несовсем.
Есть такие вещи вещи в Java как монитор объекта, который встроен на уровне базового класса java.lang.Object и позволяет творить чудеса без затрат процессорного времени (я имею ввиду технику на основе методов wait()/notify()/notifyAll()).
А вот простейший мьютекс мы получаем, используя лишь экземпляр класса java.lang.Object.

ZEN>>- в Delphi нет Layout-менеджеров размещения виджетов;
AVK>Это особенности библиотеки
Угу. В Java же "одного мира мало".

ZEN>>- в Delphi нет других стилей визуальных компонентов, кроме Window-ых (в Java есть одинаково выглядящие на любых платформах стили Swing, включающие Win/Motif/GTK/Metal/Mac);
AVK>Это особенности библиотеки
Аналогично (см. выше)

ZEN>>- в Delphi нет фреймворка SecurityAPI чтобы быть независимым от MS-платформы;
AVK>Это особенности библиотеки
Аналогично (см. выше)

ZEN>>- в Delphi нет понятия службы имён и каталогов для прозрачной конвергенции различных приложений как J2EE/JNDI, но есть, безусловно, доступ через (часто низкоуровневый) API к аналогичной ипостаси Windows/Registry&ActiveDirectory;
AVK>Это особенности библиотеки
Аналогично (см. выше)

ZEN>>- в Delphi есть возможность создавать компоненты системы прикладного назначения: COM/DCOM/COM+ — похожее есть в J2SE (любой класс — аналог COM-компонента; RMI — почти аналог DCOM-технологии) и особенно в J2EE (EJB — расширенный аналог COM+, причём по ряду возможностей несравним);
AVK>Это особенности библиотеки
Аналогично (см. выше)
<...>
ZEN>>- в Java больше настраиваешь, чем программируешь: байт-код один на всех платформах, но настроек всяких делаешь куда больше (я имею ввиду дескрипторы развёртывания, настройки JNDI, настройки RMI, J2EE);
AVK>Это какая то мутная философия. Неконкретно.
Почему?
Вопросы развёртывания продуктов играют не последнюю скрипку. Трудоёмкость здесь тоже есть и разная!
Для Delphi-приложения достаточно INI-файла (для Java-приложения аналог — properties-файл), но когда Delphi-приложение "общается" с персистентным хранилищем системы (registry), то для Java аналогичная "фича" — JNDI — вот тут-то и начинаются пляски с бубном, но, естественно, всё зависит от приложения, его "степени настраиваемости".

ZEN>>- в Delphi возможно создание приложений только для Windows (о Kylix-технологии не будем говорить, так как всё равно код получается "не чистым").
AVK>Это свойства не языка, а платформы.

Ага. Согласен.
Тогда будет правильнее говорить о Windows vs. Java.

ZEN>- свои заморочки VCL по части работы с сокетами (приложения иногда просто "валятся" на элементарных операциях с сокетами);

Не думаю, что это можно отнести на счет самой Delphi, тем более, что есть множество сторонних библиотек работы с сокетами.

ZEN>- в Delphi нет других стилей визуальных компонентов, кроме Window-ых (в Java есть одинаково выглядящие на любых платформах стили Swing, включающие Win/Motif/GTK/Metal/Mac);

QT в CLX_Applications этого не умеют?

ZEN>- в Delphi невозможно "на лету" использовать какую-то другую технологию доступа к данным кроме системно-зависимых и проприетарных (закрытых) BDE/ADO/dbExpress;

Да ну? А как же огромное кол-во "компонент прямого доступа" к IB/MSSQL/Oracle/etc ?
Почему вдруг dbExpress оказался системно-зависимым?

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

Не очень понятно. То, что Qt используется?

P.S. Я не встреваю в ваш спор, что лучше, просто мне показались спорными именно эти моменты.

Здравствуйте, Igor Trofimov, Вы писали:

ZEN>>- свои заморочки VCL по части работы с сокетами (приложения иногда просто "валятся" на элементарных операциях с сокетами);
iT>Не думаю, что это можно отнести на счет самой Delphi, тем более, что есть множество сторонних библиотек работы с сокетами.
Да, безусловно. Но то, что есть в VCL...

ZEN>>- в Delphi нет других стилей визуальных компонентов, кроме Window-ых (в Java есть одинаково выглядящие на любых платформах стили Swing, включающие Win/Motif/GTK/Metal/Mac);
iT>QT в CLX_Applications этого не умеют?
Не знаю, не пробовал.
Разве QT умеет "прикидываться" Win/Motif/GTK/Metal/Mac на Linux.
А для Windows тоже есть QT-порт, с которым работают CLX_Applications?
Я хотел сказать, что Swing умеет выглядеть, напрмер, CDE-подобным (UNIX/Motif) на любых платформах, где может работать Java.

ZEN>>- в Delphi невозможно "на лету" использовать какую-то другую технологию доступа к данным кроме системно-зависимых и проприетарных (закрытых) BDE/ADO/dbExpress;
iT>Да ну? А как же огромное кол-во "компонент прямого доступа" к IB/MSSQL/Oracle/etc ?
Я уже взял свои слова на этот счёт "обратно в зад" в одном из предыдущих высказываний.

iT>Почему вдруг dbExpress оказался системно-зависимым?
Драйверы в каком исполнении распространяются? Драйверы в виде Dll — для Windows, ...- для Linux (дополните фразу). Тогда и поговорим.

ZEN>>- в Delphi возможно создание приложений только для Windows (о Kylix-технологии не будем говорить, так как всё равно код получается "не чистым").
iT>Не очень понятно. То, что Qt используется?
Вы уверены, что CLX-приложения после перекомпиляции на обоих платформах (Windows, Linux) будут работать одинаково? Это в идеале...

iT>P.S. Я не встреваю в ваш спор, что лучше, просто мне показались спорными именно эти моменты.
А Вы встряньте! Хочется общения.

Здравствуйте, iZEN, Вы писали:

DG>>Java стабильнее и не падает от "глупых" ошибок
ZEN>Общий класс ошибок объектно-ориентированных языков — NullPointerException — обращение к несуществующему объекту.
ZEN>Чаще встречается в Java из-за динамической природы языка.

При наличии Call Stack локализовать ошибку легко, а затирание памяти очень тяжело ищется.

Здравствуйте, iZEN, Вы писали:

AVK>>Следствие урезанности RTTI.

ZEN>Нифига подобного. Reflection (получение сигнатур методов) можно реализовать в Delphi,
ZEN>а значит и полную сериализацию.

Ничего кроме published свойств через RTTI недоступно, значит никакой автоматической сериализации и никакого рефлекшена.

ZEN>>>- в Delphi трудно программировать сложные многонитиевые приложения — много возни;
AVK>>В Java меньше? Ты считаешь lock большим достижением? На самом деле простейшая синтаксическая обертка, полный аналог
<...>>
ZEN>Несовсем.

Совсем совсем

ZEN>Есть такие вещи вещи в Java как монитор объекта,

Есть. Locker в моем примере. Реализуется на коленке за полчаса.

ZEN> который встроен на уровне базового класса java.lang.Object и позволяет творить чудеса без затрат процессорного времени (я имею ввиду технику на основе методов wait()/notify()/notifyAll()).

Не знаю как в джаве, а вот в дотнете lock это чисто синтаксическая фишка, анализ сгенеренного кода ildasm'ом это подтверждает. Возможности lock идентичны джавовским. Да и не понятно зачем лок встраивать в базовый класс.

ZEN>>>- в Java больше настраиваешь, чем программируешь: байт-код один на всех платформах, но настроек всяких делаешь куда больше (я имею ввиду дескрипторы развёртывания, настройки JNDI, настройки RMI, J2EE);
AVK>>Это какая то мутная философия. Неконкретно.
ZEN>Почему?

Не знаю, у тебя надо спросить

ZEN>Вопросы развёртывания продуктов играют не последнюю скрипку. Трудоёмкость здесь тоже есть и разная!
ZEN>Для Delphi-приложения достаточно INI-файла (для Java-приложения аналог — properties-файл), но когда Delphi-приложение "общается" с персистентным хранилищем системы (registry), то для Java аналогичная "фича" — JNDI

Ты чего то путаешь. Registry это просто хранилище данных. Аналог в джаве это тектовый xml.

ZEN> — вот тут-то и начинаются пляски с бубном, но, естественно, всё зависит от приложения, его "степени настраиваемости".

Опять же непонятно каким боком тут виноват язык. Платформа, библиотека возможно, но никак не язык.

ZEN>Ага. Согласен.
ZEN>Тогда будет правильнее говорить о Windows vs. Java.

Нет, не правильнее. Перечитай сообщение, на которое я отвечал.

ZEN>Вы уверены, что CLX-приложения после перекомпиляции на обоих платформах (Windows, Linux) будут работать одинаково? Это в идеале...

Хочешь сказать, что на Java любые приложения будут работать на любой системе?
Это в идеале...

Здравствуйте, Igor Trofimov, Вы писали:

iT>Хочешь сказать, что на Java любые приложения будут работать на любой системе?
Не надо так утрировать — ведь всё зависит от окружения, библиотек в первую очередь.
А вот форматы class-файлов одни и те же что для мобильных телефонов, что для серверов приложений J2EE — один компилятор используется для разных аппаратных платформ, байт-код одинаковый.
iT>Это в идеале...
таки да.

Здравствуйте, Bigger, Вы писали:

B>Как, а Access'95
Чур меня! Пока Бог миловал. Доводилось только переделывать Access поделки на другие платформы.

B>А вообщето Лис лучше корабля, там SQL даже есть и визуальная среда, да и с базами лучше, да и с сетью тоже.
А вот это спорно. Особенно насчет сети.

Здравствуйте, FWP, Вы писали:

B>>А вообщето Лис лучше корабля, там SQL даже есть и визуальная среда, да и с базами лучше, да и с сетью тоже.
FWP>А вот это спорно. Особенно насчет сети.

Clipper vs FoxPro — это круто
Динозавры поспорим

Здравствуйте, iZEN, Вы писали:

ZEN>Разве QT умеет "прикидываться" Win/Motif/GTK/Metal/Mac на Linux.
Да.
ZEN>А для Windows тоже есть QT-порт, с которым работают CLX_Applications?
Да.
ZEN>Я хотел сказать, что Swing умеет выглядеть, напрмер, CDE-подобным (UNIX/Motif) на любых платформах, где может работать Java.
Вот и с qt то же самое.

Здравствуйте, Bigger, Вы писали:

B>Clipper vs FoxPro — это круто
B>Динозавры поспорим
Запросто!

Здравствуйте, FWP, Вы писали:

FWP>Здравствуйте, Bigger, Вы писали:

B>>Clipper vs FoxPro — это круто
B>>Динозавры поспорим
FWP>Запросто!

Тогда надо в священные войны переходить .
Только, мне они оба (и лис, и корабль) нравились одинаково

Здравствуйте, Mystic, Вы писали:

M>Здравствуйте, WolfHound, Вы писали:

WH>>Вот я и спрашиваю какого вы за эту недоделку держитесь?

M>Не недоделку, а старушку... Да, есть некоторые неудобства, но к ним уже давно привык. Ну выделяются классы не в стеке, а в динамической памяти, ну и пусть. Все равно в 99% случаев скорость работы устраивает, а в 0.9% случаев и размещение в стеке не спасло бы. Основное --- с Delphi связано очень много приятных воспоминаний, а VB.NET, C#, C++ вызывают дискомфорт.

После Delphi, конечно, C++ — сложнее и используемые приемы кажутся надуманными.
Много времени уходит на синтаксис.
И пусть уж все хорошо, но MFC и иже с ними ...
С# — это

Что вызывает дискомфорт — это Java — там все как-то иначе и не факт, что лучше. .NET имеет больше общих корней с Delphi. Так что, будем перетекать...

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, s.ts, Вы писали:

WH>>>А там все контейнеры это классы, а все классы создаются в хипе...
ST>>А есть языки где все суть есть класс и дельфя ближе к ним.

WH>И какое это имеет отношение к обращениям к хипу которых могло и не быть?

это я не закончил : " ... и есть GC и все располагается в хипе "

Здравствуйте, _wqwa, Вы писали:

_>Здравствуйте, iZEN, Вы писали:

ZEN>>Разве QT умеет "прикидываться" Win/Motif/GTK/Metal/Mac на Linux.
_>Да.
ZEN>>А для Windows тоже есть QT-порт, с которым работают CLX_Applications?
_>Да.
ZEN>>Я хотел сказать, что Swing умеет выглядеть, напрмер, CDE-подобным (UNIX/Motif) на любых платформах, где может работать Java.
_>Вот и с qt то же самое.

Ни у кого нет сомнений, что C++ умеет все ????
Дык вот, мы тут дельфу с С++ сравниваем... Так что с жабой лучше и не лезте

Здравствуйте, s.ts, Вы писали:

ST>После Delphi, конечно, C++ — сложнее и используемые приемы кажутся надуманными.

Ну... Первым моим языком программирования был Turbo C 1.5, а уже потом Pascal. Одной из причин перехода явилось корявое поведение Turbo Vision из-под Borland C++ 3.1. А потом... не знаю... С выходом Delphi 3, я с Delphi не слезаю. Сейчас пишу на VB под ASP.NET, но чувствую, что скоро лопнет терпение, и пойду работать грузчиком...