Die Emacsifizierung von Software
(sockpuppet.org)- Dank KI-Agenten lassen sich persönliche native Apps inzwischen in wenigen Stunden erstellen, wodurch Software in den Bereich Emacs-artiger individueller Anpassung rückt
- MDV.app ist ein Markdown-Viewer für macOS, bei dem Suche, SQLite-FTS-Indizierung, Lesezeichen, Inhaltsverzeichnis und Positionsspeicherung in wenigen Stunden umgesetzt wurden
- Das Problem, dass Electron-Apps jeweils eine eigene Chromium-Kopie mitbringen, sowie die Schwierigkeit nativer UI-Entwicklung waren groß, doch Claude beherrscht SwiftUI souverän
- Wie in der Emacs-Kultur entstehen immer mehr hochgradig spezifische Werkzeuge, die jeweils eigene Unbequemlichkeiten lösen, und der Wert von Ideen, Beobachtungen und Prompts steigt gegenüber fertigen Produkten
- Agentisches Coding macht es leichter, Side Projects und Terminal-Tools mit einer gut nutzbaren UI zu versehen, und verwandelt die Erstellung nativer UIs in etwas, das Spaß macht
Warum ich meinen eigenen Markdown-Viewer gebaut habe
- In der Softwareentwicklung war Markdown schon vor LLMs eine Art gemeinsame Sprache, und seit dem Aufkommen von Agenten wieder mehr TUI-Werkzeuge entstehen, ist es noch schwerer zu ertragen, Markdown im Terminal ständig scrollend zu lesen
- Als TUI-Markdown-Viewer gibt es Charms glow und Joshs Markless; Markless unterstützt auch die Navigation per Inhaltsverzeichnis, aber Terminals verwenden meist nichtproportionale Schriftarten, was bei längerem Lesen ermüdet
- Unter macOS gibt es grafische Markdown-Editoren wie Obsidian, Typora und Bear, die sich gut lesen lassen, aber allesamt Editoren sind, sodass beim Öffnen einer
.md-Datei die bestehende Bearbeitungsumgebung und Fensteranordnung durcheinandergeraten - Markdown-Viewer im App Store wirken anfangs brauchbar, doch in der Praxis zeigt sich dann oft, dass Suche fehlt, In-App-Käufe vorhanden sind oder ausgewählter Text nicht in die Zwischenablage kopiert werden kann
- Für 2026 wurde die Richtung geändert: Statt weiter nach einem halbwegs passenden Viewer zu suchen, kann man den gewünschten Markdown-Viewer nun einfach mit einem KI-Agenten erzeugen
MDV.app, gebaut mit Claude
- MDV.app wurde in wenigen Stunden auf ein Niveau gebracht, das besser ist als die dedizierten Markdown-Viewer aus dem App Store; die tatsächliche Interaktionszeit lag bei etwa 30 Minuten
- Auf einem alten MacBook wurden Xcode und git eingerichtet sowie die Claude-Umgebung vorbereitet; diese Vorarbeiten und das Nachschlagen von Hilfe zu Swift und macOS-Design liefen bereits seit einigen Wochen
- MDV ist weder die beste macOS-Anwendung noch besonders brillante Software, aber als dedizierter Markdown-Viewer für macOS ist sie mehr als gut genug und verbessert die Lebensqualität deutlich
- Zu den Hauptfunktionen von MDV gehören Textauswahl und -kopie in Dokumenten, Suche nach festen Zeichenfolgen, SQLite-FTS-Indizierung aller Markdown-Dateien im bearbeitbaren Verlauf, Lesezeichen per Tastenkürzel und Navigation per Inhaltsverzeichnis
- Beim Wechsel zwischen Dokumenten merkt sich die App die Position und setzt sie auch nach einem Neustart fort; außerdem bietet sie Farbthemen und gut lesbare Typografie, sodass beim Anklicken einer
.md-Datei sofort die gewünschte Leseumgebung aufgeht
Die Grenzen von Electron und der Wandel nativer UIs
- Jedes Mal, wenn eine Signal-Nachricht eintraf, flackerte der Bildschirm weiter, und hörte erst auf, wenn die Signal-App ausdrücklich ausgeblendet wurde; das subtile Flimmern ging fast bis an die Grenze einer Migräne
- Der Grund dafür ist, dass Signal eine Electron-App ist: Sie sieht äußerlich wie eine native macOS-App aus, ist in Wirklichkeit aber eine Konstruktion, in der eine Chromium-Kopie eine geheime Webseite rendert
- Fast jede UI-App der letzten zehn Jahre scheint ihre eigene Chromium-Kopie mit sich herumzutragen, und Electron hat sich als nicht großartig, aber ausreichend brauchbare Option gehalten
- Echte native UIs zu bauen war historisch schwierig, und selbst durchschnittliche Leute für diese Arbeit waren schwer zu finden; wirklich kompetente Entwickler für native macOS-UIs waren selten
- Claude ersetzt nicht nur einen durchschnittlichen SwiftUI-Entwickler, sondern wird tatsächlich als jemand wahrgenommen, der SwiftUI souverän beherrscht
Wie Emacs-Kultur in Software allgemein ausläuft
- MDV ist weniger ein fertiges Produkt, dessen Installation empfohlen wird, sondern eher etwas, bei dem man wie bei einer glänzenden
.emacs-Konfiguration Ideen stiehlt, um etwas Besseres zu bauen - In der Emacs-Kultur entwickeln langjährige Nutzer mit elisp Anwendungen, die aus persönlichen Frustrationen rund um Textbearbeitung entstehen, und diese Werkzeuge wachsen weit über das hinaus, was vernünftigerweise zu einem Texteditor gehören sollte
- /r/emacs ähnelt eher einer Show-and-Tell-Kultur als einer Product-Hunt-artigen Produktwerbung; es gibt zwar weit verbreitete elisp-Pakete, aber außer Magit besteht eine starke Tendenz, alles in noch glänzenderer Form selbst neu zu bauen
- Die Schwäche der Emacs-Kultur war, dass Pakete abgesehen von Magit meist hässlich und langsam waren und eine schlechte Nutzererfahrung boten, die man oft erst nach langer Beschäftigung mit elisp überhaupt entdeckt
- KI-Agenten haben diese Kultur aus Emacs herausgedrückt: Wenn sie Zugriff auf Bildschirm und Eingabe haben, können sie native UIs zuverlässig erstellen, wodurch native UIs sich vom Bereich professionell verpackter Programme in den Bereich persönlicher Anpassung verschieben
Das Potenzial persönlicher nativer Werkzeuge
- Emacsifizierte Software ist meist persönliche Software, die nur für ihren Ersteller nützlich ist, und es wird mehr Werkzeuge geben, die wie alte elisp-Programme in einer
.emacs-Datei in Vergessenheit geraten - Manchmal werden solche Programme nützlich genug, um die Grenze zu überschreiten und von mehreren Leuten installiert zu werden, doch selbst dann ist womöglich nicht das ausgelieferte Artefakt oder der Quellcode das Wichtigste
- Wenn ein Agent den gesamten SwiftUI-Code geschrieben hat, ist womöglich die Idee und Beobachtung wichtiger als das genaue Lesen des Quellcodes: dass man so etwas bauen kann und dass es gut funktioniert
- Bei dieser Art von Software könnten Prompts wertvoller sein als Quellcode, und für Menschen, die daran gewöhnt sind, Software direkt in Betrieb zu bringen, wird plötzlich alles nicht nur technisch, sondern auch praktisch programmierbar
- Von mit Agenten erzeugter Software zu sagen, man habe sie „gebaut“, wirkt fast übertrieben, weil der Aufwand so gering war; das tatsächliche Gefühl ähnelt eher dem Konfigurieren auf einer Plattform, die plötzlich viel stärker anpassbar geworden ist
- Entwickler, die KI nutzen, bringen endlich die zufälligen Side Projects zu Ende, die sich über Jahre angesammelt haben
- Nun werden solche hochspezifischen Werkzeuge nicht nur fertig, sondern können auch eine gut nutzbare UI haben, was einige der bisherigen Gründe schwächt, warum man Emacs’ unbeholfene UI in Kauf nahm
- Das Potenzial, Terminal-Apps viel leichter zu verbessern, ist deutlich größer geworden, und Werkzeuge wie
iostat,iostatüber mehrere Hosts hinweg oderbpftracelassen sich in verständlichere Formen bringen - Die Komplexität, die Brendan Gregg für
bpftrace-Visualisierungen im Terminal in Kauf nehmen musste, muss man nun nicht mehr einfach hinnehmen, und es gibt auch bereits ein selbst gebautes Beispiel - Als Vulnerability-Researcher waren die Fortschritte bei agentenbasiertem Exploit-Development im ersten Halbjahr 2026 interessant, doch für die meisten Menschen war das eine beängstigende Veränderung; dass es nun Spaß macht, native UIs zu bauen, ist dagegen fast durchweg eine gute Nachricht
- Es lohnt sich, übertrieben spezifische Werkzeuge für die eigenen Probleme zu bauen, sie kurz zu genießen und dann zu teilen — oder besser noch Screenshots und die verwendeten Prompts zu veröffentlichen
1 Kommentare
Hacker-News-Kommentare
Ich denke, es ist an der Zeit, dass Nerds Bereiche zurückerobern, die heute größtenteils zu vorgepackter Spezialsoftware geworden sind: Podcast-Apps, Musik-Apps, Feed-Reader, Bluesky-Clients, Notiz-Apps, Desktop-Lesezeichen-/Später-lesen-Apps, Chat und Messenger, Zeiterfassung, Rezeptverwaltung und Ähnliches
Mit Claude kann man leicht Ergebnisse erzielen, die besser sind als die Alternativen. Vielleicht nicht die besten oder weltweit konkurrenzfähigen Apps, aber Apps, die viel besser zu der eigenen eigenwilligen Arbeitsweise passen
Music.app ist unerquicklich zu benutzen, aber Apple hat die Kernfunktionen schon vor langer Zeit in MusicKit ausgelagert. Das eigentliche Produkt ist jetzt MusicKit, und ich weiß nicht, warum wir überhaupt noch Music.app benutzen; das ist neu
Ein Experiment in diese Richtung ist https://github.com/dharmatech/9social
Der erste Client wurde für plan9 geschrieben, weil das das Design ehrlich hält. Wenn es auf plan9/rc/acme läuft, ergibt es Sinn
Das Video-Demo ist https://youtu.be/q6qVnlCjcAI, und die aktuelle Implementierung hat weniger als 3000 Zeilen Code
Wenn wir schon von Emacs sprechen: 9social wurde stark von dem Emacs-Projekt Org Social inspiriert: https://github.com/tanrax/org-social
Ein unvollständiges tabellenbasiertes Interface zur Zeiteingabe. Ich habe es fürs Consulting gebaut, bin aber nie bis zur Datenspeicherung gekommen. Es gibt darin einen netten Algorithmus, der fast alle Arten verarbeiten kann, wie Leute natürlich Zeit eintragen; ich habe ihn gebaut, weil mich an bestehenden Zeiterfassern stört, dass sie strukturierte Eingaben erzwingen: https://stackoverflow.com/a/49185071/59087
Rezeptverwaltung: https://repo.autonoma.ca/repo/recipe-fiddle
Im LLM-Zeitalter wird es viel einfacher sein, Zutaten zu klassifizieren und für TeX zur PDF-Veröffentlichung zu formatieren. Die Idee dieses Projekts war, Webrezepte oder Scans handschriftlicher Rezepte fast per Copy-and-paste automatisch zu formatieren
In F-Droid gab es keine App, die all das erfüllte, also habe ich einfach selbst ein APK gebaut
Dank des LLM-Zeitalters ist Softwareproduktion so einfach geworden, dass sich jetzt alles wie eine .emacs-Datei anfühlt. Also bekommt jede Person ihr ganz persönliches, endlos anpassbares Software-Kuddelmuddel
Wie der OP es ausdrückt: Es ist einfacher geworden, die eigene Lösung zu bauen, als etwas Vorhandenes zu installieren oder zu lernen
Lisp ist auch eine gute Analogie. Eine alte Kritik an Lisp-Makros war, dass jeder Programmierer alles in seine eigene Privatsprache umbiegt, sodass niemand sonst es noch lesen kann
Das erinnert mich auch an Mark Tarvers Text von 2007, "The Bipolar Lisp Programmer": https://hn.algolia.com/?query=comments%3E0%20The%20Bipolar%20Lisp%20Programmer&type=story&dateRange=all&sort=byDate&storyText=none&prefix
Er sprach vom "brilliant bipolar mind", was heute auf interessante Weise mit der oft ironisch oder ernst gemeinten AI psychosis mitschwingt
In Tarvers Text https://www.marktarver.com/bipolar.html heißt es, das "throw-away design" der Lisp-Community passe perfekt zum BBM. Lisp macht es zu einfach, schnell irgendetwas hinzurotzen, sodass jeder seine eigene Lösung baut und es genügt, wenn sie für einen selbst funktioniert
In C/C++ ist es dagegen so schwer, überhaupt etwas Bedeutendes zu bauen, dass das schon eine Leistung ist und Motivation für Dokumentation und Zusammenarbeit schafft. Aus Sicht eines Arbeitgebers sind 10 Leute, die kommunizieren, dokumentieren und zusammenarbeiten, attraktiver als ein unersetzlicher Lisp-Hacker
Wenn Produktion leicht wird, wird Konsum zum Flaschenhals, und Teilen wird schwer. .emacs-Dateien sind so persönlich wie Fingerabdrücke; man kann sich Stücke daraus nehmen, aber man will nicht gleich die ganze Konfiguration eines anderen verwenden
Je stärker diese Kuddelmuddel-Systeme angepasst werden, desto schwerer wird es für andere, sie zu verstehen oder benutzen zu wollen. Nicht nur wegen der kognitiven Kosten, sondern auch weil es sich anfühlt, als trüge man fremde Kleidung. Ich würde das weniger AI psychosis nennen als AI-Solipsismus
In Software wird Konfigurationsmanagement zum schwierigen Teil. Wie teilt und versioniert man die Quelle? Was ist überhaupt die Quelle? Der Prompt? Auch der OP endet eher bei Screenshots und Prompts als bei Code
Auch auf Show HN wurde schon ein Versuchsballon gestartet, dass man Prompts teilen sollte, weil generierter Code nicht mehr die Quelle sei, aber das hat bei Leuten, die sich auskennen, viel Gegenwind ausgelöst: https://news.ycombinator.com/item?id=47213630
Auch GitHub gerät zwangsläufig unter Druck durch diese Entwicklung. Wie ein Nachfolger aussehen wird, ist unklar, aber gebraucht werden wird er. Im Moment wirkt das noch wie die Phase der pferdelosen Kutsche
Noch wichtiger ist Teamarbeit. Wenn alle BBMs sind oder jeder von uns seine eigene manische BBM-Armee hat, die rund um die Uhr nur für uns generiert, wie arbeiten wir dann zusammen? Wie kommunizieren und interoperieren diese Kuddelmuddel-Systeme miteinander? Ein Team aus AI-Solipsisten klingt widersprüchlich
Teams und Startups an der Front von AI-getriebener, agentischer Entwicklung dürften das gerade real erleben. Etwa die Frage, wie man meinen generierten Code und deinen generierten Code zusammenführt. Es ist gut möglich, dass ein Teil der Produktivitätsgewinne durch generierten Code an solcher Reibung wieder verloren geht
Schade, dass darüber öffentlich noch nicht viel gesprochen wird. Niemand will bei der obligatorischen Standing Ovation als Erster wieder sitzen, aber wenn wir so tun, als sei das alles ein kostenloses Mittagessen ohne Nachteile, wird die Diskussion langweilig und die Entwicklung langsamer
Wenn die Leute, die mit den neuen Tools die ernsthafteste und fortgeschrittenste Arbeit machen, nicht über die Nachteile sprechen, bleiben diese Nachteile nur noch den Zynikern überlassen, die AI in der Softwareentwicklung für wertlos halten. Es ist offenbar leichter, über das Aussterben der Menschheit zu reden als über mehr Bugs oder stagnierende Produktivität
Ich würde gern wissen, was tatsächlich passiert, wie Menschen darauf reagieren und wie sich das im Lauf der Zeit verändert. Vielleicht muss ich zu Meetups gehen
Passend dazu trug ein Paper den Titel "Easier to Write, Harder to Read": https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6726702
Warum sollte ich das Produkt einer bestimmten Unterhaltung mit einem LLM lesen? Wenn ich nur das Thema kenne, kann ich selbst die bessere Unterhaltung führen
Mit solcher Software ist es ähnlich. Ein bisschen Geschmack spielt eine Rolle, aber meistens sind die Idee und das Rezept das Entscheidende
Ein monatlicher „Vibe HN“-Thread wäre schön
Ich frage mich, ob man ein Video teilen kann, in dem jemand in noch kürzerer Zeit ein maßgeschneidertes WhatsApp baut. Und dabei haben wir noch nicht einmal das Problem angeschnitten, andere Leute in einen improvisierten Messenger hineinzuziehen
Jetzt heißt es eher: „Ich werfe dieses Ticket mal in Claude, du probierst es mit Copilot und dann vergleichen wir die Ergebnisse“ oder „Ich mache mit meinem groben Ergebnis einen PR, du reviewst ihn mit deinem Tool.“ Ehrlich gesagt fühlt sich das fast sinnlos an, und Pair Programming ist komplett tot
Wer will schon dabei zusehen, wie mehrere Agents laufen, Probleme in verschiedenen Working Trees behoben werden und Inkonsistenzen in
agents.mdausgebügelt werdenEs wird darauf gedrängt, vollständig autonome Cloud-Pipelines zu bauen, die sich selbst betreiben, aber das Management scheint das leise ausbremsen zu wollen. Offenbar gibt es das schlichte Verständnis, dass einige bequeme Positionen verloren gehen würden, sobald bewiesen ist, dass das wirklich fliegen kann
UNIX war kein Produkt, sondern eine Umgebung, optimiert dafür, Werkzeuge zu bauen und echte Probleme zu lösen, und diese Werkzeuge wurden in C geschrieben. Währenddessen waren die BBMs in Boston wohl mit Lisp beschäftigt
C++ ist eine ganz andere Geschichte, und dort braucht man eine IDE
Emacs hat diese Eigenschaft, weil es Lisp verwendet. Die allgemeine Tendenz, dass Programmierer alles selbst bauen, wurde bei Lisp beobachtet und The Lisp Curse genannt
Ein Fluch ist es deshalb, weil Programmierer aufhören zusammenzuarbeiten. Alle werden zu Zauberern in ihrem eigenen Turm, der allgemeine Fortschritt kommt zum Stillstand, und es folgt ein dunkles Zeitalter
Dass das LLM-Zeitalter persönliche Software hervorgebracht hat, stimmt
Aber ehrlich gesagt hat mir die Zeit mit Emacs nicht beigebracht, wie man persönliche Software baut. Meine Emacs-Konfiguration war extrem fragil, und sie gleichzeitig unter Windows und macOS zu verwenden, war ein Albtraum
Ein Uni-Projekt habe ich mit einer bizarren Mischung aus org-mode und irgendeinem Workflow geschrieben, die wunderschöne LaTeX-Dateien erzeugte, aber ich könnte heute nicht erklären, wie man das noch einmal kompiliert. Wenn ich es versuchen müsste, würde ich wahrscheinlich ein LLM bitten, es direkt in LaTeX zu übersetzen
Ich möchte in meinem Leben möglichst wenig Wartung haben, und alles selbst zu bauen passt nicht immer zu diesem Ziel
Ich habe allerdings einmal eine NETFX-Anwendung in Rust neu geschrieben, weil mich die 20 Minuten Installationszeit genervt haben: https://github.com/bevan-philip/wlan-optimizer
Die tägliche Arbeit eines Programmierers besteht darin, das Verhalten von Computersystemen zu verändern: lokal, remote, in der Cloud, eingebettet und so weiter. Anforderungen ändern sich, der Umfang verschiebt sich, der Problemraum entwickelt sich weiter, und Ablagerungen sind unvermeidlich
Man muss ständig zwischen Sprach-Stacks, Datentypen, Formaten, CLI- und Web-Tools, Protokollen, Paradigmen sowie Open-Source- und proprietären Apps wechseln
Deshalb muss man sich laufend anpassen, und auch die eigene Steuerungsebene muss sich mitverändern. Der Kern ist Automatisierung. Jede kleine Nervigkeit kann und sollte automatisiert werden. Das bedeutet endlose Verformung des Workflows, also fortlaufende Wartung der Werkzeuge, aber keine leidvolle reaktive Wartung
Als Programmierer nicht fortlaufend Software für sich selbst bauen zu wollen, ist eine Illusion. Das ist wie ein Koch, der im Restaurant Feuer macht, aber zu Hause nicht einmal ein Messer anfassen will
Emacs ist die Küche des Kochs zu Hause. Es gibt reaktive Wartung wie Reparaturen und das Nachziehen bei Veränderungen, und es gibt generative Wartung, bei der Werkzeuge geformt werden, weil sich das eigene Verständnis weiterentwickelt. Programmierer sollten Ersteres hassen und sich zu Letzterem hingezogen fühlen
Emacs eignet sich für generative Wartung nahezu einzigartig gut, weil Werkzeuge und Arbeit dort dieselbe Veranlagung teilen
Die Beschwerde, Emacs sei „zu viel Arbeit in der Konfiguration“, ist häufig, bedeutet aber meist nur: „Ich will nicht investieren, bevor ich Wert herausbekomme.“ Langfristig ist das keine kluge Strategie. Man sollte Emacs eher als universelles Werkzeug sehen, das die gesamte Wartungslast über Karriere und Leben hinweg reduziert
Emacs- oder VIM-Konfigurationen sind einfache Textdateien, die man in einem normalen Editor öffnen und nach Bedarf ändern kann, und man weiß, wo was liegt. Meine VIM-Konfiguration ist 20 Jahre alt; erst vor ein oder zwei Jahren habe ich die manuelle Paketverwaltung aufgegeben und einen Plugin-Manager eingeführt
Hier gibt es keine Gatekeeper und keine Abhängigkeiten
Der heutige Ansatz dagegen verlangt entweder 20–200 Dollar an ein Drittunternehmen zu zahlen oder eine ziemlich starke GPU für lokales Ausführen zu besitzen, dann Anweisungen in eine Textdatei zu schreiben und so lange weiterzufeilen, bis das Gewünschte herauskommt
Man fügt sich damit selbst Abhängigkeiten hinzu, und wenn das Ganze so verworren wird, dass es für Menschen schwer zu reviewen ist, werden es starke Abhängigkeiten sein. Ob das nun eine teure GPU ist oder das Senden von Daten an ein Unternehmen, das seine Aktionäre zufriedenstellen muss, macht keinen Unterschied
Wir müssen unterscheiden, wie sich diese beiden Dinge unterscheiden und was die tatsächlichen Kosten sind, die wir zahlen
Die Idee von persönlicher Software, also Programmen, die man für sich selbst schreibt, war die ursprüngliche Vision des Heimcomputings in den 1960er Jahren
Den PC hat man sich nicht exakt so vorgestellt, aber die Idee war, dass alle zu Hause ein Computerterminal haben und Programme schreiben würden, um die Dinge zu erledigen, die sie brauchen. Man stellte sich vor, Programmierung würde so einfach werden, dass jeder sie lernen könnte
Ganz dort sind wir noch nicht, aber dank LLMs nähern wir uns an
Die Idee ist, dass Nichtfachleute interessante Software in Autorenumgebungen mit gut gestalteten Bausteinen und leicht verständlichen Metaphern erstellen können. Die Schichten aus zufälliger oder überentwickelter Komplexität müssten dabei entfernt sein
Auch in dieser Vision braucht Software sorgfältiges logisches Denken, aber die Mühe, dieses Denken in ausführbaren Code zu übertragen, würde stark sinken. Es gäbe auch keine Albträume mit Toolchains und Build-Systemen
Stattdessen haben wir extrem mächtige Modelle gebaut, die komplexe Beschwörungsformeln für uns nachsprechen und neu zusammensetzen. Aber die Komplexität bleibt bestehen und ist für Nichtfachleute weiterhin undurchsichtig
Trotzdem könnten LLMs helfen, einen Teil dieser Komplexität zu beseitigen. Die Richtung, in der Einzelpersonen LLM-generierte Software leicht verstehen und selbst verändern können, ist weiterhin möglich und könnte die LLM-Welt gut ergänzen
Das ist keine Frage des Ob, sondern nur des Wann; höchstens zehn Jahre, wahrscheinlich deutlich schneller. Schon jetzt machen Verwandte von mir ohne Coding-Kenntnisse genau solche Dinge
Diese Zukunft des Computings ist wirklich wundervoll und enorm ermächtigend
Die aktuelle Swift-App hat 15.000 Zeilen, davon 5000 Tests und 10.000 Implementierung. Sie ist fast fertig und tut, was ich brauche. Es hat 20 Stunden gedauert
Da ich noch nie Swift gemacht habe, hätte mich das selbst wahrscheinlich 500 Stunden gekostet
Wahrscheinlich geht es nicht so weit, weil die meisten von uns zu bequem sind, aber es ist definitiv bedenkenswert
Schon der Begriff der Anwendung wird viel fließender werden
Wenn eine App in einer dynamischen Sprache gebaut ist, gibt es keinen Grund, Nutzer nicht den Code selbst umschreiben und völlig neue Funktionen hinzufügen zu lassen
Nicht direkt zum Artikeltext, aber ich stimme nicht zu, dass Terminals wegen der fast immer festen Breite ermüdend für längere Texte sind. Persönlich finde ich Monospace-Schrift für lange Texte viel angenehmer
Der Autor spricht einen interessanten Punkt an. Die Variablen sind die Schwierigkeit, ein Tool zu bauen, die Schwierigkeit, es zu veröffentlichen, sein Nutzen für andere, die soziale Belohnung fürs Veröffentlichen und der negative Anreiz, Abhängigkeiten hinzuzufügen
Wie schwer es wird, bestehende Lösungen zu finden, steigt mit den Kosten dafür, dass jemand sie bauen muss, und den Kosten dafür, dass jemand herausfinden muss, wie man sie veröffentlicht. Umgekehrt gilt: Je nützlicher etwas für die Community ist, desto leichter ist es zu finden, weil Leute davon erzählen
Wenn die Schwierigkeit des Bauens und die Schwierigkeit des Veröffentlichens stark auseinanderliegen, besonders wenn Bauen viel höher ist, neigen Menschen dazu, Dinge einfach zu bauen und dann zu vergessen. Wenn Veröffentlichen billig ist, gibt es weniger Problemlösungen
Wenn beides billig ist und Nutzen für andere sowie soziale Belohnung höher sind als die Abhängigkeitskosten, entsteht so etwas wie leftpad. Viele Pakete auf NPM bestehen aus hohem Nutzen und hoher Belohnung bei niedrigen Abhängigkeitskosten
In Emacs Lisp war die Bauschwierigkeit früher hoch, jetzt ist sie niedrig, und wenn man die Lernkurve überwunden hat, ist auch die Veröffentlichungsschwierigkeit niedrig. Nutzen, Belohnung und Abhängigkeitskosten sind in keine Richtung besonders hoch
Dann landet man bei einem Szenario, in dem man einfach etwas baut, bevor man überhaupt danach sucht, ob es schon ein Tool gibt. VSCode oder früher Eclipse waren anders, weil dort die Veröffentlichungsschwierigkeit hoch war
Irgendjemand Jüngeres als ich wird das vermutlich als Paper-Thema in die Welt setzen
Dieser Text deutet auf eine noch nicht eingelöste Veränderung hin, die LLM-Coding bringen könnte. Können wir Electron/React Native nun nicht fallenlassen und LLMs Figma, Wireframes und Verhaltensspezifikationen in echte native Apps für jede Plattform umwandeln lassen?
Bei CRUD-Apps kommt man mit API-Spezifikation und UI-Mockups, vielleicht sogar nur mit Screenshots einer bereits implementierten Plattform, schon ziemlich weit. Das ist genau die Art gut definierter Arbeit, in der LLMs stark sind. Gleichwertigkeitstests müsste man zu einem guten Teil automatisieren können
Werden Ausreden wie „vielleicht fügen wir Android irgendwann hinzu“ oder „wir haben nicht genug Mac-/Linux-Nutzer“ dann noch Bestand haben? Wird es noch zu rechtfertigen sein, in iOS-Apps für selten genutzte Abläufe wie Passwort-Zurücksetzen einfach ein beliebiges WebView zu öffnen?
Selbst bei Apps mit nichttrivialer Logik auf dem Gerät haben LLMs schon ziemlich gut gezeigt, dass sie Dinge in Sprachen wie Go oder Rust umschreiben können, die sich leicht cross-kompilieren lassen
Noch provokanter gesagt: Warum sollte man SwiftUI an diesem Punkt überhaupt noch lernen? Für die meisten Aufgaben fällt SwiftUI-Expertise in eine ähnliche Kategorie wie „Microsoft Word sehr gründlich lernen“
Ich respektiere Leute, die diese Zeit investieren, aber ob man das tut oder nicht, macht im Ergebnis fast nur noch einen Unterschied im Millimeterbereich
Ich denke nicht über das Programmieren insgesamt so. Ich glaube nur, dass es jetzt komplizierter geworden ist, warum man sich in bestimmte Sprachen überhaupt noch spezialisieren sollte