Was stört/fehlt euch bei aktuellen Programmiersprachen?

[Shade Of Mine]

Xin schrieb:

1. 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:

1. 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.

[typique]

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.

[typique]

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.

[Zeus]

Kellerautomat schrieb:

Zeus schrieb:

Keiner kommt auf die Idee Bytecode mit zu spezifizieren

Liegt vlt daran, dass unsere Sprachen nativ laufen sollen.

So hab ich nicht gemeint, ich will den Bytecode nicht als Executor auf Anwenderseite haben sondern als Exchanger auf Entwicklerseite.

[Kellerautomat]

Zeus schrieb:

Kellerautomat schrieb:

Zeus schrieb:

Keiner kommt auf die Idee Bytecode mit zu spezifizieren

Liegt vlt daran, dass unsere Sprachen nativ laufen sollen.

So hab ich nicht gemeint, ich will den Bytecode nicht als Executor auf Anwenderseite haben sondern als Exchanger auf Entwicklerseite.

Was?

[Shade Of Mine]

Kellerautomat schrieb:

Zeus schrieb:

Kellerautomat schrieb:

Zeus schrieb:

Keiner kommt auf die Idee Bytecode mit zu spezifizieren

Liegt vlt daran, dass unsere Sprachen nativ laufen sollen.

So hab ich nicht gemeint, ich will den Bytecode nicht als Executor auf Anwenderseite haben sondern als Exchanger auf Entwicklerseite.

Was?

Wenn du eine Library in C++ schreibst, dann kannst du diese nicht gut weiter geben. Du brauchst precompiled Versionen für alle möglichen Plattformen und unterschiedliche Objekt Formate, etc. Und wenn du Templates hast, ist eh hopfen und malz verloren.

Hier wäre ein Bytecode interessant. Ich kompiliere meine Library in den Bytecode und gebe sie dir. Und ob du diese nun auf Linux oder Windows auf 16 bit oder 128bit Architekturen verwendest ist egal - der Bytecode hat alle notwendigen Infos ohne aber dass er der offene Source Code ist.

[trottel]

Sucht ihr immer Sachen, die es schon gibt? Gib doch einfach GIMPLE weiter

[Nirvash]

Was mich bei derzeitigen Programmiersprachen stört?

- Viele Programmiersprachen unterstützen noch globale Variablen, dabei werden diese heutzutage nicht mehr verwendet, weil sie unschöne Effekte produzieren.
Wesentlich schöner wäre es nativ Konstrukte bereitzustellen, welche die Möglichkeit bieten über mehrere Funktionen Variablen zu verteilen (die nicht immer als Parameterlisten übergeben werden müssen) und auch entsprechende Methoden/Operatoren zur Verfügung stellen, um den Lese-/Schreibzugriff zu regeln.

- Anhand von Python finde ich es sehr schön den Benutzer anhand von Syntax zur Codestrukturierung zu bringen. Nichts ist grausamer als nicht eingerückten und geordneten Code lesen zu müssen. Zusätzlich gefällt mir die native Unterstützung von Dictionaries.

Als Fazit muss ich daher sagen, Python bietet schon recht vieles was ich mir an einer Programmiersprache wünsche. Jedoch habe ich für meinen ersten Punkt bisher in Python noch keine Möglichkeit dafür gefunden, muss jedoch auch zugegeben mich nicht mehr intensiv mit Python zu beschäftigen, da mein momentaer Fokus auf ANSI-C liegt und ich acuh wie der Thread-Ersteller und einige andere hier an einer eigenen Sprache mit Compiler arbeite. Diese Sprache ist jedoch sehr sehr rudimentär - PL0, falls jemandem dies etwas sagt. Geplant ist ab einem bestimmten Zeitpunkt geeignete Operationen für globale Variablen bereitzustellen um diese zu "Semi-Globalisieren".

[otze]

Nirvash schrieb:

Was mich bei derzeitigen Programmiersprachen stört?

- Viele Programmiersprachen unterstützen noch globale Variablen, dabei werden diese heutzutage nicht mehr verwendet, weil sie unschöne Effekte produzieren.
Wesentlich schöner wäre es nativ Konstrukte bereitzustellen, welche die Möglichkeit bieten über mehrere Funktionen Variablen zu verteilen (die nicht immer als Parameterlisten übergeben werden müssen) und auch entsprechende Methoden/Operatoren zur Verfügung stellen, um den Lese-/Schreibzugriff zu regeln.

Du meinst Objekte?

[Bashar]

otze schrieb:

Du meinst Objekte?

Oder Module.

[Nirvash]

otze schrieb:

Du meinst Objekte?

Im Prinzip ja, aber mit der grammatikalischen Einschränkung, dass außerhalb der main-Methode kein globaler Datentyp deklariert werden kann.

[Kellerautomat]

Shade Of Mine schrieb:

Wenn du eine Library in C++ schreibst, dann kannst du diese nicht gut weiter geben. Du brauchst precompiled Versionen für alle möglichen Plattformen und unterschiedliche Objekt Formate, etc. Und wenn du Templates hast, ist eh hopfen und malz verloren.

Hier wäre ein Bytecode interessant. Ich kompiliere meine Library in den Bytecode und gebe sie dir. Und ob du diese nun auf Linux oder Windows auf 16 bit oder 128bit Architekturen verwendest ist egal - der Bytecode hat alle notwendigen Infos ohne aber dass er der offene Source Code ist.

Nur, damit ich das richtig verstehe: Als Library-Entwickler kann ich dann meine Lib zu Bytecode kompilieren. Diesen Bytecode gebe ich an andere Entwickler weiter, sie kompilieren ihr Programm mit dem Bytecode meiner Lib zu Maschinencode?

Nirvash schrieb:

- Viele Programmiersprachen unterstützen noch globale Variablen, dabei werden diese heutzutage nicht mehr verwendet, weil sie unschöne Effekte produzieren.
Wesentlich schöner wäre es nativ Konstrukte bereitzustellen, welche die Möglichkeit bieten über mehrere Funktionen Variablen zu verteilen (die nicht immer als Parameterlisten übergeben werden müssen) und auch entsprechende Methoden/Operatoren zur Verfügung stellen, um den Lese-/Schreibzugriff zu regeln.

Ich bin der Meinunung, dass das Problem nicht globale Variablen sind. Das Problem ist, dass sie "zu global" sind. Globaler State ist teilweise einfach nötig, für z.B. Logger, stdin/stdout, Mutexe, etc.
Das Problem ist, dass er nicht richtig enkapsuliert ist. Man sollte auf keine Variablen über Modulgrenzen hinweg zugreifen können, die sind ein Implementierungsdetail des Moduls.

Nirvash schrieb:

- Anhand von Python finde ich es sehr schön den Benutzer anhand von Syntax zur Codestrukturierung zu bringen. Nichts ist grausamer als nicht eingerückten und geordneten Code lesen zu müssen. Zusätzlich gefällt mir die native Unterstützung von Dictionaries.

Gezwungene Einrückung finde ich unschön, sorry. Dictionaries gehören nicht in den Sprachkern. Es gibt viele verschiedene Möglichkeiten, wie man sie implementieren kann. Bäume, Hashtabellen, sortierte Arrays. Und bei allen gibt es noch Varianten, die sich in den Details unterscheiden. Je nach Situation kann eine andere Datenstruktur angemessen sein.

Mit überladbaren Typ-Konstruktoren und Klammern könnte man sich solche Syntax einfach selbst definieren. An diesen Features arbeite ich gerade.

[knivil]

enkapsuliert

Wort des Jahres.