Alle Jahre (Monate) wieder... Zukunft von Delphi

[rweinzierl]

Zitat von vagtler:

Zitat von Insider2004:

[...] Große, performante Projekte werden bestimmt nicht mit Skript- und Interpretersprachen a la C#, Java, VB-net etc. erstellt. Das ist alles Schnullibulli! Das kann man dazu nehmen, mal schnell ein kleines Tool zu schreiben, aber keine professionelle SW, die verkauft wird.

Soso, muss ich mal meinem Chef sagen, dass unsere Entwicklungsabteilung strategisch ganz falsch aufgestellt ist...

C# oder Java würde ich heute nicht mehr als Skriptsprachen bezeichnen. Beide Sprachen haben viel interessantes zu bieten, und sind sicherlich auch für Großprojekte geeignet. Aber, macht ein umstieg von Delphi zu ??? für kleine Projektteams sinn ? Java auf dem Client scheint auf dem Rückzug zu sein und was Oracle morgen macht weis auch niemand. Java spielt am Web Server seine Stärken aus aber eine Desktopanwendung komplett auf den Web Servertechnik umzustellen ist noch immer sehr sehr aufwendig. (Zumindest wenn man Aufwand Desktop <-> Web Server bei gleichem Funktionsumfang vergleicht).

Mit C# geht sowohl Desktop als auch Web Servertechnik, aber vorherzusehen wo die Reise bei M$ hingeht gleicht auch einem Lotteriespiel. In diesem Video werden die verschiedenen Datenbankzugriffsmethoden unter C# verglichen.
http://www.youtube.com/watch?v=SARBYnXy52I
Nach dem Video war mit klar warum ich die C# Datenbankzugriffskomponenten nicht intuitiv verstanden hatte. Es sind einfach verschiedene inkompatible Ansätze. Solange MS sich so zerplittert ( ist bei Webtechnik Webforms <-> MVC ..) oder Desktop Winforms <-> WPF, Silverlight doch nicht, mit Win RT zurück zu Com aber WinRT halbherzig gepuscht... Bei Windows 8 auch Html5 / Javacript für App Entwicklung ???? Also ich kenn mich da nicht mehr aus. Ich will nicht mein Projekt migrieren und beim Projektrelease feststellen das ich schon wieder auf einem halb toten Pferd sitze.

[jaenicke]

Zitat von hanspeter:

Neue Funktionen und große Änderungen werden in einer anderen Sprache neu implementiert.
Da experimentieren wir noch mit einer praktikablen Schnittstelle um Assemblys in Delphi möglichst nahtlos verwenden zu können.

Da kann ich Oxygene nur empfehlen. Du kannst dort Methoden einfach als exportiert markieren und dann die DLL aus Delphi normal einbinden. In C# geht das natürlich auch, aber nicht so nahtlos und schön.

Es gibt aber auch diverse größere Bibliotheken, die aber für die kleinen Schnittstellen, die wir zwischen .NET und Delphi benötigen, absolut überdimensioniert wären. Zudem möchten wir ungern von unnötig vielen Fremdanbietern und -bibliotheken abhängen.

[p80286]

Zitat von Der schöne Günther:

Hier und/oder auf StackOverflow bekommst du innerhalb weniger Minuten eine qualifizierte Antwort. Aktuelle(!) Videotutorials und Artikel gibt es in Mengen, ich bin überfordert, alle zu sichten und durchzuarbeiten. Wozu man da jetzt noch ein Buch binden muss erschließt sich mir weniger...

Papier hat den enormen Vorteil, ohne Strom und Internetanschluß zu funktionieren. Das funktioniert am Strand, in der Badewanne, im Bett ... aber vielleicht bin ich einfach zu alt.

Gruß
K-H

[RWarnecke]

Zitat von p80286:

Zitat von Der schöne Günther:

Hier und/oder auf StackOverflow bekommst du innerhalb weniger Minuten eine qualifizierte Antwort. Aktuelle(!) Videotutorials und Artikel gibt es in Mengen, ich bin überfordert, alle zu sichten und durchzuarbeiten. Wozu man da jetzt noch ein Buch binden muss erschließt sich mir weniger...

Papier hat den enormen Vorteil, ohne Strom und Internetanschluß zu funktionieren. Das funktioniert am Strand, in der Badewanne, im Bett ... aber vielleicht bin ich einfach zu alt.

Im Zeitalter von Tablets sollte der Strand, das Bett doch kein Problem sein. Außer vielleicht die Badewanne, denn wir wissen ja alle, dass Elektronik und Wasser nicht so gut zusammen arbeiten

[Furtbichler]

Ich habe selten so viel Blödsinn in einem einzigen Thread gelesen.

Zitat von Insider2004:

Delphi ist halt nur was für Profis. Der Mercedes unter den Sprachen. Teuer und edel.

Stimmt. Mercedes hat mittlerweile ein ähnliches Qualitätsmanagement wie Delphi. Ich kenne ehrlich gesagt keine andere Programmiersprache/Entwicklungsumgebung, die so verwanzt ist, wie Delphi.

Zitat von Insider2004:

Große, performante Projekte werden bestimmt nicht mit Skript- und Interpretersprachen a la C#, Java, VB-net etc. erstellt.
Das ist alles Schnullibulli! Das kann man dazu nehmen, mal schnell ein kleines Tool zu schreiben, aber keine professionelle SW, die verkauft wird.

Äh. doch. Oder werden nur kleine Projekte auf dem Arbeitsmarkt umgesetzt? Delphi erscheint in dieser Statistik gar nicht. Ich studiere den Arbeitsmarkt täglich und mir kommt nur alle paar Monate ein Delphi-Job-Angebot vor die Flinte. ich schließe daraus, das es so gut wie keine Projekte gibt, die in Delphi umgesetzt werden. Und da man für kleine Schnullibulli-Projekte keine Ausschreibung vornimmt, vermute ich mal ganz stark, das die Welt größere Projekte doch mit den von Dir als Schnullibulli-Skriptsprachen bezeichneten Weltmarktführern umsetzt.

Zitat von Insider2004:

Kleinen Saftläden würde ich ausschließlich zu Delphi raten. Die Produktivität ist am höchsten und man will ja noch zu Lebzeiten fertig werden und nicht in 20 Jahren.

Also ich werde in C# mittlerweile schneller fertig, weil der Entwicklungszyklus kürzer ist und die Programme schneller lauffähig sind. Allerdings hat Delphi hier wirklich noch eine Stärke (RAD). Leider sind RAS-Programme vom Design/Architektur her so dermaßen schlecht, das sich das doppelt und dreifach in der Wartung rächt. Und irgendwann muss man ja doch wechseln. Warum nicht gleich?

Zitat von Der schöne Günther:

Das ist als würde ich mich als LKW-Fahrer beschweren, dass der Anteil von Lastwagen im Verhältnis zu PKWs wieder zurückgeht. Ja, die fahren oft auf der gleichen Straße. Aber die sind für ganz andere Dinge gedacht und erledigen andere Aufgaben.

Ach, Delphi ist also für andere Dinge gedacht, als C#, C++, VB.NET? Das wäre mir jetzt neu. Delphi kann weniger und hat mehr Fehler, das ist richtig.

Zitat:

C# ==> Erst Winforms jetzt WPF , Silverlight sicherlich nicht mehr, bei M$ dreht sich das Karusell ab wann eine Technik als veraltet gilt immer schneller, da will und kann ich nicht mithalten.

Es gibt wirklich viele Neuerungen, im Gegensatz zu Delphi. Ich empfinde das allerdings als Vorteil. Man muss weiter forschen und auch mal (siehe Silverlight) zurückrudern. Das nennt sich 'Risiko'. Aber so geht es -im Gegensatz zu VCL- auch vorwärts. Ach: WinForms ist alt, aber im LOB-Bereich Quasistandard und bleibt es auch.

Übrigens: Wer moderne Softwarearchitekturen anwendet (MVC, MVP, MVVM) dem ist die UI letztendlich schnurz.

Meine persönlichen Erfahrungen sind:

1. Ich kenne keine IDE die ähnlich schlecht und verwanzt ist.
2. Ich kann in C# mittlerweile Dinge besser, performanter und schneller umsetzen.
3. Ich bin nicht in der Lage, meine Architektur 1:1 in Delphi umzusetzen, da moderne Sprachelemente fehlen oder nur ungenügend umgesetzt sind.
4. Ich finde keinen Delphi-Programmierer für Projekte mehr, also werde ich keinem Kunden raten, mit Delphi zu programmieren und jedem Kunden, dessen Programmierer in Delphi programmieren rate ich, auf C#/Java (je nach Schwerpunkt) zu wechseln. Klar, man kann Programmierer auch auf Delphi umschulen. Aber das machen nur Leute, die mit dem Rücken zur Wand stehen. Ich setzt doch nicht auf ein totes Pferd.
5. Moderne Softwarearchitekturen sind in Delphi-Land komischerweise und leider fast gänzlich unbekannt.

Das bisher einzig Positive ist die Mobile-Strategie von Emba. Die wäre einen Versuch wert. Wenn ich mir ein XE5+ zulegen sollte, dann nur deswegen.

[Robotiker]

Zitat von Der schöne Günther:

[LIST=1]
Wenn ich mir die armen Leute anschauen muss, die mit den Sprachen noch weiter unten auf dem sicherlich repräsentativen TIOBE-Index arbeiten müssen - Großer Gott, wie dreckig muss es denen gehen.

+1

Warum überhaupt Fussball spielen, wenn es den FC Bayern gibt. Da kommt man niemals vorbei.

Delphi (und Pascal) ist heute eher ein Nischenprodukt. Aber deswegen nicht schlecht. Das liegt aber wohl einigen Anwendern auf der Seele.

Zitat von rweinzierl:

Hallo
Wenn nicht in Delphi womit werden denn dann heute Anwendungen erstellt ?

Falls das wirklich eine Frage war:

Eine Marktübersicht kann ich dir nicht liefern. Aber ich habe mit Turbo Pascal und Borland C++ relativ zeitgleich parllel angefangen und über lange Zeit gearbeitet. Auf lange Sicht hat sich in der Tat C++ als die portablere und langfristig wartbarere Alternative erwiesen. Das mag in unserem Anwendungsfeld Industrieautomation anders sein, als z.B. bei Leuten, die nur Datenbank-Frontends bauen.

Zitat von rweinzierl:

Ich rede jetzt nicht von den ganz großen Softwarefirmen wie Autocad oder Oracle, sondern von den 1 - 5 Man Teams die in Firmen Spezial - Softwareprodukte über Jahre entwickeln / pflegen.

Also im CAD- und Simulationsbereich arbeiten selbst die kleinsten Hütten mit C++.

Auch die großen benutzen es selbst für Kleinprojekte, wie hier Autocad
http://labs.autodesk.com/utilities/miller
Wegen der Produktivität: "All produced with libCinder "
http://forum.libcinder.org/#Topic/23286000001844011

Auch im Bereich von Embedded Steuerungen ist C/C++ neben einigen Scriptsprachen weit verbreitet.

[Der schöne Günther]

Zitat von Furtbichler:

Ach, Delphi ist also für andere Dinge gedacht, als C#, C++, VB.NET? Das wäre mir jetzt neu.

Die jüngste Vergangenheit hat bsp. eindrucksvoll gezeigt dass sich Embarcadero Delphi besser für Eisenbahnsimulationen eignet als jede andere Programmiersprache

[Furtbichler]

Zitat von Der schöne Günther:

Die jüngste Vergangenheit hat bsp. eindrucksvoll gezeigt dass sich Embarcadero Delphi besser für Eisenbahnsimulationen eignet als jede andere Programmiersprache

Verdammt. Nur habe ich die gescheiterten Versuche in den anderen Sprachen nicht gesehen.

[Meflin]

Zitat von Furtbichler:

Das bisher einzig Positive ist die Mobile-Strategie von Emba. Die wäre einen Versuch wert. Wenn ich mir ein XE5+ zulegen sollte, dann nur deswegen.

Also wenn ich mir anschaue, dass damit einer der großen Vorteile des App-Prinzips weitestgehend ad absurdum geführt wurde, indem irgendwelche kruden Abhängigkeiten zu misteriösen Prozessorfeatures geschaffen wurden (Stichwort NEON), die man keinem Anwender verständlich erklären kann (Wieso läuft die App nicht bei mir? Na unterstützt denn ihr Prozessor NEON? Woher soll ich das wissen? ...), dann wäre das für mich allein schon ein No Go.
Wenn man sich dazu noch anschaut, dass die Leute hier im Forum, die es benützen, auch noch verzweifelt versuchen, ältere Geräte künstlich inkompatibel zu machen, weil sonst die Performance für simple Formular-Anwendungen zu schlecht ist, dann sieht das für mich doch nach einem gewaltigen Schuss in den Ofen aus...

Und um den Bogen zurück zum Thema zu schlagen: Einfache Cross-Plattform-Entwicklung im Mobile Bereich wäre sicher ein nice-to-have, aber auch da ist Embarcadero ein bisschen "late to the party" (Xamarin etc), und die Umsetzung ist bisher noch dazu wenig überzeugend.
Also ich sehe nicht, dass dadurch Marktanteile gut gemacht werden könnten. Auch da scheint die Zielgruppe für mich hauptsächlich aus Leuten zu bestehen, die nicht willens sind, eine andere Sprache zu erlernen.

[jfheins]

Zitat von Insider2004:

Große, performante Projekte werden bestimmt nicht mit Skript- und Interpretersprachen a la C#, Java, VB-net etc. erstellt. Das ist alles Schnullibulli! Das kann man dazu nehmen, mal schnell ein kleines Tool zu schreiben, aber keine professionelle SW, die verkauft wird.
Kleinen Saftläden würde ich ausschließlich zu Delphi raten. Die Produktivität ist am höchsten und man will ja noch zu Lebzeiten fertig werden und nicht in 20 Jahren.
Große Projekte, wo ich 10 oder 20 Mann brauche, müssen zwangsläufig VC++ (+Qt) nehmen, weil ich so viele Delphi-Programmierer auf einmal gar nicht finde.

Gerade mit dem Argument "Produktivität" kann man eigentlich nicht "pro Delphi" kommen. In .net Sprachen wird in aller Regel ein kleines bisschen Laufzeitperformance geopfert, aber dafür eben gerade Entwicklerproduktivität gewonnen.

Und zu einfaches cross-platform neigt dann doch dazu, überall gleich schlecht auszusehen. Die Benutzer erwarten ein natives look&feel, das heißt auch sich an verschiedene UI Richtlinien zu halten.