Wie sieht eine gute Programmiersprache aus?

[groovemaster]

Spielt hier keine Rolle. Das müsstest du sowieso bei beiden Beispielen noch nachschlagen, falls dies von Interesse ist.

[Bashar]

Eben, damit ist dein Argument, es wäre verständlich, wenn man mit der Sprache nicht vertraut ist, falsch.

[Don06]

Ich würde mich nicht an so kleinen Syntaxdetails aufhängen. Eine gute Programmiersprache, im Sinn von: "Die kann ich benutzen um einfach, effiziente Programme zu schreiben", sollte imho funktional und nebenläufig sein. Zusätzlich Design-by-Contract durch simple Sprachkonstrukte effezient und brauchbar implementieren. Ich meine damit auch, dass z.B. Precondition bereits zur Compile-Zeit verifiziert werden, wenn das möglich ist.
z.B.: (C++)

std::vector<int> vec;
vec.push_back(1);
vec[-1];

Hier sollte der Compiler einen Fehler aufgrund der Verletzung der Precondition "index >= 0" melden. Ich weiß, dass ist jetzt keine funktionale Sprache, aber das sollte nur kurz erläutern, wie ich mir so etwas vorstelle. Kostrukte aus der imperativen Programmierung und sequentielle Abläufe sollten nur explizit möglich sein. Ob, und in wie weit, man OO und Generische Programmierung unterstützen soll/kann, darüber bin ich mir nicht wirklich im Klaren. Aber besonders Design-by-Contract und OO könnten sich gut vertragen.

Eine weitere Bedingung, die nicht wirklich zur Sprache zählt, ist, dass man einen vernünftigen Kompiler hat, der nativen Code erzeugen. Es sollte also eine Sprache sein mit der ich performance-kritische Anwendungen entwerfen kann und nicht irgendeine Script-Sprache.

Von dem Prinzip Design-by-Contract würde ich mir erhoffen, dass die Verifizierung von der Arbeitsweise eines Moduls zu großen Teilen vom Kompiler übernommen wird. Von dem funktionalen und nebenläufigen Aspekt, dass man die Sprache auch in Zukunft verwenden kann, wenn unsere CPUs 80+ Softwarethreads anbieten. In C++ müsste man da dann ja 80 Threads händisch erzeugen und verwalten. Die Aufgabe sollte die Laufzeitumgebung übernehmen.

Vielleicht bin ich auch einfach zu naiv, aber so eine Sprache würde mir gefallen. Besonders, wenn sie noch eine klare, einfach strukturierte Syntax hätte.

Gruß
Don06

[Badestrand]

Don06, das hört sich interessant an, magst du mal ein Codebeispiel geben?

PS: Zum Thema: Ich persönlich finde ein gesundes Maß an Interpunktion gut, erfordert mehr Einarbeitung, erhöht aber meiner Meinung nach die Übersichtlichkeit.

[~fricky]

groovemaster schrieb:

Ich persönlich mag Operatoren, die intuitiv zu benutzen sind, am liebsten.

a = b + c

ist zB einfacher und mindestens so verständlich wie

a equals b plus c

Ganz einfach, weil wir dies mathematisch so gewohnt sind.

hmmm, da hast du natürlich recht. für mathematische ausdrücke und zuweisungen würde ich auch die gewohnte schreibweise nehmen. aber für vergleiche z.b. wenn zwei variablen mit dem selben wert verglichen werden sollen, eine abkürzung wie:

if (a and b is null) // in c-syntax: if (a==0 && b==0)
while (a or b greater than 7) // while (a>7 || b>7)

^^fände ich sowas ganz gut, weils der menschlichen sprache recht nahe kommt.
wobei diese 'and' und 'or' nicht nochmal als bitoperatoren auftauchen sollten.
ach ja, und dann würde ich noch ganzzahl-arithmetik beliebiger länge in die sprache einbauen.
und natürlich typlose variablen, die alles sein können, von einzelnen bits über fliesskommawerte bis hin zu mehrdimensionalen arrays.

[pointercrash**]

~fricky schrieb:

if (a and b is null) // in c-syntax: if (a==0 && b==0)
while (a or b greater than 7) // while (a>7 || b>7)

^^fände ich sowas ganz gut, weils der menschlichen sprache recht nahe kommt.
wobei diese 'and' und 'or' nicht nochmal als bitoperatoren auftauchen sollten.
ach ja, und dann würde ich noch ganzzahl-arithmetik beliebiger länge in die sprache einbauen.
und natürlich typlose variablen, die alles sein können, von einzelnen bits über fliesskommawerte bis hin zu mehrdimensionalen arrays.

Schau' Dir mal FORTH an.
Ich war's nur irgendwann müde, fig- Ports selber stricken zu müssen, die eh nur so "performant" sind wie gcc- Ableger in Version 0.01. Richtig gute Compreter gibt es nur für voll verbreitete Prozessoren.
Man schafft solange neue Befehle, bis das Gesamtproblem durch einen Befehl gelöst ist; das Konzept ist schon lässig, stammt ja auch von "Papa Moore". Leider wirken "moderne" Sachen wie OOP eher drangeflickt (was man auch bei C++ manchmal vermuten könnte) und letztendlich werkelt da eine zwar engagierte, aber nur kleine Community dran.
Für die eine oder andere Sache, die nach "bottom up"- Entwürfen schreit, immer noch meine erste Wahl, wenn's keinen C- Compiler für die Plattform gibt.

[borg]

also ich finde eine gute programmiersprache sieht aus wie python

[~fricky]

pointercrash() schrieb:

Schau' Dir mal FORTH an.

das hab ich sogar mal getan. aber ich fand z.b. dieses stack-basierte rechnen doof. intern kann forth von mir aus als stackmaschine arbeiten, aber das muss ja nicht auf den user abgewälzt werden.

pointercrash() schrieb:

Man schafft solange neue Befehle, bis das Gesamtproblem durch einen Befehl gelöst ist; das Konzept ist schon lässig....Leider wirken "moderne" Sachen wie OOP eher drangeflickt (was man auch bei C++ manchmal vermuten könnte)

ja, ich glaube auch wenn ich 'ne programmiersprache erfinden würde, würde ich alles reinfummeln, was ich irgendwie gut finde und am schluss käme ein grausames, halbdurchdachtes gebilde mit 1000 ecken und kanten raus, etwa sowas wie C++. im grunde bringt es mehr, wenn sprachen schlank sind und z.b. diese punkte erfüllen:

spirit of c schrieb:

1. Trust the programmer.
2. Don't prevent the programmer from doing what needs to be done.
3. Keep the language small and simple.
4. Provide only one way to do an operation.
5. Make it fast, even if it is not guaranteed to be portable.

aber wenn man erstmal so richtig im 'feature-reinbastel-wahn' ist, wirds bestimmt schwer sich dran zu halten.

[Das Auge liest mit]

Operatoren dürfen ruhig durch Symbole dargestellt werden. Es geht bei einer Programmiersprache nicht darum, dass jemand ohne Kenntnisse diese sofort versteht, sondern nachdem er die Definitionen der Operatoren kennt.
Ebenso wichtig ist Abstraktion bzw. die Unterstützung für Abstraktion.

Da die Geschichte der Programmiersprachen vergleichsweise kurz ist, sollte man sich an einem ähnlichen Modell orientieren. In diesem Fall die Mathematik.

[~fricky]

Das Auge liest mit schrieb:

Da die Geschichte der Programmiersprachen vergleichsweise kurz ist, sollte man sich an einem ähnlichen Modell orientieren. In diesem Fall die Mathematik.

aber die alten mathematiker, euklid usw. hatten auch nicht so'ne komplizierte symbolik wie wir heute, sondern haben mehr mit worten gearbeitet und skizzen gemalt.

[gegere]

Also was ich wirklich toll finde ist eine programmierspache, die effizient ist, und einem nicht dazu zwingt, unnötige sachen zu schreiben

struct lmaa_tata** ppv = arg1;
while(*ppv)
    *(ppv++)->ra_lama |= arg2 ^ 34;

Und so weiter und so fort...

[groovemaster]

Bashar schrieb:

Eben, damit ist dein Argument, es wäre verständlich, wenn man mit der Sprache nicht vertraut ist, falsch.

Vielleicht solltest du noch mal genauer hinschauen. Ich habe nicht geschrieben, dass es verständlich ist, sondern verständlicher. Und nochmal, deine Anmerkung spielt hier überhaupt keine Rolle. Es ging um das Verständnis der Operation selbst, nicht um die Auswertung von Operanden oder was auch immer.

[Bashar]

Was auch immer du mit "Verständnis der Operation selbst" meinst. Das Verständnis der Auswirkungen dieser Operation im Code kann es dann ja nicht sein, und was ist dieses Verständnis dann wert? Es kann doch bestenfalls die Illusion von Verständnis sein.

[muemmel]

Hi,

ich finde, daß bei Sprachen mit zu viel Wortbefehlen (begin end and or...) der eigentliche Quelltext schnell zwischen Sprachkonstrukten verschwindet. Bei C (und Verwandten) ist dagegen auf auf den ersten Blick ersichtlich was eigentlicher Quelltext ist und was Sprachkonstrukte sind.

Gruß Mümmel

[groovemaster]

Es wurde doch alles gesagt, Bashar. Lies es dir besser nochmal durch. Du solltest so clever sein und den eigentlichen Sachverhalt verstehen. Es ging jedenfalls nicht um Nebeneffekte. Dass dies nicht der Sinn von Operatoren ist, sollte dir doch bewusst sein. Ich habe eher das Gefühl, du versuchst deine Sichtweise zu objektivieren.

[wow-bitte]

groovemaster schrieb:

Ich persönlich mag Operatoren, die intuitiv zu benutzen sind, am liebsten.

a = b + c

ist zB einfacher und mindestens so verständlich wie

a equals b plus c

Ganz einfach, weil wir dies mathematisch so gewohnt sind.

= != equals

[only-olli]

ich finde python ist eine ganz hübsche sprache. durch das erzwingen der einrückung wird der code auf jedenfall hübsch übersichtlich. auch sonnst so lässt sich der quelltext gut lesen:
for x in foo:
if x not in bar:
muh.append( x )

oder list comprehension
even = [ i for i in range( 10 ) if i % 0 == 0 ]

besser zu lesen als x = A ? B : C find ich auch x = B if A else C

Außerdem kann ich programmieren wie ich möchte, und muss mich nicht z.B. OO unterwerfen wie in Java, oder komplett drauf verzichten, wie in C

[only-olli]

denkt euch die code-tags

[tfa]

only-olli schrieb:

Außerdem kann ich programmieren wie ich möchte, und muss mich nicht z.B. OO unterwerfen wie in Java, oder komplett drauf verzichten, wie in C

In Python programmierst du natürlich immer objektorientiert (Leider ist die Sprache so entworfen, dass es manchmal ganz und gar nicht danach aus sieht, was ich ziemlich hässlich finde). Darüber hinaus hast du noch die Möglichkeit (wie in anderen Skriptsprachen auch), funktional zu programmieren. Das eine schließt das andere nicht aus.

[Gast]

wow-bitte schrieb:

groovemaster schrieb:

Ich persönlich mag Operatoren, die intuitiv zu benutzen sind, am liebsten.

a = b + c

ist zB einfacher und mindestens so verständlich wie

a equals b plus c

Ganz einfach, weil wir dies mathematisch so gewohnt sind.

= != equals

Das gilt natürlich auch für alle Sprachen und vor allem für die Mathematik...