Delphi умер?

Во многом это вопрос личных предпочтений. Но есть также и объективная сторона.
Код, генерируемый компилятором Делфи не соизмерим по производительности с кодом
MS VC. Для этого достаточно произвести несложный тест:
написать одинаковый фрагмент кода, реализующий базовую логику, циклы, работу с переменными, и т. п.
и замерить его тайминг. Результат будет говорить сам за себя!

Delphi - среда быстрой разработки, вот и все, кидать компонент приятней чем писать обертки и вагон кода!

Приведу пример из одного проекта:

procedure ShowBalloonTips(sTipTitle, sTipInfo: string; iTimeOut: Cardinal; sdwInfoFlags: dword);

var

  TipInfo, TipTitle: string;

  I:Integer;

begin

  with tray do

  begin

  uFlags := uFlags or NIF_INFO;

  StrPCopy(szInfo, '');

  Shell_NotifyIcon(NIM_MODIFY, @tray);



  uFlags := uFlags or NIF_INFO;

  cbSize := SizeOf(tray);

  uFlags := dwInfoFlags;

  TipInfo := sTipInfo;

  strPLCopy(tray.szInfo, TipInfo, SizeOf(tray.szInfo) - 1);

  uTimeout := iTimeOut;

  TipTitle := sTipTitle;

  strPLCopy(tray.szInfoTitle, TipTitle, SizeOf(tray.szInfoTitle) - 1);


  dwInfoFlags := sdwInfoFlags { or NIIF_NOSOUND}; //NIIF_INFO;     //NIIF_ERROR;  //NIIF_WARNING;

  //uFlags := NIF_ICON or NIF_MESSAGE or NIF_TIP;

  szTip:='szTip';

  szInfo:='szInfo';

  szInfoTitle:='szInfoTitle';

//  tray.hBalloonIcon:=iStart;


  uFlags:=NIF_MESSAGE or NIF_ICON or NIF_TIP or NIF_STATE or NIF_INFO;

  Shell_NotifyIcon(NIM_MODIFY, @tray);

  //uVersion := NOTIFYICON_VERSION;

  //if not Shell_NotifyIcon(NIM_SETVERSION, @tray) then

  //   ShowMessage('setversion fail');

  end;


{

  //tray.cbSize := SizeOf(tray);

  tray.uFlags := NIF_ICON + NIF_INFO;

  strPLCopy(tray.szInfo, sTipInfo, SizeOf(tray.szInfo) - 1);

  tray.uTimeout := iTimeOut;

  strPLCopy(tray.szInfoTitle, sTipTitle, SizeOf(tray.szInfoTitle) - 1);

  tray.dwInfoFlags := dwInfoFlags;     //NIIF_ERROR;  //NIIF_WARNING;

  //Shell_NotifyIcon(NIM_MODIFY, @tray);

  tray.uVersion := NOTIFYICON_VERSION_4;//NOTIFYICON_VERSION;

//  if not Shell_NotifyIcon(NIM_SETVERSION, @tray) then    ShowMessage('setversion fail');

}

end;

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

{$REGION 'Загрузка/сохранение БД'}

procedure TDataModule1.SaveLoadDatabases(save: Boolean);

const

  s_integrated_tables:array  of string = ('dxMemData1', 'dxMemData2');  // таблицы без сохранения в файл, только внутренные нужды

var

  i:integer;

  s, s2:string;

  dxm:TdxMemData;

begin

  s2:=ExtractFileDir(ParamStr(0))+'\data\';

  for i := 0 to ComponentCount - 1 do

    if (Components.ClassName='TdxMemData')  then

    begin

    dxm:=(FindComponent(Components.Name) as TdxMemData);

    s:=s2+dxm.Name+'.dat';

    if (save=false) and (FileExists(s)) then

       begin

//       if (Components.Name in s_integrated_tables)

       if (Unit_tools.IndexOfArrayList(s_integrated_tables, Components.Name)=-1)

          then dxm.LoadFromBinaryFile(s);

       dxm.Active:=True;

       end;

    dxm.Active:=True;

    if (save=true) and (Unit_tools.IndexOfArrayList(s_integrated_tables, Components.Name)=-1) {and (dxm.Active=true)} then

       begin

       dxm.SaveToBinaryFile(s);

       end;

    end;

end;

написав такой несложный код, и применяя его к DataModule (контейнеру для ДБ-компонентов), я загружаю/сохраняю ДБ-таблицы на диске, причем исключая сугубо таблицы в памяти, обратите внимание на главный цикл:
for i := 0 to ComponentCount - 1 do
это и есть объектный подход, дающий мегагибкость и скорость разработки именно визуальных приложений, которых подавляющее большенство, в этом и сила Делфи

относительно кода ЕКЗ-ешки... в сентябре сравним, код компилятора перетрусили, а код VCL постоянно переписывается на асемблер, более того, в делфи самый быстрый компилятор, не самый оптимальный конечно, но если нужна скорость то пишется на асемблере, и не стоит говорить что С++ будет быстрее, это абсурд конечно, делфа без проблем позволяет писать на асемблере, так что опять мимо, опять ткну в InnoSetup написан на 2 делфи еще, и до сих пор он лидер в создании пакетов установки, или кто то скажет что MSI-работает быстрее ?)))

этот спор безосновательный до бесконечности, закрывайте топик!

Цитата ("MMM_Corp"):

этот спор безосновательный до бесконечности, закрывайте топик!

Аминь!

MMM_Corp, ну так прямо все сишники на голом API пишут, можно подумать.
Если так, C с плюсами или без были бы далеко позади, невзирая на все остальные факторы.
Тот же balloon tip в Qt делается в 3 строчки, а в Boost можно прокси-сервер написать за пару минут.

И в C++ (особенно в больших проектах) используются целые иерархии классов, построенные на
полиморфизме и шаблонных параметризациях. Есть целые фреймворки и системы уровня middleware,
которые решают широчайший круг задач.

Это общая проблема программистов, независимо от языка - изобретать велосипеды и раз за
разом решать однотипные задачи, не прибегая к утилизации кода и обобщениям, только в языках
низкого уровня она, наверное, стоит острее.

Кстати, чтобы писать на ассемблере программы, превосходящие по скорости свои аналоги на
других языках, теперь уже мало просто знать синтаксис машинных команд.
Нужно вручную выполнять много другой работы - выравнивать команды по границам линий кэша,
искать порядок инструкций, чтобы они оптимально ложились на конвейер, а еще устранять
стековые фреймы, искать незанятые регистры, инлайнить вызовы и выискивать возможности
для использования процессорных расширений SSE и FPU. Короче, тонны забот - человеку такое не под силу.

Цитата:

но в восторг он явно не придет услышав что надо качать тяжёлый дон-нет фреймворк к тому же тормозной

Вы наверное прочитали заметку 2001 года??? .NET Framework стоит давно на большинстве компов, т.к. начиная с висты он встроен. И вдобавок, у кого то еще диалап стоит, что 30 метров это "тяжелый" фреймворк? И еще, когда Вы говорите "тормозной", пожалуйста уточняйте, в чем он тормозной. А то это такой же аргумент, как Windows "глючная". Не забывайте, что времена меняются, и те аргументы, которые были актуальны 10 лет назад, сегодня уже не канают. А насчет сравнения Delphi и C#, то Delphi конечно же устарел хотя бы потому, что Вы не увидите в C# ошибку Access Violation at address 2626
51312313. C# это более высокоуровневый язык и среда, которая позволяет сосредоточиться на задаче, а не работе с указателями и прочей мутотенью. И не нужно говорить, что фреймворк делает стандартные вещи тормознутее, чем это сделал бы кодер. Скажите, какой процент кодеров лучше майкрософтовских?

Цитата:

Кстати, чтобы писать на ассемблере программы, превосходящие по скорости свои аналоги на
других языках, теперь уже мало просто знать синтаксис машинных команд.
Нужно вручную выполнять много другой работы - выравнивать команды по границам линий кэша,
искать порядок инструкций, чтобы они оптимально ложились на конвейер, а еще устранять
стековые фреймы, искать незанятые регистры, инлайнить вызовы и выискивать возможности
для использования процессорных расширений SSE и FPU. Короче, тонны забот - человеку такое не под силу.

Это дурацкая привычка программистов считать, что надо все стандартные функции надо переписывать самому. Типа себя не уважать, использовать чужой код, а если майкрософтовский так вообще. Во-первых, не факт, что квалификация программиста позволит написать более эффективный код, так еще и после него будет сложнее разбираться другим программистам. И нужно ли это заказчику? Получить производительность на 10% больше за большие деньги и большее время? Его интересует побыстрее выпустить продукт и зарабатывать деньги. Вот поэтому заказчики и выбирают C#. А платят больше за C# потому, что за более короткий срок получается сделать больше работы благодаря эффективности.

Кстати, весь холивар заключается в этом непонимании с разных сторон. Программист хочет себя реализовать, написав более изощренную программу на более низкоуровневом языке, т.к. это сложнее и пытается доказать, что это лучший вариант, хотя лучшим является вариант получения большей прибыли в кратчайший период, ведь ради этого всё и происходит.

Цитата:

Access Violation

сугубо от криворукости, вот только не надо лукавить, и на шарпе ее можно поймать! взять хотябы маршалинг, или работу с указателями...)
то что новички часто не проверяют создан ли обьект перед использованием, завершают процедуру без уничтожения обьекта - это уже пардон только от криворукости, то что в шарпе это решено костильом аля сборщик мусора, никак не означает что там такой ошибки нет, то что иногда проблемно отловить - это тоже только поначалу, если все писать правильно и грамотно сразу, то такой ошибки попросту не будет, а программы будут работать как часы

относительно фреймворков, - опять таки зло, и опять таки могу поспорить что далеко не у всех стоят все фреймворки, 1.0, 1.1, 2.0, 3.0, 4.0... и т.д. до бесконечности, да не спорю язык хорош, но вот майкрософт не внушает доверия в этом плане совершенно, где щас J# - ? верно, нигде! а всетаки был... VisualBasic - застрял в прошлом, а помню как же продвигали страшно, а щас на нем пишут очень мало, это конечно все очень насторажывает, где гарантия что с приходом винды 8, еще будет поддержка 1 фреймворка? нет никакой, также как напр. с DirectX 11, что ему мешает работать на XP непонятно, это все бизнес майкрософта, а его агресия запросто может уничтожить многолетный опыт программирования на своих продуктах без вменяемых причин, в отличии от Делфи, где много лет продвигается продукт, расширяется, поддерживается громадным комюнити, а это стабильность, опыт, надежность, постоянно пригать с языка на язык - не может породить поколение специалистов, а только волну поклоников новой моды, так как еще надо успеть не только заработать денег, но и написать стабильный софт, хотя у каждого свои цели, моя напр. написать надёжно, все перепроверить, поэтому я спокойно работаю и завышаю цену, потому что знаю за что завышаю
фреймворк хорош в нише ASP.Net , для чего он и был разработан, про что честно пишут в справке к 1 версии, это факт, хотя и сам чуть не купился на моду)

кстати то что делфовскые прогы жирные - абсурд, BPL-тоже можно таскать и размножать, и прогы будут не жирнее С++-шных, видимо не все знают что дот.нет как и С++ проги работают со своими прослойками, делфи же делает это прозрачно и не требует ничего лишнего, только виндовс и все, но если есть желание, то можно и рядом таскать BPL-ки, но это делают только для больших комплексов, и то далеко не всегда

Цитата ("CODERsp"):

Программист хочет себя реализовать, написав более изощренную программу на более низкоуровневом языке, т.к. это сложнее и пытается доказать, что это лучший вариант, хотя лучшим является вариант получения большей прибыли в кратчайший период, ведь ради этого всё и происходит.

Золотые слова !

P.S. На тот случай, если холивар закончится - спасибо всем за интересные посты.

Собственно, программы пишутся ПРИ помощи языка программирования, а не на языке программирования. Главное что у тебя в голове.
По поводу COM - тоже, что и с dll, из кода какого языка дергать не важно - смысл был в этом.

Цитата ("gagtungr"):

Собственно, программы пишутся ПРИ помощи языка программирования, а не на языке программирования.

Это самое большое противоречие, которое я встречал в литературе по программированию.
Везде учат, что правильно решать - значит мыслить в терминах задачи.
Но реализация выливается во всякие бриджи, синглетоны и проакторы, что вообще чуждо естественному человеческому взгляду на проблему.
Я не создаю экземпляр класса, а вынужден пользоваться всякими фабриками, которые вдобавок могут возвращать не сам объект, а прокси в виде
смарт-поинтера, я строю многослойные иерархии классов, наследую пустые типы, обхожу узлы итераторами и визиторами, и даже простая
строка у меня может при желании параметризироваться разными типами потоковой модели.

Причем если язык был бы другим, другими были бы и методы решения, это очевидно.
В .NET или Java хлопоты, связанные с памятью, автоматически устраняются, плюс сами эти языки поддерживают больше
абстракций, чем C++. Так "снимаются с вооружения" смарт-поинтеры, RAII, аллокаторы и многое другое.

Уверен, что это все-таки больше "на", чем "при".

Наверное, я какой-то неправильный программист...

Ну судя из всего ответ - точно нет

Цитата ("okman"):

Я не создаю экземпляр класса, а вынужден пользоваться всякими фабриками, которые вдобавок могут возвращать не сам объект, а прокси в виде
смарт-поинтера, я строю многослойные иерархии классов, наследую пустые типы, обхожу узлы итераторами и визиторами, и даже простая
строка у меня может при желании параметризироваться разными типами потоковой модели.

Причем если язык был бы другим, другими были бы и методы решения, это очевидно.
В .NET или Java хлопоты, связанные с памятью, автоматически устраняются, плюс сами эти языки поддерживают больше
абстракций, чем C++. Так "снимаются с вооружения" смарт-поинтеры, RAII, аллокаторы и многое другое.

Тут вы путаете средства разработки, основанные на каком-то конкретном языке программирования, и сам язык.

Интересно когда вы сдавали на права, вас учили на зубок разбираца в устройстве двигателя вашей машины, знать в ней каждый винтик и проводок, нет, конечно никто не будет против, но многие предпочитают просто жать газ и ехать, отдавая заботу об остальном "заботливой робототехнике", и если в общем и целом нужно написать прогу, которая будет выполнять некие действия, то почему бы не воспользоваться делфёй и множеством её компонентов, для того чтобы в короткий срок ублажить заказчика.

Цитата ("gagtungr"):

Тут вы путаете средства разработки, основанные на каком-то конкретном языке программирования, и сам язык.

Эти средства навязываются языком и неотделимы от него. Более того, язык сам является средством разработки.
Давайте рассмотрим конкретный пример.

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

На C или ассемблере регистратор был бы выполнен в виде нескольких функций, принимающих указатель на определенную
структуру, описывающую событие и его тип. Причем инициализация и очистка события возлагается на клиента.
Отдельно нужно позаботиться о корректной работе в многопоточной среде.

На C++ я бы просто сделал иерархию событий с абстрактным Event в верхушке - выбор регистратором нужного
действия происходил бы полиморфно, инициализацией и очисткой ресурсов регистратора занимались бы
конструкторы/деструкторы (RAII), а вопросы многопоточности можно было параметризировать шаблонным параметром класса.

На C# или Visual Basic .NET все вышеперечисленное не нужно, потому что есть делегаты, а потоковая модель
вообще может программироваться атрибутами .

Во всех трех случаях были выбраны реализации, каждая наиболее естественная (на мой взгляд) для своей среды.
И код сильно бы отличался.

Ну теперь пожалуйста опишите, как программируется данный пример при помощи языка, а не на языке.

Цитата ("mulbergerio"):

Интересно когда вы сдавали на права, вас учили на зубок разбираца в устройстве двигателя вашей машины, знать в ней каждый винтик и проводок, нет, конечно никто не будет против, но многие предпочитают просто жать газ и ехать, отдавая заботу об остальном "заботливой робототехнике", и если в общем и целом нужно написать прогу, которая будет выполнять некие действия, то почему бы не воспользоваться делфёй и множеством её компонентов, для того чтобы в короткий срок ублажить заказчика.

Я считаю, что каждый программист должен пройти какую-то "закалку", будь то программирование на ассемблере со сборкой
командными файлами, ковыряние в кодах ядра linux, или участие в падающем проекте с двумя миллионами строк кода и
сотнями веток в репозитории. Тогда ему будет проще решать разные инженерные задачи, когда нельзя обойтись
готовыми решениями и приходится прорубать дорогу самому. Многие высококлассные специалисты .NET и Java, перед тем
как пересесть на управляемые языки, компоненты и сервисы, прошли долгий многолетний путь на нижних "этажах",
познав многие их дрязги, "костыли", и воспитав глубокую дисциплину и приверженность субкультуре.

Это дзен.

Цитата ("okman"):

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

Задача должна решаться вот на этом этапе, все что описано ниже это уже реализация решения, а не само решение. Именно поэтому и говорят "при", а не "на".

"Закалиться" можно на любом проекте. Не важно на каком языке он реализован.

Цитата ("okman"):

Многие высококлассные специалисты .NET и Java, перед тем как пересесть на управляемые языки, компоненты и сервисы, прошли долгий многолетний путь на нижних "этажах"...

Тоже могу сказать и про тех кто пишет на Delphi. Тут уж кому какой велосипед больше нравится.

Ага.. только скайп написал и сразу откинулся.

Цитата ("gagtungr"):

Задача должна решаться вот на этом этапе, все что описано ниже это уже реализация решения, а не само решение. Именно поэтому и говорят "при", а не "на".

Говорят, но не показывают как это достигается практически.
Вы написали, что программы пишутся при помощи языка, а не на языке, но продемонстрировать этот
подход на каком-нибудь примере затрудняетесь. Оно и понятно - современные компиляторы не способны
генерировать код, основываясь на словесных абстрактных формулировках, которые дает человек.
Им подавай конкретику - какую сущность куда запихнуть и каким методом обработать.

Для работника техсервиса "починить автомобиль" значит подкрутить отверткой какую-то гайку,
поменять свечи и залить масло, а для банковского служащего это же самое значит свезти машину в ремонт и
пару часов подождать. Где тут нарушение концепции ? Каждый решил задачу починки авто наиболее
естественными и соразмерными для себя средствам.

Вот поэтому я и считаю, что данная догма хороша только на бумаге, а люди цитируют ее не осмысливая.

Цитата ("gagtungr"):

Цитата (okman):Многие высококлассные специалисты .NET и Java, перед тем как пересесть на управляемые языки, компоненты и сервисы, прошли долгий многолетний путь на нижних "этажах"...
Тоже могу сказать и про тех кто пишет на Delphi. Тут уж кому какой велосипед больше нравится.

Взято из контекста. Выше я (и другие) уже писали, что программисты языков высокого уровня часто
пренебрегают пониманием основ, таких как работа на уровне операционной системы.
Да что вообще тут говорить, если даже MMM_Corp сказал, что MSDN нафиг не нужен !