[Split von 'Eigene Klassenbibliothek'] Diskussionen um Parser

Kellerautomat

Mit dynamischen Operatoren meinte ich selbstdefinierte, richtig. Zunaechst einmal ist es so, dass man zwischen selbst definierten Operatoren und selbst definierten Overloads unterscheiden muss. Bevor ein Operator ueberladen werden kann, muss er erstmal definiert sein. Da gibt es natuerlich die built-in Definitionen, aber man kann sich auch seine eigenen bauen (Syntax aendert sich gefuehlt jede Woche mal):

// neuer Operator $$
// Symbol $$, binaer mit Prioritaet 42, links-assoziativ
operator $$ binary(42, left);

Sobald man den definiert hat, kann man diesen ganz normal ueberladen, wie man es in C++ auch tun wuerde.
Eine symantische Analyse ist damit nicht wirklich erforderlich, da es keine semantisch "falschen" Operator Definitionen gibt. Die beiden Parserschritte koennen daher direkt hintereinander ausgefuehrt werden. Das einige, was geprueft werden muss, ist dass es nicht mehrere wiederspruechige Definitionen gibt. Man kann einen Operator durchaus als binaer und unaeren prefix/postfix gleichzeitig definieren, allerdings niemals alle 3, da es dann zu Mehrdeutigkeiten kommen koennte.

Zu deinem Beispiel: Es wird beim aufbauen des ASTs zunaechst angenommen, dass es ein gueltiger Operator ist und der OpSeq Knoten erstellt. Sobald alles geparsed wurde, habe ich eine Liste aller definierten Operatoren sowie eine Liste aller OpSeqs vorliegen und kann im zweiten Parseschritt - dem Zerlegen aller OpSeqs - nachsehen, ob der Operator tatsaechlich existiert. Ob dieser Operator-Overload dann fuer die gegebenen Argument-Typen existiert, ist eine ganz andere Frage und wird erst bei der semantischen Analyse geprueft.

Xin

Kellerautomat schrieb:

Zunaechst einmal ist es so, dass man zwischen selbst definierten Operatoren und selbst definierten Overloads unterscheiden muss.

Finde ich gut.

Kellerautomat schrieb:

// neuer Operator $$
// Symbol $$, binaer mit Prioritaet 42, links-assoziativ
operator $$ binary(42, left);
Sobald man den definiert hat, kann man diesen ganz normal ueberladen, wie man es in C++ auch tun wuerde.

Ich habe noch keine dynamischen Operatoren, ich tue mich derzeit an zwei Dingen schwer: der Magic-Number "42" - wobei mir auch noch nichts besseres eingefallen ist - und "left". Ich bin sowieso schon leicht inflationär was Schlüsselwörter angeht. Selbiges mit binary.
Wie sieht's mit ternärer Operatoren aus?

Kellerautomat schrieb:

Die beiden Parserschritte koennen daher direkt hintereinander ausgefuehrt werden. Das einige, was geprueft werden muss, ist dass es nicht mehrere wiederspruechige Definitionen gibt. Man kann einen Operator durchaus als binaer und unaeren prefix/postfix gleichzeitig definieren, allerdings niemals alle 3, da es dann zu Mehrdeutigkeiten kommen koennte.

Präfix-Operatoren gibt's bei mir nicht mehr - mit Ausnahme von 'negativ'. Ich hoffe, das bleibt auch so.

Kellerautomat schrieb:

Zu deinem Beispiel: Es wird beim aufbauen des ASTs zunaechst angenommen, dass es ein gueltiger Operator ist und der OpSeq Knoten erstellt. Sobald alles geparsed wurde, habe ich eine Liste aller definierten Operatoren sowie eine Liste aller OpSeqs vorliegen und kann im zweiten Parseschritt - dem Zerlegen aller OpSeqs - nachsehen, ob der Operator tatsaechlich existiert. Ob dieser Operator-Overload dann fuer die gegebenen Argument-Typen existiert, ist eine ganz andere Frage und wird erst bei der semantischen Analyse geprueft.

Aber bringt das einen erwähnenswerten Vorteil? Du musst den Operator ja sowieso deklarieren, da könnte man die Overloads ja als Deklaration auch gleich verlangen und sich einen Durchgang sparen.
Grundsätzlich finde ich die Idee das Parsen so aufzuteilen aber sehr interessant. Ich denke da aber mehr an Präprozessing.

Kellerautomat

Xin schrieb:

Kellerautomat schrieb:
// neuer Operator $$
// Symbol $$, binaer mit Prioritaet 42, links-assoziativ
operator $$ binary(42, left);
Sobald man den definiert hat, kann man diesen ganz normal ueberladen, wie man es in C++ auch tun wuerde.
Ich habe noch keine dynamischen Operatoren, ich tue mich derzeit an zwei Dingen schwer: der Magic-Number "42" - wobei mir auch noch nichts besseres eingefallen ist - und "left". Ich bin sowieso schon leicht inflationär was Schlüsselwörter angeht. Selbiges mit binary.

Ich gebe dir Recht. Ein Grund, warum ich meine Syntax dafuer dauernd aendere, ist weil ich immer versuche die perfekte Syntax zu bekommen. Ich habe sie noch nicht gefunden.

Xin schrieb:

Wie sieht's mit ternärer Operatoren aus?

Ich habe darueber nachgedacht, aber ich halte den praktischen Nutzen fuer zu gering. Wenn, dann wuerde ich Operatoren so generalisieren, dass man eine beliebige Aritaet haben kann, aber ich bin mir nicht mal sicher, wie man das machen koennte. Das Potential fuer Mehrdeutigkeiten ist riesig, und ich koennte mir vorstellen, dass die Regeln ziemlich kompliziert werden. Falls du irgendwo Literatur dazu hast, immer her damit, das Thema interessiert mich.
Und was ist eigentlich mit einer variablen Anzahl an Argumenten?

Xin schrieb:

Kellerautomat schrieb:

Die beiden Parserschritte koennen daher direkt hintereinander ausgefuehrt werden. Das einige, was geprueft werden muss, ist dass es nicht mehrere wiederspruechige Definitionen gibt. Man kann einen Operator durchaus als binaer und unaeren prefix/postfix gleichzeitig definieren, allerdings niemals alle 3, da es dann zu Mehrdeutigkeiten kommen koennte.

Präfix-Operatoren gibt's bei mir nicht mehr - mit Ausnahme von 'negativ'. Ich hoffe, das bleibt auch so.

Was hast du gegen Praefix-Operatoren? Sollten diese nicht sogar einfacher zu parsen sein als Postfix?

Xin schrieb:

Kellerautomat schrieb:

Zu deinem Beispiel: Es wird beim aufbauen des ASTs zunaechst angenommen, dass es ein gueltiger Operator ist und der OpSeq Knoten erstellt. Sobald alles geparsed wurde, habe ich eine Liste aller definierten Operatoren sowie eine Liste aller OpSeqs vorliegen und kann im zweiten Parseschritt - dem Zerlegen aller OpSeqs - nachsehen, ob der Operator tatsaechlich existiert. Ob dieser Operator-Overload dann fuer die gegebenen Argument-Typen existiert, ist eine ganz andere Frage und wird erst bei der semantischen Analyse geprueft.

Aber bringt das einen erwähnenswerten Vorteil? Du musst den Operator ja sowieso deklarieren, da könnte man die Overloads ja als Deklaration auch gleich verlangen und sich einen Durchgang sparen.

Ich finde es sauberer abzutrennen, aber es sollte kein Problem darstellen, einen syntaktischen Shortcut einzufuehren. Ist ja nur Syntaxzucker.

Xin schrieb:

Grundsätzlich finde ich die Idee das Parsen so aufzuteilen aber sehr interessant. Ich denke da aber mehr an Präprozessing.

Danke, ich hab mir den Ansatz selbst ausgedacht.
Aber was meinst du mit Praeprozessing?

Mechanics

[quote="Kellerautomat"]Wenn, dann wuerde ich Operatoren so generalisieren, dass man eine beliebige Aritaet haben kann, aber ich bin mir nicht mal sicher, wie man das machen koennte.quote]

Meinst du sowas?

($$ a b c d)

Columbo

@Moderator mit Rechten: ggfs. abtrennen

Hihi, mein erster Split! Hoffe ich habe nicht zu viel Verwirrung gestiftet.

Was hast du gegen Praefix-Operatoren? Sollten diese nicht sogar einfacher zu parsen sein als Postfix?

Vielleicht meint er sowas wie a+++b . Entspricht es (a++)+b oder a+(++b) ? Wenn du aber lediglich den Postfix-Operator definierst verschwindet auch die Ambiguität.

Kellerautomat

Mechanics schrieb:

Kellerautomat schrieb:

Wenn, dann wuerde ich Operatoren so generalisieren, dass man eine beliebige Aritaet haben kann, aber ich bin mir nicht mal sicher, wie man das machen koennte.

Meinst du sowas?

($$ a b c d)

int operator $$ ## ?? (int a, int b, int c, int d)
{
    return a + b + c + d;
}

int x = 42 $$ 666 ## 1337 ?? 9001;

Arcoth schrieb:

Kellerautomat schrieb:

Was hast du gegen Praefix-Operatoren? Sollten diese nicht sogar einfacher zu parsen sein als Postfix?

Vielleicht meint er sowas wie a+++b . Entspricht es (a++)+b oder a+(++b) ? Wenn du aber lediglich den Postfix-Operator definierst verschwindet auch die Ambiguität.

Das habe ich ja beretis gesagt: Es darf nur maximal 2 aus {unary prefix, unary postfix, binary} geben, damit es eindeutig ist.
Auf die Regel bin ich selbst draufgekommen, aber aehnliche regeln fuer n-ary Operatoren aufstellen kann ich schwer.

Von formalen Beweisen und der ganzen Theorie hinter Parsing halte ich eh nix, ich bin da praxisorientiert. Wenn ich fuer etwas nicht sinnvolle Regeln aufstellen kann, wie sollen dann erst die Benutzer meine Sprache das Feature einsetzen koennen?

Edit: @Arcoth: Im uebrigen waere die Bedeutung deines Codes in meiner Sprache a +++ b, wobei +++ ein einziger Operator ist. Wer das getrennt haben will, muss Whitespace einfuegen.

Mechanics

Kellerautomat schrieb:

int operator $$ ## ?? (int a, int b, int c, int d)
{
    return a + b + c + d;
}

int x = 42 $$ 666 ## 1337 ?? 9001;

Mir ist jetzt nicht wirklich klar, was das ausdrücken soll.

Kellerautomat

Ein Quartaerer Operator halt.

Bashar

Gibt es sowas in freier Wildbahn? Es ist ja schon schwer, sinnvolle Beispiele für ternäre Operatoren, die Funktionen sind (also nicht ?: ) zu finden.

Kellerautomat

Koennte man z.B. statt Expression Templates zur Optimierung verwenden.

oenone

Bashar schrieb:

Gibt es sowas in freier Wildbahn? Es ist ja schon schwer, sinnvolle Beispiele für ternäre Operatoren, die Funktionen sind (also nicht ?: ) zu finden.

Pythons slice operator wäre ein quartärer Operator:

a[start:end:step]

Xin

Kellerautomat schrieb:

Ich gebe dir Recht. Ein Grund, warum ich meine Syntax dafuer dauernd aendere, ist weil ich immer versuche die perfekte Syntax zu bekommen. Ich habe sie noch nicht gefunden.

Ich frickel jetzt seit 10 Jahren an der Syntax, es kommen laufend neue Ideen, aber der Kern ist inzwischen eigentlich recht fix.
Wichtig ist nur, dass man nicht in vorgegebenen Mustern denkt.

Kellerautomat schrieb:

Was hast du gegen Praefix-Operatoren? Sollten diese nicht sogar einfacher zu parsen sein als Postfix?

Weil es - für mich logischer ist - ein Objekt zu nehmen und dann etwas damit zu machen. Es heißt ja auch nicht method.member<-this(arg1, arg2). oder (arg1, arg2)func. Warum sollte ein Operator also vorne stehen?

Kellerautomat schrieb:

Ist ja nur Syntaxzucker.

Alles ist nur Syntax-Zucker, wenn man nicht in Assembler programmiert. (Und gefälligst ohne Makro-Assembler - wir haben mal eine Grafik-Adventure-Engine in Assembler geschrieben, nur sah man gar nicht, dass es Assembler war... ein guter Assembler kann auch zuckersüß sein)

Xin schrieb:

Aber was meinst du mit Praeprozessing?

#if, #else, #endif

Und den Text dazwischen muss man sich ja auch irgendwie merken.

Arcoth schrieb:

@Moderator mit Rechten: ggfs. abtrennen

Hihi, mein erster Split! Hoffe ich habe nicht zu viel Verwirrung gestiftet.

Klappt doch wunderbar.

Arcoth schrieb:

Was hast du gegen Praefix-Operatoren? Sollten diese nicht sogar einfacher zu parsen sein als Postfix?

Vielleicht meint er sowas wie a+++b . Entspricht es (a++)+b oder a+(++b) ? Wenn du aber lediglich den Postfix-Operator definierst verschwindet auch die Ambiguität.

Ich habe deutlich mehr Postfix-Operatoren. Ich würde mir mit quasi allem in die Quere kommen.

Kellerautomat schrieb:

Mechanics schrieb:

Meinst du sowas?

($$ a b c d)

int operator $$ ## ?? (int a, int b, int c, int d)
{
    return a + b + c + d;
}

int x = 42 $$ 666 ## 1337 ?? 9001;

Denkmuster aufbrechen... eine Möglichkeit:

int operator (int a, "$$", int b, "##", int c, "??", int d );

Ein String in einer Argumentenliste kann kein Argument sein. Also muss er irgendwas anderes bedeuten.

Kellerautomat schrieb:

Von formalen Beweisen und der ganzen Theorie hinter Parsing halte ich eh nix, ich bin da praxisorientiert.

Grundsätzlich unterschreibe ich das auch so... Top-Down, Bottom-Up, Single-Pass, alles gut und schön: Die Sprache muss gut zu programmieren sein, der Rest ist heute das Problem des Parser-Herstellers.
Trotzdem kann es nicht schaden, sich mit der Theorie ein wenig auseinander zu setzen.

Bashar schrieb:

Kellerautomat schrieb:

Ein Quartaerer Operator halt.

Gibt es sowas in freier Wildbahn? Es ist ja schon schwer, sinnvolle Beispiele für ternäre Operatoren, die Funktionen sind (also nicht ?: ) zu finden.

Ich habe vor 10 Jahren eine Umfrage gestartet, was in aktuellen Programmiersprachen fehlt. Die wichtigste Erkenntnis ist, dass Software-Entwickler es sehr schwer haben, Dinge zu vereinfachen, weil sie es gewohnt sind, Probleme mit den Mitteln zu lösen, die sie haben.
Mathematiker, Ingenieure oder Anfänger interessieren sich nicht dafür, dass die Mittel begrenzt sind. Die Sachen sich, da muss es bestimmt ein Werkzeug für geben und wenn nicht, beschwere ich mich. Der Informatiker weiß, es gibt kein Werkzeug und löst sein Problem so.
Die Leute, die Compiler bauen, machen das meistens aus Spaß. Manche bauen auch das Werkzeug, dass ihnen fehlt.
Dass manche Dinge nicht in freier Wildbahn auftauchen liegt oftmals einfach nur daran, dass sich kein Sprachdesigner gefunden hat, der sich fragte, ob es Leute geben könnte, die sowas brauchen könnten, bzw. die sowas praktisch finden. Wer braucht schon ternäre Operatoren? Man kann einen Bruch wie 1 1/2 ja auch in 3/2 schreiben. Oder muss halt den passenden Konstruktor der Klasse Fraction( 1, 1, 2 ) aufrufen. Oder man definiert sich einen Operator 1_1_2, wenn man viel mit Brüchen rechnet, der Fraction( 1, 1, 2 ) aufruft.

Arcoth schrieb:

Vielleicht meint er sowas wie a+++b . Entspricht es (a++)+b oder a+(++b) ? Wenn du aber lediglich den Postfix-Operator definierst verschwindet auch die Ambiguität.

Wo ist da eine Ambiguität? a+++b ist genauso wie a+++++++++b in C++ genau definiert. In K11ts Sprache leicht anders, aber auch wohldefiniert.

Xin schrieb:

Kellerautomat schrieb:

Was hast du gegen Praefix-Operatoren? Sollten diese nicht sogar einfacher zu parsen sein als Postfix?

Weil es - für mich logischer ist - ein Objekt zu nehmen und dann etwas damit zu machen. Es heißt ja auch nicht method.member<-this(arg1, arg2). oder (arg1, arg2)func. Warum sollte ein Operator also vorne stehen?

Verstehe ich nicht. In C++ hast du sowas perverses* wie next(begin(v)) , aber was eigentlich gemeint ist ist "nimm v, nehme davon den Startiterator und inkrementiere diesen". Eine sprechendere Schreibweise wäre z.B. v:begin():next() .

Also nein, func(arg1, arg2) ist Präfix-Notation. Sogar das meiste aus C++ ist Präfix-Notation. Aber Postfix-Notation wäre lesbarer.

*im wahrsten Wortsinn

Xin

Max Munch schrieb:

Xin schrieb:

Warum sollte ein Operator also vorne stehen?

Verstehe ich nicht. In C++ hast du sowas perverses* wie next(begin(v)) , aber was eigentlich gemeint ist ist "nimm v, nehme davon den Startiterator und inkrementiere diesen". Eine sprechendere Schreibweise wäre z.B. v:begin():next() .

Wie steht's mit v.begin()++?
(Ich weiß, dass es in C++ korrekt ++v.begin() heißen würde, aber wie ich schon sagte: Ich habe keine Präfixe)

Das klassenbasierte Programmieren ist doch am Ende nichts anderes, als das Objekt nach vorne zu ziehen und die Handlung - die Methode - als Postfix-Operation dahinter zu setzen.

Schwierig wird's teils bei der STL, wo sich generische und objektorientierte Programmierung in die Quere kommen:

std::next( v.begin(), 1);

Bashar

Xin schrieb:

Bashar schrieb:

Kellerautomat schrieb:

Ein Quartaerer Operator halt.

Gibt es sowas in freier Wildbahn? Es ist ja schon schwer, sinnvolle Beispiele für ternäre Operatoren, die Funktionen sind (also nicht ?: ) zu finden.

Ich habe vor 10 Jahren eine Umfrage gestartet, was in aktuellen Programmiersprachen fehlt. Die wichtigste Erkenntnis ist, dass Software-Entwickler es sehr schwer haben, Dinge zu vereinfachen, weil sie es gewohnt sind, Probleme mit den Mitteln zu lösen, die sie haben.

Ich fürchte, du hast die Frage bzw. ihren Hintergrund anders verstanden, als ich sie gemeint habe. Prinzipiell braucht man Funktionen und Formen (Lisp-Jargon für Ausdrücke, deren Argumente nicht unbedingt ausgewertet werden, z.B. if oder while). Man könnte also z.B. while(less(x,10), assign(x, plus(x,1))) schreiben und damit über die Runden kommen. Operatoren gibt es in erster Linie, um mathematische Operatoren in der Programmiersprache abzubilden, darüber hinaus natürlich aus Bequemlichkeitsgründen. Manche Operatoren sind im Prinzip Funktionen (wie arithmetische Operatoren), manche sind Formen (wie Komma, &&, ||, ?: ). Beim Operatorüberladen (und wie mir scheint, bei euren selbstdefinierten Operatoren) gibt es nur Funktionen. Der einzige ternäre Operator in C++ ist eine Form. Es stellt sich daher die Frage, ob es überhaupt Bedarf dafür gibt, n-äre Operatoren, die Funktionen sind, einzuführen. Was ist das Vorbild in der Mathematik oder sonstwo? Das ist die "freie Wildbahn", die ich meine. Nicht andere Programmiersprachen.

Außerdem ist die Frage nicht als Kritik gemeint (auch wenn sie so klingt, mea culpa), sondern rein interessehalber.

Wer braucht schon ternäre Operatoren? Man kann einen Bruch wie 1 1/2 ja auch in 3/2 schreiben.

1 1/2 ist kein ternärer Ausdruck, sondern ein spezielles Literal. Man kann jedenfalls (in der Mathematik) nicht (1+1) 1/2 oder 2 3/x schreiben.

Mathematiker, Ingenieure oder Anfänger interessieren sich nicht dafür, dass die Mittel begrenzt sind. Die Sachen sich, da muss es bestimmt ein Werkzeug für geben und wenn nicht, beschwere ich mich. Der Informatiker weiß, es gibt kein Werkzeug und löst sein Problem so.

Kannst du dir solche Pauschalaussagen nicht einfach mal abgewöhnen?

oenone schrieb:

Bashar schrieb:

Gibt es sowas in freier Wildbahn? Es ist ja schon schwer, sinnvolle Beispiele für ternäre Operatoren, die Funktionen sind (also nicht ?: ) zu finden.

Pythons slice operator wäre ein quartärer Operator:
a[start:end:step]

Nicht schlecht, aber ich würde das wohl anders designen. Das innere ist ein Range-Ausdruck (immerhin ternär), das [] ist ein binärer Operator. Dadurch werden a[i], a[i:j], a[i:j:k] alle einheitlich behandelt, während das bei dir verschiedene Operatoren sind. (Sorry, zu faul in der Python-Doku nachzulesen, wie es wirklich ist.)

Xin

Bashar schrieb:

Manche Operatoren sind im Prinzip Funktionen (wie arithmetische Operatoren), manche sind Formen (wie Komma, &&, ||, ?: ). Beim Operatorüberladen (und wie mir scheint, bei euren selbstdefinierten Operatoren) gibt es nur Funktionen.

Was hier besprochen wurde bisher, waren lediglich Funktionen.

Bashar schrieb:

Der einzige ternäre Operator in C++ ist eine Form. Es stellt sich daher die Frage, ob es überhaupt Bedarf dafür gibt, n-äre Operatoren, die Funktionen sind, einzuführen. Was ist das Vorbild in der Mathematik oder sonstwo? Das ist die "freie Wildbahn", die ich meine. Nicht andere Programmiersprachen.

Eine interessante Fragestellung. Sonst höre ich immer "Wo ist das Neue, was eine neue Programmiersprache rechtfertigt." Nun kommt "Wo ist das Vorbild?"

Die Frage, ob Bedarf besteht ist interessant. Weil sie eigentlich überflüssig ist, wenn man ein Angebot macht. Wenn Dir jemand vor 10 Jahren erstmals ein Smartphone anbietet sagst Du doch auch nicht "Geh weg oder hast Du schon irgendwo in freier Wildbahn Bedarf für ein Händi gesehen mit dem man Internet surfen kann?"
Die Frage ist wichtig, wenn man ein Angebot entfernt, für das Bedarf besteht. Aber auch in dem Fall hat man bei Java schicke Antworten gefunden, nicht wahr?

Man kann Dinge auch mal implementieren und schauen, was sich daraus entwickelt. Dann lässt sich im Nachhinein sagen: Da bestand ein Bedarf, den man bei der Implementierung so noch nicht gesehen hat. Oder es wird ein Feature, dass keiner braucht und keinen stört.

Bashar schrieb:

Wer braucht schon ternäre Operatoren? Man kann einen Bruch wie 1 1/2 ja auch in 3/2 schreiben.

1 1/2 ist kein ternärer Ausdruck, sondern ein spezielles Literal. Man kann jedenfalls (in der Mathematik) nicht (1+1) 1/2 oder 2 3/x schreiben.

Äh... kann man nicht? Das verstehe ich nicht, mein Mathelehrer hat mir den Umgang mit diesen Termen beigebracht.

Also (1+1) 1/2 ergibt bei mir 1/2 (1+1), also 0,5*2, was nunmal 1 ergibt. 2 3/x ergibt bei mir 2x/x+3/x, was (2x+3)/x entspricht. In der Mathematik hat man sich lediglich noch nicht entschieden, ob kein Operator nun für + oder * steht. Meistens ist es eine Multiplikation, vor einem Bruch wird es gerne als Addition verwandt. Entsprechend ist die Schreibweise eher zu vermeiden. Aber schreiben und rechnen kann man es.

Bashar schrieb:

Mathematiker, Ingenieure oder Anfänger interessieren sich nicht dafür, dass die Mittel begrenzt sind. Die Sachen sich, da muss es bestimmt ein Werkzeug für geben und wenn nicht, beschwere ich mich. Der Informatiker weiß, es gibt kein Werkzeug und löst sein Problem so.

Kannst du dir solche Pauschalaussagen nicht einfach mal abgewöhnen?

Ich gendere auch nicht - darauf wird man hier erstaunlicherweise seltener angesprochen. Eigentlich nie. Aber das sollte man ja nicht pauschalisieren.

Ich hoffe und vertraue darauf, dass die Menschen ihren Verstand soweit nutzen, dass sie meinen Text entsprechend als "Die meisten von mir befragten Mathematikerinnen und Mathematiker, Ingenieurinnen und Ingeneure oder Anfängerinnen und Anfänger" verstehen können, wie sie auch bei "Der Informatiker" selbständig ein "Die Informatikerin oder der Informatiker im Allgemeinen und überlicherweise im deutlichen Gegensatz zu vorgenannten Berufsgruppen" verstehen, damit der Satz irgendwo ein Ende findet

Die Erklärung meiner Gedanken ist den meisten hier eher zu lang, also sei doch bitte erfreut, dass ich schon kürze und man sich auf die Information konzentrieren kann: Dass alleine die Informatikerinnen und Informatiker in meiner Umfrage durch Phantasielosigkeit aufgefallen sind, ihr täglich verwendetetes Werkzeug zu kritisieren. Mehr noch: einzig die Berufsgruppe der Informatikerinnen und Informatiker hat in meiner Umfrage hat die Möglichkeit abgestritten überhaupt noch etwas schaffen zu können, was besser ist als die vorhandenen Werkzeuge.

Ich bin Informatiker, ich kritisiere meine Werkzeuge, das alleine sollte Dir genügen, um zu verstehen, dass die Aussage nicht pauschal gemeint sein kann: Ausnahmen bestätigen die Regel.

Und um so abschließend Deine Frage zu beantworten: Nein und es ist von mir auch nicht geplant.

volkard

Xin schrieb:

Ich habe vor 10 Jahren eine Umfrage gestartet, was in aktuellen Programmiersprachen fehlt. Die wichtigste Erkenntnis ist, dass Software-Entwickler es sehr schwer haben, Dinge zu vereinfachen, weil sie es gewohnt sind, Probleme mit den Mitteln zu lösen, die sie haben. … Blah … blah.

Das fasse ich als generelle Beleidigung gegen alle Informatiker auf.

Xin

volkard schrieb:

Xin schrieb:

Ich habe vor 10 Jahren eine Umfrage gestartet, was in aktuellen Programmiersprachen fehlt. Die wichtigste Erkenntnis ist, dass Software-Entwickler es sehr schwer haben, Dinge zu vereinfachen, weil sie es gewohnt sind, Probleme mit den Mitteln zu lösen, die sie haben. … Blah … blah.

Das fasse ich als generelle Beleidigung gegen alle Informatiker auf.

Damit werden wir leben müssen. Man darf sich ja frei entscheiden, ob man sich beleidigt fühlen möchte.

Die Antworten auf die Umfrage habe nicht ich gegeben - und die Antworten wurden nunmal gegeben. In dem Sinne... ich würde es eher als Tatsache auffassen, dass eine Mehrheit der Informatiker (welche an meiner Umfrage teilnahmen) routiniert ihren Job macht, ohne weiter darüber nachzudenken - im Unterschied zu Mathematikern, Ingenieuren oder Anfängern, die nicht über die notwendige Ausbildung verfügten, die Gegebenheiten einfach so zu akzeptieren.

In meinem Studium erhielt ich jedenfalls auch Hinweise auf gute Standard-Tools und Standard-Lösungen, aber keine gewollte Inspiration, auf den Standard zu verzichten oder umzudefinieren und sich besseren Lösungen zu widmen. Auf die Idee muss man ja auch erstmal kommen, einer akzeptierenden Mehrheit zu widersprechen und zu fragen 'Warum ist das eigentlich Standard?' Warum mache ich automatisch was verkehrt, wenn ich es nicht nutze?

Die fehlende Fragestellung entspricht auch meiner Erfahrung mit vielen Informatikern, die wegen Geld entwickeln: Das Problem muss billig gelöst werden - nicht zwangsläufig qualitativ. Diskussion kostet Zeit, also Geld. Für das Problem muss erst entschieden werden in welche Form es passt. Man knetet das Problem solange bis es in eine der bekannten Formen passt. Aber die Formen bleiben immer starr, das Problem muss sich der Form anpassen.

Ich, als Informatiker, kann nur versuchen nicht ganz so kritiklos gegenüber meinen Tools zu sein und jeden Informatiker ermuntern, sich nicht dieser scheinbaren Mehrheit der Informatikern anzuschließen. Dann besteht auch kein Grund, sich angesprochen zu fühlen.
Ich stelle mir die Frage, warum ich kein Tool habe, dass sich dem Problem anpassen kann. Jeder Handwerker kennt Rollgabelschlüssel, die sich der zu schraubenden Mutter anpassen. Warum muss man für jede Mutter eine passende Programmiersprache lernen? Warum gibt es keine größenverstellbaren Programmiersprachen?

Wer sich als Scheuklappen-Informatiker angesprochen fühlt, darf nun beleidigt sein oder überlegen, ob er seine Tools vielleicht etwas zu kritiklos verwendet.

happystudent

Xin schrieb:

Also (1+1) 1/2 ergibt bei mir 1/2 (1+1), also 0,5*2, was nunmal 1 ergibt. 2 3/x ergibt bei mir 2x/x+3/x, was (2x+3)/x entspricht. In der Mathematik hat man sich lediglich noch nicht entschieden, ob kein Operator nun für + oder * steht.

Ne, das ist nicht zulässig. 2 3/x ist ein Term und in einem solchen darf nur die Multiplikation weg gelassen werden. Die von dir beschriebene Darstellung ist nur bei Skalaren gültig.

Die Mathematik ist hier schon eindeutig, du würdest ja auch nicht auf die Idee kommen 22 als 2*2 zu interpretieren, oder?

volkard