Welche Sprache

[volkard]

lassen wir mal Delphi außen vor. diese sprache ist tot. falls delphi überhaupt eine sprache ist.

[asc]

audacia schrieb:

• Deployment. Die Java-Runtime ist mehr oder weniger unkompliziert, aber .NET 2.0, 3.0, 3.5 und 3.5 SP1 ordentlich zu installieren, kann in größeren Umgebungen schlichtweg ein Ding der Unmöglichkeit sein. Mit Delphi kann man Anwendungen ohne externe Abhängigkeiten erstellen.

Stimmt, es ist wirklich überaus kompliziert alle Windowsupdates einzuspielen (Zusammen mit den Optionalen hat man unter XP und Vista nämlich 3.5 SP1 automatisch).

[asc]

volkard schrieb:

lassen wir mal Delphi außen vor. diese sprache ist tot. falls delphi überhaupt eine sprache ist.

Tot würde ich sie nicht nennen, es gibt noch ein paar Firmen die Delphi verwenden. Ich gebe dir aber in so fern recht, das man mittels C/C++/C#/Java und selbst VB.Net wohl mit Sicherheit höheren Praxisbezug hat.

Über kurz oder lang gehe ich aber davon aus das die Delphi und die VCL immer weiter in die Vergessenheit geraten (Es sei den Embarcadero senkt die Einstiegspreise [kostenlose oder billige Einstiegsversion]).

[+fricky]

Skalli schrieb:

C++: [...] es ist schwerer sich in den Fuß zu schießen...

du glaubst wohl jedem werbespruch.

volkard schrieb:

lassen wir mal Delphi außen vor. diese sprache ist tot. falls delphi überhaupt eine sprache ist.

die sprache schimpft sich 'object pascal'. aber eigentlich schade, borland-produkte sind ziemlich gut, doch irgendwie schafft's borland nicht, sein zeug gut zu vermarkten.

[pumuckl]

+fricky schrieb:

die sprache schimpft sich 'object pascal'.

Früher mal. Gottseidank hat das heutige Delphi mit dem damaligen Object Pascal nicht mehr so viel gemein. Dessen erste Gehversuche in Turbo Pascal 7.0 waren nämlich eher lächerlich (Turbo Pascal 6.0 + 5 neue Keywords = objektorientiert...)

[Shade Of Mine]

audacia schrieb:

Shade Of Mine schrieb:

Warum würdest du Delphi zB C# oder Java vorziehen?

Da gibt es viele gute Gründe.

Und noch ein Eck mehr dagegen

Deployment. Die Java-Runtime ist mehr oder weniger unkompliziert, aber .NET 2.0, 3.0, 3.5 und 3.5 SP1 ordentlich zu installieren, kann in größeren Umgebungen schlichtweg ein Ding der Unmöglichkeit sein. Mit Delphi kann man Anwendungen ohne externe Abhängigkeiten erstellen.

Noch nie Probleme mit JRE oder dotnetfx gehabt (wenn wir .NET 1.0 mal aussen vor lassen).

Klassenreferenzen und virtuelle Konstruktoren/virtuelle Klassenfunktionen. Weder in .NET noch in Java gibt es direkt Vergleichbares - dort muß man sich entweder mit einer manuell erstellten Metaklassenhierarchie oder mit RTTI behelfen.

Klassenreferenzen gibt es und virtuelle Ctors nennt sich factory.

Bessere COM-Unterstützung.

Kann ich nicht beurteilen, aber in C# vermisse ich eigentlich nichts.

[*]Konstruktoren haben Namen. Anstelle von

std::vector <int> vec (5);

kann man

vec := TVector<Integer>.CreateWithSize (5);

schreiben. Für so etwas bräuchte man in Java oder C# eine Factory-Funktion, und in C++ zudem die Move-Semantik.

named ctors kann man in Java und C# auch haben.

[*]Gegenüber Java: Delphi unterstützt nichtvirtuelle Methoden, call by reference, Operatorenüberladung für Werttypen (record), objektgebundene Methodenzeiger und Closures.

gilt nicht für c#.

[*]Verschachtelte Funktionen. Das schränkt den Sichtbarkeitsbereich kleiner Helferfunktionen ein und dient außerdem als äußerst effizienter Closure-Ersatz.

lambda / anonyme klassen gibts für sowas

[*]Saubere Trennung zwischen Interface und Implementierung. In Delphi-Code kann ich auf einen Blick das Interface einer Klasse überschauen. Bei Java und C# (und bei C++-Code, der fast alles in Headerdateien implementiert) benötigt man für etwas derart Essentielles zusätzliches Werkzeug.

irrelevant da du diese werkzeuge so oder so brauchst.

[*]Wie alle nativen Anwendungen benötigen Delphi-Anwendungen üblicherweise weniger Speicher als verwaltete Umgebungen, außerdem ist die Speicherverwaltung deterministisch. Auf Wunsch kann dennoch, wie in C++, ein GC eingesetzt werden.

in c# hab ich auch deterministische destruktion wenn ich will und gc bringt deutlich geschwindigkeit

[*]Die direkte Verwendung von WinAPI-Schnittstellen und die Interaktion mit C-Code ist viel unkomplizierter. Das weiß man besonders dann zu schätzen, wenn man mal etwas Zeit mit JNI verbracht hat

gilt aber nicht für c#

[*]Ein natives UI-Framework, das vom Hersteller voll unterstützt wird. Die Zukunft von WinForms ist ungewiß, und WPF hat auch seine Schwächen (Performance).

gibts wie sand am mehr.

[*]DFM-Dateien. WinForms benötigt Hacks wie Regions und partielle Klassen, damit man sich im Code überhaupt zurechtfindet.

gibts ebenfalls wie sand am mehr.

und wie sehen die nachteile aus?
ne, ich sehe gegenüber c# keinen einzigen vorteil. im legacy umfeld mag es seinen sinn haben, aber eine neuentwicklung mit delphi? ne...

[Skalli]

+fricky schrieb:

Skalli schrieb:

C++: [...] es ist schwerer sich in den Fuß zu schießen...

du glaubst wohl jedem werbespruch.

Nicht wirklich, imho trifft die Aussage es schon. Auch wenn es nicht sooo viel schwerer ist. Aber das ganze ist eigentlich alles andere als ein Werbespruch...

[+fricky]

Skalli schrieb:

+fricky schrieb:

Skalli schrieb:

C++: [...] es ist schwerer sich in den Fuß zu schießen...

du glaubst wohl jedem werbespruch.

Nicht wirklich, imho trifft die Aussage es schon. Auch wenn es nicht sooo viel schwerer ist. Aber das ganze ist eigentlich alles andere als ein Werbespruch...

das ist genau so dumm, wie die aussage "java ist einfach vieeeeeeel zu langsam".

[audacia]

asc schrieb:

Stimmt, es ist wirklich überaus kompliziert alle Windowsupdates einzuspielen (Zusammen mit den Optionalen hat man unter XP und Vista nämlich 3.5 SP1 automatisch).

Erinnerst du dich daran, daß Microsoft XP SP1 deutlich länger als geplant unterstützen mußte? Oder was Vista bei Unternehmen für eine Quote hat? Klar, im Idealfall ist das alles kein Problem. Aber jede zusätzliche Abhängigkeit birgt zusätzliche Komplikationen. Und ich habe schon genug derartiger Probleme gesehen.

~fricky schrieb:

die sprache schimpft sich 'object pascal'.

Soweit ich weiß, wurde sie irgendwann angesichts der Tatsache, daß sie mit Wirths Pascal nicht mehr viel gemein hat, in "Delphi Language" umbenannt.

Shade Of Mine schrieb:

Noch nie Probleme mit JRE oder dotnetfx gehabt (wenn wir .NET 1.0 mal aussen vor lassen).

Das ist schön, aber daß es dir bisher immer gut erging, widerlegt mein Argument nicht. Ich jedenfalls hatte schon eine Menge Probleme mit verschiedenen Versionen der .NET-Runtimes.

Shade Of Mine schrieb:

Klassenreferenzen gibt es

Es gibt System.Type, aber du kannst damit nicht Klassenpolymorphie anwenden. Sieh dir lieber erstmal das Feature in Delphi an, bevor du so pauschal antwortest.

Shade Of Mine schrieb:

und virtuelle Ctors nennt sich factory.

Ja, so nennt sich der Workaround, den man mangels virtueller Konstruktoren benutzen muß.

Shade Of Mine schrieb:

audacia schrieb:

Gegenüber Java: Delphi unterstützt nichtvirtuelle Methoden, call by reference, Operatorenüberladung für Werttypen (record), objektgebundene Methodenzeiger und Closures.

gilt nicht für c#.
[...]

audacia schrieb:

Die direkte Verwendung von WinAPI-Schnittstellen und die Interaktion mit C-Code ist viel unkomplizierter. Das weiß man besonders dann zu schätzen, wenn man mal etwas Zeit mit JNI verbracht hat

gilt aber nicht für c#

Deshalb schrieb ich auch "Java" und "JNI", Mr Redundancy

Shade Of Mine schrieb:

in c# hab ich auch deterministische destruktion wenn ich will

Aber kein deterministisches Speichermanagement.

Shade Of Mine schrieb:

und gc bringt deutlich geschwindigkeit

Für viele Anwendungsfälle trifft das zu, aber wenn das ein Problem ist, kannst du ja auch in Delphi einen haben.

Shade Of Mine schrieb:

irrelevant da du diese werkzeuge so oder so brauchst.

In der alltäglichen Arbeit ja. Aber ich starte nicht für jeden Codeschnipsel, den ich lesen will, gleich die IDE. Dennoch ist das hauptsächlich ein ästhetischer Vorteil. Um Delphi-Code lesbar zu machen, muß man nicht erst Regions, Code Folding etc. bemühen. Er ist einfach lesbar.

Shade Of Mine schrieb:

gibts wie sand am mehr.

Gute UI-Frameworks für .NET? An welchem Meer?
Die UI-Frameworks sind einer der größten Schwachpunkte bei .NET. WinForms ist träge (GDI+), und WPF ist noch längst nicht so verbreitet wie WinForms. Von AWT und Swing muß ich vermutlich gar nicht erst anfangen; auf Seiten Javas ist eigentlich nur SWT eine Option, wenn das Ergebnis unter Windows vernünftige Usability bieten soll.

Shade Of Mine schrieb:

und wie sehen die nachteile aus?

Die gibts natürlich ebenso. Vor allem wären das weniger umfangreiche RTTI und der Wegfall der Vorteile, die sich durch die Nutzung eines Managed Environments ergeben.

Shade Of Mine schrieb:

ne, ich sehe gegenüber c# keinen einzigen vorteil.

Bei allem Respekt, aber weil du keinen Vorteil siehst, heißt das noch lange nicht, daß es keinen gibt.

Vielleicht solltest du einfach mal eine Weile mit einer der neueren Delphi-IDEs arbeiten

[Shade Of Mine]

audacia schrieb:

Bei allem Respekt, aber weil du keinen Vorteil siehst, heißt das noch lange nicht, daß es keinen gibt.

Sollen wir mal die Nachteile von Delphi gegenüber C# oder Java aufzählen...?

Vielleicht solltest du einfach mal eine Weile mit einer der neueren Delphi-IDEs arbeiten

vermutlich hat sich seit 2006 wohl eine menge getan, wieder ein guter punkt gegen delphi, nicht wahr?

[asc]

audacia schrieb:

asc schrieb:

Stimmt, es ist wirklich überaus kompliziert alle Windowsupdates einzuspielen (Zusammen mit den Optionalen hat man unter XP und Vista nämlich 3.5 SP1 automatisch).

Erinnerst du dich daran, daß Microsoft XP SP1 deutlich länger als geplant unterstützen mußte? Oder was Vista bei Unternehmen für eine Quote hat? Klar, im Idealfall ist das alles kein Problem. Aber jede zusätzliche Abhängigkeit birgt zusätzliche Komplikationen. Und ich habe schon genug derartiger Probleme gesehen.

Selbst ohne den Updatemechanismus war meine Unternehmenserfahrungen das die Probleme bezüglich Java/.Net sich nicht viel unterscheiden (Tendenziell habe ich sogar von mehr Javaproblemen mitbekommen, Java ist aber auch verbreiteter - Wobei ich selbst schon ca. 4x Probleme mit Javaversionen auf diversen Rechnern hatte, und nur einmal mit .Net).

Ich gehe davon aus das beide Java wie .Net etwa gleich viele Installationsprobleme machen.

cu André

[audacia]

Shade Of Mine schrieb:

audacia schrieb:

Bei allem Respekt, aber weil du keinen Vorteil siehst, heißt das noch lange nicht, daß es keinen gibt.

Sollen wir mal die Nachteile von Delphi gegenüber C# oder Java aufzählen...?

Vielleicht wäre es besser, wenn du die potentiellen Vorteile von C# und Java gegenüber Delphi aufzählst; besonders, da du Delphi offenbar nicht allzu gut kennst

[Shade Of Mine]

audacia schrieb:

Sollen wir mal die Nachteile von Delphi gegenüber C# oder Java aufzählen...?

Vielleicht wäre es besser, wenn du die potentiellen Vorteile von C# und Java gegenüber Delphi aufzählst; besonders, da du Delphi offenbar nicht allzu gut kennst ;)[/quote]
Ja, mein wissen ist aus 2006. Da war Delphi Schrott.

Aber ganz einfach: Know How ist für Java und C# en masse da.
Warum sollte man ein Projekt jetzt mit Delphi anfangen oder es gar lernen wenn man Anfänger ist. Lustige Sprachfeatures kann ich zu hauf nennen. zB IO ist enorm toll. Aber was bietet Delphi wirklich? .NET Binding ist sicher toll, doch warum Delphi und nicht C#?

C# ist enorm toll. Du hast Support von der Industrie, du kannst Know How kaufen und es gibt massig Informationen. Delphi bietet keine wirklichen Sprachfeatures mehr, maximal diese Klassenpolymorphie die so toll sein soll (wobei ich den Sinn hier generell nicht verstehe weil dann duck typing doch einfach besser geeignet wäre, oder?). GUI Framework nehme ich an wird immernoch die VCL verwendet die nun gegenüber Qt keine Vorteile bietet (nur wieder weniger know how vorhanden) oder eben .net wo du wieder wie C# dastehst.

Ich habe mir nun http://entwickler.de/zonen/portale/psecom,id,101,online,1928.html durchgelesen und muss sagen die neuen Features in Delphi 2009 sind ein ziemlich alter Hut. Aber gut, es hat sicher features die andere Sprachen nicht haben - das steht ausser frage. Nur warum man Delphi nehmen sollte beantwortet das nicht. Denn von der Sprache her ist Delphi keine gute Lehrsprache - ergo für Anfänger ungeeignet da zuviel compiler magie. Und in der Industrie wegen fehlendem support auch nicht wirklich brauchbar.

da müsste es schon sehr gute argumente geben warum man ein projekt damit machen sollte. Sprich: Ich kann mir nur legacy Gründe vorstellen warum man heute auf Delphi setzen will. Legacy Gründe sind schön und gut, keine Frage - wir setzen auch oft aus legacy Gründen auf suboptimale techniken - aber deshalb würde ich hier jetzt nicht unbedingt 4D als Datenbank lösung empfehlen

[audacia]

Shade Of Mine schrieb:

C# ist enorm toll. Du hast Support von der Industrie, du kannst Know How kaufen und es gibt massig Informationen.

Ich stimme zu, daß aus Karrieresicht die Entscheidung für C# zukunftssicherer ist.

Shade Of Mine schrieb:

Delphi bietet keine wirklichen Sprachfeatures mehr, maximal diese Klassenpolymorphie die so toll sein soll (wobei ich den Sinn hier generell nicht verstehe weil dann duck typing doch einfach besser geeignet wäre, oder?).

Ja, ganz offensichtlich verstehst du den Sinn nicht.

Shade Of Mine schrieb:

GUI Framework nehme ich an wird immernoch die VCL verwendet die nun gegenüber Qt keine Vorteile bietet (nur wieder weniger know how vorhanden)

Komponentenmarkt? Bessere Windows-Unterstützung? Bessere IDE-Unterstützung? Bessere Sprachunterstützung (moc anyone?)?

Shade Of Mine schrieb:

Denn von der Sprache her ist Delphi keine gute Lehrsprache - ergo für Anfänger ungeeignet da zuviel compiler magie.

Unfug. Im Übrigen wäre das bei C# nicht anders.

[Muetze187]

Nette Diskussion, auch wenn ich nur die Hälfte verstehe

Evtl. gut für die Zukunft wäre eine Sprache mit denen man so kleine Gadgets erstellen kann wie z.B. fürs iphone oder was die Zukunft so bringt. Ich behaupte einfach mal unwissender Weise das c++ die erste Wahl ist!?

mfg
muetze

[Gast]

Muetze187 schrieb:

Evtl. gut für die Zukunft wäre eine Sprache mit denen man so kleine Gadgets erstellen kann wie z.B. fürs iphone oder was die Zukunft so bringt.

Für das iPhone nimmt man wohl eher Objective C. Damit wirst du aber auch nur glücklich wenn du auch einen Mac hast.
Nimm die Sprache die dich am meisten interessiert. Irgendwas zu lernen weil du damit in Zukunft vielleicht etwas machen können wirst... das bringts nicht. Imo.

[DEvent]

Ich verstehe nicht wieso sich so manche an Sprachfeatures aufgeilen. Mich interessiert es ueberhaupt nicht ob Sprache X closures, named ctors, nested functions und was nicht alles tolles hat. Die Frage ob Sprache X das richtige Werkzeug fuer das Problem Y ist, ist weitaus wichtiger.

Fuer mich zaehlen die folgenden Eigenschaften einer Sprache:
a) Einfachheit der Sprache
b) die Bibliotheken die verfuerbar sind
c) die Kosten der Portierbarkeit
d) die Zeit fuer die Entwicklung

Z.B. C++ schneidet in a) und d) ganz schlecht ab, in b) sehr gut und in c) bedingt gut (kommt drauf an welche Bibliotheken man verwendet). C# ist in b) und d) sehr gut. Da die meisten sowieso nur fuer Windows entwickeln, spielt also fuer die meisten d) keine Rolle. Java ist IMHO sehr gut in allen 4 Punkten.

Vor allem deswegen haben sich Sprachen wie Java, C# oder PHP gegenueber C oder C++ durchgesetzt. Wozu brauche ich Templates und manuelle Speicherverwaltung wenn ich eine GUI oder eine Webanwendung schreiben will? Wozu brauche ich Structs, Operatorueberladung, Autoboxing?

Klar verschinden C/C++ dadurch nicht. C/C++ sind die generischen Sprachen, die sich fuer alles eignen, in denen man die maximale Freiheit hat. Java, C#, Php u.a. eigenen sich aber weitaus besser fuer spezielle Themen, wie GUI, Webanwendung, usw.

Mein Tipp an den Thread Ersteller ist es: Wenn du Programmieren lernen willst, dann lern C. Fuer Webanwendungen nimm Php, Java, Ruby (ich habe sehr schlechte Meinung ueber C#, deswegen empfehle ich C# nicht).

Hier ist auch eine gute Seite die meine Meinung ueber C# bestaerkt:
http://www.geocities.com/csharpfaq/

Auch meine Meinung ueber unchecked exceptions spiegelt die Seite sehr gut wieder:

Unchecked exceptions results in shorter but less robust code.

[audacia]

DEvent schrieb:

Ich verstehe nicht wieso sich so manche an Sprachfeatures aufgeilen. Mich interessiert es ueberhaupt nicht ob Sprache X closures, named ctors, nested functions und was nicht alles tolles hat. Die Frage ob Sprache X das richtige Werkzeug fuer das Problem Y ist, ist weitaus wichtiger.

Und daß es da eine Korrelation geben kann, ist dir unbegreiflich?

[tfa]

audacia schrieb:

DEvent schrieb:

Ich verstehe nicht wieso sich so manche an Sprachfeatures aufgeilen. Mich interessiert es ueberhaupt nicht ob Sprache X closures, named ctors, nested functions und was nicht alles tolles hat. Die Frage ob Sprache X das richtige Werkzeug fuer das Problem Y ist, ist weitaus wichtiger.

Und daß es da eine Korrelation geben kann, ist dir unbegreiflich?

Ich glaube auch, die Features einer Sprache sind eher zweitranging für die Frage, ob sie sich als Werkzeug für ein bestimmtes Problem eignet oder nicht. Wenn man sich techikverliebt zu sehr an den tollen Features "aufgeilt", verliert man am Ende andere, wichtigere Aspekte aus den Augen.
Einige davon hat DEvent ja schon genannt. Ich würde unbedingt hinzufügen:
e) Verfügbarkeit von Entwicklern und Beratern

Und ich glaube, da scheidet Delphi nicht besoders gut ab verglichen mit C++, C# oder Java.

Der erste Punkt (Einfachheit) ist auch wichtig. Was nützen tolle Sprachkonstrukte, die man selten braucht, die nicht jeder versteht und anwenden kann und am Ende eher Probleme schaffen als lösen?
(Nur interessehalber: Welche Vorteile haben benannte Konstruktoren gegenüber Fabrikmethoden?)

DEvent schrieb:

Fuer Webanwendungen nimm Php, Java, Ruby

PHP verstößt ganz massiv gegen deinen Punkt a) - lieber nicht.

DEvent schrieb:

Auch meine Meinung ueber unchecked exceptions spiegelt die Seite sehr gut wieder:

Unchecked exceptions results in shorter but less robust code.

Bei diesem Punkt irrt diese Seite ganz gewaltig IMHO. Aus meiner Java-Erfahrung würde ich eher sagen:

Checked Exceptions results in longer and less robst code.

Ich glaube, diese Meinung verbreitet sich auch in Java immer mehr (ich hoffe es zumindest).

[audacia]

tfa schrieb:

Einige davon hat DEvent ja schon genannt. Ich würde unbedingt hinzufügen:
e) Verfügbarkeit von Entwicklern und Beratern

Und ich glaube, da scheidet Delphi nicht besoders gut ab verglichen mit C++, C# oder Java.

Richtig. Dennoch gilt für Delphi wie für fast jede andere Sprache: ein erfahrener Programmierer kann sie bei Bedarf innerhalb kurzer Zeit erlernen. Warum sollte man nicht einen C#-Programmierer in einem Delphi-Job beschäftigen können, eine grundsätzliche Agilität des Programmierers vorausgesetzt?

tfa schrieb:

(Nur interessehalber: Welche Vorteile haben benannte Konstruktoren gegenüber Fabrikmethoden?)

Eine Frage der Begünstigung. In Delphi bist du grundsätzlich gezwungen, deinem Konstruktor einen Namen zu geben; in C++/Java/... sind unbenannte Konstruktoren üblich, und du mußt i.d.R. einen Konstruktor und eine Factory-Methode schreiben, wenn du eine aussagekräftige Konstruktorbenennung willst.

In C++ ist es besonders schlimm, da man man Move-Semantik oder NRVO benötigt, um vector<SomeHeavyStruct>::createWithSize(3000) überhaupt benutzen zu können, außerdem muß man im Zweifelsfalle alle Argumente aus der Factory-Methode an den Konstruktor weiterreichen (-> Initialisierungsliste). Das sind alles Workarounds infolge einer (IMHO) grundlegenden Fehlkonzeption, die man in Delphi schlicht nicht braucht.

tfa schrieb:

Checked Exceptions results in longer and less robst code.