Welcher Sprache gehört die Zukunft?

DEvent

Das ist wirklich nicht ganz verständlich. Die Syntax von C ist wirklich nicht einleuchtend. Liegt aber vermutlich daran, das C so populär geworden ist und es einfach jeder kennt. Das zieht natürlich weitere Kreise. Aber im Grunde ist die C-Syntax beschissen und die Syntax von C++ ... (<-- sparen wir uns das mal lieber )

Ich finde die Syntax von C und C++ extrem einleuchtend. Nennt mal ein richtiges Beispiel wo die Syntax total unintuitiv sein soll. Verwechslungsgefahr ist kein Argument, da dies bei allem besteht und total subjektiv ist. Anfängerunfreundlich ist auch kein Argument, da dies wieder bei allem besteht und ebenfalls subjektiv ist.

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 { }.

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)?

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;

Mr. N

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;

Ich nehme an, du hast absichtlich nicht

vector<vector<int> > foo;

geschrieben.

Viel krasser ist doch sowas:

void (*signal(int, void (*)(int))(int);

Bashar

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)

Die Standardisierung kann ich nicht als Argument gelten lassen. Das wird heute als wichtig wahrgenommen, aber früher (sagen wir ca. 1995) haben die Leute sich nen Borland Compiler geschnappt und nach Herzenslust in der conio.h und sonstwo irgendwelche Funktionen zusammengesucht, oder gleich mit Visual C++ angefangen irgendwelche Fenster zusammenzuklicken. Von void main will ich gar nicht anfangen. Die Nachwehen dieser Zeit spürt man heute noch.
Von der Programmstruktur her ist Pascal doch wohl deutlich klarer. Und zu Zeiten von Turbo Pascal war Pascal auch deutlich beliebter, ich erinnere mich an so manche Diskussion mit uneinsichtigen Pascallern Aber ganz plötzlich hieß es überall C++ (gemeint war meistens C). Also ich würde vermuten, dass C mit C++ und dem OOP-Hype angeschwemmt wurde. Dazu kommt der Coolness-Faktor durch die Unix-Guru-Aura, die C manchmal verbreitet. Einen Obfuscated-Pascal-Contest würde ich mir jedenfalls ziemlich langweilig vorstellen. (Alles auf PCs bezogen natürlich, die Unixer machen schon immer C, das ist klar.)

Mr. N 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;
Ich nehme an, du hast absichtlich nicht
vector<vector<int> > foo;
geschrieben.

Du bist aber ein ganz schlaues Kerlchen

pale dog

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

Bashar

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.

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.