Welche Sprache

[asc]

tfa schrieb:

Das meinte ich nicht mit aufgeblasen, sondern die Sprachen selbst. Die Downloadgröße ist völlig egal.

Dann führ das bitte mehr aus. Meine Javakenntnisse sind leider nicht auf dem aktuellen Stand, um einen fairen Vergleich zu machen - zumindest auf den Stand von Java 1.4 sehe ich hier nicht wirklich einen großen Unterschied.

[tfa]

Was willst du denn hören? Eine Liste der Features, die Java nicht hat im Gegensatz zu C#?

[asc]

tfa schrieb:

Was willst du denn hören? Eine Liste der Features, die Java nicht hat im Gegensatz zu C#?

Nein, sondern welches Feature den fälschlich in C# eingeführt wurde (Sowohl Java als auch .Net haben versucht eine mächtige Bibliothek zur Verfügung zu stellen, schlagen imho daher in die selbe Quelle).

[tfa]

Z.B.: Structs, implizite Type Conversions, Indexers, Operatorüberladung (selten sinnvoll, oft gefährlich), LINQ, "unsafe"

Sachen, die in Java fehlen: Reifed Generics, ARM-Blöcke
Sachen, die in Java überflüssig sind: checked Exceptions
Bei Closures bin ich mir nicht sicher, wie ich sie (in einer statisch typisierten Sprache) finden soll.

(Sowohl Java als auch .Net haben versucht eine mächtige Bibliothek zur Verfügung zu stellen, schlagen imho daher in die selbe Quelle).

Sprache!=Bibliothek. In Sachen Bibliotheken gibt es nicht viel, was ansatzweise an Java heranreicht. Aber darum geht es nicht.

[berniebutt]

@Bashar: Dann hast Du in dieser Zeit noch nicht programmieren müssen. ALGOL war sogar besser als FORTRAN, nur leider aus Europa, nicht aus USA. Ich finde überall die wesentlichen Grundlagen der Programmierung auch heute noch wieder. Meine heutige Wahl ist C++. Das wollte ich dem Fragesteller sagen.

[Bashar]

berniebutt schrieb:

@Bashar: Dann hast Du in dieser Zeit noch nicht programmieren müssen. ALGOL war sogar besser als FORTRAN, nur leider aus Europa, nicht aus USA.

Ich meinte das nicht ironisch. Kernighan und Ritchie kamen nicht von Assembler, sondern standen wie viele andere auf den Schultern von Riesen, im Falle von C sind die Vorgänger B und BCPL. Und ALGOL ist natürlich der Stammvater aller modernen blockstrukturierten Sprachen.
Es hörte sich bei dir so an als gäbe es nur FORTRAN und dann hat jemand mit C etwas völlig neues geschaffen, worauf die FORTRAN-Programmierer alle umgestiegen sind.

[muemmel]

Hi,

schau Dir auf alle Fälle auch mal Delphi an, für einen reinen Hobbyprogrammierer der eventuell nebenbei mal was für sienen Job programmieren will ist das aus meiner Sicht nicht die schlechteste Alternative und man hat mit der dazu gehörenden mitgelieferten VCL ein recht mächtiges Werkzeug für Oberflächen und Datenbankanbindung dabei.

Gruß Mümmel

[Shade Of Mine]

muemmel schrieb:

schau Dir auf alle Fälle auch mal Delphi an, für einen reinen Hobbyprogrammierer der eventuell nebenbei mal was für sienen Job programmieren will ist das aus meiner Sicht nicht die schlechteste Alternative und man hat mit der dazu gehörenden mitgelieferten VCL ein recht mächtiges Werkzeug für Oberflächen und Datenbankanbindung dabei.

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

[Skalli]

Hach, wunderbar dieser Thread.
Programmiersprachen sind, wie so viele Dinge, auch eine Glaubensfrage. Es lässt sich objektiv enorm schwer einschätzen was wirklich "besser" ist. Die meisten Sprachen haben Vor- und Nachteile und sind somit, für jeweils andere Zwecke, besser oder schlechter geeignet.
Mein ganz persönliche Meinung:
Visual Basic: Sehr leicht zu lernen und zu benutzen, man erziehlt schnelle Erfolge, habe ich aber seit VB 5 und 6 nicht mehr benutzt. (Habe mit 3.0 angefangen).

Java: Mag ich garnicht. Nein, Java ist NICHT schlecht, ich mag es einfach nicht. Es ist ziemlich sicher und man kann wenig falsch machen. Recht leicht zu lernen da rein Objekt Orientiert (zumindest 95%). ^^
Ich mag Java nicht, da es einfach vieeeeeeel zu langsam ist. Ausserdem ist es schwer damit tief in Systeme einzugreifen. Vieles, das im Hintergrund passiert, ist nicht greifbar.

C: Mag ich sehr gerne, leider nicht Objekt Orientiert... ^^ Stroustup sagte es ist sehr leicht sich damit in den Füß zu schießen... ^^

C++: Mein Favorit! Sehr Hardwarenah, klasse Performance, es ist schwerer sich in den Fuß zu schießen, aber wenn man es schafft, reißt es einem das ganze Bein ab (Stroustrup). Unterstützt OOP, Strukturiertes Programmieren, Event gesteuertes Programmieren, etc...
Aber: Man sollte wissen was man tut!

C#: Ich war so doof diese Sprache zu verurteilen bevor ich gezwungen war sie zu benutzen (Man hat leider nicht immer die freie Wahl der Programmiersprache bei Projekten...). Was soll ich sagen: Java recht ähnlich, ich hab es trotzdem sehr lieb gewonnen. Macht es trotz allem recht einfach Hardwarenah zu gehen. Sehr leicht zu lernen und zu benutzen und auch gut dokumentiert. Eignet sich bedingt für Spiele dank ManagedDX (wird aber wohl nicht weiter unterstützt in Zukunft). Der allergrößte Nachteil ist imho das es sich zu schnell Entwickelt! Ja, richtig gelesen. Kaum hat sich eine Technologie etabliert, .NET 3.5, da kommt schon die nächste. Ich möchte nicht wissen wie viele gerade mal .NET 2.0 installiert haben.

Einfach toll, leider kaum verbreitet, ich hoffe die Sprache findet viel mehr Anklang. Vereint die Vorteile von C#, C, C++, Java etc... Anschauen lohnt sich gewiss!

Assembler: Macht unheimlich viel Spass und hat den "Aufregungsfaktor". Das liegt wohl auch daran, dass ein Professor, den ich hatte, immer davor gewarnt hat, wie leicht man sein Betriebssystem unbrauchbar machen und Hardware (ältere Hardware, neuere hat meistens Sicherheitsfunktionen) zerstören kann. (Einer hat einen Röhrenmonitor im Labor zerlegt in dem er einen "unpraktischen" Wert für die Hz Zahl eingeben hat...)
Programmiert habe ich hier x86 und HC12. Alleine das zusammenbauen eines Mainboards für den Prozessor und das Gestalten und Bauen einer Aufsteckplatine hat unheimlich viel Spass gemacht! Wer gerne Lötkolben nutzt hat hier sein wahre Freude! Man MUSS wissen was man tut!!!

PHP (HTML) : Spassig, ich habe sogar mal einen IRC Bot in PHP geschrieben. Tolle Sprache für Serverseitige Webandwenungen, bedingt auch für Clientseitige Programme geeignet (ohne Verbindungs zum Server, Standalone (wie der IRC Bot)). Auch besser als ich erst dachte, aber hat viele Lücken und Probleme...

Ganz ohne Sprache programmieren: Hehe, es geht... macht aber wenig Spass, und ist sehr unpraktisch und gefährlich. Um mit einem Hex Editor Programme schreiben braucht auch viel Erfahrung mit Assembler, aber einmal vertippt und man hat was kaputt gemacht. Vorteil und Nachteil: Man braucht keinen Compiler

Esotherische Sprachen (Brainfuck, Java2k): *kicher* Spassig, aber unheimlich unpraktisch. Nach meinem Versuch mit Java2k ein "Hello World" zu schreiben habe ich nach "Hel" (mit 96%iger Wahrscheinlichkeit) aufgegeben. Ich hab den Überblick verloren und in einem Quellcode, ohne Zeilenangaben, der kaum lesbar ist bringt die Fehlermeldung "SYNTAX ERROR SOMEWHERE" garnix.

Wenn man eine Sprache gelernt hat und halbwegs beherrscht ist es kein Problem eine andere auch zu lernen da die Grundlagen alle gleich sind. Je mehr man jedoch eine Sprache nutzt, desto besser wird man in ihr. Man lernt dann die ganzen tollen Tricks und Kniffe kennen.

Anhang ^^ :
"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off." - Bjarne Stroustrup

Links:
http://www.digimars.com/d/index.html
Java2k: http://de.wikipedia.org/wiki/Java2K

Das sollte erstmal reichen

[audacia]

Shade Of Mine schrieb:

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

Da gibt es viele gute Gründe.

• 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.
• 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.
• Bessere COM-Unterstützung. Das meiste (implizite Speicherverwaltung, safecall, Dispinterfaces) unterstützt C# auch, aber implements, indizierte Properties und dynamische Methodenaufrufe gibt es noch immer nur in Delphi. (Immerhin will Microsoft die letzten beiden in C# 4.0 als "Innovation" einführen. )
• resourcestring.
• 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.

• Gegenüber Java: Delphi unterstützt nichtvirtuelle Methoden, call by reference, Operatorenüberladung für Werttypen (record), objektgebundene Methodenzeiger und Closures.
• Verschachtelte Funktionen. Das schränkt den Sichtbarkeitsbereich kleiner Helferfunktionen ein und dient außerdem als äußerst effizienter Closure-Ersatz.
• 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.
• 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.
• 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
• 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).
• DFM-Dateien. WinForms benötigt Hacks wie Regions und partielle Klassen, damit man sich im Code überhaupt zurechtfindet.

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