2 Punkte von GN⁺ 2023-07-10 | 3 Kommentare | Auf WhatsApp teilen
  • Object Pascal zielt darauf ab, eine gut lesbare, moderne objektorientierte Sprache mit nativer Performance zu verbinden, und ist eine Option für die Entwicklung wartbarer Anwendungen auf mehreren Plattformen
  • Dank starker Typisierung, Prüfungen zur Compile-Zeit und Laufzeitprüfungen werden Fehler wie Tippfehler in Namen oder Typinkompatibilitäten eher abgefangen, bevor sie Nutzer erreichen
  • Bei Bedarf lassen sich Pointer, OS- und CPU-spezifischer Code bis hin zu Assembly verwenden; die Castle Game Engine entscheidet sich jedoch dafür, schnellen Code auch ohne Assembly beizubehalten
  • Als Zielplattformen kommen Windows, Linux, macOS, Mobile, Konsolen und Web infrage; bei der Castle Game Engine sind Engine-Code und Game-Code in derselben Sprache geschrieben
  • Mit FPC, Lazarus, Delphi, VS-Code-Integration und Anbindung an verschiedene Bibliotheken lässt sich auch im Pascal-Ökosystem ein praktikabler Entwicklungsworkflow aufbauen

Gut lesbares und typsicheres Object Pascal

  • Object Pascal wird als moderne, gut lesbare und schnelle typsichere Cross-Platform-Sprache betrachtet
  • Wer bereits andere objektorientierte Sprachen kennt, kann sie vergleichsweise leicht lernen; als Lernmaterial steht Modern Object Pascal Introduction for Programmers zur Verfügung
  • Sie bietet Funktionen, die man von einer modernen objektorientierten Sprache erwartet
    • Klassen
    • Units
    • Properties
    • Generics
    • Interfaces
    • Reflection
    • Closures
  • Die Syntax legt den Schwerpunkt auf gut lesbaren Code
  • Für Typsicherheit stellt sie eigene Typen wie boolean, string, char, set, enum und range bereit
    • Sichere Umwandlungen, etwa das Zuweisen eines Integer an einen float, werden einfach gehandhabt
    • Andere Umwandlungen müssen explizit vorgenommen werden

Wie Fehler beim Kompilieren und zur Laufzeit abgefangen werden

  • Object Pascal legt großen Wert auf Prüfungen zur Compile-Zeit
  • Bei Refactorings wie dem Umorganisieren von Datenstrukturen kann man den Compiler dazu bringen, die Stellen sichtbar zu machen, die angepasst werden müssen
  • Offensichtliche Fehler wie Tippfehler in Namen oder Typinkompatibilitäten passieren die Kompilierung nicht und erreichen daher keine Nutzer
  • Zusätzlich werden Laufzeitprüfungen bereitgestellt
    • Prüfung von Array-Grenzen
    • Prüfung auf Integer-Überlauf
    • Assertions
    • Prüfung auf Speicherlecks
  • Laufzeitprüfungen werden genutzt, um Probleme in Debug-Versionen zu finden, und können in Performance-kritischen Release-Versionen deaktiviert werden
  • Beim Kompilieren mit dem CGE editor werden Debug-/Release-Modi automatisch gesetzt; der Modus lässt sich im Menü „Run“ wechseln
  • Als weiterführende Dokumentation dienen What are range and overflow checks (and errors) in Pascal und Detecting Memory Leaks

Native Performance und so viel Low-Level-Kontrolle wie nötig

  • Object Pascal wird zu nativem Code kompiliert, wodurch sich eine gute Grundperformance leichter erreichen lässt
  • In normalen Anwendungen ist es meist nicht nötig, bis zu Low-Level-Optimierungen hinabzugehen
  • Bei Bedarf lassen sich Low-Level-Funktionen in beliebigem Umfang nutzen
    • Verwendung von Pointern
    • Pointer-Arithmetik
    • Schreiben von OS- und CPU-spezifischem Code
    • Hinzufügen von Assembly-Code
  • Um Portabilität und Lesbarkeit des Codes zu erhöhen, enthält die Castle Game Engine überhaupt keinen Assembly-Code, zielt aber dennoch auf schnelle Ausführung ab
  • Auch die Kompilierung ist eher schnell; in einem Beispiel dauerte ein Desktop-Build beim ersten Öffnen eines neuen Projekts 2,5 Sekunden, ein Android-Build 10,1 Sekunden

Mehrere Plattformen und die Entwicklungsweise der Castle Game Engine

  • Object Pascal kann für verschiedene Plattformen eingesetzt werden
    • Desktop: Windows, Linux, macOS, Raspberry Pi, FreeBSD, vermutlich alle Unix-Systeme
    • Mobile: Android, iOS
    • Konsolen: Nintendo Switch
    • Web: WebAssembly, JS mit pas2js
  • Die von der Castle Game Engine unterstützten Plattformen sind unter Castle Game Engine platforms supported zu finden
  • Einen Überblick über alle möglichen Ziele bieten FPC target platforms und Delphi target platforms
  • In der Castle Game Engine sind Engine-Code und Game-Code in derselben Sprache geschrieben
  • Die Engine ist Open Source und kann bei Bedarf als Fork von CGE angepasst werden

Bibliotheken und Ökosystem der Entwicklungstools

  • Für Pascal gibt es bestehende Bibliotheken und Units aus vielen Bereichen
    • Datenbanken
    • XML, JSON
    • AI
    • Blockchain
    • Networking
  • Bestehende Bibliotheken mit C-API lassen sich einfach integrieren oder linken
    • Renderer
    • Sound-Bibliotheken
    • Physik-Engines
  • Auch Python libraries in Pascal können verwendet werden
  • Das wichtigste Tool-Ökosystem umfasst
    • FPC: Open-Source-Compiler Free Pascal Compiler
    • Lazarus: Open-Source-Pascal-IDE auf Basis von FPC
    • Delphi: kommerzieller Pascal-Compiler und IDE
    • VS Code: Mehrere Tools im CGE- und Pascal-Ökosystem unterstützen ausdrücklich die Integration in VS Code

3 Kommentare

 
gmong 2023-07-20

Delphi … weckt Erinnerungen. Borland, Delmadang …

 
xguru 2023-07-10

In der Zeit, als ich Windows-Entwicklung gemacht habe, schien Object Pascal mit Delphi wirklich das Beste gewesen zu sein.

 
GN⁺ 2023-07-10
Hacker-News-Kommentare
  • Wer früher Delphi verwendet hat, kennt Lazarus wahrscheinlich schon. Lazarus kommt einem faktisch einer Open-Source-Neuimplementierung sehr nahe und läuft bzw. kompiliert nativ fast überall, auch auf ARM-Boards wie dem Raspberry Pi.
    Die Installation von Bibliotheken kann allerdings umständlich sein, weshalb zunächst FpcUp und später FpcUpDeluxe entwickelt wurden, um die Installation von IDE, Modulen und einigen ziemlich interessanten Add-ons zu automatisieren.
    https://wiki.freepascal.org/fpcupdeluxe
    Es gibt auch eine Demo eines Tachometer-Widgets, das schnell mit den in FpcUpDeluxe enthaltenen kostenlosen Widgets gebaut wurde.
    https://ibb.co/9bchx7T
    FpcUpDeluxe funktioniert auch unter Alpine Linux; auf der Release-Seite muss man einfach die musl-Version herunterladen. Dadurch eröffnet sich die Möglichkeit, auch sehr kleine Systeme mit Instrumentenanzeigen auszustatten. Der Code wird auf vielen Plattformen nativ kompiliert und schnell ausgeführt, ganz ohne Interpreter oder Webbrowser.

  • Früher war Delphi/Pascal meine Hauptsprache, und in den letzten 10 bis 20 Jahren habe ich nach einer Sprache gesucht, die besser zu mir passt. Ich habe auch recht lange Haxe verwendet, hatte am Ende aber das Gefühl, in die Falle „das macht man einfach mit Makros“ geraten zu sein. Mit Makros kann man zwar alles machen, aber wenn es genug davon gibt, programmiert am Ende jeder in seiner eigenen Makro-Erweiterungssprache.
    JavaScript hat brauchbare Verbesserungen bekommen und könnte immer noch mehr vertragen, aber ich arbeite inzwischen auch viel damit. Vor einigen Jahren habe ich beim Schreiben von 8-Bit-AVR-Code wieder FreePascal verwendet, und das hat wirklich Spaß gemacht. Als ich die neueren Features ausprobierte, fühlte es sich wie eine wirklich moderne Sprache an, und mir gefiel auch, dass ich wegen des kleinen Zielsystems kaum die Standardbibliothek benutzt, sondern den benötigten Code direkt selbst geschrieben habe.
    So konnte ich die über Jahre gewachsene Abwärtskompatibilitäts-Unordnung in den Namespaces von FreePascal vermeiden, etwa die Ebenen von TList, TFPList, TFPGList und TFPGObjectList. Am meisten vermisst habe ich, dass der Compiler auf Zielen ohne FPU oder Emulation keine konstanten Gleitkomma-Ausdrücke erlaubte. Das hätte eigentlich möglich sein sollen, weil sich so etwas zur Compile-Zeit berechnen lässt.
    Nachdem ich andere Umgebungen genutzt habe, empfinde ich es inzwischen als Einschränkung, dass man Variablen nicht mitten in einer Funktion definieren kann, und ich hätte gern auch eine Verschachtelung auf Ebene lokaler Unterfunktionen. Der Unterschied zwischen begin/end und {} ist mir ziemlich egal. Inzwischen bevorzuge ich Sprachen mit Groß-/Kleinschreibung und ohne Zeichenpräfixe an Typen. Das liegt vermutlich vor allem an der Entwicklung der Editoren. Syntax-Highlighting und Live-Linting verlagern Informationen in einen separaten Bereich und reduzieren so das visuelle Rauschen im Text.
    Wenn es eine Nachfolgesprache von FreePascal als echter Neuanfang gäbe, wäre ich wahrscheinlich ziemlich begeistert. Eine neue Standardbibliothek, die moderne Features als erstklassige Bestandteile nutzt, wäre großartig; vielleicht baue ich so etwas nach der Rente selbst einmal.

    • begin/end und {} bedeuten tatsächlich nicht dasselbe. {} definiert einen lokalen Gültigkeitsbereich, begin/end hingegen nicht.
  • In den 90ern habe ich einige Jahre beruflich mit Delphi gearbeitet und mochte es, aber ich war irgendwann müde davon, wie Borland und die späteren Eigentümer das Produkt und die Sprache immer wieder schlecht gemanagt haben. Anders Hejlsberg verließ Borland ebenfalls, ging zu Microsoft und entwickelte C#; meiner persönlichen Meinung nach ist das eine deutlich bessere Sprache und Architektur, in die man seine Zeit investieren kann.

    • Eine C#-Desktop-App zuverlässig auszuliefern, ist im Vergleich zu der einzelnen EXE, die Delphi/Lazarus erzeugt, nahezu ein absoluter Albtraum.
  • Heutzutage nutze ich Pascal aus Spaß wegen der Ressourcenbeschränkungen. Das alte Borland Turbo Pascal 3.00A läuft auf CP/M und liefert Editor, Compiler und Bibliotheken komplett innerhalb von 64 KB
    Es ist schnell genug für interaktives Arbeiten und erzeugt ausreichend guten Code für Low-Level-Utilities, einfache Spiele und allerlei Hacks. Ich habe Pascal nie in größeren oder moderneren Umgebungen verwendet, aber meine jüngsten Erfahrungen waren ziemlich zufriedenstellend, daher habe ich nicht vor, es auszuschließen

    • Turbo Pascal und später Delphi waren der Moment, in dem sich eine Programmiersprache zum ersten Mal wirklich greifbar anfühlte. Am Ende bin ich bei C und C++ gelandet, aber ich hatte immer den Wunsch, zu einer ausdrucksstärkeren Sprache zurückzukehren
      Ich wusste bis heute nicht, dass es noch moderne Pascal-Implementierungen gibt, und vielleicht sollte ich mich wieder mit meiner ersten Liebe anfreunden
    • Falls du es noch nicht ausprobiert hast, solltest du dir Free Pascal ansehen. Es unterstützt viele Plattformen
      Wenn du CP/M brauchst, kannst du auf der Website nachsehen, ob es unterstützt wird, und selbst wenn, würde mich das nicht überraschen. Die textbasierte UI-IDE ist Turbo Pascal sehr ähnlich und blitzschnell. Die Sprache hat viel mehr fortgeschrittene Funktionen als Turbo Pascal, aber man muss sie nicht verwenden, wenn man nicht will
      Als ich es früher kurz unter Windows getestet habe, waren auch die erzeugten Binärdateien wie bei C sehr klein, und ein einfaches Hello-World-Programm lag unter 50–60 KB
    • Ach, die Nostalgie von Pascal. Zu Zeiten des TRS-80 Model III habe ich die stolze Summe von 80–100 Dollar zusammengespart und das Pascal 80-Paket, die Version von New Classics, gekauft. Es war praktisch eine frühe IDE und für damalige Maßstäbe ziemlich hervorragend. http://www.trs-80.org/pascal-80/
      Ich erinnere mich, dass es ein gewaltiger Fortschritt gegenüber der M-III-BASIC-Entwicklungsumgebung war, und meine Spiele und Utilities liefen selbst in 48 KB RAM ziemlich gut. Ich frage mich, was aus der Pascal-80-Codebasis geworden ist. Besser als moderne Werkzeuge für Retro-Hardware wird sie kaum sein, vermutlich sogar deutlich schlechter. „Oh Pascal!“ war das Buch, mit dem ich diese Sprache gelernt habe, und da Pascal erst einige Jahre später kommerziell genutzt wurde, gab es vermutlich ohnehin nicht viele andere Optionen
  • Bei einigen Gründen fällt es mir schwer zuzustimmen. Object Pascal ist keine moderne Sprache. 1998 war sie das vielleicht, aber danach hat sie sich nicht mehr stark weiterentwickelt, und die letzte große Änderung waren Generics, die später kamen als in fast allen anderen Sprachen
    FPC erzeugt auch nicht besonders schnellen Code, und die Objektmerkmale von Object Pascal sind für Lokalität ebenfalls nicht vorteilhaft. Schneller als Skriptsprachen ist es zwar, aber im Allgemeinen langsamer als typische Ahead-of-Time-kompilierte Sprachen, auch wenn man solche mit Garbage Collection einbezieht
    Dafür ist das Ökosystem großartig. Es gibt viele gute Bibliotheken und Werkzeuge, und am bemerkenswertesten ist Lazarus, ein Delphi-Klon. Leute, die FPC oder Delphi verwenden, haben sich meistens nicht besonders für Sprachmodernisierung interessiert, sondern wollten einfach Dinge erledigen. Für neue Entwickler scheint es aber wohl nicht besonders attraktiv zu sein, daher weiß ich nicht, wie die Zukunft aussieht

    • Dass Generics in FPC eingeführt wurden, ist schon 17 Jahre her und hat mit jüngsten Änderungen wenig zu tun. Wenn man nach einer größeren neueren Ergänzung sucht, wären anonyme Funktionen und Funktionsreferenzen, also Closures, ein passenderer Kandidat
      Die tatsächliche Leistung ist ausreichend, und wenn man einen Bottleneck findet, kann man bei Bedarf optimieren. Im Vergleich zu C++ kann es mit „höherstufigen“ Klassen etwas lästiger sein, aber unmöglich ist es nicht
      Wenn man mit minimalem Aufwand bessere Grundleistung möchte, gibt es auch das neue LLVM-Backend. Dafür muss man allerdings Compiler, Runtime-Bibliothek und FCL usw. alle mit dem LLVM-Backend bauen, also den Compiler aus dem Quellcode erstellen, aber das dauert nur ein paar Minuten. Allerdings wird der Compiler dann deutlich langsamer, und persönlich finde ich nicht, dass der Leistungsunterschied das wert ist
    • Das scheint mir zu abwertend. Früher gab es auch Benchmarks, in denen es so schnell wie C++ war, und bei seinem Haupteinsatzgebiet, lokalen GUI-Apps, habe ich nichts erlebt, das so unmittelbar reagiert, auch keine C#-GUI-Apps oder Ähnliches
      Daher würde mich interessieren, welcher Benchmark zu der Einschätzung geführt hat, dass es etwa 50-mal langsamer sei, als es tatsächlich ist
    • Ich kenne FPC nicht, aber Delphi 7 lag vor 10 Jahren im Competitive Programming ungefähr auf dem Niveau von C++ und war etwa 2–3-mal schneller als Java
      Mit Competitive Programming meine ich kurze, CPU-lastige, single-threaded Algorithmusberechnungen mit maximal 1–3 Sekunden Laufzeit pro Ausführung, also ein Umfeld, das für JIT ungünstig ist und mit Standard-Compiler- und Runtime-Einstellungen, ohne externe Bibliotheken oder Tuning abläuft. Der damalige Common Sense war, C++/Pascal zu verwenden oder mit Java anzufangen und, falls „time limit exceeded“ kam, die 200–300 Zeilen lange Lösung noch einmal in C++ zu schreiben, um durchzukommen
    • Der größte Unterschied zwischen Pascal und C++ ist die Developer Experience
      Pascal verwendet einen Single-Pass-LL(1)-Compiler und ermöglicht dadurch Kompilierzeiten im Millisekundenbereich. Das ergibt eine REPL-ähnliche Erfahrung, bei der Edit→Compile→Run in unter einer Sekunde abgeschlossen ist. C/C++ mit Makros und langsamen Kompilierzeiten bot die schlechtere Developer Experience und war zumindest für mich der Grund, statt C Pascal und statt C++ Delphi zu lernen
    • Ich stimme nicht stark zu, dass das Ökosystem großartig sei. Ich habe etwa 10 Jahre mit Pascal gearbeitet und war wegen des Mangels an modernen Bibliotheken oft frustriert; am Ende musste ich entweder selbst Lösungen bauen oder Ideen komplett aufgeben
  • Ich verstehe nicht, warum man das unbedingt tun sollte. Alte Sprachen müssen wegen Legacy-Support erhalten bleiben, aber ich sehe wenig Sinn darin, solche modernen Features mit Gewalt in alte Sprachen hineinzupressen
    Ich nutze viel Java, aber ehrlich gesagt hätten fast alle Features nach Java 8 nie hinzugefügt werden sollen. Lambdas sind in Java zum Beispiel eher ein Flickwerk
    Wenn man moderne Features will, sollte man eine moderne Sprache verwenden. Wenn man im Java-Ökosystem bleiben will, kann man Kotlin nutzen. Pascal habe ich buchstäblich seit Jahrzehnten nicht mehr gesehen, und zuletzt in den 1980ern damit programmiert, daher rede ich hier nur über Java, aber so eine Feature-Liste zu Pascal hinzuzufügen wirkt lächerlich

    • Lambdas seien Flickwerk? Hältst du es wirklich für besser, stattdessen eine anonyme Klasse mit genau einer Methode zu erstellen?
    • In Java ist Interoperabilität zwischen Sprachen einfach, daher ist eine Wahl wie Kotlin leichter. Gleiches gilt für Clojure. Wenn man aber C++ nutzt, gibt es keinen einfachen Pfad, auf etwas anderes upzugraden
      Trotzdem hat es Wert, moderne Features hineinzubringen. Man kann zwar für neue Projekte statt C++ eine moderne Sprache wie Rust wählen, aber bereits geschriebene Millionen Zeilen C++-Code können durch moderne Features verbessert werden. Man muss sich nur ansehen, wie C++11 alles verändert hat
    • Dann müsste man Programmiersprachen viel häufiger wechseln. Um diesen Prozess zu verlangsamen, erscheint es vernünftig, neue Features mit nachgewiesenem Nutzen hinzuzufügen und zu integrieren
    • Bis vor Kurzem hatte Java abgesehen von seinem absurd großen Ökosystem wenig, was es besser machte als Delphi vor 15 Jahren. Natürlich schlägt dieses Ökosystem am Ende alles
      Die Java-Sprache hat wegen der Entscheidung, statt Sprachfeatures Bibliotheken zu verwenden, enorme Mengen an Boilerplate-Code erzeugt, und ich halte diese Richtung für falsch. Alles, was in Python, Lisp oder Haskell möglich ist, ist auch in Java möglich, aber per Definition auch in brainf*ck. Die tatsächliche Komplexität von Java-Lösungen wird höher als in feature-reichen Sprachen, und am Ende implementiert man solche Sprachfeatures entweder auf leicht kaputte Weise neu oder zieht massenhaft Abhängigkeiten heran, die sie ersetzen sollen. So oder so wächst nur die API-Oberfläche, die man lernen muss
    • Konkurrenzfähige JVM-Sprachen gibt es erst seit einigen Jahren. Scala war eine Sackgasse, Clojure eher ein Hype, und Rhino/JS war in seinen Ambitionen sehr begrenzt
      Dank der Verbesserungen an Java blieb die JVM relevant und konnte DotNet in Schach halten, was angesichts der Geschichte von Microsoft eine gute Sache war
  • Wird oft übersehen, aber das Ada-Embedded-Ökosystem hat Vorteile bei statischer Analyse, Debugging und der Reife der Target-Unterstützung

    • Ich fand, Ada wurde schon immer unterschätzt. Persönlich schätze ich Features wie Speichersicherheit, ein standardisiertes Nebenläufigkeitsmodell, Unterstützung für Einheiten- und Maßtypen sowie Precompilation
      Adas Pascal-ähnliche Syntax wirkt zwar wortreich, ist aber nicht schwer zu lesen. Auch VHDL basiert syntaktisch auf Ada, daher kann es für Leute, die beide Sprachen zusammen verwenden, sogar einfacher sein
      Swift erfüllt ebenfalls einige dieser Punkte und ergänzt komfortable Features wie Closures, Automatic Reference Counting und Typherleitung. Bei Maßtypen weiß ich es nicht genau, aber es scheint machbar zu sein. Ein HDL wie Swift scheint es allerdings noch nicht zu geben
    • Ich frage mich, ob Ada inzwischen Android- und iOS-Targets unterstützt. Als ich zuletzt nachgesehen habe, schien es keinen klaren Weg zu geben, für das NDK zu bauen
    • Nicht gerade der einsteigerfreundlichste Start auf macOS
  • Pascal ist tatsächlich gut und die Performance ist auch ordentlich. Es war nach Basic die zweite Sprache, die ich in der Oberstufe gelernt habe
    Ich verstehe nicht, warum die Branche in den späten 1990ern und frühen 2000ern zu Python, Ruby, Java und JavaScript zurückfallen musste

    • Ich habe kürzlich einen Vortrag zu diesem Thema gesehen: https://www.youtube.com/watch?v=Tml94je2edk
      Darin wird erklärt, warum dynamisch typisierte Sprachen wie Python, Ruby und JS in den 1990ern populär wurden: weil sie beim Erstellen von Websites schnelle Feedback-Schleifen boten und weder IDE noch Compiler erforderten. IDEs und Compiler waren damals langsam und oft nicht kostenlos
      Außerdem kamen die Nutzer damals ohnehin über 56k-Modems online, daher brachte es wenig, Entwicklungszeit gegen mehr Performance einzutauschen. Der Vortrag enthält auch viele interessante Punkte dazu, wie sich die Entwicklung in den letzten 10 bis 20 Jahren verändert hat und warum sich der Trend wieder in Richtung statischer Typisierung bewegt
    • Computer wurden schneller und Speicher wurde billiger, also musste man Verwendung dafür schaffen ;-)
      Außerdem wurde der Webbrowser zu einer populären Programmierplattform, und dort nutzte man vor allem JavaScript. Noch heute versucht man zusätzlich zum Browser-Teil ein vollständiges Betriebssystem in den Webbrowser hineinzustopfen, und Chrome ist schon ziemlich nah dran
  • Mein erstes Projekt im ersten Studienjahr war ein Aufzugssimulator in Pascal, mit Textgrafik. Im Vergleich zu C-artigen Sprachen hatte Pascal etwas Elegantes, was mir Freude gemacht hat
    Deshalb habe ich heute Spaß an Nim; soweit ich weiß, wurde Nim außer von Ada und Python auch von Wirth-Sprachen wie Pascal, Modula-3, Oberon und Delphi beeinflusst

  • Pascal ist nicht so schlecht und hat meiner Ansicht nach tatsächlich Vorteile gegenüber manchen modernen Programmiersprachen. Natürlich ist es nicht perfekt und hat auch Nachteile
    Ich nutze für DOS-Programmierung gelegentlich Pascal und BASIC, und zumindest dafür scheint Pascal ganz gut zu sein. C wird zwar auch für DOS-Programmierung verwendet, aber besonders im Real Mode wirkt es nicht gerade ideal
    Für Linux-Programmierung bevorzuge ich meist C, verwende aber auch PostScript. Ich denke, sowohl C als auch PostScript haben gegenüber manchen modernen Sprachen gewisse Vorteile. Pascal kann auch für andere Programme genutzt werden, und sogar TeX wurde in Pascal geschrieben

    • Mich würde interessieren, wofür du PostScript verwendest. Es ist spannend, Leute zu sehen, die es für etwas anderes als Druck-bezogene Aufgaben einsetzen