Delphi-Projekt-Argumentesammlung u.Vergleich

**Medium**

Es gibt drei große Anbieter von Compiler Toosl. Microsoft = Visual Studio; Intel = C, Fortran ..... und Embacadero = DELPHI + C++

Sun/Oracle = Java, [irgendwer] = PHP, und sicherlich noch 2-5 andere, die ähnlich oder mehr relevant wie Delphi sind. Bei mir ist's halt auch einfach, dass ich mit Pascal groß wurde, und in unserem Betrieb eine recht große Codebase existiert, die zu portieren ein echter Akt wird. Aber ich muss gestehen, dass auch ich diesen Akt mittelfristig kommen sehe - jedoch freue ich mich nicht wirklich darauf =)

**Olli73**

Also mir fallen zu allen genannten Programmiersprachen/Entwicklungsumgebungen nur Argumente dagegen ein:

Java:
Java möchte ich nicht (mehr) auf meinem Rechner haben (aus Anwendersicht). Selbst Oracle schafft es nicht, dass ihre Anwendungen bzw. andere Anwendungen, die komplett mit Oracle-Tools entwickelt wurden, auf der aktuellen Version laufen. Und die alten Versionen haben natürlich noch mehr Sicherheistlücken als die aktuelle eh schon hat und diese werden auch nicht mehr geschlossen. Und sobald Java installiert ist, ist es im IE aktiv, auch wenn es dort deaktiviert wurde - das ist ja wie eine offene Haustür (im Firefox kann man zumindest das Plugin deaktivieren, wenn man aber auch Java-Applets benötigt, bleibt nur noch Chrome, da man (nur?) dort festlegen kann, welche Applets man starten möchte). Der Updater ist grottenschlecht. Es werden keine nativen Controls verwendet, was dann meist wirkt wie ein Fremdkörper im System, und es ist gerne auch etwas "zäh". Und die "Plattformunabhängigkeit" ist seit iOS, WinRT & Co auch nicht mehr als Vorteil zu nennen.

C#/.net:
Habe irgendwie das Gefühl, MS rudert bei dem Thema c#/.net & Co zurück. Bei WP7 hat man noch voll auf C# und Silverlight gesetzt, bei WP8 und WinRT läßt man jetzt wieder C++ zu, was als zusätzliche Option ja OK ist, aber Silverlight & Co verschwinden in der Versenkung und man setzt wieder auf COM-Technologie. 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.

C/C++:
Wer hardwarenah programmiert kommt da nicht drumrum, aber man kann zu viele "Schweinereien" damit machen. Die Profis programmieren meist so, dass kein Anfänger den Code verstehen kann.

Delphi:
Die Verbreitung nimmt ab und daher scheint die Zukunft ungewiss. Und wenn man dann noch hier die Kommentare von Delphi(!)-Entwicklern sieht...

Mir gefällt halt die Sprache und ich kenne mich damit aus, also bleibe ich solange wie möglich bei Delphi.

**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)

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.

**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?

**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.

**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.

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.