Welcher Sprache gehört die Zukunft?

Artchi schrieb:

Tim schrieb:
DEvent schrieb:

Ich finde die Syntax von C und C++ extrem einleuchtend. Nennt mal ein richtiges Beispiel wo die Syntax total unintuitiv sein soll.
vector<vector<int>> foo;
Na, das >> bei den Templates ist aber ein Bug. Kann man ja nicht als by-Design gelten lassen. Der VisualC++ 2005 versteht übrigens vector<vector<int**>>** foo; ohne Leerzeichen! Eine C++0x-Korrektur die jetzt bereits implementiert wurde.

Ob "Bug" oder "by-design" ist doch latte. Es ist nicht intuitiv. Das war gefragt.

rüdiger

Klar, die meisten Syntax-Kriminalitäten sind reine Fragen der Gewöhnung. Aber das macht es noch lange nicht intuitiv Genauso wenig wird ein Fortran-Programmierer die von mir dargelegten Fortran Konstrukte (s. letztes Posting) unverständlich oder als problematisch empfinden...

CStoll schrieb:

C hat eine klare Programmstruktur und ist nebenbei standardisiert (letzteres können Basic und Pascal nicht von sich behaupten).

äh, es gibt ISO Standards sowohl für BASIC, als auch PASCAL.

Walli schrieb:

Naja, in C++ merkt man meist aber am Kontext was gemeint ist. + kann auch für addieren oder konkatenieren stehen.

Das man + für das zusammenhängen zweier Strings überladen hat, ist einfach nur einer der Punkte, die absolut total dämlich an der Standard Library in C++ sind. Ich verstehe nicht warum die Standard-Komitee Mitglieder so etwas machen konnten!

Aber auch in C ist die Bedeutung von a+b vom Kontext abhängig...

Artchi schrieb:

Na, das >> bei den Templates ist aber ein Bug. Kann man ja nicht als by-Design gelten lassen. Der VisualC++ 2005 versteht übrigens vector<vector<int**>>** foo; ohne Leerzeichen! Eine C++0x-Korrektur die jetzt bereits implementiert wurde.

Kann der GCC im C++0x-Modus ebenfalls (und einiges mehr aus C++0x :))

pale dog schrieb:

Artchi schrieb:

Der VisualC++ 2005 versteht übrigens vector<vector<int**>>** foo; ohne Leerzeichen!

...und was macht er, wenn das argument des inneren vectors keine eingebauter typ ist, also sowas:
vector<vector<hui>> boo;
?

genau gleich parsen

wenn du eben den op>> anwenden willst, dann musst du A<A<(k>>i)>> schreiben.

rüdiger

Walli schrieb:

Mit C++ sicher... Ausser die Erkennung ist intelligent und man muss nicht jede Klammer einzeln einsprechen .

Das dürfte in jeder Programmiersprache umständlich sein (außer vielleicht in Apple Skript ;)). Aber ich denke mal das es selbst mit Erkennungsraten von 99,9999999% immer noch unproduktiv ist. (Oder tippt ihr euren Code immer linear runter?)

Mr. N

Bashar schrieb:

Mr. N schrieb:
An Lisp ist zum Beispiel
setf
unintuitiv.
Troll :p

Ich finde setf wirklich unintuitiv.

pale dog schrieb:

das problem ist mehrdeutigkeit und damit einhergehende schlechte lesbarkeit, komplexe funktionen, die sich hinter unscheinbaren operatoren verstecken usw.
das hatten wir aber alles schon im op-overloading thread breitgewälzt.

Nicht ganz. Wir haben dich mit Argumenten für Operator-Overloading vollgestopft und du hast am Ende "Basta, das bringt doch nix" gesagt. Dass du es jetzt von dir aus hier wieder bringst ist natürlich ein Fehler.

pale dog

Mr. N schrieb:

Nicht ganz. Wir haben dich mit Argumenten für Operator-Overloading vollgestopft und du hast am Ende "Basta, das bringt doch nix" gesagt. Dass du es jetzt von dir aus hier wieder bringst ist natürlich ein Fehler.

weswegen wir es hier auch nicht wieder aufwärmen sollten.

btw, zu dem komischen vector-gedöns da oben. schlucken der msvc bzw. GCC eigentlich sowas:

int vector=1, hui=2, boo=3;
int x = vector<vector<hui>> boo;

?
mein intuitives c-coder verständnis sagt mir, dass sie's müssten,
(vector kleiner vector kleiner hui right-shift boo)

Mr. N

pale dog schrieb:

btw, zu dem komischen vector-gedöns da oben. schlucken der msvc bzw. GCC eigentlich sowas:
int vector=1, hui=2, boo=3;
int x = vector<vector<hui>> boo;
?
mein intuitives c-coder verständnis sagt mir, dass sie's müssten,
(vector kleiner vector kleiner hui right-shift boo)

Jo, geht. Aber nur wenn std::vector nicht im Scope ist, sonst:

<stdin>:3: error: 'int vector'; redeclared as different kind of symbol

Xin

CStoll schrieb:

Bashar schrieb:

Über die Mainstream-Akzeptanz aber schon.

Das wird sich auch wieder legen (spätestens wenn die Computer lernen, menschliche Sprache zu verstehen)

Wobei mich schon mal interessieren würde, woher das eigentlich, auch historisch, kommt.

C hat eine klare Programmstruktur und ist nebenbei standardisiert (letzteres können Basic und Pascal nicht von sich behaupten).
(und hier im Forum sind nicht C-basierte Sprachen ohnehin seltener anzutreffen)

Computer werden nicht lernen, Menschen zu verstehen. Menschen sind nicht in der Lage Information eindeutig über gesprochene Sprache zu transportieren, Betonungen sind nicht eindeutig bewertbar. Der Ausdruck "das passt wie die Faust auf's Auge" wird von 50% der Menschen als "passt perfekt" und vom Rest als "passt überhaupt nicht" verstanden. Beides ist korrekt.

Die menschliche Sprache ist häufig undefiniert und interpretationsfähig oder emotional.

Die exakte Information des vorherigen Satzes weiß nur ich. Der Rest kann nur raten und wird ungefähr wissen, was ich meine. Menschliche Sprache hat keine Prioritätskennzeichner.

DEvent schrieb:

Ich finde die Syntax von C und C++ extrem einleuchtend. Nennt mal ein richtiges Beispiel wo die Syntax total unintuitiv sein soll.

MyClass( int var ) : a ( var ) {} // Initialisierung 
int a(4);                         // Initialisierung
int a = 4;                        // Initialisierung
a = 4;                            // Zuweisung

int a = 4;
int pa = &a;

printf( "Variable dividiert durch Wert von Zeiger : %d", a/*pa );

Lügner

Mr. N schrieb:

Bashar schrieb:
Mr. N schrieb:
An Lisp ist zum Beispiel
setf
unintuitiv.
Troll :p
Ich finde setf wirklich unintuitiv.

Hat das was mit der Syntax zu tun?

pale dog

Xin schrieb:

...
int a(4);                         // Initialisierung
int a = 4;                        // Initialisierung
...

wer hat sich eigentlich so einen schwachsinn einfallen lassen?

CStoll

Mr. N schrieb:

CStoll schrieb:

Irgendwann werden wir sie dem Computer diktieren

Ist das nicht super-unpraktisch?

Ich sag' nur Star Trek: "Hallo, Computer" (oder auch "Tastatur - wie rückständig"). Irgendwann wird es darauf hinauslaufen, daß wir dem Computer nur noch unser Problem schildern und er dann selbständig nach einer passenden Lösung sucht

DEvent schrieb:

Ich habe zuerst in Pascal programmiert und dann in C++. Damals fand ich es super nicht mehr begin und end schreiben zu müssen, sondern einfach { }.

Als ich angefangen habe mit C++, habe ich die begin/end's schon vermisst - aber man gewöhnt sich ja an alles

Das einzige was ich nicht verstehe ist, dass man einige Operatoren als friends definieren muss, aber andere als normale Klassenmethoden belassen kann. Wieso wurde nicht einfach alle Operatoren als Methoden definiert, die sich so wie erwartet verhalten (also wozu der Unterschied zwischen Ops als friend und Ops als Methoden)?

Das hat aber nichts mit der C-Syntax als Sprachgrundlage zu tun, sondern mit der Auflösung der operator-Überladung. Ein C++ Operator wird entweder als Methode des ersten Operanden oder als globale Funktion definiert - wenn du dem ersten Operanden keine zusätzlichen Methoden mitgeben kannst (weil's z.B. ein Build-in Typ ist), bleibt nur die globale Funktion (und die braucht im Ernstfall halt friend-Zugriff).

pale dog schrieb:

Xin schrieb:
...
int a(4);                         // Initialisierung
int a = 4;                        // Initialisierung
...
wer hat sich eigentlich so einen schwachsinn einfallen lassen?

Das Standardisierungskommitee (sowas ist besonders nützlich, wenn du mit Templates arbeiten willst - eigene Typen können mit der T a(x); Syntax initialisiert werden, und im Gegensatz zu Java sollen Build-ins weitgehend austauschbar mit eigenen Typen sein).

Edit: (ich wußte doch, ich hab' etwas vergessen)

rüdiger schrieb:

CStoll schrieb:

C hat eine klare Programmstruktur und ist nebenbei standardisiert (letzteres können Basic und Pascal nicht von sich behaupten).

äh, es gibt ISO Standards sowohl für BASIC, als auch PASCAL.

Aber es gibt deutlich mehr BASIC-Dialekte als C-Variationen (vergleich z.B. C64 Basic mit VBA - kaum zu glauben, daß die Sprachen miteinander verwandt sein sollen)

pale dog

CStoll schrieb:

eigene Typen können mit der T a(x); Syntax initialisiert werden, und im Gegensatz zu Java sollen Build-ins weitgehend austauschbar mit eigenen Typen sein).

ach du schreck , dann soll das wohl einen konstruktoraufruf andeuten.
ich hasse C++!

Der Durchschnitt

pale dog schrieb:

CStoll schrieb:

eigene Typen können mit der T a(x); Syntax initialisiert werden, und im Gegensatz zu Java sollen Build-ins weitgehend austauschbar mit eigenen Typen sein).

ach du schreck , dann soll das wohl einen konstruktoraufruf andeuten.
ich hasse C++!

Ich bin ehrlich gesagt auch kein Verfechter von C++, aber du siehst wirklich Probleme, wo keine sind.

CStoll

pale dog schrieb:

CStoll schrieb:

eigene Typen können mit der T a(x); Syntax initialisiert werden, und im Gegensatz zu Java sollen Build-ins weitgehend austauschbar mit eigenen Typen sein).

ach du schreck , dann soll das wohl einen konstruktoraufruf andeuten.
ich hasse C++!

Das soll, keinen Konstruktoraufruf andeuten, das ist ein Konstruktor-Aufruf

Artchi

pale dog schrieb:

CStoll schrieb:

eigene Typen können mit der T a(x); Syntax initialisiert werden, und im Gegensatz zu Java sollen Build-ins weitgehend austauschbar mit eigenen Typen sein).

ach du schreck , dann soll das wohl einen konstruktoraufruf andeuten.
ich hasse C++!

LOL! Und sowas nennt sich Programmierer...

Bashar

Lügner schrieb:

Ich finde setf wirklich unintuitiv.

Hat das was mit der Syntax zu tun?

Nein, damit, dass das erste Argument von setf syntaktisch ein Funktionsaufruf sein kann, aber die Funktion gar nicht aufgerufen wird. Kurz für Nicht-Lisp-Kenner: Man kann eine Variablenzuweisung folgendermaßen machen:

(setq a 42) ;; wie a = 42 in C

Für Zuweisung von Strukturkomponenten oder Listen- oder Arrayelementen funktioniert das aber nicht mehr, da das keine Variablen sind. Dafür gibts dann spezielle Funktionen, die aus Traditionsgründen noch existieren, aber recht unintuitiv sind. Die Alternative ist das setf-Makro. In der einfachsten Form funktioniert es wie setq:

(setf a 42) ;; wird als Makro expandiert zu (setq a 42)

.
Man kann allerdings auch sowas machen wie

(setf (car mylist) 23) ;; setzt das erste Element ("car") der Liste auf 23

. Die Idee ist, dass das erste Argument von setf ein generalisierter "Platz" ist, dem man auch irgendeine Art und Weise etwas zuweisen kann. Man kann das intuitiv so verstehen, dass setf dafür sorgt, dass (car mylist) danach gleich 23 ist.
Das ganze ist erweiterbar, man kann zu jeder Funktion eine setf-Expansion definieren, so dass auch

(setf (meine-funktion a b c) 4711)

funktioniert. Wenn man die Idee der "places" verstanden hat, ist das ganze eigentlich ziemlich intuitiv. Mr.N hat nur ein Problem damit, dass da syntaktisch ein Funktionsaufruf steht, der keiner ist. Da Makros und Spezialoperatoren (if, and, let, defun, do ...) aber in Lisp meistens die Eigenschaft haben, dass nicht alle Argumente ausgewertet werden, ist das dieses Problem eigentlich keins.

LordJaxom

pale dog schrieb:

ach du schreck , dann soll das wohl einen konstruktoraufruf andeuten.
ich hasse C++!

Schaffen wir es, den Hass derart zu schüren dass Du dem C++-Board fernbleibst? (scnr)

Ein Beispiel, wo es meiner Meinung nach unintuitiv ist: (Annahme: T ist kein POD)

T t(); // Funktion
int i(); // Funktion

T t; // Default-Konstruiert ein T
int i; // Uninitialisierter Integer

AnyClass::AnyClass()
  : t() // Default-Konstruiert ein T
  , i() // Default-Initialisiert ein int (mit 0)
  {}

T f = T(); // Default-Konstruiert ein T, benötigt aber Copy-Semantik
int f = int(); // Default-Initialisiert ein int (mit 0), benötigt zwar auch Copy-Semantik, aber die ist für PODs gegeben

Damit ist es nicht möglich, ein Template zu schreiben, welches sowohl PODs als auch z.B. noncopyable non-PODs default-initialisiert, es seidenn dies geschieht in einer Initialisierungsliste. (Oder übersehe ich was?)

Mr. N

Bashar schrieb:

Mr.N hat nur ein Problem damit, dass da syntaktisch ein Funktionsaufruf steht, der keiner ist. Da Makros und Spezialoperatoren (if, and, let, defun, do ...) aber in Lisp meistens die Eigenschaft haben, dass nicht alle Argumente ausgewertet werden, ist das dieses Problem eigentlich keins.

Naja, es ist kein Problem. Aber eben nicht intuitiv.

CStoll schrieb:

Ich sag' nur Star Trek: "Hallo, Computer" (oder auch "Tastatur - wie rückständig").

Ich sag' nur: "Äh ja toll."

Science-Fiction-Autoren entscheiden ja nicht nach Praktikabilität, ob sie etwas schreiben, umgesetzt wird aber meistens nur, was praktikabel ist (bzw. eine Untermenge davon).

Ich will mal versuchen mir vorzustellen, wie das optimalerweise laufen würde:

Rede an den Computer schrieb:

"In the function template Foobar dependent on typename Type One and integral constant Number One specialised on Number One equals 4, after the assignment of a list to Spritzlidi add an assignment of Spritzlidi appended by Spritzlidi to Spritzlidi Two and replace all subsequent occurences of Spritzlidi in scope by Spritzlidi Two."

Mir würde da das Sprachzentrum zu sehr belastet werden.

pale dog schrieb:

wer hat sich eigentlich so einen schwachsinn einfallen lassen?

Offensichtlich klügere Leute als du, da es Sinn macht.

pale dog

Der Durchschnitt schrieb:

Ich bin ehrlich gesagt auch kein Verfechter von C++, aber du siehst wirklich Probleme, wo keine sind.

für mich isses kein problem. irgendwie passt ja auch zu dieser fricklersprache

CStoll schrieb:

Das soll, keinen Konstruktoraufruf andeuten, das ist ein Konstruktor-Aufruf

konstruktoren für int's? der erfinder der registermaschine u.ä. leute würden im grabe rotieren

Artchi schrieb:

LOL! Und sowas nennt sich Programmierer...

nennt sich sowas nicht! auch wenn sowas manchmal was programmieren darf.

LordJaxom schrieb:

Schaffen wir es, den Hass derart zu schüren dass Du dem C++-Board fernbleibst? (scnr)

dazu müsst ihr ein paar foren abschaffen. wenn nur noch das c++ forum da ist, gehe ich weg...

Mr. N

pale dog schrieb:

konstruktoren für int's? der erfinder der registermaschine u.ä. leute würden im grabe rotieren

Wo ist das Problem?

(Du bist übrigens ein wesentlich schlimmerer Troll als ich. Und es wird wieder mal Zeit für einen neuen Nick, gell?)

CStoll

Mr. N schrieb:

Science-Fiction-Autoren entscheiden ja nicht nach Praktikabilität, ob sie etwas schreiben, umgesetzt wird aber meistens nur, was praktikabel ist (bzw. eine Untermenge davon).

Das läuft dann auf den (früher bereits erwähnten) Unterschied zwischen Programmentwickler und Anwender hinaus. Der Entwickler schreibt fein strukturierte (und mikro-optimierte) Algortihmen und wird wohl auch in der zukunft noch schreiben (bzw. Programmtexte eintippen), der Anwender schmeißt dem Computer sein Problem entgegen und erwartet eine Lösung, ohne sich um die genauen Abläufe kümmern zu wollen.
(und SF-Autoren beschreiben meist die Welt aus Sicht von Anwendern ;))

Ich will mal versuchen mir vorzustellen, wie das optimalerweise laufen würde:

Rede an den Computer schrieb:

"In the function template Foobar dependent on typename Type One and integral constant Number One specialised on Number One equals 4, after the assignment of a list to Spritzlidi add an assignment of Spritzlidi appended by Spritzlidi to Spritzlidi Two and replace all subsequent occurences of Spritzlidi in scope by Spritzlidi Two."

Mir würde da das Sprachzentrum zu sehr belastet werden.

Ja, diktierte Programme basieren bestimmt nicht auf C- oder Basic-artiger Syntax. Die kannst du zwar recht übersichtlich aufschreiben, aber nur sehr umständlich vorlesen - für sprachgesteuerte Entwicklungsumgebungen wird sich zwangsläufig etwas eigenständiges entwickeln (was sich eher an der menschlichen Sprache orientieren wird).