В объеме дистрибутивов приложений, «простоте» установки, требуемых ресурсах, поддержке не COM библиотек, тормозах C# действительно «превзошел» Delphi в несколько раз. Это не говоря о том, что вы даже Win32 от .NET отличить не соизволили.
Про агрегирование (точнее, делегирование реализации интерфейса другому классу) — на уровне языка платформа .NET и C# его не поддерживает. Как паттерн же его можно реализовать хоть в ассемблере. В общем опять судите как о программах, так и об оппонентах, ничего о них не зная, господин тролль.
Вы явно не в курсе истории Delphi, так как стратегию Borland, начиная с восьмой версии, иначе как самоубийственной назвать сложно.
Правильно определив будущий мэйнстрим, избрали самую плохую реализацию из возможных:
1. Положили болт на Win32, в результате ничего не выиграли, зато потеряли основную массу разработчиков, а ведь был хороший шанс занять освобожденную MS нишу.
2. Потащили VCL в .NET — это оказалось не нужно ни для перехода c Win32 (все равно платформы слишком разные) ни для обучения с нуля — исходный фреймворк вполне самодостаточен.
3. Прибили прежнюю IDE и вместо использования Visual Studio сделали свою на .NET — в результате получили отставание по поддерживаемым технологиям, прожорливость по ресурсам и кучу багов.
4. Прибили прежнюю справку и сделали новую с нуля в непотребном мелкомягком формате — в результате медлительность и неполнота справки Delphi стали притчей во языцех.
То что после этого Delphi не умер — наглядный показатель ее силы и качества как языка и инструмента разработки.
Поясняю. Основное преимущество нативных приложений — скромные требования к ресурсам и малый объем дистрибутива.
Могут ли им воспользоваться скомпилированные в нативный код Java и C#?
Откуда эта страсть к наклейке ярлыков? Этак можно Яву назвать средством создания пилорам для корпоративных бабок (что соответствует истине примерно в той же степени как и «средство создания оболочек»).
Хотелось бы увидеть хорошее пользовательское приложение на Яве ;)
Дело не во фразе — дело в логике.
Delphi всю свою историю прежде всего предназначалась для GUI-приложений на платформе Win32 и там она до сих пор более чем актуальна (простота создания пользовательских интерфейсов, COM-объектов, клиентов различных СУБД и т.п. до сих пор не превзойдена благодаря сочетанию выразительности и читабельности языка). И требовать решительных успехов в неродных областях — значит проявлять заведомую предвзятость.
Кстати, пока не видел ни в одном статически типизированном языке встроенной поддержке агрегирования.
Считать тот же Skype проектом мелким или не успешным можно тоже только от большого желания повоевать.
Как раз эти самые ошибки «другого рода» и заставляют мучительно искать места утечек.
При автоматическом освобождении нужно не забыть обнулить все ссылки на объект… иначе утечки никуда не денутся.
Так что сборка мусора полезна, но избавляет только от сравнительно простых ошибок, которые легко обнаруживаются и без нее. ИМХО для хорошего разработчика польза (в плане избавления от ошибок) сводится к уменьшению сложности на константу, причем небольшую.
> Я пока понял (а скорее просто сам знаю), что на Delphi можно решать те же задачи и с неменьшими (а порой и с гораздо бОльшими) трудозатратами, что и на других средствах, плюс он значительно менее популярен
Ну вот и классика подоспела — человек ничего не знает о предмете, не дает никакой конкретики, но заявляет что знает и жалуется на отсутствие конкретики у оппонентов.
> Грубо говоря, есть при использовании Delphi приходится тратить в 3 раза больше ресурсов, чем на (к примеру) C#, то и разработка будет в 3 раза дороже.
У этого аргумента есть только один недостаток — он не соответствует действительности.
SciTE — подходит по всем пунктам без исключения.
Использую его, так как он не требует инсталляции, легко интегрируется с любыми консольными инструментами, позволяет легко не терять пользовательских настроек при смене версии, расширяется Lua-скриптами, хорошо документирован.
Предложение интересное, но излишне сложное в реализации, хотя достоинства его очевидны.
Стоит рассмотреть, а не будет ли простой игнор эффективнее сложного бота?
Если посты пользователя, помеченного как тролля, будет видеть только он сам и другие тролли, а для гостевого доступа выставить лаг в 10-30 минут, то тролление станет очень неинтересным занятием даже для того, кому заранее известно про данный механизм контроля. Причем чем больше троллей — тем выше эффективность (начиная с какого-то момента они вообще переходят на самообеспечение, кормя друг дружку), а чем меньше — тем меньше нужда в автоматике (модератор спокойно справится и сам).
Пример из RTL Delphi. Этот код создает класс при десериализации его из потока.
procedure CreateComponent;
var
ComponentClass: TComponentClass;
begin
try
ComponentClass := FindComponentClass(CompClass);
Result := nil;
if Assigned(FOnCreateComponent) then
FOnCreateComponent(Self, ComponentClass, Result);
if Result = nil then
begin
Result := TComponent(ComponentClass.NewInstance);
if ffInline in Flags then
begin
Include(Result.FComponentState, csLoading);
Include(Result.FComponentState, csInline);
end;
try
Result.Create(Owner);
except
Result := nil;
raise;
end;
end;
Include(Result.FComponentState, csLoading);
except
if not Recover(Result) then raise;
end;
end;
А для не полностью сконструированных конструктор должен все сделать сам. RAII помогает, конечно, но тем не менее дельфийский подход требует намного меньше труда и внимания — достаточно лишь аккуратно написать деструктор.
Формулировка и впрямь слишком резкая. Точнее, бросать исключения из конструктора в C++ требует гораздо больше труда и внимательности, так как деструктор при этом вызван не будет, а неинициализированные части объекта содержат мусор. В результате за очистку при прерывании инициализации отвечает конструктор, не имея вдобавок простых средств для отделения зерна от плевел.
Со стороны C++-программиста на проблему можно посмотреть по ссылке: alenacpp.blogspot.com/2006/11/blog-post.html
Про агрегирование (точнее, делегирование реализации интерфейса другому классу) — на уровне языка платформа .NET и C# его не поддерживает. Как паттерн же его можно реализовать хоть в ассемблере. В общем опять судите как о программах, так и об оппонентах, ничего о них не зная, господин тролль.
Правильно определив будущий мэйнстрим, избрали самую плохую реализацию из возможных:
1. Положили болт на Win32, в результате ничего не выиграли, зато потеряли основную массу разработчиков, а ведь был хороший шанс занять освобожденную MS нишу.
2. Потащили VCL в .NET — это оказалось не нужно ни для перехода c Win32 (все равно платформы слишком разные) ни для обучения с нуля — исходный фреймворк вполне самодостаточен.
3. Прибили прежнюю IDE и вместо использования Visual Studio сделали свою на .NET — в результате получили отставание по поддерживаемым технологиям, прожорливость по ресурсам и кучу багов.
4. Прибили прежнюю справку и сделали новую с нуля в непотребном мелкомягком формате — в результате медлительность и неполнота справки Delphi стали притчей во языцех.
То что после этого Delphi не умер — наглядный показатель ее силы и качества как языка и инструмента разработки.
Могут ли им воспользоваться скомпилированные в нативный код Java и C#?
Хотелось бы увидеть хорошее пользовательское приложение на Яве ;)
Delphi всю свою историю прежде всего предназначалась для GUI-приложений на платформе Win32 и там она до сих пор более чем актуальна (простота создания пользовательских интерфейсов, COM-объектов, клиентов различных СУБД и т.п. до сих пор не превзойдена благодаря сочетанию выразительности и читабельности языка). И требовать решительных успехов в неродных областях — значит проявлять заведомую предвзятость.
Кстати, пока не видел ни в одном статически типизированном языке встроенной поддержке агрегирования.
Считать тот же Skype проектом мелким или не успешным можно тоже только от большого желания повоевать.
При автоматическом освобождении нужно не забыть обнулить все ссылки на объект… иначе утечки никуда не денутся.
Так что сборка мусора полезна, но избавляет только от сравнительно простых ошибок, которые легко обнаруживаются и без нее. ИМХО для хорошего разработчика польза (в плане избавления от ошибок) сводится к уменьшению сложности на константу, причем небольшую.
Ну вот и классика подоспела — человек ничего не знает о предмете, не дает никакой конкретики, но заявляет что знает и жалуется на отсутствие конкретики у оппонентов.
У этого аргумента есть только один недостаток — он не соответствует действительности.
Использую его, так как он не требует инсталляции, легко интегрируется с любыми консольными инструментами, позволяет легко не терять пользовательских настроек при смене версии, расширяется Lua-скриптами, хорошо документирован.
Стоит рассмотреть, а не будет ли простой игнор эффективнее сложного бота?
Если посты пользователя, помеченного как тролля, будет видеть только он сам и другие тролли, а для гостевого доступа выставить лаг в 10-30 минут, то тролление станет очень неинтересным занятием даже для того, кому заранее известно про данный механизм контроля. Причем чем больше троллей — тем выше эффективность (начиная с какого-то момента они вообще переходят на самообеспечение, кормя друг дружку), а чем меньше — тем меньше нужда в автоматике (модератор спокойно справится и сам).
procedure CreateComponent; var ComponentClass: TComponentClass; begin try ComponentClass := FindComponentClass(CompClass); Result := nil; if Assigned(FOnCreateComponent) then FOnCreateComponent(Self, ComponentClass, Result); if Result = nil then begin Result := TComponent(ComponentClass.NewInstance); if ffInline in Flags then begin Include(Result.FComponentState, csLoading); Include(Result.FComponentState, csInline); end; try Result.Create(Owner); except Result := nil; raise; end; end; Include(Result.FComponentState, csLoading); except if not Recover(Result) then raise; end; end;Со стороны C++-программиста на проблему можно посмотреть по ссылке: alenacpp.blogspot.com/2006/11/blog-post.html