Was stört/fehlt euch bei aktuellen Programmiersprachen?

Kellerautomat

Xin schrieb:

Kellerautomat schrieb:

Und wie behandelst du dann Fehler, bei denen am Zeitpunkt des Auftretens nicht bekannt ist, wie sie behandelt werden sollen? Gerade das macht Exceptions doch so praktisch.

Vereinfach ausgedrückt: "false".

Wenn die rufende Funktion kein Ergebnis bekommt, kann sie das vielleicht reparieren.

Wenn ich aber eine Exception schmeiße und 5 Funktionen über mir kommt eine "Division by zero" Exception an, dann kann die damit auch nix mehr anfangen. Ich gehe schön brav Step by Step den Stacktrace hoch. Ein Schritt nach dem anderen, niemals zwei auf einmal. Jeder darf mal kurz überlegen, ob die Rückgabe der Funktion für ihn existenziell wichtig ist, oder ob man da noch was machen kann.

Dann hast du aber in jeder Funktion Fehlerbehandlungscode, was nicht nur ineffizient, sondern auch unglaublich mühsam ist. Was machst du eigentlich in Konstruktoren?

Xin schrieb:

Kellerautomat schrieb:

Man muss es eben explizit sagen. Selbst wenn eine Funktion in der Basklasse überschreibbar ist, wird sie in einer abgeleiteten Klasse automatisch wieder final.

Dass man Ableitungen verbietet, mag ich nicht.

Dass man die Überschreibbarkeit für Ableitungen fordern muss... darüber muss ich nachdenken, ob ich das für eine gute Idee halte.

Und, hast du dir schon eine Meinung gebildet?

Xin schrieb:

Ein Nullable kann Null sein oder nicht. Ein (int*?) könnte entsprechend Null sein oder nullptr oder irgendwo hin zeigen. Das ist nicht semantisch gleichwertig zu (int *), aber ob es ein Mehrwert ist?
Bei int, float und enum ist es unbestritten ein Mehrwert - nur halt die Frage, ob das die Implementierung rechtfertigt und damit die Notwendigkeit das Konstrukt zu erlernen.

Ich bin mir nicht sicher, ob ich einen int*? überhaupt erlauben soll, ähnlich wie man in C++ keinen Zeiger auf eine Referenz erzeugen kann.
Ich halte die Semantik zumindest für fragwürdig und denke, dass das Verwirrung stiften würde.

Bei Klassentypen ist Nullable auch nützlich: Man erkennt am Interface, ob eine Funktion null entgegennehmen/zurückgeben kann, oder nicht. Das füehrt dazu, dass viel null-Behandlungscode wegfällt, der in z.B. Java üblich ist.

Xin schrieb:

Kellerautomat schrieb:

Was willst du damit sagen?

Dass ich es begrüßt hätte, wenn der '='-Operator nicht für als Kopier-Operator missbraucht wird, der von Anfängern dann mit dem '=='-Operator verwechselt wird.

Ich kann das Problem selbst nicht nachvollziehen. Ich glaube, der Fehler ist mir vor ungefähr einem Monat zum ersten mal passiert, und das war um vier Uhr morgens. Wie wärs mit Haskell-Syntax?

x <- 42

Xin schrieb:

Kellerautomat schrieb:

Nichts, das ist ungültiger Code. In Codezeile 3 hättest du = verwenden müssen.

Warum unterscheidest Du dann im Quelltext zwischen Zuweisung und Initialisierung?
Warum muss der Code ungültig sein?

Weil ich finde, dass eine Unterscheidung zwischen Initialisierung und Zuweisung den Code klarer macht. Und wenn, dann verwende ich sie konsistent.
Den Vorteil in Konstruktoren habe ich ja schon genannt:

type Foo
{
	// Memberfunktionen und Kon/Destruktoren sind per default public
	Foo(int x, float y, string z)
	{
		// beliebiger Code, member noch nicht initialisiert
		let temp := someComputation()

		println(.x) // x noch nicht initialisiert, daher read nicht erlaubt --> compiletime error

		.x := x / temp // initialisierung

		if y % 2 == 0
			.y := 42 // nope, bedingte Initialisierung nicht erlaubt --> compiletime error

		// read von .x okay, wurde initialisiert
		.z := .x ~ z
	}

	// Member sind private per default
	int x
	float y
	string z
}

(Syntax noch nicht fertig)
Auf Member greift man explizit mit der .member Syntax zu. In C++ gibt es verschiedene Namenskonventionen, etwa m_Member oder member_. Damit baue ich das fest in die Sprache ein.

Kellerautomat

ipsec schrieb:

Fehlerbehandlung über Rückgabewerte funktioniert, allerdings braucht man dazu Sum-Typen, sonst hat man ein Problem, wenn die Funktion noch einen normalen Rückgabewert hat. Und damit man dann nicht ständig die Rückgabewerte prüfen muss, braucht man auch noch Monaden bzw. Unterstützung für monadische Strukturen.

Tatsächlich sind insbesondere Sum-Typen in Verbindung mit Pattern Matching eines der Dinge, die mir bei vielen Sprachen, auch C++, fehlen.

Über Sum-Typen habe ich nachgedacht, aber ich habe noch keine Idee, wie ich sie in die Sprache integrieren würde. Im Moment halte ich auch andere Dinge für wichtiger.
Von Monaden habe ich leider zu wenig Ahnung, um darüber eine qualifizierte Aussage zu treffen. Ich wollte bei Zeiten mal etwas mehr Haskell lernen.

typique schrieb:

Kellerautomat schrieb:
Was die stdlib angeht, habe ich zwar Ranges geplant, aber noch keine Details. Vermutich würde ich Indizierung in die Sprache einbauen:
let foo := get_other_stuff()

foreach(i, value in foo)
    printfln("% --> %", i, value)
Genau das ist mein Problem mit aktuellen Programmiersprachen: Sie haben viel zu viele Sprachfeatures. Eine Sprache muss schlank und erweiterbar sein und Features sollen von der Library implementiert werden, wenn möglich.

Es gibt sehr viele Features, die ganz nett wären. Und das schlimmste, was man machen kann, ist diese als Special Case in die Sprachdefinition einbauen.

Das sehe ich ähnlich wie Xin. Wichtige Sprachfeatures sollen leicht verfügbar sein.
Vielleicht helfen da automagisch gemanagte Imports, aber das ist ein IDE-Feature. Nicht jeder verwende eine solche IDE.

In C++ jedenfalls ist es furchtbar nervig, dass ich für jede Kleinigkeit was includen muss.

typique schrieb:

Gerade das Indexproblem wäre einfach zu lösen: foo gibt einen Typ zurück, der sich in ein 1-Tupel (Nur Wert) oder 2-Tupel (Index+Wert) umwandeln lässt. Wenn foo eine Map wäre, wären das 1-Tupel (Key-Value-Pair), 2-Tupel (Index + Key-Value-Pair) und 3-Tupel (Index + Key + Value).

Wie implementierst du sowas effizient? Warum muss der Index üeberhaupt im Wert enhalten sein? Der kann einfach mitgezählt werden.
Vielleicht ginge das mit einem Code Generator.

typique schrieb:

Viele der Features, die du genannt hast, lassen sich verallgemeinern und zusammenmergen.

Beispiel:
let int x := void
Wird nur sehr selten gebraucht und wenn, dann lässt sich das durch einen uninitialized<int> lösen, der intern aligned_storage<int> (was sowieso benötigt wird) verwendet. Gewinn: Einfachere Sprache, weniger Fehlerquellen.

Wenn ich es brauche, will ich es einfach verfügbar haben.

Kellerautomat

Xin schrieb:

Kellerautomat schrieb:

Idealerweise kann man Code sowohl zur Lauzeit, als auch zur Compilezeit ausführen, ohne Änderungen. Details habe ich mir aber noch nicht überlegt.

AST-Interpreter.

Ist lustig, wenn man Goto implementiert.

Also ein Interpreter im Compiler. Und der Interpeter JIT-compiled. Compiler im Interpreter im Compiler?

goto werde ich vermutlich nicht einbauen. Habe ich noch nie gebraucht.

Xin schrieb:

Kellerautomat schrieb:

Allerdings weiss ich noch nicht, ob ich Referenzen auf Primitive einführe. const wird es aber definitiv geben.

Beschäftige Dich mit der Frage, inwieweit Du Primitive einführst.

Ich hab mir schon lange den Kopf zerbrochen und bin mir immer noch unsicher. Ich bin kein Freund von "alle Typen sind Klassen", genauso will ich aber nicht reine Primitive wie in Java. Beispielsweise macht es Sinn, dass man Objekte der Klasse BigInteger addieren kann, wenn man auch ints addieren kann. Genauso sollte int aber auch statische Properties haben können wie eine Klasse, etwa .SIZE/.ALIGN oder .MIN/.MAX. Irgendwo muss man eine Linie ziehen, die Frage ist nur wo.

Xin schrieb:

Kellerautomat schrieb:
Sowas nenne ich "flags enum":
enum flags X
{
    foo,
    bar,
    baz = foo | bar
}
Flags sind kein Enums. Darum heißt es bei mir nur flags. Der Rest ist identisch.

Ich hab drüber nachgedacht, ob es enum flags oder nur flags sein soll. Beides sind Aufzählungen an Werten, lediglich verwendet werden sie unterschiedlich. (enum ist ein Oder-Typ, während flags ein Und-Typ ist)
Letztendlich ists aber nur Syntax.

Xin schrieb:

Wenn ich meine Sprache startklar habe, sollten wir uns mal auf eine kühles Getränk treffen und uns über die Syntax austauschen. Mir scheint, wir werden reichlich gemeinsamkeiten finden.

Du bist Deutscher, oder? Etwas weit weg für mich.

Xin

Kellerautomat schrieb:

Dann hast du aber in jeder Funktion Fehlerbehandlungscode, was nicht nur ineffizient, sondern auch unglaublich mühsam ist. Was machst du eigentlich in Konstruktoren?

Zum einen ist es nicht ineffizient, denn Du musst so oder so fragen, ob das Ergebnis einen Sinn ergibt, wenn Du - falls Du unzufrieden bist - throw rufen möchtest.

Außerdem kostet try...catch auch dann, wenn alles super ist.

Konstruktoren sind bei mir im Prinzip normale Funktionen.

Kellerautomat schrieb:

Xin schrieb:

Kellerautomat schrieb:

Man muss es eben explizit sagen. Selbst wenn eine Funktion in der Basklasse überschreibbar ist, wird sie in einer abgeleiteten Klasse automatisch wieder final.

Dass man Ableitungen verbietet, mag ich nicht.

Dass man die Überschreibbarkeit für Ableitungen fordern muss... darüber muss ich nachdenken, ob ich das für eine gute Idee halte.

Und, hast du dir schon eine Meinung gebildet?

Nein.

Kellerautomat schrieb:

Xin schrieb:

Ein Nullable kann Null sein oder nicht. Ein (int*?) könnte entsprechend Null sein oder nullptr oder irgendwo hin zeigen. Das ist nicht semantisch gleichwertig zu (int *), aber ob es ein Mehrwert ist?
Bei int, float und enum ist es unbestritten ein Mehrwert - nur halt die Frage, ob das die Implementierung rechtfertigt und damit die Notwendigkeit das Konstrukt zu erlernen.

Ich bin mir nicht sicher, ob ich einen int*? überhaupt erlauben soll, ähnlich wie man in C++ keinen Zeiger auf eine Referenz erzeugen kann.
Ich halte die Semantik zumindest für fragwürdig und denke, dass das Verwirrung stiften würde.

Dann baust Du Sonderbedingungen ein.

Kellerautomat schrieb:

Bei Klassentypen ist Nullable auch nützlich: Man erkennt am Interface, ob eine Funktion null entgegennehmen/zurückgeben kann, oder nicht. Das füehrt dazu, dass viel null-Behandlungscode wegfällt, der in z.B. Java üblich ist.

Wow, das klingt echt gut!

In der PM stand 2005 ein Bericht, dass Autos per Funk den Ampeln ein Signal geben können, so dass die Ampeln rechtzeitig auf Grün schalten können, damit man nachts nicht einsam und verlassen an einer roten Ampel stehen müsste. Das ist natürlich Zukunftsmusik bis alle Fahrzeuge mit dem passenden Sender ausgestattet sind und die Ampeln mit dem entsprechenden Empfänger.

Ein Leserbrief erklärte, dass man die Ampeln auch abschalten kann und sich die Autofahrer an den daran befestigten Schildern über die Vorfahrt informieren könnte.

Bau Dir kein aufwendige Problemlösung für ein bereits perfekt gelöstes Problem:
Eine Nullable-Reference heißt in C++ Pointer.

Kellerautomat schrieb:

Xin schrieb:

Kellerautomat schrieb:

Was willst du damit sagen?

Dass ich es begrüßt hätte, wenn der '='-Operator nicht für als Kopier-Operator missbraucht wird, der von Anfängern dann mit dem '=='-Operator verwechselt wird.

Ich kann das Problem selbst nicht nachvollziehen. Ich glaube, der Fehler ist mir vor ungefähr einem Monat zum ersten mal passiert, und das war um vier Uhr morgens. Wie wärs mit Haskell-Syntax?
x <- 42

Ich habe bei CSS abgeguckt.

x: 42;

:= ist mir zu lang, dafür wird die Wert-Zuweisung zu oft benutzt.

Der Vergleich ist ==. Die Gleichsetzung (enums, flags) erfolgt mit =. Grundsätzlich versuche ich den = Operator allerdings eher klein zu halten, weil es die Leute so oder so schon nerven wird, wenn sie Zuweisungen mit = eingeben und dann Fehlermeldungen erhalten. Dann sollten sie wenigstens aussagekräftig und unmissverständlich sein. Das wird schwierig, wenn = im Alltag nicht klar aussortiert werden kann.

Kellerautomat schrieb:

Weil ich finde, dass eine Unterscheidung zwischen Initialisierung und Zuweisung den Code klarer macht. Und wenn, dann verwende ich sie konsistent.

Eigentlich finde ich den Unterschied als Entwickler uninteressant.
Es wäre nur schön, wenn das Objekt existiert, wenn ich es erstmal nutze.

Kellerautomat schrieb:

if y % 2 == 0
			.y := 42 // nope, bedingte Initialisierung nicht erlaubt --> compiletime error

Genau das will ich haben. Bedingte Initialisierung.

Kellerautomat schrieb:

Auf Member greift man explizit mit der .member Syntax zu. In C++ gibt es verschiedene Namenskonventionen, etwa m_Member oder member_. Damit baue ich das fest in die Sprache ein.

Hehehe, hast Du Zugriff auf mein Wiki?
Das habe ich mir bei Visual Basic abgeguckt, wenn ich mich recht entsinne.

Du benutzt diese .member Syntax hier bei Funktionen?

Ethon

Ich verstehe das Argument gegen Exceptions nicht. Warum sind Exceptions schlecht nur weil der Programmierer zu faul ist sie am richtigen Ort zu behandeln?
Aber lieber ne Exception die bis zu main durchfliegt als ignorierte Fehlerbehandlung in den tieferen Funktionen was zu komplett undefinierten Verhaltens des Programm führt.
Lieber ne ConfigNotFound Exception als ein Programm das am Rad dreht weil es meint ne Config eingelesen zu haben obwohl gar keine da war.

krümelkacker

Kellerautomat schrieb:

krümelkacker schrieb:

Ich hätte gerne concepts light².

Damit meinst du was?

ein ausgefeiltes concepts light
wie auch immer das dann aussehen wird.

Kellerautomat schrieb:

krümelkacker schrieb:
Ich hätte gern eine bessere Tuple-Unterstützung. Zum Beispiel so etwas wie folgende syntaktische Abkürzung
tuple<int,int&,double&> get_stuff();

int main() {
  {a,b,const& c} = get_stuff();
  cout << a;
  cout << b;
  cout << c;
}
für so etwas:
tuple<int,int&,double&> get_stuff();

int main() {
  tuple<int,int,const double&> abc = get_stuff();
  cout << std::get<0>(abc);
  cout << std::get<1>(abc);
  cout << std::get<2>(abc);
}
Etwas ähnliches gibt es schon: std::tie.
Mit Pattern Matching liesse sich das in meiner Sprache so schreiben:
let { a, b, c } := get_stuff()
Allerdings weiss ich noch nicht, ob ich Referenzen auf Primitive einführe. const wird es aber definitiv geben.

std::tie ist mir bekannt. Du musst die Variablen allerdings vorher definieren, ggf initialisieren (über tie bekommst du nur eine Zuweisung) und hast damit auch keine Typdeduktion mehr.

Xin

Ethon schrieb:

Ich verstehe das Argument gegen Exceptions nicht. Warum sind Exceptions schlecht nur weil der Programmierer zu faul ist sie am richtigen Ort zu behandeln?
Aber lieber ne Exception die bis zu main durchfliegt als ignorierte Fehlerbehandlung in den tieferen Funktionen was zu komplett undefinierten Verhaltens des Programm führt.
Lieber ne ConfigNotFound Exception als ein Programm das am Rad dreht weil es meint ne Config eingelesen zu haben obwohl gar keine da war.

Die Frage geht wohl an mich.

Im Grundgedanken liegst Du richtig. Exceptions sind ja auch nicht von dummen Leuten ohne Grund eingeführt worden. Genau das ist das Konzept.

Es gibt zwei Strategien Sprachfeatures (das gilt also nicht nur für Exceptions) zu bewerten: Das Sprachfeature ist gut, wenn sich der Mensch daran diszipliniert halten würde und das Sprachfeature ist schlecht, weil der Mensch der Mensch sich nicht diszipliniert daran halten kann.

Exceptions haben nur dann einen Vorteil, wenn sie behandelt werden. Als Entwickler willst Du aber oftmals erstmal Deinen Algorithmus laufen haben, so dass sich unter try ein catch-All wiederfindet. Wenn Du mal professionell entwickelt hast, wirst Du weiterhin mal erlebt haben, dass laufend ein Projektmanager in der Tür steht und fragt, ob Du jetzt fertig bist und Dir neue Aufgaben gibt. Außerdem ist die aktuelle gerade nicht so wichtig und eigentlich ja auch fertig - läuft ja.

Du wirst in dem Code also reichlich Catch-All finden - die Exception fliegt also nicht zu main durch. Damit sind sämtliche Fehlerindizien weg. Aber das Programm eiert nun genauso rum, wie eine nicht abgefangene Fehlerbehandlung. Du erhältst also irgendwo eine valide Exception, die Dich darauf hinweist (idealerweise kommt wenigstens die zweite durch, aber muss ja nicht). Das ganze wird also recht willkürlich, weil die Exception in einem Bereich auftritt, der mit (eigentlich) validen Daten gefüttert wird auch perfekt getestet ist. Das Catch-All verheimlicht aber, dass es einen Fall gibt, wo die Daten nicht valide sind. Das findet kein Mensch mehr, besonders, wenn erst die dritte oder vierte Exception in der Reihe zum User durchdringt.

Debuggt man durch Exceptions findet man sich im Schadensfall nicht mehr an der Stelle, wo der Fehler passiert ist. Der Stackframe ist weg. Eventuell löst der Abbau des Stackframes auch neue, andere Exceptions aus.

Auch die Catch-Anweisung ist fehleranfällig. Gerne werden Exceptions voneinander abgeleitet. Ein Catch behandelt dann auf einmal eine Oberklasse eines Fehlers, ist aber auf die Spezialisierung gar nicht ausgelegt. Der Fehler wird behandelt, aber eben nicht korrekt. Eclipse fördert das auch, in dem es vorschlägt, statt mehrerer Spezialisierungen diese durch die Oberklasse zusammen zu fassen. Bei catch kommt dann nur noch "allgemeiner Programmfehler" an, der muss behandelt werden und das tun die Leute auch. Nur weiß halt keiner, was er eigentlich behandeln müsste und schon haben wir wieder ein Catch-All, weil der Algorithmus muss fertig werden.
Exceptions waren in meiner bisherigen Karriere für mehr Fehler verantwortlich als die eigentlichen Algorithmen, deren Fehlerbehandlung sie übernehmen sollten.

Wenn man nun erklärt, dass der Programmierer schuld ist, weil er Exceptions falsch benutzt, dann ist das korrekt. Meiner Erfahrung nach ist die Fehlerbehandung mit Exceptions in größeren Projekten nicht mehr möglich, weil sie sich über das ganze Programm verstreut, statt sich in dem kleinen Rahmen abzuspielen, der für genau einen Funktionsaufruf gilt. Hier kann ich diszipliniert arbeiten.

Ich gehe den zweiten Ansatz. Der Programmierer kann ein großes Projekt nicht überblicken, also muss ich Konstrukte vermeiden, die ihm zu Fehlern drängen. Exceptions gehören für mich dazu.

Kellerautomat

Xin schrieb:

Kellerautomat schrieb:

Dann hast du aber in jeder Funktion Fehlerbehandlungscode, was nicht nur ineffizient, sondern auch unglaublich mühsam ist. Was machst du eigentlich in Konstruktoren?

Zum einen ist es nicht ineffizient, denn Du musst so oder so fragen, ob das Ergebnis einen Sinn ergibt, wenn Du - falls Du unzufrieden bist - throw rufen möchtest.

Außerdem kostet try...catch auch dann, wenn alles super ist.

Wenn ich davon ausgehen kann, dass im Fehlerfall eine Exception geworfen wird, muss ich gar nichts prüfen.
Bei einem ordentlichen Compiler kosten Exceptions gar nichts, solange sie nicht geworfen werden. Siehe http://lazarenko.me/2011/07/22/c-exception-handling-and-performance/.

Xin schrieb:

Konstruktoren sind bei mir im Prinzip normale Funktionen.

Das heisst, sie können etwas zurückgeben? Ruft man die explizit auf?

Xin schrieb:

Kellerautomat schrieb:

Ich bin mir nicht sicher, ob ich einen int*? überhaupt erlauben soll, ähnlich wie man in C++ keinen Zeiger auf eine Referenz erzeugen kann.
Ich halte die Semantik zumindest für fragwürdig und denke, dass das Verwirrung stiften würde.

Dann baust Du Sonderbedingungen ein.

Nur weil ich definiere, was int*? bedeutet, wird das Konstrukt nicht besser. Wenn sich jedes Mal jemand fragt, was die genaue Semantik davon ist, ist es besser, es gleich nicht zu erlauben.

Xin schrieb:

Kellerautomat schrieb:

Bei Klassentypen ist Nullable auch nützlich: Man erkennt am Interface, ob eine Funktion null entgegennehmen/zurückgeben kann, oder nicht. Das füehrt dazu, dass viel null-Behandlungscode wegfällt, der in z.B. Java üblich ist.

Wow, das klingt echt gut!

In der PM stand 2005 ein Bericht, dass Autos per Funk den Ampeln ein Signal geben können, so dass die Ampeln rechtzeitig auf Grün schalten können, damit man nachts nicht einsam und verlassen an einer roten Ampel stehen müsste. Das ist natürlich Zukunftsmusik bis alle Fahrzeuge mit dem passenden Sender ausgestattet sind und die Ampeln mit dem entsprechenden Empfänger.

Ein Leserbrief erklärte, dass man die Ampeln auch abschalten kann und sich die Autofahrer an den daran befestigten Schildern über die Vorfahrt informieren könnte.

Bau Dir kein aufwendige Problemlösung für ein bereits perfekt gelöstes Problem:
Eine Nullable-Reference heißt in C++ Pointer.

Ich kann deiner Analogie leider nicht folgen.
Pointer möchte ich, soweit möglich, ersetzen. Nicht, dass ich Pointer für schlecht halte, aber es gibt für die meisten Fälle sicherere Alternativen. Zumal Objekte, wie schon gesagt, per default Reference-Counted sind - ein roher Pointer hat da nicht die richtigen Kopiersemantiken.

Und nur, um es nochmal hervorzuheben: Eine Referenz ist bei mir - anders als in Java - NICHT nullable. T? ist das, was T in Java ist - mit dem Unterschied, dass es auch mit Primitiven funktioniert.

Xin schrieb:

Ich habe bei CSS abgeguckt.
x: 42;
:= ist mir zu lang, dafür wird die Wert-Zuweisung zu oft benutzt.

Der Vergleich ist ==. Die Gleichsetzung (enums, flags) erfolgt mit =. Grundsätzlich versuche ich den = Operator allerdings eher klein zu halten, weil es die Leute so oder so schon nerven wird, wenn sie Zuweisungen mit = eingeben und dann Fehlermeldungen erhalten. Dann sollten sie wenigstens aussagekräftig und unmissverständlich sein. Das wird schwierig, wenn = im Alltag nicht klar aussortiert werden kann.

Gefällt mir persönlich überhaupt nicht. Ist halt Geschmackssache.

Xin schrieb:

Kellerautomat schrieb:

Weil ich finde, dass eine Unterscheidung zwischen Initialisierung und Zuweisung den Code klarer macht. Und wenn, dann verwende ich sie konsistent.

Eigentlich finde ich den Unterschied als Entwickler uninteressant.
Es wäre nur schön, wenn das Objekt existiert, wenn ich es erstmal nutze.

Kellerautomat schrieb:
if y % 2 == 0
			.y := 42 // nope, bedingte Initialisierung nicht erlaubt --> compiletime error
Genau das will ich haben. Bedingte Initialisierung.

Das glaube ich nicht. Ich glaube eher, du willst abhängig von einer Bedingung mit einem von zwei Werten initialisieren. Das kannst du mit einer temporären Variable oder ?:.

Xin schrieb:

Kellerautomat schrieb:

Auf Member greift man explizit mit der .member Syntax zu. In C++ gibt es verschiedene Namenskonventionen, etwa m_Member oder member_. Damit baue ich das fest in die Sprache ein.

Hehehe, hast Du Zugriff auf mein Wiki?
Das habe ich mir bei Visual Basic abgeguckt, wenn ich mich recht entsinne.

Du benutzt diese .member Syntax hier bei Funktionen?

VB kann ich nicht mal, nie gelernt. Ich kam von selbst auf die idee :p

.member lässt sich innerhalb von Methoden, Konstruktoren und Destruktoren verwenden. Bzw., es muss verwendet werden.

ipsec

Bezüglich Exceptions:

Ich verstehe das Beispiel mit loadConfig . Wenn die Datei nicht da ist, muss sich die Funktion darum kümmern, irgendwo anders die Config herzubekommen, oder eine neue anzulegen, oder ähnliches. Es wäre falsch, wenn die Exception einfach durchrauscht. Aber loadConfig ruft getFileContents auf und das wiederum openFile . Und was soll nun getFileContents machen, wenn openFile einen Fehler erzeugt? Es kann diesen nur weiter geben, es ist gar nicht in der Position, selbstständig Entscheidungen zu treffen.

In der Regel gibt es sehr viele dieser Hilfsfunktionen. Und in diesen ist das Standardmuster meistens das folgende:

func1();
if(fehler) return fehler;
func2();
if(fehler) return fehler;
usw.

Exception bieten genau das als Voreinstellung, auch über mehrere Ebenen hinweg. Und auf den oberen Ebenen können die Funktionen, die die Anwendungslogik abbilden (z.B. loadConfig ) die Exceptions fangen und basierend darauf Entscheidungen treffen, wie zu verfahren ist.

Fehlerbehandlung über Rückgabewerte (wie z.B. in Go) auf der anderen Seite erzwingt den Programmierer, die if -Aufrufe aus dem Pseudocode oben immer explizit zu schreiben. Laut meiner Erfahrung macht man das in der Regel nicht, insbesondere, wenn der Fehler unwahrscheinlich ist. Standardbeispiel: wer prüft den Rückgabewert von printf ? Gerade wenn man den Algorithmus erstmal laufen haben will, lässt man die Fehlerbehandlung gerne weg. Das ist hier aber drastischer als im Exception-Fall. Wenn ein Fehler auftritt, ist der Programmzustand in der Regel inkonsistent. Exceptions brechen dann ab und führen das Programm erst dann weiter, wenn jemand meint, sich um den Fehler kümmern zu können. Der Fehler-Rückgabewert wird aber ignoriert und die Programm arbeitet auf einen inkonsistenten Zustand weiter, der Bug taucht dann in der Regel an einer gänzlich anderen Stelle auf.

Fehler über Rückgabewerte haben den Vorteil, dass der Fehler nicht durchs ganze Programm fliegt, aber sie führen zu verschleppten Bugs und außerdem zu unhandlicherem Code. Aus

a();
b();
c();

wird

if(err = a()) return err;
if(err = b()) return err;
if(err = c()) return err;

Aus

return parseConfig(readFileContents(filename))

wird

content, err = readFileContents(filename);
if(err) return nil, err;
conf, err = parseConfig(content);
if(err) return nil, err;
return conf, nil;

Die Fehlerbehandlung wird monoton und man fragt sich, ob einem das nicht abgenommen werden kann.

Im Prinzip kann man die Vorteile vereinen und sowohl lokale Fehler und compilergeprüfte Fehlerbehandlung als auch elegenten Code, der nicht mit Fehlerprüfung durchsetzt ist, haben. Wie gesagt durch Sum-Typen und Monaden. Ich kenne keinen anderen Weg, lasse mich aber auch gerne eines besseren belehren. Insbesondere, Xin, würde mich interessieren, wie du dir das vorgestellt hast und wie du die Probleme umgehen möchtest.

Xin

Kellerautomat schrieb:

Xin schrieb:

Kellerautomat schrieb:

Dann hast du aber in jeder Funktion Fehlerbehandlungscode, was nicht nur ineffizient, sondern auch unglaublich mühsam ist. Was machst du eigentlich in Konstruktoren?

Zum einen ist es nicht ineffizient, denn Du musst so oder so fragen, ob das Ergebnis einen Sinn ergibt, wenn Du - falls Du unzufrieden bist - throw rufen möchtest.

Außerdem kostet try...catch auch dann, wenn alles super ist.

Wenn ich davon ausgehen kann, dass im Fehlerfall eine Exception geworfen wird, muss ich gar nichts prüfen.
Bei einem ordentlichen Compiler kosten Exceptions gar nichts, solange sie nicht geworfen werden. Siehe http://lazarenko.me/2011/07/22/c-exception-handling-and-performance/.

Zwei Kommentare dazu:

try und die } nach try kosten Zeit, denn es muss festgelegt werden wo throw im Fehlerfall hinspringen muss und wenn } erreicht wird, muss die Änderung zurückgenommen werden, damit zum übergeordneten catch-Block gesprungen wird. Scott Meyer beschreibt das in Effektive C++, keine Ahnung in welchem Band.
Wenn Du dir Gedanken darüber machst, wie Du eine Sprache implementierst, muss Dir klar sein, dass Du in einem try anders agierst als außerhalb und diese Änderung musst Du im Programm vermerken und das gibt's nunmal nicht kostenlos.
Das Beispiel mit den zwei Divisionen ist semantisch nicht gleich, entsprechend auch nicht vergleichbar. Es ist vergleichbar unter der Annahme, dass der konstruierte Fall geeignet wäre, einen objektiven Vergleich zu gestalten. Das Exception-Beispiel entspricht nicht dem Beispiel mit dem Rückgabecode, sondern nur dann, wenn der erste Aufruf von divide die gleiche Fehlerbehandlung benötigt, wie der zweite.

Erzeugt die erste Division eine Statusänderung im Programm, so muss die Fehlerbehandlung der zweiten Division das berücksichtigen. Das ganze funktioniert mit zwei divide()-Funktionen, so dass es gut aussieht. Ich mache keine gut aussehenden Features. Ich will praktische Features.

Musst Du die Statusänderung zurücknehmen, zerpflückt sich Deine Fehlerbehandlung. Entweder beginnst Du mit temporären Variablen zu jonglieren oder Du baust ganz sauber um beide divides getrennte try-Catch-Blöcke packen. Viel Aufwand, nur um einen Rückgabecode zu prüfen.

Ansonsten reicht für das Beispiel if( divide(..) && divide(..) ) {} else { einmalige Fehlerbehandlung. }

Der Artikel hat sich einen Show-Case rausgesucht in dem mehrere Annahmen implizit so getroffen werden, dass try-catch sinnvoll erscheint. Ich treffe meine Entscheidungen lieber aus Schwächen in Produktivcode. Meine Erfahrung und darauf aufbauend meine Entscheidung ist, Ausnahmen regelmäßig zu verwenden, ist ziemlicher Mist.

Ich gebe zu, den Rest habe ich mir nicht mehr angeguckt. Die Argumentation hatte ich schon etliche Male und da der Autor mit dem gleichen Blödsinn eröffnet erwarte ich später nichts Neues.

Kellerautomat schrieb:

Xin schrieb:

Konstruktoren sind bei mir im Prinzip normale Funktionen.

Das heisst, sie können etwas zurückgeben? Ruft man die explizit auf?

Die Möglichkeit gibt es.

Bzgl. des Aufrufs spiele ich noch mit einer Reihe von Möglichkeiten.

Kellerautomat schrieb:

Nur weil ich definiere, was int*? bedeutet, wird das Konstrukt nicht besser. Wenn sich jedes Mal jemand fragt, was die genaue Semantik davon ist, ist es besser, es gleich nicht zu erlauben.

Das sehe ich anders, hier käme Willkür ins Spiel. Aber da ich kein int*? in der Semantik habe, also auch kein int?, stellt sich die Frage für mich nicht.

Im Gegensatz zu uninitialized<int> sehe ich nullable<int> tatsächlich als Library-Feature, denn für alle Datentypen lässt sich das notfalls über einen Zeiger ausdrücken, der immer Nullable ist. In C++: int const *: "Da steht das gewünschte int - oder es gibt keins."
Das ist bei int nicht so schön, wie int?, aber funktioniert für alle KlassenObjekte absolut in Ordnung. Für den seltenen Sonderfall der Primitive baue ich kein eigenes Konstrukt.
Die Notwendigkeit für int? sehe ich nicht.

Aber sollten unsere Sprachen weiterhin so große Ähnlichkeit aufweisen, haben wir schonmal einen unbedeutenden Unterschied

Kellerautomat schrieb:

Xin schrieb:

Kellerautomat schrieb:

Bei Klassentypen ist Nullable auch nützlich: Man erkennt am Interface, ob eine Funktion null entgegennehmen/zurückgeben kann, oder nicht. Das füehrt dazu, dass viel null-Behandlungscode wegfällt, der in z.B. Java üblich ist.

Wow, das klingt echt gut!

In der PM stand 2005 ein Bericht, dass Autos per Funk den Ampeln ein Signal geben können, so dass die Ampeln rechtzeitig auf Grün schalten können, damit man nachts nicht einsam und verlassen an einer roten Ampel stehen müsste. Das ist natürlich Zukunftsmusik bis alle Fahrzeuge mit dem passenden Sender ausgestattet sind und die Ampeln rmit dem entsprechenden Empfänger.

Ein Leserbrief erklärte, dass man die Ampeln auch abschalten kann und sich die Autofahrer an den daran befestigten Schildern über die Vorfahrt informieren könnte.

Bau Dir kein aufwendige Problemlösung für ein bereits perfekt gelöstes Problem:
Eine Nullable-Reference heißt in C++ Pointer.

Ich kann deiner Analogie leider nicht folgen.
Pointer möchte ich, soweit möglich, ersetzen. Nicht, dass ich Pointer für schlecht halte, aber es gibt für die meisten Fälle sicherere Alternativen. Zumal Objekte, wie schon gesagt, per default Reference-Counted sind - ein roher Pointer hat da nicht die richtigen Kopiersemantiken.

Hehehe, Du bist der Sprachdesigner. Du entscheidest welche Semantik ein Pointer hat.

Kellerautomat schrieb:

Und nur, um es nochmal hervorzuheben: Eine Referenz ist bei mir - anders als in Java - NICHT nullable. T? ist das, was T in Java ist - mit dem Unterschied, dass es auch mit Primitiven funktioniert.

T ptr ist bei mir, was in Java T ist, was in C++ T * ist, bei Dir T?.
T ist bei mir, was in Java nicht geht, was in C++ T &, bei Dir T.
T copy ist bei mir, was in Java auch nicht geht, in C T und bei Dir...?

ptr sieht erstmal scheiße aus. Das ist beabsichtig. In 95% kann man das ptr weglassen, also mit Referenzen arbeiten. Und genau das ist ja auch das Ziel. Wo kein Null reingehen kann, kann auch keine Null-Pointer-Exception/SegFault kommen.

Kellerautomat schrieb:

Genau das will ich haben. Bedingte Initialisierung.

Das glaube ich nicht. Ich glaube eher, du willst abhängig von einer Bedingung mit einem von zwei Werten initialisieren. Das kannst du mit einer temporären Variable oder ?:.[/quote]
Mit einer temporären Variable?

Natürlich muss das Objekt initialisiert sein, wenn es erstmals initialisiert wird.
Das muss die semantische Analyse halt erfassen.

ipsec schrieb:

Die Fehlerbehandlung wird monoton und man fragt sich, ob einem das nicht abgenommen werden kann.

Shade Of Mine

Xin schrieb:

try und die } nach try kosten Zeit, denn es muss festgelegt werden wo throw im Fehlerfall hinspringen muss und wenn } erreicht wird, muss die Änderung zurückgenommen werden, damit zum übergeordneten catch-Block gesprungen wird. Scott Meyer beschreibt das in Effektive C++, keine Ahnung in welchem Band.
Wenn Du dir Gedanken darüber machst, wie Du eine Sprache implementierst, muss Dir klar sein, dass Du in einem try anders agierst als außerhalb und diese Änderung musst Du im Programm vermerken und das gibt's nunmal nicht kostenlos.

Das ist unter x86 so, unter x64 tun wir eine ip map verwenden. wir erkennen anhand der position des ip welchen zustand wir haben und was wir tun müssen wenn hier eine exception fliegt. kostet nur beim start der anwendung ein paar byte speicher zu laden.

weiter habe ich dann nicht gelesen :p

Xin

Shade Of Mine schrieb:

Das ist unter x86 so, unter x64 tun wir eine ip map verwenden. wir erkennen anhand der position des ip welchen zustand wir haben und was wir tun müssen wenn hier eine exception fliegt. kostet nur beim start der anwendung ein paar byte speicher zu laden.

Warum braucht man dafür eine x64? Ich hatte mir etwas Vergleichbares ausgedacht, aber eben nicht mit try-catch und ich sehe keinen Grund weswegen das mit einem x86 nicht gehen sollte!?

Punkt tut an Dich gehen tun.
Obwohl ich mir das eigentlich hätte denken können, dass man die Implementierung überdenkt, die anderen Compilerentwickler sind ja auch nicht blöd. Wieder was gelernt.
Das macht throw allerdings noch teurer - oder muss man da auch noch was lesen?

Fällt ein Minus-Punkt gegen Exceptions weg. Blöderweise war das eher eine Randnotiz, denn der Aufwand ist/war gering, aber eben nicht kostenlos.

Shade Of Mine schrieb:

weiter habe ich dann nicht gelesen :p

Dass Du die anderen Punkte nicht kommentiert hast, ist auch eine Aussage.

Mal gucken, was der nächste findet. :->

Kellerautomat

Xin schrieb:

Kellerautomat schrieb:

Wenn ich davon ausgehen kann, dass im Fehlerfall eine Exception geworfen wird, muss ich gar nichts prüfen.
Bei einem ordentlichen Compiler kosten Exceptions gar nichts, solange sie nicht geworfen werden. Siehe http://lazarenko.me/2011/07/22/c-exception-handling-and-performance/.

Zwei Kommentare dazu:

try und die } nach try kosten Zeit, denn es muss festgelegt werden wo throw im Fehlerfall hinspringen muss und wenn } erreicht wird, muss die Änderung zurückgenommen werden, damit zum übergeordneten catch-Block gesprungen wird. Scott Meyer beschreibt das in Effektive C++, keine Ahnung in welchem Band.
Wenn Du dir Gedanken darüber machst, wie Du eine Sprache implementierst, muss Dir klar sein, dass Du in einem try anders agierst als außerhalb und diese Änderung musst Du im Programm vermerken und das gibt's nunmal nicht kostenlos.

Nein, da muss nichts festgelegt werden. Das steht in dem Artikel unter "Under the hood" (zero cost exception handling). Ich habe mir das konkrete Beispiel nicht einmal angesehen, es ging mir lediglich um die Funktionsweise. Das hätte ich klarstellen müssen, mein Fehler.

Xin schrieb:

Kellerautomat schrieb:

Xin schrieb:

Konstruktoren sind bei mir im Prinzip normale Funktionen.

Das heisst, sie können etwas zurückgeben? Ruft man die explizit auf?

Die Möglichkeit gibt es.

Bzgl. des Aufrufs spiele ich noch mit einer Reihe von Möglichkeiten.

Welche Möglichkeiten ziehst du bisher in Betracht?

Xin schrieb:

Kellerautomat schrieb:

Nur weil ich definiere, was int*? bedeutet, wird das Konstrukt nicht besser. Wenn sich jedes Mal jemand fragt, was die genaue Semantik davon ist, ist es besser, es gleich nicht zu erlauben.

Das sehe ich anders, hier käme Willkür ins Spiel. Aber da ich kein int*? in der Semantik habe, also auch kein int?, stellt sich die Frage für mich nicht.

Im Gegensatz zu uninitialized<int> sehe ich nullable<int> tatsächlich als Library-Feature, denn für alle Datentypen lässt sich das notfalls über einen Zeiger ausdrücken, der immer Nullable ist. In C++: int const *: "Da steht das gewünschte int - oder es gibt keins."
Das ist bei int nicht so schön, wie int?, aber funktioniert für alle KlassenObjekte absolut in Ordnung. Für den seltenen Sonderfall der Primitive baue ich kein eigenes Konstrukt.
Die Notwendigkeit für int? sehe ich nicht.

Aber sollten unsere Sprachen weiterhin so große Ähnlichkeit aufweisen, haben wir schonmal einen unbedeutenden Unterschied

T? ist aber kein T*, es hat Wertesemantik. Nur werden bei Referenztypen die Referenzen kopiert, nicht die Objekte. Daher entspricht es da quasi einem T*.

Xin schrieb:

Kellerautomat schrieb:

Ich kann deiner Analogie leider nicht folgen.
Pointer möchte ich, soweit möglich, ersetzen. Nicht, dass ich Pointer für schlecht halte, aber es gibt für die meisten Fälle sicherere Alternativen. Zumal Objekte, wie schon gesagt, per default Reference-Counted sind - ein roher Pointer hat da nicht die richtigen Kopiersemantiken.

Hehehe, Du bist der Sprachdesigner. Du entscheidest welche Semantik ein Pointer hat.

Ein Pointer ist wie in C und C++, um Interop zu ermöglichen.

Xin schrieb:

Kellerautomat schrieb:

Und nur, um es nochmal hervorzuheben: Eine Referenz ist bei mir - anders als in Java - NICHT nullable. T? ist das, was T in Java ist - mit dem Unterschied, dass es auch mit Primitiven funktioniert.

T ptr ist bei mir, was in Java T ist, was in C++ T * ist, bei Dir T?.
T ist bei mir, was in Java nicht geht, was in C++ T &, bei Dir T.
T copy ist bei mir, was in Java auch nicht geht, in C T und bei Dir...?

ptr sieht erstmal scheiße aus. Das ist beabsichtig. In 95% kann man das ptr weglassen, also mit Referenzen arbeiten. Und genau das ist ja auch das Ziel. Wo kein Null reingehen kann, kann auch keine Null-Pointer-Exception/SegFault kommen.

Ich finde es schlecht, so viele Arten zu haben, mit Objekten umzugehen. Das überfordert den Otto-Normal Programmierer, und dann kommt Unfug raus. Ich habe T und T?, für Parameter gibt es noch ref und out.

Xin schrieb:

Kellerautomat schrieb:

Xin schrieb:

Genau das will ich haben. Bedingte Initialisierung.

Das glaube ich nicht. Ich glaube eher, du willst abhängig von einer Bedingung mit einem von zwei Werten initialisieren. Das kannst du mit einer temporären Variable oder ?:.

Mit einer temporären Variable?

Natürlich muss das Objekt initialisiert sein, wenn es erstmals initialisiert wird.
Das muss die semantische Analyse halt erfassen.

Du kannst sowas hier machen:

let int tmp := void

if(cond)
	tmp = value1
else
	tmp = value2

.x := tmp

Alternativ mit ?:.

Solltest du tatsächlich eine bedingte Initialisierung wollen, bitte ich um Erklärung wozu. Ich halte das für gefährlich.

Kellerautomat schrieb:

typique schrieb:
Viele der Features, die du genannt hast, lassen sich verallgemeinern und zusammenmergen.

Beispiel:
let int x := void
Wird nur sehr selten gebraucht und wenn, dann lässt sich das durch einen uninitialized<int> lösen, der intern aligned_storage<int> (was sowieso benötigt wird) verwendet. Gewinn: Einfachere Sprache, weniger Fehlerquellen.
Wenn ich es brauche, will ich es einfach verfügbar haben.

Der Punkt ist ja, dass es fast nie gebraucht wird. Vielleicht um Container zu schreiben, aber nicht in 0815-Code.

let int tmp := void

if(cond)
    tmp = value1
else
    tmp = value2

.x := tmp

->

int tmp = [&](){
  if (cond)
    return value1;
  else
    return value2;
}();

Kellerautomat

typique schrieb:

Der Punkt ist ja, dass es fast nie gebraucht wird. Vielleicht um Container zu schreiben, aber nicht in 0815-Code.

Im Zusammenhang mit out-Parametern kann man es verwenden.

Kellerautomat schrieb:

typique schrieb:

Der Punkt ist ja, dass es fast nie gebraucht wird. Vielleicht um Container zu schreiben, aber nicht in 0815-Code.

Im Zusammenhang mit out-Parametern kann man es verwenden.

out wird duch Tupel unnötig.

Kellerautomat

typique schrieb:

Kellerautomat schrieb:

typique schrieb:

Der Punkt ist ja, dass es fast nie gebraucht wird. Vielleicht um Container zu schreiben, aber nicht in 0815-Code.

Im Zusammenhang mit out-Parametern kann man es verwenden.

out wird duch Tupel unnötig.

Hmm. Da könntest du Recht haben, das habe ich mir noch nicht überlegt. Gute Idee eigentlich.

berniebutt

Die Fragestellung als solche gefällt mir nicht, weil Programmiersprachen und die diese benutzenden Compiler allein ein Hilfsmittel der Programmierung sind und sein sollen.

Also mal eine konkrete Anforderung: Ein Kunde spricht seine Wünsche zur Programmleistung auf Band. Der Compiler wertet die Spracheingabe aus, erstellt das
Design und macht ein lauffähiges Programm daraus. Basta!

Zeus

Keiner kommt auf die Idee Bytecode mit zu spezifizieren

Kellerautomat

Zeus schrieb:

Keiner kommt auf die Idee Bytecode mit zu spezifizieren

Liegt vlt daran, dass unsere Sprachen nativ laufen sollen.