Die 2 besten Programmiersprachen sind IMO Python und D

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

[muemmel]

Hi,

wie gut oder elegant etwas programmiert ist liegt immer an dem ders programmiert. Ein alter eingeschworener Fortran-Programmierer wird in JEDER Sprache Fortran-Programme schreiben, und ein überzeugter Cobol-Programmierer macht aus allem ein Cobol-Programm.
Gegen wirr im Kopf helfen auch Java und Ada nicht, sondern höchstens gegen Vergesserchen und Verschreiberchen.

Gruß Mümmel

[Shade Of Mine]

muemmel schrieb:

wie gut oder elegant etwas programmiert ist liegt immer an dem ders programmiert. Ein alter eingeschworener Fortran-Programmierer wird in JEDER Sprache Fortran-Programme schreiben, und ein überzeugter Cobol-Programmierer macht aus allem ein Cobol-Programm.
Gegen wirr im Kopf helfen auch Java und Ada nicht, sondern höchstens gegen Vergesserchen und Verschreiberchen.

Und genau das ist so falsch dass es zum himmel schreit. Warum denken immer alle Leute dass das so ist? Warum ist der Programmierer das essentielle?

Wenn ich einen voll koffer einen Auftrag gebe, wird er ihn vergeigen. Punkt aus.

Das interessante aber ist, wenn wir nicht von Vollkoffern reden, sondern vom durchschnitt.

Das ganze ist überall anzutreffen wo sich Menschen duellieren (zB bei online spielen oder hier (wer den größeren e-penis hat)). das relevante beim programmieren ist die tool chain. wenn ich 2 gleichgute programmierer hinsetze wird der produktiver sein der die besseren tools hat. ergo: die tools sind wichtig.

gute programmierer erkennen das und nutzen es zu ihrem vorteil: da wenn sie nicht aufpassen jemand der schlechter ist vielleicht produktiver arbeiten kann wenn er die besseren tools hat. deshalb ist es immer essentiell vor dem projektstart die tools festzulegen die man verwenden will (zumindest die richtung, die einzelnen speziellen tools lassen sich dann ja auswechseln).

ich habe zB gestern ein kleines script geschrieben dass csv dateien auswertet. ich wette jemand der mit grep und bash scripten gut umgehen kann hätte statt meinen 10 minuten nur 5 gebraucht. eben weil er die produktiveren tools verwendet hätte. nur für mich persönlich war ein php script schneller, da ich da nichts nachschlagen musste und die ganze zeit runter hacken konnte. mit grep wäre es uU aber doppelt so schnell gegangen nur hätte ich erstmal 10 minuten doku lesen müssen.

wenn man das einmal verstanden hat, dann sollte einem einiges klar werden. vorallem dass, das man sich immer weiterbilden muss und ein stillstand dazu führt dass man überrundet wird.

vielleicht lernt man dann auch die tools zu schätzen mit denen man arbeiten kann und programmiert nicht in jeder sprache fortran...