>Алексей, а когда ориентировочно планируется это самое появление (если уже
>планируется)?

2010 год. Ведь сначала надо 64-битную версию выпустить.

Кроме того, мне кажется, что потребность разработки именно под Линукс черезчур раздута в данный конкретный момент. Да, многие разработчики хотели бы пересобрать свое приложение на новой версии и одним махом открыть для своего софта мир Линукс. Но насколько он велик? Вопрос актуальный и для Эмбаркадеро, и для производителей софта.
Возьмем для примера Firebird, как популярный и исторически многоплатформенный продукт, и посмотрим на его загрузки за 12 месяцев

под Windows Win32 -   612,764

http://sourceforge.net/project/stats/detail.php?group_id=9028&ugn=firebird&type=prdownload&mode=12months&package_id=2 9791

Win64 21,153

Linux i386 72,394
http://sourceforge.net/project/stats/detail.php?group_id=9028&ugn=firebird&type=prdownload&mode=12months&package_id=1 2460&release_id=0
 
Linux amd64 - 12,238
Freebsd   3,532
Mac OS X 12,236

Т.е. отличия на порядок. Причем - это серверный софт, а Линукс в качестве серверов занимает куда более сильные позиции, чем в качестве десктопов.
Конечно, можно упрекнуть, что раз нет средств разработки вроде Дельфи для Линукс, поэтому он и используется меньше, но тут уже был опыт с Кайликсом, да и на Java под Линукс можно разрабатывать. Опять же есть пример кросс-платформенного QT, который почему-то начал склоняться к мобильным разработкам и потом продался Нокии.

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

>Как и во времена Кайликс, с поддержкой различных версий библиотек под
>каждую платформу, или просто одна какая-либо виртуальная машина?

Не могу сказать, как она будет реализована. Но вряд ли это будет
виртуальная машина.

С уважением,
Алексей Ковязин

> [40] AlexeyKovyazin   (11.09.08 13:28)

Судя по этой статистике разработка Дельфи под Линукс - выгоднее, чем под 64 битную винду...
Однако 64 бита - вот они, а Линукс только в планах.

P.S.
ИМХО такое количество багов в IDE наделали, чтобы разница с Лазарусом менее заметна была...

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

Конкретно для Эмбаркадеро этот вопрос решается просто - достаточно взглянуть на количество запросов на Quality Central. Это достаточно представительная выборка. Собственно, ваши потребители - это и есть разработчики. Они хотят такой продукт, пусть получат его. А уж принесет он им реальную прибыль или нет, Эмбаркадеро это не особо должно волновать. Производители ПО - не дети малые, и вполне трезво могут оценить свои будущие успехи на линуксовом рынке. А кроссплатформенность предполагает, что затраты разработчиков на портирование софта будут минимальны, так что вполне окупятся даже сравнительно небольшими продажами по сравнению с Windows-версиями.

баг скролла с русскоязычными комментариями и строками исправили. не может не радовать ;)

> Eraser ©   (17.09.08 18:23) [43]

это первое, на что я внимание обратил :) дождались...

> Eraser ©   (17.09.08 18:23) [43]

как мало нужно для радости, оказыывается

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

Думаю, он сам собой исправился, когда среда стала юникодной

кста, народ, а кто нить пробывал написать хелпер к дженерик-классу ?? Ну там например

type
 TBinaryOp<T> = reference to function(ALeft, ARight: T): T;

 TListHelper<T> = class helper for TList<T>
 public
   function FoldLeft(const AInit: T; AFunc: TBinaryOp<T>): T;  
 end

??
Дельфи под рукой нет, не могу проверить..

> jack128_   (18.09.08 11:42) [47]


Честно говоря работать с полу Generics нет никакого желания.
Считаю, что прикрутить generics виртуальной машины с языку со статической компиляцией - это изврат.
А тем более прикручивать constraints. Это мягко говоря более чем странно.
Чуваки с TeamB уже озвучили идею это добавления operators contraints.

Помимо того, что IComparer<T> - это тихий ужас.
Кстати его ограничение, что он позволяет сравнивать только идентичные типы.

Вообщем чуваки хотят добавить ограничения оператора. То есть если есть у нас типы например U,V,W,Z и есть выражение в коде у нас например.

U+V*W/Z.
То бы должны будет описать все операторы над всеми типами используемые в этом выражение. Представьте если выражение на 2 порядка сложнение.
То есть вместо того, чтобы переложить на компилятор, они хотят переложить анализ на программиста.

Если так будет, то в топку Delphi от Codegear.

Для нормальной реализации им нужно немедленно отказаться от generics и прикрутить template от С++, которые мощнее.

P.S. Описывать(ограничивать) параметризованную операцию для каждой уникальной пары типов на каждый пук в языке со статической компиляцией - это обзац.

Я долго молчал, не хотел никого расстраивать. Но извините не сдержался.