Delphi-Projekt-Argumentesammlung u.Vergleich

**Bernhard Geyer**

Java: Java möchte ich nicht (mehr) auf meinem Rechner haben (aus Anwendersicht).

Man kann ja Problemlos verwenden ohne es zu installieren. Man ist also für eine Desktop-Anwendung von den ganzen Mist den aktuell Oracle macht relativ geschützt.
Und iOS, WinRT & Co sind auch keine problem wenn man eine Online/Webanwendung mit Java macht (Backend Java, Frontend JS/HTML5)

Zitat von Olli73:

C#/.net:

Also was .NET im Frontend (Client) bedeutet hat das war uns relativ egal. Hatten nur einmal eine Windows-Phone-Anwendung entwickelt die wir jetzt in die Tonne treten können. War sozuagend ein teures Gastspiel

Zitat von Olli73:

C/C++:

Mir reichen die Erfahrungen als es noch Win3.1 relevant war. Man, habe ich es nach einiger Zeit gehasst und bin dann hingegangen teil soweit möglich nach Delphi(1) umzustellen.

Zitat von Olli73:

Man kann zwar weiterhin C# verwenden, aber die Schlüsseltechnologie von MS wird es wohl nicht mehr sein/werden, sondern es wird weiterhin nur die altbekannten C++/COM/...-Technologien etwas schöner verpacken.

Was ja durchaus eine Chance für Delphi sein kann. Einfachere COM-Programmierung als in C++ war ja immer eine der Stärken.

Allerdings muss man da die richtige Niche finden. Die MSDN beschreibt die Positionierung von C# und C++ im Moment so

Zitat:

C++ is experiencing a renaissance because power is king again. Languages like Java and C# are good when programmer productivity is important, but they show their limitations when power and performance are paramount. For high-efficiency and power, especially on hardware that has limited hardware, nothing beats modern C++.

http://msdn.microsoft.com/en-us/library/hh279654.aspx

Zitat von Bernhard Geyer:

Zitat von Olli73:

C/C++:

Mir reichen die Erfahrungen als es noch Win3.1 relevant war.

Oppa erzählt vom Krieg.

Kein Wunder, dass die platten Anti-C++ Argumente, wie im Startbeitrag dieses Threads, nicht ziehen, um neue Leute für Delphi zu interessieren. ISO C++, von MS gerne Modern C++ genannt, sieht deutlich anders aus, als alter WinApi-Code. Pointer und diesen ganzen Makro Quatsch sieht man da höchst selten.

Bin mal gespannt, wie Embarcaderos neue Liebe für C++ in der Delphi Gemeinde ankommt. Das Struppi mal auf einer Delphi Konferenz spricht, hätte ich vorher nicht geglaubt:

http://blogs.embarcadero.com/davidi/2012/11/21/41993/

Zitat von Robotiker:

ISO C++, von MS gerne Modern C++ genannt, sieht deutlich anders aus, als alter WinApi-Code.

Ich zitier mich einfach mal selber und zeige ein paar Codeschnippsel aus der Hilo-Beispiel App für Windows 8.

Ist dieses C++ unstrukturierter und schlecher zu lesen als z.B. C# ?

markieren

Code:

			vector<unsigned int> RandomPhotoSelector::CreateRandomizedVector(unsigned int vectorSize, unsigned int sampleSize)

{

    // Seed the rand() function, which is used by random_shuffle.

    srand(static_cast<unsigned int>(time(nullptr)));

    // The resulting set of random numbers.

    vector<unsigned int> result(vectorSize);

    // Fill with [0..vectorSize).

    iota(begin(result), end(result), 0);

    // Shuffle the elements.

    random_shuffle(begin(result), end(result));

    // Trim the list to the first sampleSize elements if the collection size is greater than the sample size.

    if (vectorSize > sampleSize)

    {

        result.resize(sampleSize);

    }

    return result;

}

oder

markieren

Code:

			void ImageBrowserViewModel::StartMonthQuery(int queryId, cancellation_token token)

{

    m_runningMonthQuery = true;

    OnPropertyChanged("InProgress");

    m_photoCache->Clear();

    run_async_non_interactive([this, queryId, token]()

    {

        // if query is obsolete, don't run it.

        if (queryId != m_currentQueryId) return;

        m_repository->GetMonthGroupedPhotosWithCacheAsync(m_photoCache, token).then([this, queryId]

        (task<IVectorView<IPhotoGroup^>^> priorTask)

        {

            assert(IsMainThread());

            if (queryId != m_currentQueryId)  

            {

                // Query is obsolete. Propagate exception and quit.

                priorTask.get();

                return;

            }

            m_runningMonthQuery = false;

            OnPropertyChanged("InProgress");

            if (!m_runningYearQuery)

            {

                FinishMonthAndYearQueries();

            }

            try

            {     

                // Update display with results.

                m_monthGroups->Clear();                   

                for (auto group : priorTask.get())

                {  

                    m_monthGroups->Append(group);

                }

                OnPropertyChanged("MonthGroups");

            }

            // On exception (including cancellation), remove any partially computed results and rethrow.

            catch (...)

            {

                m_monthGroups = ref new Vector<IPhotoGroup^>();

                throw;

            }

        }, task_continuation_context::use_current()).then(ObserveException<void>(m_exceptionPolicy));

    });

}

Das ist die Sprache, mit der Delphi in Zukunft, auch Mobilbereich, konkurriert. Erst recht, wenn der C++ Builder seinen neuen, auf CLang basierenden, Compiler hat. Nicht irgendwelches Zeug, von vor 20 Jahren.

Argumente wie "Delphi liegt mir einfach besser" oder "Das bin ich so gewohnt", sind doch gute Gründe für Delphi. Aber dieser Thread trägt den Titel "Argumentesammlung und Vergleich". Da muss man schon mit dem richtigen Vergleichen. Und das ist im nativen Bereich der Vergleich Delphi/FireMonkey/Free Pascal mit der ganzen C++11 / Qt / Boost usw. Welt. Ganz ohne Bezug auf MS, Delphi will ja auch Cross Plattform sein.

**Bernhard Geyer**

Zitat von Robotiker:

Oppa erzählt vom Krieg.

Oppe dauert hoffentlich noch 15 Jahre

Zitat von Robotiker:

Kein Wunder, dass die platten Anti-C++ Argumente, wie im Startbeitrag dieses Threads, nicht ziehen, um neue Leute für Delphi zu interessieren. ISO C++, von MS gerne Modern C++ genannt, sieht deutlich anders aus, als alter WinApi-Code.

War schon "supermodernes" MFC. Gegen VCL hat es aber eher noch Assemblercode ausgeschaut ...

Zitat von Robotiker:

Bin mal gespannt, wie Embarcaderos neue Liebe für C++ in der Delphi Gemeinde ankommt. Das Struppi mal auf einer Delphi Konferenz spricht, hätte ich vorher nicht geglaubt:

http://blogs.embarcadero.com/davidi/2012/11/21/41993/

Diese C++-Liebe kommt doch alles paar Jahre wieder. Was war noch mit den C++-Builder X der ja eigentlich das problem der Plattformunabhängigkeit erledigen sollte? Glücklicherweise war das ein Versucher den ich nicht mal eine Testinstallation gewürtigt habe.

Zitat von Bernhard Geyer:

War schon "supermodernes" MFC. Gegen VCL hat es aber eher noch Assemblercode ausgeschaut ...

Das bringt mir die Gelegenheit wieder zum eigentlichen Thema des Threads zurückzukommen.

In gewisser Weise haben VCL und MFC ja derzeit etwas gemeinsam. Beide sind irgendwie am Ende des Weges angekommen und werden von ihren Herstellern etwas stiefmütterlich behandelt.

Kein Zweifel, dass die VCL eine der besten Lösungen für klassische Windows Desktop Anwendungen ist. Höchstens Qt kann da mithalten. MS hat da im nativen Bereich im Moment nix, allerdings haben sie für Win8 Apps gezeigt, dass sie mit C++11 ein natives Gegenstück zu C# haben, siehe die Beispiele oben. Wohlmöglich kommt das demnächst auch für Desktop Anwendungen, dann werden die Karten neu gemischt.

Die Liebe von Embarcadero gehört derzeit ganz klar dem "brennenden Affen", sowohl für Delphi als auch dem C++ Builder. Wenn ich mir das so ansehe, im Licht der "Argumente" des Threaderstellers, wie

Zitat:

Sehr einfache plattformübergreifende GUI-Erstellung
Wartbarkeit: Wesentlich klarerer und damit wartbarer Code als mit C/C++
Stabile Plattformbasis, also nachhaltige Investition
usw.

dann wird mir unwohl.

Andere Dinge sind relativ

Zitat:

Ein kürzlich von Delphi1 geschriebenes größeres Projekt liess sich erstaunlich einfach und schnell auf Delphi 2010 hochziehen: Nachhaltigkeit.

Mit dem OpenSource-Projekt OWLnext laufen Projekte aus Borland C++ 4 von 1994 auf Visual Studio 2012 ...

Zitat:

Keine Garbage-Collection notwendig, also auch keine Zwangs-Pause des Programmbenutzers üblicherweise genau dann wenn etwas schnell gehen muss.

Ich glaube die C++11 Beispiele oben zeigen sehr gut, dass andere Sprachen deterministische Resourcenbereinigung auch sehr gut hinkriegen. Nebenbei bemerkt, machen aktuelle .net Frameworks keine Stop The World Garbage Collection mehr.

In diesem Punkt steckt etwas wahres

Zitat:

durch den einfach decompilierbaren Bytecode der Dot-Net-Sprachen und in Java exportiert jeder Verantwortliche, der Programm(Teile) in einer dieser Sprachen ausser Hauses gibt oder gelangen läßt, i.A. Firmengeheimnisse. ...
Da solche Firmengeheimnisse „kriegsentscheidend“ für eine Firma sind, kann tatsächlich das dann zufällig kurz danach auftauchende Konkurrenzprodukt aus chinesischer Produktion den Tod der Firma einleiten.

Natürlich gibt es Obfuskatoren, das Thema hatten wir ja schon.
Aber ich wage mal die Behauptung, dass viele kommerzielle Win8 (+ Phone) Apps in C++ geschrieben werden, um dieses Problem zu umgehen. Die syntaktischen Unterschiede, s.o., halten sich in Grenzen, beide greifen auf die selbe API und Klassenbibliothek zu, usw.
Das ist sicher ein Gebiet, in dem Delphi mit nativer Cross Plattform Entwicklung punkten könnte, wenn die Qualität und Performance stimmen.

Performance ist allerdings so ein Gebiet, wo ich mir mehr von Delphi wünschen würde. Es gibt zwar Threads in der Sprache und ein wenig Angebot im Bibliotheksbereich (OmniThread). Aber verglichen mit dem, was es z.B. bei Intel oder MS gibt ist das recht dünn besetzt. Mit einer Visual Studio Express kann man seine C++ Threads mit C++ AMP auch auf der Grafikkarte laufen lassen, in zukünftigen Versionen wohl auch in der Cloud. Es gibt die Parallel Patterns Library, der Compiler hat einen Autovektorisierer und einen Autoparallelisierer.

Im Mobilbereich tun sich neue Problemfelder auf, z.B. ARM-Prozessoren mit "big little" Technik, also Prozessoren mit unterschiedlich schnellen Kernen, was Multithreading ein wenig komplitiert.

Alles Dinge, wo sich neue Delphis beweisen müssen. Im Moment halte ich es mit abwarten und C++ Programmieren.

**Olli73**

Zitat von Bernhard Geyer:

Zitat von Olli73:

Java: Java möchte ich nicht (mehr) auf meinem Rechner haben (aus Anwendersicht).

Man kann ja Problemlos verwenden ohne es zu installieren. Man ist also für eine Desktop-Anwendung von den ganzen Mist den aktuell Oracle macht relativ geschützt.
Und iOS, WinRT & Co sind auch keine problem wenn man eine Online/Webanwendung mit Java macht (Backend Java, Frontend JS/HTML5)

Solange Desktop- und Webserveranwendungen keine Java-Installation auf dem Client voraussetzen, ist es ja noch OK.

Zitat von Bernhard Geyer:

Hatten nur einmal eine Windows-Phone-Anwendung entwickelt die wir jetzt in die Tonne treten können. War sozuagend ein teures Gastspiel

Funktionieren sollte die aber auch noch unter WP8?!

**Bernhard Geyer**

Zitat von Olli73:

Solange Desktop- und Webserveranwendungen keine Java-Installation auf dem Client voraussetzen, ist es ja noch OK.

Oracle arbeitet ja seit einiger Zeit daran das man keine PC's mehr mit installierten Java mehr vorfindet.

Zitat von Olli73:

Zitat von Bernhard Geyer:

Hatten nur einmal eine Windows-Phone-Anwendung entwickelt die wir jetzt in die Tonne treten können. War sozuagend ein teures Gastspiel

Funktionieren sollte die aber auch noch unter WP8?!

Nein, funktioniert nicht mehr. Oder bekommt z. B. Active Sync noch unter WP8 zum laufen?

**Meflin**

Delphi hat meiner Meinung nach genau einen echten Vorteil: es ist die einzige Sprache, mit der man mit halbwegs (!) schönem Code native Windows-Anwendungen schreiben kann. Mit C++ scheint es ja, relativ zur Gesamtheit der Programmiersprachen, völlig unmöglich zu sein, schönen Code zu schreiben (und auch die in diesem Thread gezeigten Beispiele sind da nicht unbedingt eine Ausnahme. Code-Clutter by Design

). Delphi ist da zwar auch weit vom Optimalzustand entfernt, aber nunja...

Das Dumme an der Sache ist nur: Es gibt immer weniger Gründe, wieso man native Anwendungen entwickeln wollen würde. Einerseits landen immer mehr Anwendungen im Browser (was quasi die billigste Plattformunabhängigkeit ist) und sind damit durchaus erfolgreich (siehe z.B. Google Docs oder Play Music). Andererseits ist der Ressourcenverbrauch von Runtimes wie .Net oder Java, der ja gerne als Gegenargument angeführt wurde / wird, für den überwiegenden Teil der Anwendungsfälle einfach kein Gegenargument mehr. Dafür bekommt man als Entwickler deutlich modernere Sprachen (Java meine ich damit nicht unbedingt... aber es gibt ja durchaus noch mehr, was zu Java-Bytecode kompiliert wird

) mit denen man deutlich schneller ein fertiges, wartbares Produkt produzieren kann. Von der Größe der Communities und verfügbarer Codebase (Libraries etc) mal ganz zu schweigen.

**Olli73**

Zitat von Bernhard Geyer:

Oracle arbeitet ja seit einiger Zeit daran das man keine PC's mehr mit installierten Java mehr vorfindet.

Ja, die geben sich wirklich viel Mühe dabei. Allerdings setzen sie selbst immer Java voraus, werden wohl irgendwann die einzigen sein. Und wenn ich mir dann die Tools wie SQL*Plus & Co anschaue... Naja, für Abfragen & Co nutze ich nur noch meine eigenen Tools (mit Delphi geschrieben).

Zitat von Bernhard Geyer:

Zitat von Olli73:

Zitat von Bernhard Geyer:

Hatten nur einmal eine Windows-Phone-Anwendung entwickelt die wir jetzt in die Tonne treten können. War sozuagend ein teures Gastspiel

Funktionieren sollte die aber auch noch unter WP8?!

Nein, funktioniert nicht mehr. Oder bekommt z. B. Active Sync noch unter WP8 zum laufen?

Meintest du jetzt "Windows mobile" (<=6.5) oder "Windows Phone" (>=7.0). Ich bin von letzterem ausgegangen...

**Bernhard Geyer**

Zitat von Olli73:

Ja, die geben sich wirklich viel Mühe dabei. Allerdings setzen sie selbst immer Java voraus, werden wohl irgendwann die einzigen sein. Und wenn ich mir dann die Tools wie SQL*Plus & Co anschaue...

Ich glaube nicht das es bei Oracle irgendeinen gibt der weiß was sie so alles mit ihrem Oracle-DB-Installieren. Mich würde es überraschen wenn es bei aktuellen oracle-Versionen nur eine Java-Version wäre die sie installieren.

Zitat von Bernhard Geyer:

Zitat von Olli73:

Zitat von Bernhard Geyer:

Hatten nur einmal eine Windows-Phone-Anwendung entwickelt die wir jetzt in die Tonne treten können. War sozuagend ein teures Gastspiel

Funktionieren sollte die aber auch noch unter WP8?!

Nein, funktioniert nicht mehr. Oder bekommt z. B. Active Sync noch unter WP8 zum laufen?

Meintest du jetzt "Windows mobile" (<=6.5) oder "Windows Phone" (>=7.0). Ich bin von letzterem ausgegangen...[/QUOTE]
War schon noch Mobile - Bei dieser permanente Unbenennung des mittlerweilen sterbenden CE-Kerns kommt man leicht durcheinander.
Mit Windows Phone hatte es MS schon geschafft irrelevant zu sein und für die neuen Mobilen Entwicklungen kommt erst iOS, dann Android und zum Schluss Windows.