warum C++ statt Delphi?

[stahli]

Ich hoffe, das ist nicht schon mehrfach besprochen worden...

Ich habe in letzter Zeit ab und zu in die neuen C++ Videos rein gesehen und bin überrascht.
Welche Gründe gibt es, das zu nutzen?

Sicher ist es eine Gewohnheitsfrage aber ich finde die Sprache unnötig kompliziert.
Anscheinend hängt C++ Delphi auch in einem technologisch hinterher (was offenbar gerade ausgeglichen wird).

Welche Gründe gibt es (vor allem für Neueinsteiger) pro C++ gegenüber Delphi?

[Aphton]

Ne sehr subjektive und keineswegs professionelle Meinung (bin noch Student xD)
C & Konsorten sind Universalsprachen. Man kann damit für sehr viele (wenn nicht alle) Systeme entwickeln.

Ein ähnlicher Vergleich wäre Englisch & Deutsch - beide Sprachen haben ihre Pros & Cons, jedoch kann man mit beiden
mehr oder weniger dasselbe anstellen - kommunizieren, egal in welcher Form.
Englisch jedoch ist die bedeutendste Weltsprache.

Ich hab aber in letzter Zeit mehr das Gefühl, dass Java sich in den Vordergrund drängt und C vom Tron stoßen
wird bzw. schon hat.
Letzendlich ist Java - von der Syntax her - wieder in C Dialekt.

[Insider2004]

Keine Frage. C/C++ ist die grösste Sxxxxxsprache aller Zeiten. Es gibt 1000 Freiheitsgrade, wo man was falsch machen kann. Vom Ergonomischen her gesehen also die absolute Katastrophe. Leider hat sie sich durchgesetzt, obwohl Pascal früher rauskam. Namhafte Compiler-Hersteller haben leider auf C gesetzt. Und wenn Du heute Geld mit Programmierung verdienen musst, bleibt dir leider nur C. Allerdings ist bei One-Man-Shows Delphi die 1. Wahl, weil die Produktivität extrem hoch ist. Ich schätze mal, 1 Delphi-Programmierer ist so schnell wie 20 C/C++-Programmierer.

[Insider2004]

Java würde ich eher als Skriptsprache für den Internetbrowser sehen. Völlig ungeeignet für performante Desktop-Programme. Wenn du professionelle (wissenschaftliche) Programme erstellen musst, kommst du um native Programmierung nicht herum.

[cookie22]

Zitat:

Anscheinend hängt C++ Delphi auch in einem technologisch hinterher (was offenbar gerade ausgeglichen wird).

Wenn du hier C++ schreibst, meinst du den C++ Builder.

Wenn man mit C++ anfängt, dann mit Visual Studio. Visual C++ Express gibt es kostenlos und man darf damit ohne Limits kommerziell programmieren. Schon darum lohnt sich für Anfänger der C++ Builder kaum. Außerdem ist der Compiler technisch Jahre hinter MS und Intel. Man kann C++ auch für .Net Programme nutzen, auch das ist ein Vorteil von VC++. Außerdem arbeitet der C++ Builder mit der in Pascal geschriebenen VCL. Dann doch bitte gleich Delphi.

Zitat:

Java würde ich eher als Skriptsprache für den Internetbrowser sehen. Völlig ungeeignet für performante Desktop-Programme.

Das halte ich für ein Gerücht.

[knight]

Zitat:

Zitat von cookie22 (Beitrag 1196659)

Zitat:

Java würde ich eher als Skriptsprache für den Internetbrowser sehen. Völlig ungeeignet für performante Desktop-Programme.

Das halte ich für ein Gerücht.

Schaue dir mal die Berichte (der Entwickler) zu LibreOffice 3.4 an. Dort hat man einige Im- und Exportfilter von Java auf C++ umgestellt (bei LibreOffice will man generell weg von der Java-Abhängigkeit). Die C++ Variante ist 40x schneller als die Java Variante gewesen (und ich glaube nicht, daß man da schon alle Optimierungsmöglichkeiten genutzt hat).

knight

[cookie22]

Natürlich sind native Programme schneller, aber das es für performante Desktop-Programme nicht taugt galt vielleicht vor 10 jahren, aber mittlerweile sind die Rechner so schnell, dass da kaum noch Unterschiede auffallen. Außerdem ist auch nicht alles grundsätzlich 40 mal langsamer.

[Bernhard Geyer]

Zitat:

Zitat von Insider2004 (Beitrag 1196657)

Java würde ich eher als Skriptsprache für den Internetbrowser sehen. Völlig ungeeignet für performante Desktop-Programme. Wenn du professionelle (wissenschaftliche) Programme erstellen musst, kommst du um native Programmierung nicht herum.

Falsch Falsch Falsch.

Java ist kein Script-Sprache! Java ist neben C#/.NET die Programmiersprache/Runtime im Professionellen Serverumfeld.
Performante Desktop-Programme sind absolut kein Problem (Sind aktuell dabei ein Delphi-Programm nach Java zu portieren). Grundsätzlich kein Performancenachteile und in Teilbereichen schneller als Delphi. Und das Programm läuft auf Windows/MacOS und als Serverprogramm auf praktisch jeden relevanten Betriebssystem auf dem Tomcat läuft.

[Bernhard Geyer]

Zitat:

Zitat von knight (Beitrag 1196661)

Schaue dir mal die Berichte (der Entwickler) zu LibreOffice 3.4 an. Dort hat man einige Im- und Exportfilter von Java auf C++ umgestellt (bei LibreOffice will man generell weg von der Java-Abhängigkeit). Die C++ Variante ist 40x schneller als die Java Variante gewesen (und ich glaube nicht, daß man da schon alle Optimierungsmöglichkeiten genutzt hat).

Da waren wohl die Java entwickler von einer zu starken Objektorientierung und Abstrahierung zu fasziniert das sie dabei die Performance vergessen haben. Kann mal passieren. Hätten wahrscheinlich durch ein paar Stunden Profiling diese vervierzigfachung der Performance auch hin bekommen.

[BMI]

Frohe Weihnachten allen!
Oder zumindest Frohe Fest/Feier*/Frei-tage!

mhh, ich dachte immer, daß c++ aufgrund der differenzierteren Aufteilung der Spachelemente in Libraries noch effizienteren und einen Tacken schneller laufenden Code produzieren kann.
Noch schneller sei/ist wohl nur C - und darüber geht wohl nur Prozessor optimierter Assemblercode -
wobei bei C ja da noch ermöglicht schneller komplexere Programme (wie modernere Betriebssysteme außer UNIX) schneller zu erstellen.

Obwohl es sogar GUIbasierte Dateimanager für DOS in Assembler gab, setzt man ASM denk ich heute nur noch für kürzere Spezialcodestücke, die wenig Zeilen INLINE CODE aber maximale Effizienz brauchen ein (10-100 Zeilen)

Dafür ist das Schreiben in C fehleranfälliger als C++.

Und JAVA - der Compiler bringt doch auch in Maschinensprache übersetzten Code hervor, der auf ausgelagerte, vorgefertigte compilierte Funktionen zurückgreift - ähnlich DLLs - nur permanent eben.
Das ist doch keine Scriptsprache. Javascript - das is für den Browser.
Aber das Klassen/Funktionensystem hat mir 1992 schon nicht gefallen. fand ich persönlich ekelhaft anzuwenden. Aber das kann man nicht generalisieren.

C/c++ war mir leider zu zeitaufwendig zu lernen und damals gab es noch kein bezahlbares Internet.

Bin von Quickbasic (1993) über VB5 (1997) direkt zu Delphi 3(2002).

[Aphton]

Ich kenn mich mit Java noch nicht so gut aus (muss es jedoch wegen Uni lernen >/), aber man kann angeblich Codebereiche definieren, die zur Laufzeit nicht interpretiert sondern richtig kompiliert und ausgeführt werden.
Das hat sicher nen Namen, mag es mir jemand verraten? ^_^
Habs, JIT

[pixfreak]

Hallo zusammen,

C++ ist um ein vieles mächtiger als Delphi. Allein die Template Möglichkeiten gehen bei weitem über die der Generics von Delphi hinaus.

Oder die Möglichkeit der Mehrfachvererbung: Ok, man muss schon aufpassen, was man da wie vererbt, das kann sehr schnell unübersichtlich und fehleranfällig werden, lässt einem aber doch weite Freiheiten. Die Interface sind da nur ein fadenscheiniger Ersatz.

Mit Boost bzw. jetzt dem neuen Standard kann man viele schöne Sachen machen, Multithreading z.B. ist reltiv schnell und sicher umgesetzt.

Ja und da ist noch die Sache, dass ich fast jede Klasse auch lokal instanziieren kann und nicht immer mit new einen neuen Speicherplatz dynamisch anfordern muss. In Delphi gibt es da ganz schnell diese häßlichen try..finaly Verschachtelungen, wenn ich mal etwas mehr in einer Methode brauche, ok, etwas am Design verändert, kann ich das vielleicht auch vermeiden.

Ich persönlich mag C++ sehr gerne und kann damit auch recht gut um, es bedarf allerdings eine lange Lernphase, aber wenn man es drauf hat, dann kann man recht dolle Sachen damit machen.

Persönlich fehlt mir in C++ aber die with-Anweisung, da hat Delphi was voraus ;-)

Ich finde, das vergleichen der Sprachen ist aber nur eine seite der Medallie. Zum proggen brauche ich auch noch einen Compiler und am besten eine ordentliche IDE. Und da geht es schon los.

Wenn ich das richtig verfolgt habe, sind die neuen C++ Features nur im 64 Bit Compiler verfügar, man belehre mich, wenn ich mich irren sollte. Für 32 Bit werkelt immer noch der alte. Die Produktivität ist mit dem C++ Builder nicht mit Delphi zu vergleichen, ein Hauptgrund warum ich als One-man-Tastaturhämmerer auf Delphi setze, wegen z.B.

• keine Refaktorings, außer Umbenennen, und das nur sehr oberflächlich
• keine Klassenvervollständigung ala Strg-shift-C, man muss immer in zwei Dateien, Header und Code, die Funktionen einfügen und bearbeiten (ok, mit UML gehts auch so, der Klassenbrowser regt mich in den akuellen Versionen nur auf)
• VCL wird halt irgendwie mit rein operiert, VCL Klassen müssen dynamisch angelegt werden, statisch geht nicht
• der Experte für vorcompilierte Header ist tricky, man muss schon selbst Hand anlegen, damit ordentliche precomiled Headers heraus kommen, die auch was bringen in Bezug auf Compiliergeschwindigkeit. Und da kommen z.B. die DevExpress Compos, die haben in einem Header Daten stehen und die zerschießen den precomiled Header so, dass er nicht verwendet werden kann. Ich hab das schon mehrmals denen geschrieben, ist aber in jeder Version wieder drinne... (Ich habs dann mal rausoperiert...)
• der Delphi Compiler ist um Welten schneller, ok für den Builder gibt es TwineCompile, da sieht man mal, was ginge, aber Delphi bleibt schneller (single-pass)
• Code-completion funktioniert nur mit einem ordentlichen precomiled Header und auf einem schnellen Rechner ordentlich, sonst passiert es schon mal, dass man über eine Sekunde wartet, bis die Code completion angezeigt wird, und ist sie einmal angestossen muss man auch warten und kann nicht weitertippen :-(

Also, der Emba Compiler (ich rede jetzt mal nur vom 32er) ist wie schon gesagt, meilenweit hinter den aktuellen Compilern zurück. Aber es gibt noch ein Problem: Welches Tool nimmt man für die Oberflächenprogrammierung? Ok, QT fällt mir gerade ein, VCL braucht die Builder IDE und die ist grottig, MFC ist doch eh fast WinAPI, ja und dann?

Also meine Meinung: Für "Backboxen" würde ich C++ mit einem vernünftigen Compiler nehmen, kommt eine GUI dazu, dann entweder in Schichten mit verschiedenen Systemem arbeiten oder eben auf das Brot- und Wassertool Delphi ausweichen. (Um .net habe ich bis jetzt einen Bogen gemacht und Java mag ich persönlich nicht so...)

So, nun denn, frohe Weihnachten!


Gruß Pixfreak

[Bernhard Geyer]

Zitat:

Zitat von pixfreak (Beitrag 1196673)

C++ ist um ein vieles mächtiger als Delphi. Allein die Template Möglichkeiten gehen bei weitem über die der Generics von Delphi hinaus.

Vielfaches halte ich übertrieben. Es ist in einzelnen Bereichen Mächtiger.

Zitat:

Zitat von pixfreak (Beitrag 1196673)

Oder die Möglichkeit der Mehrfachvererbung: Ok, man muss schon aufpassen, was man da wie vererbt, das kann sehr schnell unübersichtlich und fehleranfällig werden, lässt einem aber doch weite Freiheiten. Die Interface sind da nur ein fadenscheiniger Ersatz.

Voll Kontra. Ich kenn nur C++ die Mehrfachvererbung kann und das auch nur weil man nicht fähig war mit Interfaces einen vernünftige Implementierung hin zu bekommen.
Mehrfachvererbung verursacht bei weiten mehr Probleme als es löst. Interfaces ist ein Sprachkonstrukt ohne das viele Realisierungen nicht so elegant zu realisieren wären.

Zitat:

Zitat von pixfreak (Beitrag 1196673)

Mit Boost bzw. jetzt dem neuen Standard kann man viele schöne Sachen machen, Multithreading z.B. ist reltiv schnell und sicher umgesetzt.

Das fehlt bei Delphi natürlich (wie so viele Spezialbibliotheken die man nur für C/C++ zur verfügung stellt).

Zitat:

Zitat von pixfreak (Beitrag 1196673)

Ja und da ist noch die Sache, dass ich fast jede Klasse auch lokal instanziieren kann und nicht immer mit new einen neuen Speicherplatz dynamisch anfordern muss.

Ich vermiss das nicht

Zitat:

Zitat von pixfreak (Beitrag 1196673)

In Delphi gibt es da ganz schnell diese häßlichen try..finaly Verschachtelungen, wenn ich mal etwas mehr in einer Methode brauche, ok, etwas am Design verändert, kann ich das vielleicht auch vermeiden.

Ohne GC (wie bei Java) muss man halt die ganzen Variablen etwas früher en Block anlegen. Dann kommt man mit 1-2 try-finaly-Ebenen aus.

Zitat:

Zitat von pixfreak (Beitrag 1196673)

Ich persönlich mag C++ sehr gerne und kann damit auch recht gut um, ...

Ich bin froh das ich es im Berufsleben nur relativ kurz benötigt hatte und dort dann nach Delphi umstellen konnte. Der Produktiviätsgewinn gegenüber MFC/VisualC++ war gewaltig.

Zitat:

Zitat von pixfreak (Beitrag 1196673)

Persönlich fehlt mir in C++ aber die with-Anweisung, da hat Delphi was voraus ;-)

Die With-Anweisung fliegt bei uns immer raus wenn man sie trifft. Die ungewollten Fehler damit sind zu zeitaufwendig zu finden. Wenn man doch wie in VB den Punkt nicht eingespart hätte ....

Zitat:

Zitat von pixfreak (Beitrag 1196673)

Also meine Meinung: Für "Backboxen" würde ich C++ mit einem vernünftigen Compiler nehmen, kommt eine GUI dazu, dann entweder in Schichten mit verschiedenen Systemem arbeiten oder eben auf das Brot- und Wassertool Delphi ausweichen. (Um .net habe ich bis jetzt einen Bogen gemacht und Java mag ich persönlich nicht so...)

Unnötigerweise mehre IDE's und Sprachen einzusetzen kann schnell zum Scheitern eines Projektes führen. Wir hatten vor ca. 12 Jahren ein neues Projekt aufgesetzt. Zuerst hatten wir alle uns schön in .NET mit VS eingearbeitet und hatten schon soweit uns alle damit anzufreunden und es als die sinnvolle Lösung angesehen haben (Waren gemischt Delphi, MFC/VS-Entwickler und eine paar "Hardcore" C-Entwickler die primär auf Embedded-Systemen gearbeitet hatten). Jedoch gab's eine paar "superschlaue" Externe (die auch noch was zu sagen hatten) die meinten wir müssten das anders machen und auf existierende Lösungen aufsetzen wie ein auf FTP basierendes Messaging-System (Welchen Vorteil FTP hier hatte ist mir heute noch nicht klar). Es wurde dann festgelegt den einen Teil mit C umzusetzen ist(ist ja schön portierbar falls man irgendwann mal eine Port nach Linux benötigt), die Mittleware mit C++ (letztendlich ATL und MFC schön gemischt mit maximaler komplexität) und Client war dann noch offen ob .NET oder Delphi. Da wir schon einen Großteil des Vorteils einer einheitlichen Umgebung aufgegeben hatten sind wir bei Delphi geblieben.
Bei der ersten Integrationsphase hat sich dann gezeigt wo die Probleme lagen und ich hätte jede Wette gewonnen da es mal wieder typisch vagabuntierende (String-)Zeiger auf C++-Seite waren. Hab mir dann relativ schnell einen anderen Job gesucht da es klar war das diese Lösung mit Volldampf an die Wand fährt.

[Robotiker]

Hallo,

erstmal frohe Weihnachten allen hier.

Ist wirklich ein super Forum, nette Leute, interessante Themen, sogar extra für Weihnachten wird ein Sprach-Flamewar geboten. :-D

Soll die Frage denn bedeuten "Warum den C++ Builder statt Delphi ?". Das ist eine berechtigte Frage. Die Antwort lautet sicher: Weil Emba die Kunden braucht, nur deshalb erinnert man sich an das Stiefkind im Produktportfolio.

Wenn die Frage wirklich allgemein gehalten ist, gilt sicher das Wittgenstein-Zitat "Die Grenzen meiner Sprache sind die Grenzen meiner Welt". Die Welt von C++ ist halt um so viele Anwendungsbereiche größer, als die Welt von Windows Anwendungen mit Datenbankanbindung.

[Bernhard Geyer]

Zitat:

Zitat von Robotiker (Beitrag 1196676)

..., sogar extra für Weihnachten wird ein Sprach-Flamewar geboten. :-D

Man tut was man kann :-)

Zitat:

Zitat von Robotiker (Beitrag 1196676)

Soll die Frage denn bedeuten "Warum den C++ Builder statt Delphi ?". Das ist eine berechtigte Frage. Die Antwort lautet sicher: Weil Emba die Kunden braucht, nur deshalb erinnert man sich an das Stiefkind im Produktportfolio.

Nachdem sich Borland/Codegear/Emba aus dem Java-IDE-Bereich zurückgezogen hat (letzte Version JBuilder® 2008 R2 wäre es blamabel als IDE-Hersteller auch noch C++ aufzugeben. Vor allem wen man schon eine Multisprach-IDE entwickelt hat.

[hoika]

Hallo,

weil heutzutage leider viele Programme in C++ entwickelt sind.
Nachwuchs in den Unis ist dank fehlender freier Compiler
(Lazarus zählt nicht) nicht zu erwarten.
Und wenn es keinen Nachwuchs gibt,
gibt es keine neuen Projekte mit Delphi.

Eine zweite Sache sind die vielen zu pflegenden Projekte in C++.
Als Maintenance-Entwickler (ein schönes Wort) werden C++-Programmierer gesucht.


Heiko

[Popov]

Zitat:

Zitat von stahli (Beitrag 1196654)

warum C++ statt Delphi?

Die Frage ist Gleiche wie - warum MS DOS statt DR DOS, VHS statt Video 2000, Bluray statt HD DVD, Hans statt Klaus, Moni statt Bigi? Weil es mal zum richtigen Zeitpunkt da war und irgendwann die kritische Masse von Leuten erreicht wurde, die drauf setzten.

[Robotiker]

Zitat:

Zitat von hoika (Beitrag 1196678)

Und wenn es keinen Nachwuchs gibt,
gibt es keine neuen Projekte mit Delphi.

Die Altersverteilung der Programmierer ist in der Tat bei C++ total anders. Vor kurzem habe ich ein Video von einem Vortrag auf einer amerikanischen C++ Konferenz gesehen, leider finde ich die Quelle nicht mehr (es war entweder von der C++ now, oder der Going Native), da wurde die Auswertung des Alters der Teilnehmer gezeigt.

Die Verteilung hatte zwei "Kamelhöcker", einen der älteren C++ Programmierer von Ende 30 bis Mitte 50, aber einen höheren vorderen Höcker von Anfang bis Ende 20. Dazwischen die "Java Lücke".

Diese junge Generation fehlt Pascal ziemlich vollständig. (Was erklären dürfte, warum David I jetzt C++ Weihnachstsgedichte posten muss.)

Wenn ich in der Firma nur das Wort Delphi erwähne, ernte ich böse Kommentare von den jüngeren, a la "Das hatte ich in der Schule, das ist voll Sch....".

[cookie22]

Über kurz oder lang wird Delphi am fehlenden Nachwuchs kaputt gehen. Schade, dass Emba nur im Hier und Jetzt lebt und nicht an die Zukunft denkt. :(

[Insider2004]

Delphi/Pascal wird immer seine Anwender haben. Fragt sich nur, wie lange es Emba schafft, die Kosten niedrig zu halten um nicht pleite zu gehen. Aber selbst wenn Emba pleite geht, die Delphi-Code-Base ist zig Millionen wert und wird dann von irgendjemanden aufgekauft und weitergeführt werden.

[Delphi-Laie]

Zitat:

Zitat von Insider2004 (Beitrag 1196656)

Allerdings ist bei One-Man-Shows Delphi die 1. Wahl, weil die Produktivität extrem hoch ist. Ich schätze mal, 1 Delphi-Programmierer ist so schnell wie 20 C/C++-Programmierer.

Das ist ja interessant bis niedlich. Was schrieb ich vor ca. einem Dreivierteljahr hier?

[Bernhard Geyer]

Zitat:

Zitat von cookie22 (Beitrag 1196684)

Über kurz oder lang wird Delphi am fehlenden Nachwuchs kaputt gehen.

Der Nachwuchs aus den Unis ist zweitrangig. Ein fähiger .NET oder Java-Entwickler wird sich relativ problemlos (nach Einarbeitungszeit) auch in Delphi zurecht finden. Schwerwiegender ist die Fehlenden Plattformunabhängigkeit. Welche Applictionserver werden aktuell von Delphi unterstützt? Auf welchen Server-Betriebssystemen kann man Delphi-Lösungen laufen lassen? Welche Mobilen Plattformen werden jetzt unterstützt?

Bei der Entwicklung neuer Lösungen ist das wichtige als "Bekommen wir in 4 Wochen einen neuen Delphi-Entwickler".
Denn wenn die IDE/Programmiersprache nicht auf der nötigen Zielplattform läuft nützen dir auch 1000 Entwickler nix (außer sie entwicklen die IDE+Framework)

Zitat:

Zitat von cookie22 (Beitrag 1196684)

Schade, dass Emba nur im Hier und Jetzt lebt und nicht an die Zukunft denkt. :(

Zu Bor-Code-Emba hat zu Delphi (fast) immer auch der C++-Compiler dazu gehört.

[Robotiker]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1196688)

Zu Bor-Code-Emba hat zu Delphi (fast) immer auch der C++-Compiler dazu gehört.

Die Delphi Community sollte auch heute auf den Erfolg des neuen C++ Compilers hoffen, er dürfte die wichtigste Möglichkeit sein, die Kundenbasis zu vergrößern.

Im Moment wirkt das alles wie bei Delphi 2006, da haben sie die C++ Version auch verspätet nachgereicht. Nun war diese Version (in beiden Sprachen) kein Qualitätswunder. Aber danach kam 2007, das war sicher ein wichtiger Meilenstein in der Delphi- und C++ Builder-Entwicklung. In soweit bin ich optimistisch für XE4 und hab mir XE3 erstmal gespart.

[Insider2004]

Gerade eben ist der neue 64-bit-C++-Compiler rausgekommen. Von daher kann man nicht sagen, sie würden nichts tun. Der Codegenerator ist auf dem neuesten Stand und erzeugt besseren Code als alle anderen von Emba. In den nächsten Jahren soll dann eine neue modernisierte Delphi-Sprache kommen.

[Memnarch]

Zitat:

Zitat von Aphton (Beitrag 1196672)

Ich kenn mich mit Java noch nicht so gut aus (muss es jedoch wegen Uni lernen >/), aber man kann angeblich Codebereiche definieren, die zur Laufzeit nicht interpretiert sondern richtig kompiliert und ausgeführt werden.
Das hat sicher nen Namen, mag es mir jemand verraten? ^_^
Habs, JIT

Falsch(Huch..sind da meine Lehrer an der Berufsschule mal mehr up2date o.O?!)
In Java(Zumindest auf den gängigen Platformen Win/Linux/Mac) wird der KOMPLETTE JavaBytecode per Jitcompiler zur laufzeit auf den Prozessor compiliert. Interpretiert wird da gar nichts mehr ;).

Java ist schon wirklich sehr schnell geworden. Das einzige was hier noch performance killen KÖNNTE wäre dieser Java-Wahn der zigfachen verschachtelten Abstraktion bevor auch nur ein hauch von Implementierung zu erkennen ist. Das ist so ziemlich das einzige was mich an Java tierisch nervt!

[Aphton]

Zitat:

Zitat von Memnarch (Beitrag 1196728)

Zitat:

Zitat von Aphton (Beitrag 1196672)

Ich kenn mich mit Java noch nicht so gut aus (muss es jedoch wegen Uni lernen >/), aber man kann angeblich Codebereiche definieren, die zur Laufzeit nicht interpretiert sondern richtig kompiliert und ausgeführt werden.
Das hat sicher nen Namen, mag es mir jemand verraten? ^_^
Habs, JIT

Falsch(Huch..sind da meine Lehrer an der Berufsschule mal mehr up2date o.O?!)
In Java(Zumindest auf den gängigen Platformen Win/Linux/Mac) wird der KOMPLETTE JavaBytecode per Jitcompiler zur laufzeit auf den Prozessor compiliert. Interpretiert wird da gar nichts mehr ;)

Uhm, joa, ich habs mir ja nur ergoogelt bzw. bei Wikipedia nachgelesen.
Ich wusste nicht, dass das der Fall war, also dass alles kompiliert anstatt interpretiert wird. Hmmm.

[Insider2004]

Ich mag Programmiersprachen, wo genau das da steht, was dann auch gemacht wird und man nicht erst Knoten im Hirn bekommt. C und Java zählen da wohl nicht dazu. Was bei Java unheimlich nervt sind die grossen Einrückungen und die unübersichtlichen Klassendeklarationen. Bei C sind es die Trennnung von .h und .c. Man hat alles doppelt und man weiss nie, wo man zuerst nachschauen muss.

[Furtbichler]

Zitat:

Zitat von Insider2004 (Beitrag 1196742)

Was bei Java unheimlich nervt sind die grossen Einrückungen und die unübersichtlichen Klassendeklarationen.

Das beweist deine außerordentliche Fachkenntnis und Erfahrung (ebenso, wie der Quatsch mit der höheren Produktivität von Delphi-Programmierern).
Also:
1. "große Einrückungen" sind keine Eigenschaft der Sprache, sondern des Programmierers bzw. der verwendeten Code Formatting Convention.
In Delphi benötigt man nach gängiger Praxis 2x2 Einrückungseinheiten, schau mal:

Delphi-Quellcode:

if foo then
  begin
    bar;
  end

Java dagegen nur 2 (gängige Praxis)

Code:

if( foo ) {
  bar();
}

Also, wenn Du schon so argumentierst, dann müsstest Du ja bei Delphi kotzen...

2. "unübersichtliche Klassendeklarationen" sind Geschmacksache und (vor allen Dingen) eine Sache der Gewohnheit. Also bei C/C++ gebe ich Dir Recht, aber bei Java nicht.

[Chemiker]

Hallo,

ich finde C++/ C und Delphi sind zwei tolle Sprachen.

Man muss mit C++ etwas mehr Kommentare schreiben und sollte auch nicht die Lesbarkeit bis zum Letzten ausreizen und produktiv kann man genauso wie in Delphi sein, da gibt es eigentlich nicht einen so großen Unterschied.

Bis bald Chemiker

[Insider2004]

Deine Beispiele Zeigen mir, dass du das Thema voll erfasst hast.

Zitat:

Zitat von Furtbichler (Beitrag 1196768)

Zitat:

Zitat von Insider2004 (Beitrag 1196742)

Was bei Java unheimlich nervt sind die grossen Einrückungen und die unübersichtlichen Klassendeklarationen.

Das beweist deine außerordentliche Fachkenntnis und Erfahrung (ebenso, wie der Quatsch mit der höheren Produktivität von Delphi-Programmierern).
Also:
1. "große Einrückungen" sind keine Eigenschaft der Sprache, sondern des Programmierers bzw. der verwendeten Code Formatting Convention.
In Delphi benötigt man nach gängiger Praxis 2x2 Einrückungseinheiten, schau mal:

Delphi-Quellcode:

if foo then
  begin
    bar;
  end

Java dagegen nur 2 (gängige Praxis)

Code:

if( foo ) {
  bar();
}

Also, wenn Du schon so argumentierst, dann müsstest Du ja bei Delphi kotzen...

2. "unübersichtliche Klassendeklarationen" sind Geschmacksache und (vor allen Dingen) eine Sache der Gewohnheit. Also bei C/C++ gebe ich Dir Recht, aber bei Java nicht.

[Bernhard Geyer]

[QUOTE=Furtbichler;1196768]Also:
1. "große Einrückungen" sind keine Eigenschaft der Sprache, sondern des Programmierers bzw. der verwendeten Code Formatting Convention.
In Delphi benötigt man nach gängiger Praxis 2x2 Einrückungseinheiten, schau mal:

Delphi-Quellcode:

if foo then
  begin
    bar;
  end

Java dagegen nur 2 (gängige Praxis)

Code:

if( foo ) {
  bar();
}

Also, wenn Du schon so argumentierst, dann müsstest Du ja bei Delphi kotzen...

Also wir (und der größte Teil der VCL-Sourcen verwendet hier nur eine Einrückung
In Delphi benötigt man nach gängiger Praxis 2x2 Einrückungseinheiten, schau mal:

Delphi-Quellcode:

if foo then
begin
  bar;
end

und bei Java/C++ kann man genau so 2* einrücken:

Code:

if( foo )
  {
    bar();
  }

Also 1:1 zwischen den Sprachen :-)

Zitat:

Zitat von Furtbichler (Beitrag 1196768)

2. "unübersichtliche Klassendeklarationen" sind Geschmacksache und (vor allen Dingen) eine Sache der Gewohnheit. Also bei C/C++ gebe ich Dir Recht, aber bei Java nicht.

Dort wo es unpraktisch/eine Sackgase beschritten wurde wude ja bii .NET und Java schon mindestens eine Redesign duchgeführt.

[cookie22]

Code:

if( foo ) {
  bar();
}

Halte ich für wesentlich schlechter lesbar als.

Code:

if( foo )
  {
    bar();
  }

[Furtbichler]

Mir egal, ich habe mir zwei der Codestandards von Java angeschaut, u.a. bei Wiki. Und ich persönlich halte

Code:

if (foo)
{
  bar();
}

für noch besser, denn wozu ein '{' einrücken?. So wird es mir im VS für C# angeboten, zumindest mit meinem Refactoring-Tool.

Aber das ist eh alles nebensächlich, denn wenn Du '{' und '}' mit 'begin' und 'end' ersetzt, kommt eh das Gleiche heraus. Ich wollte damit nur sagen, das eine Sprache nichts mit der Art und Weise gemein hat, wie Programmierer sie anordnen.

[Bernhard Geyer]

Zitat:

Zitat von Furtbichler (Beitrag 1196783)

Aber das ist eh alles nebensächlich, denn wenn Du '{' und '}' mit 'begin' und 'end' ersetzt, ...

Hatte nicht mal jemand gepostet das dies in einer Firma so gemacht wurde. Und zwar begin/end in C/C++ verwendet?

[Furtbichler]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1196786)

Zitat:

Zitat von Furtbichler (Beitrag 1196783)

Aber das ist eh alles nebensächlich, denn wenn Du '{' und '}' mit 'begin' und 'end' ersetzt, ...

Hatte nicht mal jemand gepostet das dies in einer Firma so gemacht wurde. Und zwar begin/end in C/C++ verwendet?

Super! Dann besteht ja kein Unterschied mehr zwischen C,C++,C#,Java und Delphi!

Zitat:

Die Qualität einer Programmiersprache ist meßbar und verhält sich proportional zum Quotienten aus der Anzahl der Buchstaben zu der Anzahl der Sonderzeichen.

:wall:

[p80286]

Lest doch mal die letzten Beiträge....
Wenn die einzigen Unterschiede zwischen den Sprachen in der Art der Kommentierung, der Schleifenbegrenzung und der Menge der Sonderzeichen liegt, dann ist es wirklich schnurzpiepegal welche Sprache man nutzt.
ich persöhnlich bevorzuge übrigens

Delphi-Quellcode:

if something then begin
  donothing
end;

egal ob mit geschweiften Klammern oder Langtext.
Wichtig ist letztlich, ob die Sprache einem liegt, genügend Bibliotheken für die gewünschte Funktionalität vorhanden sind und der Compiler schnell genug ist.

Gruß
K-H

[Pentium 80486]

Zitat:

Wenn ich in der Firma nur das Wort Delphi erwähne, ernte ich böse Kommentare von den jüngeren, a la "Das hatte ich in der Schule, das ist voll Sch....".

Ich möchte gerne etwas zu "Das hatte ich in der Schule, ..." sagen:

Ich kenne ein Gymnasium, an welchem ebenfalls Delphi unterrichtet wird. Den Schülern, ~10/11 Klasse, werden bereits nach nur wenigen Schulstunden unlösbare Aufgaben aufgetragen.
So sollen sie z.B. bereits nach nur einer Unterrichtsstunde ein vollfunktionsfähiges Lottoprogramm erstellen - und das für die nächste Unterrichtsstunde!

Wie bitte sollen die Schüler nach nur einer Unterrichtsstunde, wo man gerade erst die BASICs kennenlernt, ein Lottoprogramm erstellen?

Zudem ist der "Delphi-Lehrer" an diesem Gymnasium einfach nur "ein Lehrer", welcher "irgendwann mal" einen kurzen Lehrgang zur Programmiersprache Delphi gemacht hat.

Kein Wunder, dass die jungen Damen und Herren alle rummeckern, sobald sie das Wort "Delphi" hören.



Die Programmiersprache Delphi sollte mehr respektiert werden!
Es ist eine wunderbare, einfach zu erlernende und sehr mächtige Programmiersprache - sie hat Respekt, und keine "Schimpfe" verdient.


An Schulen sollte viel eher LaTeX, Basic oder, wenn selbst das zu "schwer" ist, die Programmierumgebung "Robot Karol" verwendet werden.

[bytecook]

Zitat:

Zitat von p80286 (Beitrag 1196826)

Lest doch mal die letzten Beiträge....
Wenn die einzigen Unterschiede zwischen den Sprachen in der Art der Kommentierung, der Schleifenbegrenzung und der Menge der Sonderzeichen liegt, dann ist es wirklich schnurzpiepegal welche Sprache man nutzt.
ich persöhnlich bevorzuge übrigens

Delphi-Quellcode:

if something then begin
  donothing
end;

egal ob mit geschweiften Klammern oder Langtext.
Wichtig ist letztlich, ob die Sprache einem liegt, genügend Bibliotheken für die gewünschte Funktionalität vorhanden sind und der Compiler schnell genug ist.

Gruß
K-H

a) Wir sind formatkompatibel :) (Halte das so seit TP for Windows ...)
b) bin gleicher Meinung...
c) Manchmal muss man halt auch auf andere Sprachen zurückgreifen [Beispiel Win CE 6/7 => VS 2005/2008/2012 for Embedded]

[musicman56]

Hallo,

vorab, ich bin Einzelkämpfer und verwende nichts anderes als Delphi. Ein guter Kumpel, ebenfalls Einzelkämpfer, schreibt überwiegend mit C++. Wenn wir uns ab und zu mal austauschen, dann kommen wir fast immer zum gleichen Ergebnis: Er ist neidisch, wie schnell/produktiv ich im Vergleich zu ihm bin. Wir programmieren beide überwiegend Datenbank-Anwendungen und da sehe ich Delphi klar im Vorteil. In anderen Bereichen mag es auch ganz anders aussehen. Darum hab ich mich damals bei der Emba-Übernahme auch gefreut und gehofft, dass sich Delphi langfristig gut weiter entwickeln wird.

Worüber ich mir bei Delphi aber Sorgen mache ist, dass das Gesamtprodukt immer mehr Fehler aufweist, welche die Produktivität enorm belasten. Was nützen mir neue Funktionen die ich eh nur wenig oder gar nicht benutze, wenn die Basics nicht mehr richtig funktionieren. Die Fehlersuche kostet mich jetzt mit XE2 fast die doppelte Zeit wie mit 2007. Um dann immer öfter festzustellen, dass irgendwas in XE2 nicht klappt. Mit 2007 war das noch anders, da konnte ich mich darauf konzentrieren, meine eigenen Bugs zu suchen und zu finden.

Wenn das Emba nicht in den Griff kriegt, ist der Vorteil der höheren Produktivität bald dahin. Dann sehe ich auch schwarz um den Nachwuchs.

[cookie22]

Zitat:

Zitat von musicman56 (Beitrag 1198403)

Dann sehe ich auch schwarz um den Nachwuchs.

Warum sollte auch irgendein Anfänger oder irgendeine Schule auch nur auf die Idee kommen, Delphi zu benutzen, wenn man doch so gut wie jede andere Sprache völlig kostenlos bekommt? So lange Emba hier nicht seine Arroganz ablegt und sich von völlig antiquierten Marketingkonzepten trennt, geht Delphi über kurz oder lang den Bach herunter. :(

VC++ ist auf jeden Fall um ein vielfaches Zukunftssicherer als Delphi. Eigentlich sehr schade.