Die 2 besten Programmiersprachen sind IMO Python und D
-
denn beide ergänzen sich perfekt.
D für die Systemprogrammierung
und
Python für Scripte, GUIs und Mockups
-
Abgesehen von D kann ich dem nur zustimmen.
-
Abgesehen von Python und D kann ich dem nur zustimmen.
-
long long double schrieb:
Abgesehen von D kann ich dem nur zustimmen.
Was spricht gegen D?
-
wir alle?!?
-
Skym0sh0 schrieb:
wir alle?!?
Das ist keine Begründung.
-
denn beide ergänzen sich perfekt.
C für die Systemprogrammierung
und
Asm für Scripte, GUIs und Mockups:schland: :schland: :schland: :schland:
-
IMO
die interessiert aber niemanden
-
Skym0sh0 schrieb:
wir alle?!?
Die C++ Fanboys!?!
-
Was nen Unsinn..
Ne Programmiersprache ist immer so gut, wie man sie nutzt..Ist genau wie die Frage, ob man das Haus besser mit nem roten Pinsel malen kann oder mit nem grünen
-
D ist total irrelevant und wird es auch immer bleiben.
Python ist einfach nur hässlich.
-
DocJunioR schrieb:
Was nen Unsinn..
Ne Programmiersprache ist immer so gut, wie man sie nutzt..Ist genau wie die Frage, ob man das Haus besser mit nem roten Pinsel malen kann oder mit nem grünen
nein, die toolchain ist relevant. sprich: sprache, library, compiler/interpreter, IDE,...
bsp: asm ist für simple logfile analysen einfach das falsche - egal wie man es dreht oder wendet...
-
Shade Of Mine schrieb:
nein, die toolchain ist relevant. sprich: sprache, library, compiler/interpreter, IDE,...
...persönlicher Geschmack, Kundenwünsche, Chefentscheidung, Vorhandene Literatur (Dokumentation und Bücher), ...
cu André
P.S: Ich hoffe mal das hier niemand ist der D als schön empfindet und gleichzeitig C++ als zu komplex/kryptisch bezeichnet - Dies ist jetzt keine Aussage zur Qualität von D oder C++.
-
XYZabc123 schrieb:
Python ist einfach nur hässlich.
Eigentlich ist Ästhetik einer der Gründe, warum ich Python nutze.
-
long long double schrieb:
XYZabc123 schrieb:
Python ist einfach nur hässlich.
Eigentlich ist Ästhetik einer der Gründe, warum ich Python nutze.
Alles eine Geschmacksfrage. Was mich an Python nervt:
* in Member-Methoden ständig den völlig überflüssen self-Parameter mitschleppen. Das sieht dann immer so aus, als sei OO später drübergestülpt worden.
* keine Sichtbarkeitsmodifier. Statt dessen Missbrauch von Unterstrichen in Methodennamen. *Würg*
* warum len(string) statt string.len()? Warum versteckt sich die Objektorientiertheit hinter irgendwelchen obskuren, freien Funktionen (was soll len(..) sein?). Am Ende muss man doch wieder die OO-mäßig die Methode __len__ definieren (Wieder Pflicht-Unterstriche, wieder *Würg*!)
* keine Blöcke wie in Ruby.
-
tfa schrieb:
* warum len(string) statt string.len()? Warum versteckt sich die Objektorientiertheit hinter irgendwelchen obskuren, freien Funktionen (was soll len(..) sein?). Am Ende muss man doch wieder die OO-mäßig die Methode __len__ definieren (Wieder Pflicht-Unterstriche, wieder *Würg*!)
unterstriche sucken - aber len(str) ist soviel besser als str.len() da man dadurch ein hauptproblem der oop sehr schön angeht: erweiterbarkeit der funktionalität einer klasse. da ist python einfach top. objective-c bietet hier zB categories aber der python ansatz ist einfach am saubersten.
-
Shade Of Mine schrieb:
tfa schrieb:
* warum len(string) statt string.len()? Warum versteckt sich die Objektorientiertheit hinter irgendwelchen obskuren, freien Funktionen (was soll len(..) sein?). Am Ende muss man doch wieder die OO-mäßig die Methode __len__ definieren (Wieder Pflicht-Unterstriche, wieder *Würg*!)
unterstriche sucken - aber len(str) ist soviel besser als str.len() da man dadurch ein hauptproblem der oop sehr schön angeht: erweiterbarkeit der funktionalität einer klasse. da ist python einfach top. objective-c bietet hier zB categories aber der python ansatz ist einfach am saubersten.
Diesen Mechanismus gibt es ja nur für eine handvoll Funktionen und Operatoren. Oder kann man das auch selbst definieren? Grundsätzlich wird hier also kein Problem gelöst. Schlimmer noch, es wird dadurch uneinheitlich.
Ich versteh auch nicht, was du hier mit Problem der "erweiterbarkeit der funktionalität einer klasse" meinst. In hochdynamischen OO-Skriptsprachen kannst du Klassen (sogar einzelne Objekte) und deren Methoden umdefinieren und erweitern wie du willst.
-
*Oh Herr, befreie uns von diesen sich ewig wiederholenden und im Kreis drehenden "Welche-Programmsprache-ist-die-beste?"-Threads*
-
tfa schrieb:
Shade Of Mine schrieb:
tfa schrieb:
* warum len(string) statt string.len()? Warum versteckt sich die Objektorientiertheit hinter irgendwelchen obskuren, freien Funktionen (was soll len(..) sein?). Am Ende muss man doch wieder die OO-mäßig die Methode __len__ definieren (Wieder Pflicht-Unterstriche, wieder *Würg*!)
unterstriche sucken - aber len(str) ist soviel besser als str.len() da man dadurch ein hauptproblem der oop sehr schön angeht: erweiterbarkeit der funktionalität einer klasse. da ist python einfach top. objective-c bietet hier zB categories aber der python ansatz ist einfach am saubersten.
Diesen Mechanismus gibt es ja nur für eine handvoll Funktionen und Operatoren. Oder kann man das auch selbst definieren? Grundsätzlich wird hier also kein Problem gelöst. Schlimmer noch, es wird dadurch uneinheitlich.
Ich versteh auch nicht, was du hier mit Problem der "erweiterbarkeit der funktionalität einer klasse" meinst. In hochdynamischen OO-Skriptsprachen kannst du Klassen (sogar einzelne Objekte) und deren Methoden umdefinieren und erweitern wie du willst.Wäre es nicht schön, wenn man in C++ freie Funktionen als Methode des Typs des ersten Arguments der Funktion anwenden könnte?
z.B.
vector& append(vector &a, const vector &b) { // b an a hängen //... return a; } vector a, b; a.append(b);
-
zu D.