Wie sieht eine gute Programmiersprache aus?

[Happ]

Hallo,

mich würde gerne eure Meinung dazu interessieren: Sollte eine gute Programmiersprache lieber Operatoren(==, !=, ...) oder Keywords bieten(equal, not_equal, ...)?

Wäre z.B. ein If (x equal z) besser als ein If (x == z)

Wie seht ihr das? Wie würdet ihr eine gute Programmiersprache von der Syntax her aufbauen. Schreibt einfach Codebeispiele, am Besten mit Begründung warum es so besser ist

[Elektronix]

Ich finde, eine gute Programmiersprache sollte so aussehen, daß sie auch für Anfänger einigermaßen leicht verständlich ist, sowohl in der Syntax, alsauch in den Operatoren und anderen Zeichen.
Mit Zeichen wie

If (i!=0, I>100, I++)

kann kaum ein Anfänger etwas anfangen. C und C++ leisten dieses Kriterium also nicht.
Außerdem sollte eine gute Programmsprache die Möglichkeit bieten, den Programmtext optisch zu strukturieren (Bei C++ die {...} für Funktionsblöcke) bzw. diese Strukturen erzwingen, damit sich alle Programmierer die gleichen Marotten angewöhnen und einer den anderen versteht.

[~fricky]

ich würde die keywords (equal, not-equal, etc.) vorziehen. sowas ist leichter lesbar. aber dafür muss man bei c-ähnlichen operatoren weniger schreiben. und bei schleifen z.b. würde ich eher eine syntax wie for x=a to b step c anstatt for (x=a; x<=b; x+=c) nehmen.

[Bashar]

Gut für was?

Was für Anfänger gut ist, kann für Fortgeschrittene hinderlich sein; was für wissenschaftliche Anwendungen gut ist, kann für kaufmännische Anwendungen schlecht sein usw.

[zwutz]

~fricky schrieb:

und bei schleifen z.b. würde ich eher eine syntax wie for x=a to b step c anstatt for (x=a; x<=b; x+=c) nehmen.

was das ganze aber unflexibler macht, wenn man mehr als eine Schleifenbedingung oder eine zweite Zählvariable hat.

Aber afair hat Basic diese Syntax

zu den Operatoren:
ich ziehe die C++-Operatoren den ausgeschriebenen vor und denke auch, dass es für Anfänger leichter zu erlernen ist (vor allem, da er einige eh bereits aus dem Matheunterricht kennen dürfte)

Die ausgeschriebenen schützen nicht vor Fehlern, vor allem, wenn man sich um die Schreibweise (equal vs equals, not_equal vs equal_not) Gedanken machen muss, während die C++-Operatoren da eindeutig sind

[groovemaster]

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.

Das bedeutet aber nicht, dass deshalb Schlüsselwörter nicht geeignet sind. Ich wüsste nicht, was gegen einen Mix spricht. Letztendlich ist das hauptsächlich ein Problem des Lexers, solche Sachen zu unterscheiden.

a or b

ist zB verständlicher als

a | b

Beim ersten Beispiel kann jeder halbwegs versierte Programmierer erkennen, dass es sich um eine logische Verknüpfung handelt. Beim zweiten Beispiel müsste man sich erstmal mit der jeweiligen Sprache vertraut machen.

[Bashar]

groovemaster schrieb:

Beim zweiten Beispiel müsste man sich erstmal mit der jeweiligen Sprache vertraut machen.

Im ersten Beispiel wohl nicht? Ist das ein Shortcut-Or oder nicht?

[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