Welcher Sprache gehört die Zukunft?

Mr. N

Bashar schrieb:

Tim schrieb:

Du bist aber ein ganz schlaues Kerlchen

Das ist aber auch nicht wirklich prinzipbedingt oder beabsichtigt und wird in C++0x gefixt. Ich würde mal behaupten dass es uns hier schwer fallen wird, unintuitive Merkmale der Syntax von C++ zu finden, da die meisten C++ wahrscheinlich sogar träumen oder so Man neigt doch immer dazu, die eigene Sprache zu verteidigen.

An Lisp ist zum Beispiel

setf

unintuitiv.

Bashar

Mr. N schrieb:

An Lisp ist zum Beispiel
setf
unintuitiv.

Troll :p

Walli

pale dog schrieb:

Mr. N schrieb:
Viel krasser ist doch sowas:
void (*signal(int, void (*)(int))(int);
gewohnheitssache.
für einen, der oft mit function pointers rumfummelt, ist sowas gut lesbar.
viel schlimmer finde ich:
a << b;
in C und sprachen mit C-ähnlicher syntax wie z.b. Java ist das einfach bitweises schieben, also kein grosses rätsel.
in C++ aber kann es alles mögliche sein

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

Bashar

<< steht für den Aufruf der entsprechenden operator<<-Funktion, wo ist das Problem? Der Autor der entsprechenden Funktion oder Klasse muss dafür sorgen, dass der intuitiv ist. Ansonsten hast du in C das gleiche Problem. plus(a,b) kann alles mögliche sein, z.B. Subtraktion, aber wer sowas macht, wird direkt aufgeknüpft

Hallo

Am Beispiel von pale dog sieht man doch wie subjetiv die Bewertung ist. Viele hier sind sicher mit mir der Meinung, dass Operatorenüberladung eine tolle Sache ist und den Code lesbarer macht. Andere wiederum halten es für Teufelszeug und können damit nichts anfangen. Desweiteren sollte Syntax auch nicht unbedingt dafür da sein, dass Anfänger sie sofort verstehen, sondern sie muss sich im Praxiseinsatz bewähren und robust sein.

chrische

pale dog

Bashar schrieb:

<< steht für den Aufruf der entsprechenden operator<<-Funktion, wo ist das Problem?

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.

Artchi

Mr. N schrieb:

CStoll schrieb:

Irgendwann werden wir sie dem Computer diktieren

Ist das nicht super-unpraktisch?

Und wie! Ich stelle mir gerade vor, wie ich mit meinen aktuellen zwei Kollegen in einem Büro sitze, und jeder von uns in ein Mikro seinen Code diktiert. Drei Leute quatschen irgend einen Code und man versteht sein eigenes Wort nicht mehr. Ganz davon abgesehen, das ich mich nicht konzentrieren kann, wenn im selben Raum irgendjemand die ganze Zeit quatscht.

Neee, also Code diktieren ist das letzte was unter "Fortschritt" fällt.

Artchi

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.

pale dog

Artchi schrieb:

Ich stelle mir gerade vor, wie ich mit meinen aktuellen zwei Kollegen in einem Büro sitze, und jeder von uns in ein Mikro seinen Code diktiert.

...und weil sowas doof ist, bekommt jeder ein eigenes zimmerchen. ist doch ein netter nebeneffekt.

pale dog

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;

?

LordJaxom

pale dog schrieb:

...und weil sowas doof ist, bekommt jeder ein eigenes zimmerchen. ist doch ein netter nebeneffekt.

Wie langweilig.

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?