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

G>Паскаль был придуман как учебный язык для изучения основ программирования. Прежде всего из-за этого он приобрел популярность, и его уже потом Борланд (собственно и выросший, насколько помню, на Турбо Паскале) стал его развивать как промышленный. На Дельфи не работал, но в свое время мне Турбо Паскаль не нравился своей эклектичностью: на язык, изначально придуманный только для обучения, не для разработки, стали искуственно навешивать необходимую функциональность и модные фичи. Но это все эмоции. Понятно, что на Паскале можно писать.

Ну, во-первых, тот же питон тоже был придуман для обучения, как и scheme — но это им не мешает занимать свою нишу (в случае с питоном очень даже неплохую).
Во-вторых, одного взгляда на C++ должно хватать, чтобы понимать какими агли хаками шел переход от C до C++ (есть где-то в недрах gcc C++ препроцессор — т.е. преобразование программы на C++ в программу на C — все конструкции С++ раскрываются как макросы).


G>Раньше на Паскаль смотрели без уважения и нехорошо из-за нестандартности, отсутствия кроссплатформенности и вообще минимальной переносимости.
Тут о сих пор народ мало волнует переносимость, а уж лет 10 назад (в России в крайнем случае).

G>И ведь среда по подходу не хакерская ни разу. Формочки там всякие, драг-н-дропы. Несерьезно .
Ну как раз всяких примеров сниферов и тому подобных шутк на дельфях хватало. Опять же — make в комплекте шел — пиши все в шелле, никто не мешает.

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

DOO>Во-вторых, одного взгляда на C++ должно хватать, чтобы понимать какими агли хаками шел переход от C до C++ (есть где-то в недрах gcc C++ препроцессор — т.е. преобразование программы на C++ в программу на C — все конструкции С++ раскрываются как макросы).
Это неверно. GCC транслирует программу на С++ в общее представление (в GIMPLE, а потом в RTL). Чистый С идёт точно по такому же пути.

В очень ранних версиях (типа 1.x) — может и по другому было.

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

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

DOO>>Во-вторых, одного взгляда на C++ должно хватать, чтобы понимать какими агли хаками шел переход от C до C++ (есть где-то в недрах gcc C++ препроцессор — т.е. преобразование программы на C++ в программу на C — все конструкции С++ раскрываются как макросы).
C>Это неверно. GCC транслирует программу на С++ в общее представление (в GIMPLE, а потом в RTL). Чистый С идёт точно по такому же пути.
Я имел ввиду, что не сам gcc — как компилятор C++ так делает, а была какая-то отдельная программка (я ее ни разу не смотрел в работе), которая именно переводила C++ в С путем препроцессинга. Вроде она до сих пор имеется в пакете gcc — надо бы поискать.

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

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

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


J>>знаешь, нормальный дельфист сразу видет парные Create/Free. Приемущество c++ в том, что в нем объекты на стеке могут распологаться..
G>Конструкторы могут называтся как угодно. Банальным Ctrl+F уже не найдешь.

Не понял, ты не знаешь как называется конструктор в твоем(или чужом) классе??

G>>>2)Отсутствие интерфейсов и множественного наследования. (наследие паскаля)
J>>интерфейсы есть уже лет 10, наверно...
G>Да уж, только то COM-интерфейсы
в дельфи самостоятельная реализация интерфейсов, никак на ком не завязаная на ком. Другое дело, что она СОВМЕСТИМА с ком, но это только плюс ей.


G>>>4)Отсутствие перегрузки функций (в ранних версиях) и операторов (вплоть до поздних). (тоже наследие паскаля)
J>>хм. ранние — это какие?? такое ощущение, что ты знаешь только о delphi1
G>Я работал на делфях версий 2-7.
G>Перегрузка функций появилась в delphi 5 кажись, перегрузка операторов не было и в delphi 7
Ну вот я и говорю delphi5 вышла в конце 90х, несли мне не изменяет память. А перегрузка операторов — да, была только для вариантов.

G>>>5)Ужасная работа с указателями. (наследие паскаля)
J>>Что значит "ужасная" ??? Или строгая типизация тя не устраивает???
G>Отсутствие операций инкремента и декремента, а также невозможно указать типа указателя в месте использования.
var
D: ^Double;
P: Pointer;
begin
Inc(D, 10); // инкремент

PInteger(P)^ := 10; // явное указание типа указателя..
end;


G>Класс TThread. 1)Не позволяет узнать завершился ли поток — надо использовать WinAPI.

Чесно говоря никогда не было узнавать завершился ли поток, обычно требует подождать пока поток завершиться. Но в любом случае — уверен, что в стандартные либы с++ тоже далеко не полностью покрывают функционал WinAPI.. Собственно это и не требуется..

G>2)Непонятен в использовании (из-за наследования), на первой работе неделю ловили баг из-за неправильного использования Thread. Человек банально скопировал код из примера и сам чего-то дописал.

Знаешь, если человек не в состоянии перекрыть абстрактный метод, то не понятно, как он вообще работает программистом?? А "чего-то" дописать, чтоб после этого ничего не работало — и я могу

G>3)Потоки есть — а примитивов синхронизации в VCL нет, приходится снова юзать WinAPI

SyncObjs.pas ???

G>>>9)Исполняемые файлы получаются очень тяжеловесными.
J>>Хм. Ну давай я статически слинкую mfc exe'шник и сбилжу пустую форму на дельфи с ран-тайм пакетами — и скажу MSVC — генерирует очень тяжеловесные экзешники.
G>А почему Borland C++ Builder собирает exeшники в 3-4 раза меньшие по объему?

Насколько я помню билдер по умолчанию динамически линкует библиотеки, а дельфи — статически..

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

H>>И неконтролируемая... Из-за которой, порой, возникают прелесные фризы на ровном месте.
G>За год работы на .NET ни одного случая не видел, вам видимо везет.

Видимо. И не только мне. На форумах обсуждалось неоднократно с последующими советами понавставлять по коду GC.Collect

H>>Да ты что? Управляемая (читай контролируемая) сборка мусора это недостаток? Я еще добавлю, что Delphi и за интерфейсами сама следит.
G>А как еще можно было сделать динамические строки и массивы, но не нагружать программиста вызовами Free?

Ну так это же плюс. Чего ты его охаял?

G>В C++ автоматически вызывается деструктор по выходу из scope.
G>За интерфейсам следит не делфи, за интерфейсам следит комилятор, фактически вставляя вызов Release для интерфейса, что может потянуть кучу необъяснимых глюков. Да и разная семантика работы с классами, реазиующими интрфейсы и нереалзующими их — тоже немалый недостаток.

Под Delphi я и имел ввиду компилятор (а что же еще-то может за этим следить...). Семантика для работы с интерфейсными классами и с обычными может быть одинаковой (см. TComponent). Но все это тонкости дающие большую гибкость. И необъяснимые глюки это может вызвать только там, где программист работает сам незная с чем (или не до конца понимая механизм).

H>>Чет я не понял... Чего тебе IDE должна поддерживать в процедуре или функции?
G>Delphi 7 нажимаешь ctrl+space begin, end, procedure, function он и не думает завершать.

2005/6 имеют Code Templates. Штука очень приятная и расширяемая.

H>>Уж и не знаю кому сложнее, но старому Паскалисту сильно проще чем в C++
G>Ну смотри пример выше. сылочная объектная модель без GC вносит ограничения, которые невозможно обойти.
G>Хотя я не сомневаюсь что старому паскалисту делфи гораздо легче чем С++.

Это с возвратом созданного объекта чтоль? Ну и в чем проблема? Вот GetMem/VirtualAlloc тоже сырую память отдают и ее возвращать нужно. Не смущает? На самом деле ни какой проблемы в этом нет, объекты, как правило создаются для хранения в каких-либо коллекциях/списках и прочих. И уж точно нет ни какого напряга дернуть Free. Придирки, и не более того.

H>>Интерфейсы есть с очень древней (3/4) версии. А в шарпе делегирование оных есть уже?
G>COM — нитерфейсы. К ООП они вообще мало отношения имеют. Делегирование интерфейсов в шарпе нет по тойже причине. Если поковыряться с интеропом, то возможно что-то подобное есть и на .NET. Но мне не доводилось таким заниматься.

Что значит COM-интерфейсы? Бинарно совместимы -- да. И что? К ООП имееют прямое отношение: тут и инкапсуляция и полиморфизм. А делегирование позволяет сэкономить массу времени при кодировани и кстати, увеличивает полиморфизм.

H>>Дженерики есть в 2007 под .Net. В 2008 обещают и для нативного кода.
G>Мда... Это на фоне того, что появилось в C# 3.0 в 2007 году. Делфи тут оооочень сильно отстает.

Уж не про LINQ ли ты говоришь Ну в 2008 или 2009 обещают анонимные методы добавить еще.

G>>>4)Отсутствие перегрузки функций (в ранних версиях) и операторов (вплоть до поздних). (тоже наследие паскаля)
H>>Перегрузка функций/методов есть с 4 версии. Операторы можно перегружать уже с 2005 (для классов только под .Net, для натива можно перегружать для advanced records (class-like)). А с 2006 есть еще и перегружаемые свойства-массивы. Можно еще добавить class/record хелперы.
G>А с какого года это есть в C++? Тут очевидно стремление delphi догнать С#

Какая разница кто-кого догоняет или откуда заимствуются те или иные фичи? Ты тут о минусах говорил, я же тебе на плюсы указываю.

G>>>5)Ужасная работа с указателями. (наследие паскаля)
H>>Конкретика? Типизация указателей имеется со времен... очень давно в общем имеется. Адресная арифметика на уровне. Чего не нравится?
G>то что надо явно объявлять тип указателя и отсутствие инкремента\декремента

Работать можно и с нетипизированными. Инкремент/декремент работает на типизированных, что очень правильно.

H>>Чудесная библиотека ввода/вывода (позволяющая при умении заворачивать интереснейшие вещи без участия низкоуровневых API).
G>Пример в студию.

Ну я код постить не собираюсь, в гугле найдешь если интересно. Я наводку дам. В паскале есть чудесная функция Write/WriteLn реализовать которую средствами самого языка невозможно (не прибегая к константным массивам, что все равно не является полноценным решением), но использовать которую очень удобно. Можно легким движением руки превратить ее в приличный логгер перенаправив вывод (да не просто перенаправить, а целый обвяз создать) куда угодно. Делается это именно благодаря библиотечному устройству и без каких либо низкоуровневых API.

H>>Списки (различные), стеки, очереди, бит-контейнеры, ассоциативные массивы. Мало?
G>Это оно когда появилось? Случаем не в Delphi.NET ?

В нативной 2006 точно есть. Может и в 2005 было, я не помню.

H>>И вправду можешь не продолжать... Ты явно не в теме (ну, или сильно субъективен, что аж перекашивает).
G>Я на Delphi писал большую часть моей программистской жизни.
G>А вы на C# попробуйте пописать, сразу поймете.

Я скорее на Ada пересяду, чем на C#

G>Вообще я заметил что субъективизмом страдают те, кто пишет на Delphi и других языков и технологий не знает.
G>Прочитайте http://www.rsdn.ru/article/nemerle/Amplifier.xml

Автор(ы): Чистяков Влад (VladD2)
Дата: 03.03.2007
Язык программирования Nemerle заинтересовал многих в первую очередь своей мощнейшей подсистемой мак-росов. Однако и без них Nemerle предоставляет ряд су-щественных улучшений по сравнению с традиционными, императивными языками программирования (такими как Java, C# и C++).
Nemerle, кроме традиционного императивного програм-мирования, поддерживает функциональное программи-рование. Это выражается в наличии конструкций, упро-щающих манипуляцию функциями, построение и анализ сложных структур данных и т.п.
К сожалению, если вы не использовали возможности, присущие функциональным языкам ранее, то вам будет трудно оценить, насколько Nemerle может оказаться вам полезным в реальной повседневной работе. Данная статья призвана в неформальной форме продемонс-трировать это.

про "Парадокс Блаба"

Заметь, не я тут на языки наезжал не имея представления о текущем положении дел.

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

G>>>5)Ужасная работа с указателями. (наследие паскаля)
H>>Конкретика? Типизация указателей имеется со времен... очень давно в общем имеется. Адресная арифметика на уровне. Чего не нравится?
G>то что надо явно объявлять тип указателя и отсутствие инкремента\декремента

Что я никогда не понимал в наездах на Delphi, так это про ужасные указатели. Откуда отсутствие инкремента\декремента?

var
P: ^LongInt;

..
Inc(P);
..

Какие проблемы и как делать инкремент\декремент без объявления типа указателя (фактически задавая размер памяти, адресуемой указателем)?
В Delphi нет пост/прекрементов, но это не напрягает и имхо это вообще наследие архитектуры PDP-11, где пост/прекременты поддерживались на уровне системы команд процессора.

Единственное чего не хватает — нельзя написать

var
P: ^LongInt;

..
I:= P[J];
..

В текущей версии такое возможно только с PChar, но обещают в это году разрешить делать это с любым указателем.

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

<skip>
G>И ведь среда по подходу не хакерская ни разу. Формочки там всякие, драг-н-дропы. Несерьезно .
Как так не хакерская? Некоторые особо одаренные люди пишут на дельфях не только драйвера уровня ядра для виндовс ХР, но и вирусы различные(viruslist посмотрите, пример — Trojan-PSW.Win32.Lmir.a). Правда, для этого приходится выкорчевывать различные vcl и rtl библиотеки.

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

J>>хм. прочем тут дельфи? Утечки памяти были, есть и будут во всех языках без GC

DOO>GC в Дельфи был. И очень неплохой — они использовали собственный менеджер памяти (из-за этого программа на дельфи кушала память большими кусками, по 10 Мб, если мне не изменяет память).

Это не GC в полном понимании слова. Редкая гадость, надо признать.

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

L>>Что хотелось бы иметь:

L>>1. Объявление переменных в месте использования. Не критично, но ползти в var неприятно.
DOO>На вкус и цвет — когда в одном месте, оно читабельнее.

Дело не во вкусе.

Примеры:

...
foreach(CollectionItem item in someCollection) 
{
}
...

try {
...
} catch (ArgumentException e) {
...
}

L>>2. Переопределяемых операторов. Часто сложная математика выглядит с ними привычнее.
DOO> Читать потом тяжко...
DOO>

DOO>CString str;
DOO>...
DOO>(char *)str //вот и пойми, что это перегруженный оператор на самом деле :xz:
DOO>

На счет перегрузки операторов соглашусь: в общем случае перегрузка операторов — зло, но во всяческих фреймворках и узкоспециализированных библиотеках (в основном математического направления) они весьма и весьма полезны.

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

I>>По своему опыту скажу, что низкокачественного кода было написано дохрена и больше, чем высококачественного, не зависимо от платформы.

G>Во всех программах на делфи, которые я видел, были утечки памяти. Для Java и .NET такого быть не может

Не так все просто с GC`ами Java и .NET.

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

DR>>Не нравится Дельфи из за типично чрезвычайно низкого качества написанных на ней программ. Троечники собирают на этом небезопасном языке свои компоненты из компонентов написанных другими троечники, а конечные программы являются результатом нескольких итераций этого процесса.

DOO>Что-то мне подсказывает, что еще пара лет и так же начнут хаять .Net с C#...

Сомневаюсь сильно. Java вон куда старше .NET и ничего — живет и здравствует.

Пока .NET развивается в правильном направлении.

Обещают в следующем фреймворке DI стандартны. Это скорее хорошо, чем плохо, учитывая, что сейчас только ленивый не изобретает свой IoC/DI... Хотелось бы только верить, что он будет как минимум на уровне Castle Windsor.

Интересно будет посмотреть на Microsoft`овский DLR (Dynamic Language Runtime). Признаю, что питаю слабость к Ruby — полагаю большие надежды на IronRuby.

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

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

J>Не понял, ты не знаешь как называется конструктор в твоем(или чужом) классе??
В том классе, который не я написал — не знаю. Мне много раз приходилось править код написанный до меня.

J>Ну вот я и говорю delphi5 вышла в конце 90х, несли мне не изменяет память. А перегрузка операторов — да, была только для вариантов.
Я больше всего работал в Delphi7 — большенитсво впечатлений оттуда.

J>var
J> D: ^Double;
J> P: Pointer;
J>begin
J> Inc(D, 10); // инкремент

J> PInteger(P)^ := 10; // явное указание типа указателя..
J>end;

А вы на C++ писали? Похоже вы не знаете о применении автоинкремента.


G>>Класс TThread. 1)Не позволяет узнать завершился ли поток — надо использовать WinAPI.
J>Чесно говоря никогда не было узнавать завершился ли поток, обычно требует подождать пока поток завершиться. Но в любом случае — уверен, что в стандартные либы с++ тоже далеко не полностью покрывают функционал WinAPI.. Собственно это и не требуется..
Если вам не требуется, то не значит что другим не требуется.

G>>2)Непонятен в использовании (из-за наследования), на первой работе неделю ловили баг из-за неправильного использования Thread. Человек банально скопировал код из примера и сам чего-то дописал.
J>Знаешь, если человек не в состоянии перекрыть абстрактный метод, то не понятно, как он вообще работает программистом?? А "чего-то" дописать, чтоб после этого ничего не работало — и я могу
А я в C# не могу так написать.

J>Насколько я помню билдер по умолчанию динамически линкует библиотеки, а дельфи — статически..
Я сравнивал при статической линковке.

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

_>>>Постоянно читая RSDN имел возможность неоднократно убедиться что большинство участников сильно не любят Delphi. Уж очень стало интересно, а за что собственно?
SB>>Не знаю как другим, но мне не нравится:
SB>>1.
SB>>

SB>>:=
SB>>

___>А по моему, так все правильно. По идее семантика оператора сравнения должна отличаться от оператора присваивания.

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

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


G>>>5)Ужасная работа с указателями. (наследие паскаля)
J>>Что значит "ужасная" ??? Или строгая типизация тя не устраивает???

G>Отсутствие операций инкремента и декремента,

Это ВЕСЬМА спорный аргумент.

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

G>На Delphi
G>

G>function TSameObject.CreateStringList: TStringList;
G>begin
G>  Result := TStringList.Create;
G>end;

G>...

G>var x:TStringList;
G>begin
G> x:=SameObject.CreateStringList;
G>end; //А тут ничего не вызовется, получим утечку памяти
G>

С тем же успехом можно сказать, что и в C++ нельзя позвращать ссылку, т.к. ее нужно будет освобождать.

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

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

H>Видимо. И не только мне. На форумах обсуждалось неоднократно с последующими советами понавставлять по коду GC.Collect
Мда... Перечитайте лучше форумы.

H>>>Да ты что? Управляемая (читай контролируемая) сборка мусора это недостаток? Я еще добавлю, что Delphi и за интерфейсами сама следит.
G>>А как еще можно было сделать динамические строки и массивы, но не нагружать программиста вызовами Free?
H>Ну так это же плюс. Чего ты его охаял?
Это не плюс, это необходимость. Плюс был бы если бы можно было врубать GC для всех объектов.

H>Под Delphi я и имел ввиду компилятор (а что же еще-то может за этим следить...).
В .NET следит рантайм.

H>Семантика для работы с интерфейсными классами и с обычными может быть одинаковой (см. TComponent). Но все это тонкости дающие большую гибкость. И необъяснимые глюки это может вызвать только там, где программист работает сам незная с чем (или не до конца понимая механизм).
В C# люди работают, не зная с чем, и баги не возникают почему-то.

H>2005/6 имеют Code Templates. Штука очень приятная и расширяемая.
Мда... в 2005 году уже студия 2005 есть.

H>Это с возвратом созданного объекта чтоль? Ну и в чем проблема? Вот GetMem/VirtualAlloc тоже сырую память отдают и ее возвращать нужно. Не смущает? На самом деле ни какой проблемы в этом нет, объекты, как правило создаются для хранения в каких-либо коллекциях/списках и прочих. И уж точно нет ни какого напряга дернуть Free. Придирки, и не более того.
Я ловил сотни ошибоки из-затого что люди забывали/не_знали_что_надо вызывать Free. В Управляемых средах вообще таких проблем нет. Придирки вполе по делу. Вы просто не понимаете, потому что не работали с этим.

H>Уж не про LINQ ли ты говоришь Ну в 2008 или 2009 обещают анонимные методы добавить еще.
В 2009 уже C# 4.0 будет. Так что делфи все равно отстает.

H>Какая разница кто-кого догоняет или откуда заимствуются те или иные фичи? Ты тут о минусах говорил, я же тебе на плюсы указываю.
Эти плюсы не перекрывают минусы. А в других языках и платформах минусов поменьше.

H>Ну я код постить не собираюсь, в гугле найдешь если интересно. Я наводку дам. В паскале есть чудесная функция Write/WriteLn реализовать которую средствами самого языка невозможно (не прибегая к константным массивам, что все равно не является полноценным решением), но использовать которую очень удобно. Можно легким движением руки превратить ее в приличный логгер перенаправив вывод (да не просто перенаправить, а целый обвяз создать) куда угодно. Делается это именно благодаря библиотечному устройству и без каких либо низкоуровневых API.

Мда... Посмотри функционал iostream в C++, TextWriter в .NET (в Java есть аналогичные классы) — побогаче будет.
Типы text, file of ... — вообще ужас. Поганейшее наследие паскаля.
Если вы не знаете других способов, то это на значит что delphi в чем-то удобен.

H>В нативной 2006 точно есть. Может и в 2005 было, я не помню.
Смешно даже. STL для C++ сущесвует гораздо раньше, в .NET изначально было (c 2001 года), в Java еще раньше.
Delphi тут сильно отстает.

H>Я скорее на Ada пересяду, чем на C#
Удачи.

H>Заметь, не я тут на языки наезжал не имея представления о текущем положении дел.
Вы сначала изучите текущее положение дел не только в Delphi, тогда поговорим.
С момента появления C# 2.0 делфи в положении догоняющего, и вероятнее всего это исправить не удастся.

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

G>>Отсутствие операций инкремента и декремента,
kuj>Это ВЕСЬМА спорный аргумент.

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

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

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

G>>На Delphi
G>>

G>>function TSameObject.CreateStringList: TStringList;
G>>begin
G>>  Result := TStringList.Create;
G>>end;

G>>...

G>>var x:TStringList;
G>>begin
G>> x:=SameObject.CreateStringList;
G>>end; //А тут ничего не вызовется, получим утечку памяти
G>>

L>С тем же успехом можно сказать, что и в C++ нельзя позвращать ссылку, т.к. ее нужно будет освобождать.
В C++ можно вернуть объект (не ссылку), в делфяф такое нельзя сделать в принципе

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

_>>>В чем по вашему мнению я заблуждаюсь? Что такого рулезного есть в новомоюдых сишарпах и иже с ними кроме монстровидных, а часто еще и тормозных RTE/виртуальных машин?
G>>Автоматическая сборка мусора.

H>И неконтролируемая... Из-за которой, порой, возникают прелесные фризы на ровном месте.

Не может быть никаких фризов. Сборщик муссора ведь не в главном потоке приложения выполняется.

_>>>Кстати, сборка мусора для некоторых типов данных (строки и динамические массивы) у Delphi была уже тогда.
G>>Это не преимущество, а попытка скрыть недостатки.

H>Да ты что? Управляемая (читай контролируемая) сборка мусора это недостаток?

В общем случае это таки недостаток. Особенно, когда нет в наличии generic smart pointer`ов (прерогатива C++).

G>>2)Отсутствие интерфейсов и множественного наследования. (наследие паскаля)

H>Интерфейсы есть с очень древней (3/4) версии. А в шарпе делегирование оных есть уже?

В C# есть полноценные делегаты, а в C# 3.0 есть полноценные lambda-выражения.

Без полноценного DI в Delphi толку от интерфейсов куда как меньше.

G>>3)Отсутствие Generic типов или шаблонов любого вида. (наследие паскаля)

H>Дженерики есть в 2007 под .Net.

Думаю тут речь не шла о .NET Delphi. Иначе спор деградировал бы до: какой язык — Delphi.Net или X лучше.

Я бы привел в качестве примера Boo (python синтаксис, с расширяемой compiler pipe).

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

G>>>Отсутствие операций инкремента и декремента,

kuj>>Это ВЕСЬМА спорный аргумент.

G>Знаю, но некоторые выражения на С++ с использованием автоинкремента очень громоздко выразить без него.

Ну это скорее камень в огород C++