Die 2 besten Programmiersprachen sind IMO Python und D

[DocJunioR]

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

[XYZabc123]

D ist total irrelevant und wird es auch immer bleiben.
Python ist einfach nur hässlich.

[Shade Of Mine]

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...

[asc]

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++.

[long long double]

XYZabc123 schrieb:

Python ist einfach nur hässlich.

Eigentlich ist Ästhetik einer der Gründe, warum ich Python nutze.

[tfa]

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.

[Shade Of Mine]

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.

[tfa]

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.

[Elektronix]

*Oh Herr, befreie uns von diesen sich ewig wiederholenden und im Kreis drehenden "Welche-Programmsprache-ist-die-beste?"-Threads*

[__Stefan__]

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);

[rüdiger]

zu D.

[.filmor]

tfa schrieb:

* 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.

Programmier mal etwas länger Python, dann wirst du die Eleganz erkennen
Das Objektmodell ist halt etwas völlig anderes als in C++.

tfa schrieb:

* keine Sichtbarkeitsmodifier. Statt dessen Missbrauch von Unterstrichen in Methodennamen. *Würg*

Missbrauch? Ich find's ehrlich gesagt klasse, dass Python stark auf Konvention setzt. Denn die kann man, wenn man wirklich gute Gründe hat umgehen, bei Sprachmitteln geht das nicht.

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*!)

Wie oben schon geschrieben, das __len__ ist eine Konvention. So etwas ähnliches gibt's zB auch für pickle.

Ducktyping ftw \o/

Da ich in D nicht so firm bin btw Python + C++ auch in dieser Priorität (am Besten mit Boost.Python verknüpft)

[tfa]

.filmor schrieb:

tfa schrieb:

* 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.

Programmier mal etwas länger Python, dann wirst du die Eleganz erkennen
Das Objektmodell ist halt etwas völlig anderes als in C++.

Wer will schon C++? Schau dir mal Ruby an! Das ist eine elegante OO-Sprache ohne Holpereien.

tfa schrieb:

* keine Sichtbarkeitsmodifier. Statt dessen Missbrauch von Unterstrichen in Methodennamen. *Würg*

Missbrauch? Ich find's ehrlich gesagt klasse, dass Python stark auf Konvention setzt. Denn die kann man, wenn man wirklich gute Gründe hat umgehen, bei Sprachmitteln geht das nicht.

Man kann sie auch umgehen, wenn man schlechte Gründe hat -- oder (schlimmer noch) nur glaubt gute Gründe zu haben, ohne zu wissen, was man anrichtet.
Solch wichtige Features gehören in die Sprache.
Auf diese Weise lassen sich die Modifier auch verändern, z.B. eine Klasse import per Mixin ein Modul, das einige Methoden als protected deklariert anbietet. Diese Klasse möchte nun Methoden veröffentlichen. Geht das mit Methodennamenkonvention?

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*!)

Wie oben schon geschrieben, das __len__ ist eine Konvention. So etwas ähnliches gibt's zB auch für pickle.

Ducktyping ftw \o/

Ja, und wo ist der Vorteil? Gerade bei Ducktyping ist sowas überflüssig.

[Helium]

rüdiger schrieb:

zu D.

Was'n scheiß. Es gibt ja viele interessante und sinvolle Dinge was Typsysteme angeht, aber ... na egal, lassen wir das.

[groovemaster]

Frage zu D schrieb:

long long double schrieb:

Abgesehen von D kann ich dem nur zustimmen.

Was spricht gegen D?

Gegenfrage: Was spricht für D?

[Das stimmt nicht]

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

Das ist natürlich gelogen, denn es gibt Pinsel an denen man sich verletzen kann,
wenn man sie an der falschen Stelle anfaßt.
Z.B. gibt es Pinsel mit Holzgriff, und einige davon sind schlecht gehobelt, d.h.
man kann sich da ganz schnell einen Spreißel einfangen.
Das entspricht C++.

Dann gibt es Pinsel die sind sehr gut gehobelt, lackiert und sehr gut
in einer Lackschickt eingebunden, daß man sich dort einen Spreißel holt ist
so gut wie ausgeschlossen.
Das ist z.B. D, Java und Ada.

[dffghj]

Elektronix schrieb:

*Oh Herr, befreie uns von diesen sich ewig wiederholenden und im Kreis drehenden "Welche-Programmsprache-ist-die-beste?"-Threads*

D un Python hatten wir noch nicht.

Die Klassiker sind:
C v. C++
Pascal vs. C++
Ada vs. C++
und
Java vs C++.

D ist aber Recht neu und Python hat seinen Siegeszug auch erst so langsam.
Das verkorkste PHP dominiert ja leider immer noch.

[asc]

Das stimmt nicht schrieb:

Das ist natürlich gelogen, denn es gibt Pinsel an denen man sich verletzen kann,
wenn man sie an der falschen Stelle anfaßt.
Z.B. gibt es Pinsel mit Holzgriff, und einige davon sind schlecht gehobelt, d.h.
man kann sich da ganz schnell einen Spreißel einfangen.
Das entspricht C++.

Dann gibt es Pinsel die sind sehr gut gehobelt, lackiert und sehr gut
in einer Lackschickt eingebunden, daß man sich dort einen Spreißel holt ist
so gut wie ausgeschlossen.
Das ist z.B. D, Java und Ada.

Und meist hat man das Gefühl das man bei letzteren immer noch irgendwo ein Bleigewicht ist, oder man bekommt einfach mehr als man für den Einzelfall wirklich braucht (Pinsel mit Teleskopstange, eingebauten Radio und Toaster...).

Die Programmiersprache ist wirklich immer so gut wie man sie einsetzt und für was man sie einsetzt. Der vergleich mit einem schlecht gehobelten Holzgriff mit der gefahr von Splittern bei C++ ist auch verkehrt. Besser wäre zu sagen das der Griff spitz zuläuft und - wenn man nicht aufpasst - sich daran verletzen kann. Das von dir geschriebene Impleziert eigentlich das man mit C++ keinen Sauberen und Fehlerfreien Code schreiben kann, aber dies kann man mit jeder Sprache - es erfordert nur entsprechende Übung. Die einen Sprachen machen es einfacher (meist auf Kosten von anderen Punkten), die anderen nicht, aber erlauben es auch.

Mein Fazit: Es gibt keine besseren und schlechteren Sprachen, sondern nur Sprachen die in einen konkreten Fall besser oder schlechter geeignet sind und ggf. mehr oder weniger große Anforderungen an den Entwickler stellen.

cu André

[Sprachfanatiker]

Disclaimer: Ich bin keine Sprachfanatiker.

Python ist ja wohl die hässlichste Sprache die es auf Gottes Erde gibt. Da sollte man die Energie lieber in eine schöne Sprache wie Ruby stecken um der mal einen hochoptimierten JIT-Compiler zu spendieren.

Ruby ist die Sprache der Zukunft

@Shade für Textmanipulation benutze ich immer Asm, gibt einfach nichts besseres dafür

[long long double]

Sprachfanatiker schrieb:

Python ist ja wohl die hässlichste Sprache die es auf Gottes Erde gibt.

These - Argument - Beispiel.

asc schrieb:

Mein Fazit: Es gibt keine besseren und schlechteren Sprachen, sondern nur Sprachen die in einen konkreten Fall besser oder schlechter geeignet sind und ggf. mehr oder weniger große Anforderungen an den Entwickler stellen.

Amen.