Review der Programmiersprache V (2022)

ffdd270 · 2022-06-23T23:12:31+09:00

Review der Programmiersprache V Dies ist ein Review, in dem die vom V-Sprachprojekt beworbenen Funktionen im Jahr 2022, einige Jahre nach dem Erscheinen von V, direkt getestet werden. Die Features wurden in die Kategorien nicht funktionsfähig, Warnung und funktionsfähig eingeteilt. Unten stehen die Ergebnisse dieser Bewertungsliste. Beispielcode für die Bewertung und die Begründungen dafür finden sich alle im Haupttext. Die folgende Liste wurde beim Lernen von Englisch übersetzt, daher können sachliche Fehler enthalten sein. Bitte nur als Referenz verwenden. Eine einfache Sprache, die sich gut warten lässt. Eine subjektive Behauptung. N/A Sicherheit Kein Null. In V lassen sich Null-Pointer (V-Referenzen) ohne Compiler-Fehler oder Warnung erzeugen. Nicht unterstützt. Keine undefined values. Nicht initialisierter Speicher kann ohne Compiler-Fehler oder Warnung gelesen werden. Nicht unterstützt. Kein undefined behavior. Der V-Compiler verhinderte nicht, drei verschiedene Formen von UB zu schreiben. UB tritt auf. Nicht unterstützt. Kein Variablen-Shadowing (das Phänomen, dass bei gleichem Namen in unterschiedlichen Namensräumen ein Name verdeckt wird). Lokale Variablen konnten nicht verdeckt werden. Nicht unterstützt. Bounds-Checking. Es gibt einige grundlegende Prüfungen, aber sie lassen sich trivial umgehen. Warnung. Konstante Variablen als Standard. Variablen sind keine bedeutungsvollen Konstanten. Einer mut-deklarierten Variablen kann eine konstante Referenz zugewiesen werden; ändert man dann die Variable, lässt sich dadurch auch die ursprüngliche konstante Variable leicht verändern. Nicht unterstützt. Reine Funktionen als Standard. Diese Behauptung ist bedeutungslos, weil sie Reinheit so umdefiniert, dass damit Unreinheit gemeint ist. (Der Autor weist darauf hin, dass die Unterstützung von I/O-Funktionen inhärent unrein sein muss. In der Dokumentation stand zwar, dass alle Funktionen außer I/O-Funktionen rein seien, aber er argumentiert, dass Funktionen ab dem Moment, in dem sie I/O-Funktionen aufrufen können, nicht mehr rein sind. Daher scheint die Aussage inhaltlich ausgehöhlt zu sein. Im Haupttext wird ein lächerliches Beispiel gezeigt, in dem reine Funktionen unreine Werte ausgeben.) Nicht unterstützt. Konstante Structs als Standard. Es wurde oben bereits gezeigt, dass sich konstante Variablen umgehen lassen. Nicht unterstützt. Option und obligatorische Fehlerprüfung für deren Ergebniswerte. Funktioniert wie beworben. Sum Types (Syntax wie type MyType = string | int.) Sum Types scheinen im Allgemeinen zu funktionieren, haben aber interne Implementierungsprobleme. (Durch das Anlegen von zwei weiteren Typen wird es möglich, in V eigentlich verbotene Referenzen als Sum Types zu verwenden.) Warnung. Generalisierung (Generics) Eine grundlegende Implementierung existiert, aber sie ist sehr fehlerhaft und scheint völlig von der selbst hervorgehobenen Sicherheit und Compiler-Performance abgekoppelt zu sein. Nicht unterstützt. Keine globalen Variablen. V verhindert die Erstellung oder Veränderung global geteilten Zustands auf keine sinnvolle Weise. Nicht unterstützt. Performance So schnell wie C (der Haupt-Backend-Compiler von V erzeugt menschenlesbaren C-Code) Die Performance-Behauptungen von V scheinen nicht verifiziert zu sein. Nicht unterstützt. C-Interoperabilität ohne Zusatzkosten Funktioniert wie beworben. Minimierte Allokationen Eine subjektive Behauptung. N/A. (Der Autor zeigte, dass V-Code mit einer int-Deklaration bei der Übersetzung nach C zu einem Ergebnis führt, in dem auf C-Seite int per malloc alloziert wird.) Eingebaute Serialisierung ohne Runtime-Reflection Funktioniert wie beworben. Kompiliert zu nativen Binärdateien ohne jegliche Dependencies. Es scheint, dass V diese Behauptung noch nicht erreicht hat, aber in der allgemeinen Idee steckt etwas Wahrheit: V-Programme sind relativ eigenständig und klein. Warnung. Schnelle Kompilierung V kompiliert 1 Million Zeilen pro Sekunde und pro CPU-Kern. Der V-Compiler kam nicht einmal in die Nähe der behaupteten Leistung. (Sogar auf der Benchmark-Website des V-Compilers werden nur etwa 200.000 V-Zeilen kompiliert.) Nicht unterstützt. V ist in V geschrieben und kann sich selbst in unter 1 Sekunde kompilieren. Funktioniert wie beworben. Innovatives Memory-Management Die Behauptungen von V sind nicht gut untermauert, und die derzeit existierende Implementierung lässt sich nicht als innovativ beschreiben. Nicht unterstützt

(mawfig.github.io)

10 Punkte von ffdd270 2022-06-23 | 1 Kommentare | Auf WhatsApp teilen

Review der Programmiersprache V

Dies ist ein Review, in dem die vom V-Sprachprojekt beworbenen Funktionen im Jahr 2022, einige Jahre nach dem Erscheinen von V, direkt getestet werden.
Die Features wurden in die Kategorien nicht funktionsfähig, Warnung und funktionsfähig eingeteilt. Unten stehen die Ergebnisse dieser Bewertungsliste. Beispielcode für die Bewertung und die Begründungen dafür finden sich alle im Haupttext.
Die folgende Liste wurde beim Lernen von Englisch übersetzt, daher können sachliche Fehler enthalten sein. Bitte nur als Referenz verwenden.

Eine einfache Sprache, die sich gut warten lässt.
- Eine subjektive Behauptung.
- N/A

Sicherheit

Kein Null.
- In V lassen sich Null-Pointer (V-Referenzen) ohne Compiler-Fehler oder Warnung erzeugen.
- Nicht unterstützt.
Keine undefined values.
- Nicht initialisierter Speicher kann ohne Compiler-Fehler oder Warnung gelesen werden.
- Nicht unterstützt.
Kein undefined behavior.
- Der V-Compiler verhinderte nicht, drei verschiedene Formen von UB zu schreiben. UB tritt auf.
- Nicht unterstützt.
Kein Variablen-Shadowing (das Phänomen, dass bei gleichem Namen in unterschiedlichen Namensräumen ein Name verdeckt wird).
- Lokale Variablen konnten nicht verdeckt werden.
- Nicht unterstützt.
Bounds-Checking.
- Es gibt einige grundlegende Prüfungen, aber sie lassen sich trivial umgehen.
- Warnung.
Konstante Variablen als Standard.
- Variablen sind keine bedeutungsvollen Konstanten. Einer mut-deklarierten Variablen kann eine konstante Referenz zugewiesen werden; ändert man dann die Variable, lässt sich dadurch auch die ursprüngliche konstante Variable leicht verändern.
- Nicht unterstützt.
Reine Funktionen als Standard.
- Diese Behauptung ist bedeutungslos, weil sie Reinheit so umdefiniert, dass damit Unreinheit gemeint ist.
- (Der Autor weist darauf hin, dass die Unterstützung von I/O-Funktionen inhärent unrein sein muss. In der Dokumentation stand zwar, dass alle Funktionen außer I/O-Funktionen rein seien, aber er argumentiert, dass Funktionen ab dem Moment, in dem sie I/O-Funktionen aufrufen können, nicht mehr rein sind. Daher scheint die Aussage inhaltlich ausgehöhlt zu sein. Im Haupttext wird ein lächerliches Beispiel gezeigt, in dem reine Funktionen unreine Werte ausgeben.)
- Nicht unterstützt.
Konstante Structs als Standard.
- Es wurde oben bereits gezeigt, dass sich konstante Variablen umgehen lassen.
- Nicht unterstützt.
Option und obligatorische Fehlerprüfung für deren Ergebniswerte.
- Funktioniert wie beworben.
Sum Types (Syntax wie type MyType = string | int.)
- Sum Types scheinen im Allgemeinen zu funktionieren, haben aber interne Implementierungsprobleme. (Durch das Anlegen von zwei weiteren Typen wird es möglich, in V eigentlich verbotene Referenzen als Sum Types zu verwenden.)
- Warnung.
Generalisierung (Generics)
- Eine grundlegende Implementierung existiert, aber sie ist sehr fehlerhaft und scheint völlig von der selbst hervorgehobenen Sicherheit und Compiler-Performance abgekoppelt zu sein.
- Nicht unterstützt.
Keine globalen Variablen.
- V verhindert die Erstellung oder Veränderung global geteilten Zustands auf keine sinnvolle Weise.
- Nicht unterstützt.

Performance

So schnell wie C (der Haupt-Backend-Compiler von V erzeugt menschenlesbaren C-Code)
- Die Performance-Behauptungen von V scheinen nicht verifiziert zu sein.
- Nicht unterstützt.
C-Interoperabilität ohne Zusatzkosten
- Funktioniert wie beworben.
Minimierte Allokationen
- Eine subjektive Behauptung.
- N/A. (Der Autor zeigte, dass V-Code mit einer int-Deklaration bei der Übersetzung nach C zu einem Ergebnis führt, in dem auf C-Seite int per malloc alloziert wird.)
Eingebaute Serialisierung ohne Runtime-Reflection
- Funktioniert wie beworben.
Kompiliert zu nativen Binärdateien ohne jegliche Dependencies.
- Es scheint, dass V diese Behauptung noch nicht erreicht hat, aber in der allgemeinen Idee steckt etwas Wahrheit: V-Programme sind relativ eigenständig und klein.
- Warnung.

Schnelle Kompilierung

V kompiliert 1 Million Zeilen pro Sekunde und pro CPU-Kern.
- Der V-Compiler kam nicht einmal in die Nähe der behaupteten Leistung. (Sogar auf der Benchmark-Website des V-Compilers werden nur etwa 200.000 V-Zeilen kompiliert.)
- Nicht unterstützt.
V ist in V geschrieben und kann sich selbst in unter 1 Sekunde kompilieren.
- Funktioniert wie beworben.
Innovatives Memory-Management
- Die Behauptungen von V sind nicht gut untermauert, und die derzeit existierende Implementierung lässt sich nicht als innovativ beschreiben.
- Nicht unterstützt

1 Kommentare

ffdd270 2022-06-23

Es ist zwar allgemein bekannt, dass V noch einen weiten Weg vor sich hat, aber dieser Beitrag beschreibt den Prozess, mit dem genau das belegt wird, sehr gut. Wählen Sie einfach etwas aus der Liste aus, das Sie interessiert, und prüfen Sie dann einmal nach, wie das belegt wird.