What killed Perl for me was readability, long before Perl 6/Raku. I was an Awk programmer from way back, so took to Perl quickly once it was available. Then in the late 90's I wrote a utility program in Perl that generated some nice HTML documentation for me from some kind of input format I no longer recall.
A year later I tried to use that script on another project, but had to make some changes; and couldn't make heads or tails of it. Shortly thereafter I had occasion to look at some Tcl/Tk I'd written at about the same time...and it made perfect sense to me.
Had I used Perl on a daily basis, rather than occasionally, I might have stuck with it. Instead I switched to Tcl/Tk, and never regretted it.
Reminds me of the pre-GitHub days, when I had to use CM tools designed to appeal to project and CM managers, not to the poor developers who had to use them every day. Anybody else remember Harvest?
I've been doing development using JavaFX, Swing's successor, for many years. It's got its quirks, and places where the dev team stopped iterating on the API a little too soon; but it works and does some really nice stuff.
AI of this kind is nothing more than AI-generated companionship porn. It's destructive of users and of real relationships, as we're already seeing with earlier generations of chatbots (including non-LLM chatbots).
I'd like to see this succeed, but I'm skeptical that a small team can keep up with the major players in this area. Many years ago Dan Kennedy (of the SQLite team) wrote a lovely HTML widget for TCL/TK. It rendered CSS 1.0 quite nicely, and was a pleasure to use, modulo a few font-related bugs; but was soon rendered obsolete and out of date. Not blaming Dan, here; it simply wasn't a one-person job. Meanwhile, I'd rewritten an app to make use of it. Got burned once, don't want to get burned again.
I feel like part of the solution here is to build the browser as reusable modular components. For some parts of browsers that's been common for years: JS engines (V8, SpiderMonkey, etc) are typically reusable, as are rendering backends (WebRender, Skia, etc), and lower-level components like Freetype/Harfbuzz/icu.
Servo's CSS engine Stylo is also modular, and is shared by Firefox which is part of how they've managed to not completely fall behind in web standards support despite the project being all but abandoned for several years.
I'm building another browser engine Blitz [0] which also uses Stylo, and we're building our layout/text engine in such a way that it can be reused so future browser engines (at least ones written in Rust) shouldn't need to build either Style or Layout if they don't want to.
A few more infrastructure pieces like this and browser engine development starts to look more approachable.
It's several small teams. Servo is modular, and parts of it are useful outside of Servo. Other projects are using and maintaining and enhancing those modules. For example, IIRC dioxus uses many of the modules.
Edit: see sister comment by the actual Dioxus guy, which is more accurate than mine!
Leuchtturm 1917 dot grid journal, Uniball Jetstream pen, and a minimalist version of Ryder Carroll's bullet journaling advice. (https://bulletjournal.com)
I like the Leuchtturm journals because they have page numbers and they don't fall apart.
I record todos, appointments, significant events, and detailed notes on anything I'm studying or thinking about in detail. Each successive journal gets a number, so that so I can easily and unequivocally reference any page in any journal.
Unless you're solving the same old problem for the Nth time for a new customer, you don't really understand the problem fully until you write the code.
If it's a new problem, you need to write the code so that you discover all the peculiar corner cases and understand them.
If it's the (N+M)th time, and you've been using AI to write the code for the last M times, you may find you no longer understand the problem.
Dunno. I’ve been at this since the late ‘80’s, and have run into precious few developers who were interested in software and programming for its own sake. For most of them it was just a job.
A year later I tried to use that script on another project, but had to make some changes; and couldn't make heads or tails of it. Shortly thereafter I had occasion to look at some Tcl/Tk I'd written at about the same time...and it made perfect sense to me.
Had I used Perl on a daily basis, rather than occasionally, I might have stuck with it. Instead I switched to Tcl/Tk, and never regretted it.
reply