Welcher Sprache gehört die Zukunft?

[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).

[rüdiger]

Mr. N schrieb:

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.

Es ist doch sehr intuitiv von der Benutzung und Lesbarkeit. Bei (setf (car a) 42) weiß man doch sofort was gemeint ist. Das daraus resultierende (rplaca a 42) , finde ich dagegen weniger intuitiv. :p

Aber welche Programmiersprache ist rein intuitiv? Selbst Sprachen wie Python, Ruby oder ADA haben ihre Grenzen

[CStoll]

pale dog schrieb:

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

Was hat denn der damit zu tun? C++ ist keine Registermaschine - und wir haben auch kein Problem damit, int-Variablen zu konstruieren

[Gast]

Ich glaube, es wäre besser zu fragen: "Welche Sprache ist eine Eintagsfliege".
(Dann würde ich übrigens für C# stimmen )

[this-*gt*that]

SeppSchrot schrieb:

Ich glaube, es wäre besser zu fragen: "Welche Sprache ist eine Eintagsfliege".
(Dann würde ich übrigens für C# stimmen )

Sachlichkeit kann man bei deiner Signatur ja nicht erwarten...

[Artchi]

Dann dürfte aber sowas:

4.toString()

auch nicht möglich sein. Aber angeblich soll das ein ganz tolles Feature in manchen Sprachen (C# und Ruby) sein. Aber wenn C++ was mit nativen Typen macht, was etwas OO'isch ist, ist es natürlich schlechtes Design. Oh man, pale dog ist glaub ich DER Troll schlecht hin hier im Forum. Wann wird pale dog wieder anders heißen? (immerhin hat er sich ja shcon mal von vista nach pale dog transformiert, was kommt als nächstes?)

[CStoll]

Artchi schrieb:

Oh man, pale dog ist glaub ich DER Troll schlecht hin hier im Forum.

Da dürftest du recht haben. Und inzwischen hab' sogar ich es aufgegeben, ihm die Vorteile von C++ nahebringen zu wollen (meistens jedenfalls).

Wann wird pale dog wieder anders heißen? (immerhin hat er sich ja shcon mal von vista nach pale dog transformiert, was kommt als nächstes?)

Sollen wir schonmal anfangen, Namensvorschläge zu sammeln (mir fällt auf Anhieb noch 'net' und 'ten' ein - kennt jemand zufällig die komplette Sammlung?)

[Mr. N]

CStoll schrieb:

Wann wird pale dog wieder anders heißen? (immerhin hat er sich ja shcon mal von vista nach pale dog transformiert, was kommt als nächstes?)

Sollen wir schonmal anfangen, Namensvorschläge zu sammeln (mir fällt auf Anhieb noch 'net' und 'ten' ein - kennt jemand zufällig die komplette Sammlung?)

Wie wärs denn mit "sharp"?

[pale dog]

Mr. N schrieb:

(Du bist übrigens ein wesentlich schlimmerer Troll als ich...

es kann nur einen geben

CStoll schrieb:

...und wir haben auch kein Problem damit, int-Variablen zu konstruieren

bitweise? oder darf's auch schneller gehen?

Artchi schrieb:

Oh man, pale dog ist glaub ich DER Troll schlecht hin hier im Forum. Wann wird pale dog wieder anders heißen? (immerhin hat er sich ja shcon mal von vista nach pale dog transformiert, was kommt als nächstes?)

weiss ich selbst noch nicht, aber ihr werdet mich bestimmt wieder schnell enttarnen

CStoll schrieb:

Und inzwischen hab' sogar ich es aufgegeben, ihm die Vorteile von C++ nahebringen zu wollen...

du hast noch nie einen wirklichen vorteil genannt, immer nur so kleinigkeiten, die manchmal gut, aber oft auch weniger gut sind. vielleicht gibt es keine echten vorteile?

[Mr. N]

pale dog schrieb:

CStoll schrieb:

...und wir haben auch kein Problem damit, int-Variablen zu konstruieren

bitweise? oder darf's auch schneller gehen?

Da wird nicht wirklich ein Konstruktor aufgerufen.

int i(0); //in C++
int i = 0; /*in C*/

Beides ist exakt gleich schnell.

pale dog schrieb:

du hast noch nie einen wirklichen vorteil genannt, immer nur so kleinigkeiten, die manchmal gut, aber oft auch weniger gut sind. vielleicht gibt es keine echten vorteile?

Nein, das zeigt eher, dass du mit den genannten Vorteilen nichts anfangen kannst oder willst.

[CStoll]

pale dog schrieb:

CStoll schrieb:

...und wir haben auch kein Problem damit, int-Variablen zu konstruieren

bitweise? oder darf's auch schneller gehen?

Wen kümmern solche Details - wichtig ist nur, daß am Ende ein fertiger int-Wert dasteht. (wie man dorthin kommt, ist das Problem desjenigen, der die Klasse int geschrieben hat - also des Compiler-Herstellers

CStoll schrieb:

Und inzwischen hab' sogar ich es aufgegeben, ihm die Vorteile von C++ nahebringen zu wollen...

du hast noch nie einen wirklichen vorteil genannt, immer nur so kleinigkeiten, die manchmal gut, aber oft auch weniger gut sind. vielleicht gibt es keine echten vorteile?

Nein, ich fange die Diskussion nicht wieder an, hat bei dir ohnehin keinen Sinn (Scheuklappen sind ja eine feine Sache, aber du solltest deine mal absetzen ;)).

[Xin]

pale dog schrieb:

Xin schrieb:

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

wer hat sich eigentlich so einen schwachsinn einfallen lassen?

Es ist kein Schwachsinn, es ist sogar sehr sinnvoll, da bei einer Zuweisung erst das Objekt a erzeugt würde, anschließend ein temporäres Objekt, um dann das Objekt 'a' wieder zu zerstören, weil man das temporäre Objekt drüberkopiert, um das temporäre Objekt dann wieder zu zerstören.

Man spart also viel Zeit damit, das "=" hier als Initialisierung zu verstehen, statt als Zuweisung.

Im Gegenzug bedeutet "=" dann aber eben nicht Zuweisung, sondern mal Zuweisung und mal Initialisierung, je nach Kontext.
Was für den Programmierer im ersten Augenblick einfacher ist, weil er sich nicht von C kommend umgewöhnen muss, bedeutet für die Sprache eine zusätzliche Sonderbedingung. Die Sprache wird damit 'unsauber'.
Das mag 99,9% der Progammierer nicht negativ auffallen, 99% fällt es vermutlich gar nicht auf.

Es ändert aber nichts daran, dass "=" trotzdem ein kontextabhängiger Operator ist. Wer sich also in Basic ärgert, dass "=" hier Zuweisung und da Vergleich darstellt, sollte sich im klaren sein, dass C++ auch nicht vollkommen kontextfrei ist.

Mr. N schrieb:

pale dog schrieb:

CStoll schrieb:

...und wir haben auch kein Problem damit, int-Variablen zu konstruieren

bitweise? oder darf's auch schneller gehen?

Da wird nicht wirklich ein Konstruktor aufgerufen.

int i(0); //in C++
int i = 0; /*in C*/

Beides ist exakt gleich schnell.

Ähh... das mit dem Konstruktor kann man so nicht sagen, da derartige Dinge logischerweise 'inline' ablaufen.
Von der Sprachlogik her, ruft die Initialisierung den Konstruktor von int, welcher in diesem Fall den Setter für int ruft, welcher den ASM Befehl 'move #0, Addr_von_i' schreibt.
Im zweiten Fall wird lediglich der Setter aufgerufen, was den gleichen Assemblerbefehl ergibt.
Im Endprodukt kommen in beiden Fällen lediglich die Ausgabe der Setterfunktion für i raus, ergo ist beides gleich schnell.

Dass Du von einem Konstruktor nicht direkt etwas mitbekommst, muss nicht zwangsläufig bedeuten, dass es keinen gibt.

[this-*gt*that]

Xin schrieb:

pale dog schrieb:

Xin schrieb:

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

wer hat sich eigentlich so einen schwachsinn einfallen lassen?

Es ist kein Schwachsinn, es ist sogar sehr sinnvoll, da bei einer Zuweisung erst das Objekt a erzeugt würde, anschließend ein temporäres Objekt, um dann das Objekt 'a' wieder zu zerstören, weil man das temporäre Objekt drüberkopiert, um das temporäre Objekt dann wieder zu zerstören.

Man spart also viel Zeit damit, das "=" hier als Initialisierung zu verstehen, statt als Zuweisung.

Im Gegenzug bedeutet "=" dann aber eben nicht Zuweisung, sondern mal Zuweisung und mal Initialisierung, je nach Kontext.
Was für den Programmierer im ersten Augenblick einfacher ist, weil er sich nicht von C kommend umgewöhnen muss, bedeutet für die Sprache eine zusätzliche Sonderbedingung. Die Sprache wird damit 'unsauber'.
Das mag 99,9% der Progammierer nicht negativ auffallen, 99% fällt es vermutlich gar nicht auf.

Es ändert aber nichts daran, dass "=" trotzdem ein kontextabhängiger Operator ist. Wer sich also in Basic ärgert, dass "=" hier Zuweisung und da Vergleich darstellt, sollte sich im klaren sein, dass C++ auch nicht vollkommen kontextfrei ist.

Nicht vollkommen kontextfrei? lol?
Ich sag nur: *, <, =, &, ++, -- usw.

Ich hab den Thread nicht gelesen (warum auch, is ja eh immer das selbe), aber ich finde es auch nicht gerade elegant, dass Foo f = 2 eine Initialisierung ist. Hab schon seeehr oft gesehen, dass Anfänger fest davon überzeugt sind, dass das eine Zuweisung (operator= ist) - was ja auch konsequenter wäre.

[pale dog]

Xin schrieb:

pale dog schrieb:

Xin schrieb:

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

wer hat sich eigentlich so einen schwachsinn einfallen lassen?

Es ist kein Schwachsinn, es ist sogar sehr sinnvoll, da bei einer Zuweisung erst das Objekt a erzeugt würde, anschließend ein temporäres Objekt, um dann das Objekt 'a' wieder zu zerstören, weil man das temporäre Objekt drüberkopiert, um das temporäre Objekt dann wieder zu zerstören.

mal angenommen es würde wirklich so ablaufen (was ich nicht glauben kann) - aber wozu? wieso so umständlich?
würde es nicht völlig reichen, ein objekt 'a' (egal wie es aussieht, ob nun eingebauter datentyp oder selbstdefiniert) zu erzeugen und es dann mit '4' zu initialisieren?

[CStoll]

Du bist doch derjenige hier, der auch das letzte Quentchen Geschwindigkeit aus dem Code rausquetschen will (und jetzt denk mal daran, daß dort nicht unbedingt ein int stehen könnte, sondern ein echt großes Objekt, bei dem jeder Ctor-Aufruf eine halbe Ewigkeit benötigt)

[pale dog]

CStoll schrieb:

...und jetzt denk mal daran, daß dort nicht unbedingt ein int stehen könnte, sondern ein echt großes Objekt, bei dem jeder Ctor-Aufruf eine halbe Ewigkeit benötigt

dann wäre der von Xin beschriebene ablauf ja umso schlimmer, oder verstehe ich jetzt irgendwas nicht?

[CStoll]

pale dog schrieb:

CStoll schrieb:

...und jetzt denk mal daran, daß dort nicht unbedingt ein int stehen könnte, sondern ein echt großes Objekt, bei dem jeder Ctor-Aufruf eine halbe Ewigkeit benötigt

dann wäre der von Xin beschriebene ablauf ja umso schlimmer, oder verstehe ich jetzt irgendwas nicht?

Er hat's erkannt - und genau aus diesem Grund ist der Ausdruck T b=a; keine (Default)Konstruktion mit anschließender Zuweisung, sondern eine direkte Initialisierung (und um konsistent zu bleiben, gilt das nicht nur für (potentiell große) UDT's, sondern auch für Built-in's).

[Mr. N]

Xin schrieb:

Mr. N schrieb:

pale dog schrieb:

CStoll schrieb:

...und wir haben auch kein Problem damit, int-Variablen zu konstruieren

bitweise? oder darf's auch schneller gehen?

Da wird nicht wirklich ein Konstruktor aufgerufen.

int i(0); //in C++
int i = 0; /*in C*/

Beides ist exakt gleich schnell.

Ähh... das mit dem Konstruktor kann man so nicht sagen, da derartige Dinge logischerweise 'inline' ablaufen.
Von der Sprachlogik her, ruft die Initialisierung den Konstruktor von int, welcher in diesem Fall den Setter für int ruft, welcher den ASM Befehl 'move #0, Addr_von_i' schreibt.
Im zweiten Fall wird lediglich der Setter aufgerufen, was den gleichen Assemblerbefehl ergibt.
Im Endprodukt kommen in beiden Fällen lediglich die Ausgabe der Setterfunktion für i raus, ergo ist beides gleich schnell.

Dass Du von einem Konstruktor nicht direkt etwas mitbekommst, muss nicht zwangsläufig bedeuten, dass es keinen gibt.

Doch. int hat keinen Konstruktor. Versuch mal, int::int(0) aufzurufen.

Ach ja, meistens reicht doch sowas wie

xor rbx,rbx

um eine Variable i zu initialisieren...

[minhen]

Mr. N schrieb:

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.

Das ist natürlich Blödsinn. Wenn würde man natürlich eine deklarative Sprache, bei der man also eher die Lösungen statt die Lösungswege beschreibt, verwenden. Und von diesen deklarativen Sprachen eignen sich Logik-Programmiersprachen besonders gut, da dort die Übersetzung aufgrund der logischen Struktur natürlicher Sprachen besonders einfach ist.
So reicht schon eine handvoll Zeilen aus um ein Programm in Prolog zu schreiben, welches sehr einfache deutsche Sätze "versteht" und mit ihnen arbeiten kann (gerade spaßeshalber getestet - 11 Zeilen hab ich gebraucht). Das ist eine Sache von wenigen Minuten.
Solange man sich auf Ausschnitte der natürlichen Sprache beschränkt - die aber keinesfalls trivial sein müssen! - ist das ganze überhaupt kein Problem.
Der Grund warum es sowas nicht gibt ist eher der, dass es nicht produktiv wäre. Ein Aufsatz ist, wie man sich leicht vorstellen kann, schwerer zu warten als ein prägnant formulierter Programmcode. Das ist vielleicht auch ein Grund, weshalb C-Syntax so populär ist. "begin" und "end" sind halt nicht so prägnant wie "{" und "}".