Klartext gibt es seit Jahrzehnten – und er wird bleiben

 (unsung.aresluna.org)
2 Punkte von GN⁺ 4 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Diagramm- und UI-Design-Tools auf Basis von monospaced Klartext werden wieder verstärkt genutzt; die Vertrautheit textbasierter Bearbeitungsoberflächen und die Portabilität des Dateiformats geben ihnen langfristige Beständigkeit
  • Tools wie Mockdown, Wiretext und Monodraw eignen sich gut für niedrigschwellige Diagramme, weil sie bewusst nur begrenzte visuelle Optionen bieten, und passen auch für die Einbettung in Quellcode
  • Mockdown ist sofort im Web und auf Mobilgeräten nutzbar, Wiretext läuft im Web, ist aber nur für Desktop gedacht, und Monodraw wird als Mac-App angeboten
  • Der Ansatz, der in den 1970er- und 1980er-Jahren seinen Höhepunkt hatte, kehrt in einer Form zurück, die an TUI-Systeme wie Turbo Vision erinnert, nun aber mit modernem Look-and-Feel, Leistung, Web-Barrierefreiheit sowie guter Bedienbarkeit per Maus und Trackpad
  • Je leistungsfähiger Computer werden, desto nützlicher wird ein arbeitsstil mit selbst gesetzten Beschränkungen, und solche Klartext-Tools dienen zunehmend auch als Einstiegspunkt für gen AI

Die Beständigkeit von Klartext-Tools

  • Als Diagramm- und UI-Design-Tools auf Basis von Klartext oder „ASCII“ werden Mockdown, Wiretext, Monodraw genannt
    • Mockdown läuft direkt im Web und unterstützt auch Mobilgeräte
    • Wiretext läuft im Web, kann aber nur auf dem Desktop genutzt werden
    • Monodraw wird als Mac-App angeboten
  • Solche Tools werden eingesetzt, wenn man absichtlich begrenzte visuelle Optionen bevorzugt, wenn man niedrigschwellige Diagramme für den Einbau in Quellcode erstellen will, und zunehmend auch als Einstiegspunkt für gen AI
  • Ein Ansatz, der in den 1970er- und 1980er-Jahren seinen Höhepunkt hatte, erlebt in moderner Form ein Comeback
    • Er erinnert an TUI-Systeme wie Turbo Vision
    • Hinzu kommen moderner Stil, Leistung, Web-Barrierefreiheit sowie Bedienbarkeit mit Maus und Trackpad
  • Die Arbeitsweise mit bewussten Beschränkungen gewinnt selbst an Bedeutung
    • Je leistungsfähiger Computer werden, desto nützlicher ist es bereits, sich selbst Beschränkungen zu setzen, um die Arbeit zu erleichtern
    • Mit der Verbreitung von AI werden selbst gesetzte Beschränkungen auch in der Hinsicht wichtig, dass sie Arbeit gezielt schwieriger machen können
  • Monospaced Klartext hat nicht nur wegen der Portabilität seines Dateiformats Bestand, sondern auch, weil Textbearbeitung als Interface weit verbreitet und leistungsfähig ist
  • Das ASCII spray von Mockdown wird als besonders unterhaltsames Element hervorgehoben
  • Mit „ASCII“ ist hier weniger ein streng technischer Begriff gemeint als vielmehr eine umgangssprachliche Bezeichnung – ähnlich wie man sich wiederholende Animationen pauschal als „GIF“ bezeichnet

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 일 전
Hacker-News-Meinungen

  • Ich habe mich gefreut, dass Plain-Text-Buchhaltung als Beispiel genannt wurde.
    Ich habe die Buchführung meines Einzelunternehmens von QuickBooks auf Beancount+Fava umgestellt und bin deutlich zufriedener damit. Außerdem habe ich ein textbasiertes Rechnungssystem und ein Fahrtenbuch angebunden sowie einen Validator hinzugefügt, der dafür sorgt, dass bei Ausgaben mit Steuerstatus zwingend Belege verknüpft sind.
    Es ist viel schneller und einfacher zu benutzen als QuickBooks, ich muss keine Werbung sehen, und mit git plus RFC3161-Commit-Nachweisen kann ich belegen, wann ich was hinzugefügt habe. Außerdem ist die Gefahr geringer, dass durch unachtsame Textänderungen Einträge verschwinden, und man kann leicht prüfen, wann einzelne Posten angelegt wurden.
    Der Kern ist komplett Plain Text, aber wenn man möchte, habe ich auch Fava-Erweiterungen ergänzt, damit sich alles im Browser bearbeiten lässt. Ein TUI-Fava mit Diagrammen wäre noch besser, aber das Web-UI ist völlig in Ordnung.
    Jetzt bleibt nur noch die Frage, wie mein Steuerberater das anschauen wird.

    • Von Beancount höre ich gerade zum ersten Mal, aber es klingt ziemlich verlockend.
      Ich bin US-Amerikaner, arbeite aber in einem anderen Land und habe deshalb ständig mit zwei Währungen zu tun. Gnucash konnte Mehrwährungen für uns nie zufriedenstellend abbilden, daher führen meine Frau und ich unsere Aufzeichnungen bisher in Textdateien.
      Wir haben das Format ziemlich konsistent verwendet, daher denke ich, dass sich beim Umstieg auf Beancount mit einem Konvertierungsskript oder mit Hilfe eines LLM etwa 95 % der Arbeit automatisieren ließen; nur Einträge, die nicht geparst werden können, müssten als Warnungen erscheinen.
      Ich werde wahrscheinlich auch in Richtung Beancount + Fava gehen.
    • Das ist wirklich eine tolle Anregung für meine Plain-Text-Accounting-Projekte.
      Besonders würde ich gern mehr darüber erfahren, wie RFC3161-Commit-Nachweise eingesetzt werden.
      Ich nehme an, dass Commits mit GPG signiert werden, um zu zeigen, dass sie vom Autor stammen, aber ich frage mich, ob dabei ein externer Zeitstempeldienst und eine externe CA genutzt werden oder ob eine eigene Vertrauenskette aufgebaut wird.
      Ich würde auch gern wissen, mit welchen Unterlagen und Verfahren man das in der Praxis nachweist, wenn ein Buchprüfer die Echtheit der Buchungs-Commits verlangt.
    • Diese Herangehensweise gefällt mir wirklich.
      Auch wenn ich selbst einfache Dateiformate entwerfe, denke ich immer mit, wie ich sie bei Bedarf in ein gängigeres Format umwandeln könnte.
      Schon allein das Wissen, dass es bei Bedarf einen Ausweg gibt, um die Daten an andere weiterzugeben, beruhigt mich.
      In diesem Fall ließe sich das wahrscheinlich auch leicht in CSV umwandeln, das ein Steuerberater akzeptieren würde.

  • Die Blütezeit mag in den 1970er- und 1980er-Jahren gelegen haben, aber auch in der frühen DOS-Zeit der 1990er gab es hervorragende TUIs.
    Das war noch vor der vollständigen Vorherrschaft von Windows, und meist hatte man VGA-kompatible Grafikkarten und Monitore, sodass man hochauflösende, scharfe Textmodi mit anpassbaren Schriftarten nutzen konnte; oft war auch eine Maus vorhanden.
    Genau in so einer Umgebung bin ich mit QBASIC und EDIT.COM aufgewachsen.
    Einige Anwendungen von damals hatten sogar bereits einen richtigen Mauszeiger implementiert; das zeigt dieses Bisqwit-Video sehr gut: https://www.youtube.com/watch?v=7nlNQcKsj74

    • Ich mochte damals den Borland-Code-Editor wirklich sehr.
      Das war der Editor, der in Turbo-C, Turbo-Pascal und ähnlichen Produkten steckte; man könnte ihn fast schon eine IDE nennen.
      Auch WordPerfect, WordStar und Lotus 1-2-3 im Textmodus waren ziemlich hervorragend.
    • Für mich liegt der Höhepunkt der TUI irgendwo bei Norton Commander oder Midnight Commander.
    • Ich würde sogar sagen, dass wir gerade jetzt die Blütezeit der TUI erleben.
      Wenn man sich Omarchy anschaut, ein Betriebssystem, das sich um Terminal und Konfigurationsdateien dreht, wirkt das fast paradiesisch.
      Wenn wir auf eine Welt zusteuern, in der die wichtigste Schnittstelle zu Maschinen ein textbasiertes Gespräch ist, bin ich gespannt, wie weit sich dieser Trend noch entwickeln wird.
      Viele hier hören das vielleicht nicht gern, wenn man über AI spricht, aber ich freue mich wirklich auf diese Zukunft.

  • Als ich den Titel sah, bin ich gedanklich in eine etwas andere Richtung abgebogen als der eigentliche Text, aber wenn man glaubt, dass Plain Text die Grundlage einfacher und robuster Computerarbeit ist, dann ist Dylan Beatties Vortrag There's no such thing as plain text sehenswert.
    https://www.slideshare.net/slideshow/theres-no-such-thing-as-plain-text-dylan-beattie/249952971
    Man findet auch leicht Videos von verschiedenen Konferenzauftritten dazu.

    • Ich habe das Video noch nicht gesehen, aber schon anhand der Folien scheint eines der Hauptthemen das Problem der Kodierung zu sein.
      Dort tauchen auch Beispiele wie UTF-16LE und UTF-16BE auf.
      Zum Glück ist UTF-8 inzwischen faktisch der Standard, sodass man bei den meisten Dokumenten ohne besonderen Anlass davon ausgehen kann, dass sie UTF-8 sind.
      Selbst wenn ich eine Textdatei bekomme, deren Kodierung ich nicht kenne, würde ich die Wahrscheinlichkeit, dass sie UTF-8 ist, auf etwa 99,7 % schätzen. Daher fühlt es sich für mich inzwischen wieder legitim an zu sagen, dass es Plain Text sehr wohl gibt.
    • Nur anhand der Folien erschließt sich mir die Argumentation nicht besonders gut.
      Falls die Aussage ist, dass Dinge wie Codepages oder UTF-16 zwar Plain Text seien, es in Wahrheit aber doch nicht sind, dann wirkt diese Behauptung aus Sicht des Jahres 2026 ziemlich aus der Zeit gefallen.
      UTF-8 ist inzwischen praktisch überall.
    • Ich habe diese Formulierung schon länger verwendet, aber immer nur mit dem vagen Gefühl, dass es dazu bestimmt schon einen richtigen Vortrag geben müsste.
      Es ist schön zu sehen, dass es so ein Material tatsächlich gibt.
    • Ich stimme dieser These entschieden nicht zu.
      Ein so komplexes und eigentümliches System wie Unicode kann man nicht wirklich plain nennen, und auch heute treten in vielen Anwendungen regelmäßig Unicode-Probleme auf.
      Das einzige Textsystem, das meiner Ansicht nach wirklich überall zuverlässig funktioniert, ist weiterhin ASCII, und erst so etwas sollte man als Plain Text bezeichnen.
      Das bedeutet zwar eine Einschränkung auf vorwiegend englische Inhalte, aber in vielen Umgebungen ist das sogar ganz natürlich, und ich kann diese Position verteidigen, obwohl ich selbst kein englischer Muttersprachler bin.

  • Plain Text ist wirklich großartig.
    Ich verwalte mehr als 20 Jahre meiner Notizen mit https://github.com/nickjj/notes.
    Auch Rechnungen bearbeite ich seit etwa 7 Jahren im Plain-Text-Stil mit https://github.com/nickjj/invoice.
    Für die Nachverfolgung von Einnahmen und Ausgaben nutze ich außerdem https://github.com/nickjj/plutus, und ich bin damit sehr zufrieden.
    Inzwischen exportiere ich einfach die Bank-CSV, spiele sie in Plutus ein und gleiche ein paar Minuten lang nur noch grob die Kategorien ab, dann ist die Buchführung erledigt.
    Auf diese Weise mache ich nun schon im zweiten Jahr meine Steuererklärung.

  • Text ist Lindy.
    Er hat den Test der Zeit bestanden und ist ebenso weit verbreitet wie SQL oder TCP/IP.
    Das erinnert mich auch an Graydon Hoares alten Beitrag Always bet on text.
    [1]: https://news.ycombinator.com/item?id=8451271
    [2]: https://graydon2.dreamwidth.org/193447.html

  • Ich frage mich, ob HN hier auch als Plaintext zählt.
    Die Website besteht zwar eindeutig aus HTML und Hyperlinks, aber das tatsächliche Nutzungserlebnis ähnelt eher einer klickbaren Textoberfläche.
    Kryptografisch betrachtet könnte man HTML durchaus als Plaintext ansehen, da es in ascii/utf-8 kodiert ist; auf MIME-Type-Ebene unterscheiden text/plain und text/html jedoch zwischen Dokumentstruktur und Stilinformationen.
    Auch Terminals gelten oft als Plaintext, enthalten aber in Wirklichkeit Metainformationen in Form von für Menschen nicht ohne Weiteres lesbaren Escape-Sequenzen.
    Umgekehrt gibt es in sozialen Medien viele Bilder, die nur aus ein paar Zeilen Text bestehen, und aktuelle mobile Plattformen können Text in Bildern inzwischen erkennen und sogar auswählbar machen.
    Da stellt sich dann auch die Frage, ob ein Bild, das nur Text und sonst nichts enthält, als Plaintext gilt.
    Was ich letztlich fragen möchte, ist, wo wir heute, viele Jahrzehnte nach der ersten Implementierung, die Grenze von Plaintext ziehen würden.

    • HN ist einfach ganz normales HTML, daher finde ich es nicht abwegig, es Plaintext zu nennen.

  • Das geht zwar etwas am eigentlichen Thema vorbei, aber ich musste an statistische Diagramme auf Basis von Textzeichen denken.
    Vor langer Zeit habe ich die DOS-Ausbildungsversion von MINITAB benutzt; sie konnte Scatterplots, Dotplots und Box-and-Whisker-Plots mit Textzeichen zeichnen.
    Wenn ich mich richtig erinnere, konnte man zwischen reinem Text bzw. ASCII und DOS-Zeichen zum Linienzeichnen wählen.
    Die Idee war, Leute dazu zu bringen, ihre Daten erst einmal zu explorieren, bevor sie mit formalen statistischen Tests weitermachen.
    Ich frage mich, ob es heute noch Programme gibt, die auf diese Weise einen ordentlichen Dotplot im Terminal darstellen.

  • Die Liste ganz oben ließe sich noch verlängern.
    https://asciiflow.com/
    https://asciidraw.github.io/
    Ich frage mich, welche weiteren Tools es noch gibt.

  • Es gibt auch M-x artist-mode, direkt in Emacs nutzbar.

  • Plain Text ist ohne Frage großartig, aber sobald Strukturierung nötig wird, fängt man bei jeder Datei wieder ganz von vorn an.
    Es gibt immer mehr Menschen, die nostalgisch auf die improvisierte Verarbeitung von Plain Text mit zusammengewürfelten alten Unix-Tools blicken, aber so ein Ansatz taugt für provisorische Situationen und ersetzt kein sauber spezifiziertes Format.

    • Es gibt reichlich strukturierte Plaintext-Formate wie XML, JSON, YAML, RDF, EDN, LaTeX, OrgMode, Markdown.
      Sie lassen sich als gewöhnlicher zeilenorientierter Text verarbeiten, auch in strukturierte Daten transformieren, und es existieren längst Clients oder Reader, die sie quasi wie WYSIWYG rendern.