I just used to use dillo because it was faster, cleaner, and left more RAM free for other uses. If there was a sufficiently broken site that I still wanted to bother loading, I'd fire up whatever the big browser was called back then.
Dillo started as a fork of the Armadillo browser which was based on GTK+. It was the next version - Dillo 2 - which was ported to FLTK. The GTK+ version did not support CSS and initially did not support frames/iframes either. I submitted a patch which added support for the latter somewhere around 2003 which was never merged before the port to FLTK but which I have used for quite a while until these features became less important due to the uptake of CSS.
I just started it up and it turned out to be Dillo 3.0 from 2011. I do not know if it was using FLTK back then, but a quick search says that FLTK has been ported to DOS so that might not be an obstacle for the current developers to keep FreeDOS support if they wanted to.
I've also worked with CSV (barely) and SVN (more extensively) and I was blown away by Git.
You can have real branches! Many of them! You don't have to manually merge them! It's decentralized, you can have multiple origins, it lets you work offline! The list goes on and on.
There were many compelling reasons to switch to Git. But for all the articles about jj out there, I've never read any compelling reason to switch to jj. "It easier", "the commands are somewhat more ergonomic"... that's all?
One thing JJ has that git doesn't is the concept of first class conflicts. In JJ, rebasing or merging never fails, but it might record a conflict to resolve later. Git, on the otherhand, forces you to drop we everything to resolve conflicts immediately. It sounds like a small thing - but in my experience, being able to resolve conflicts later when I feel like it is absolutely amazing and really helps reduce context switching.
You don't need to switch from git to jj. You just try out jj on your git project and see if it clicks. If you don't like it, you just don't continue using it.
First and foremost I was wrong thinking that I was smarter than others — that's not even how intelligence works.
Second I was wrong being so stubbornly pro-tabs / anti-spaces (for example). It doesn't make that much of a difference, so there's no point in being so passionate about it.
And third I was wasting everyone's time (and my persuasion powers) by not choosing my battles more wisely.
My suggestion would be nowadays: let's choose a popular style guide, set up a linter and be done with it.
How is it spreading knowledge around? A lot of times it gives half backed answers and a lot of beginners are using it while learning. That's not a good mix in my opinion.
I've been helping someone who's learning programming and I've had a look at their code. All of it is vibe coded. And the vibes are nightmarish, I don't think the AI is helping at all.
The only thing it's useful for is sparing expert programmers some tedious work, that's my perception as a programmer.
Well, if you tell me that many people are using LLMs poorly, and in a way that won't benefit them or their team in the long term, then I wouldn't be too surprised.
There are probably more ways to use them poorly than ways to use them well.
And AI companies are pushing usage patterns that may make you dependent on them.
---
But I mention 4 ways that LLMs helped me recently here
i.e. VimScript, SQL, login shells, Linux container syscalls -- with some results you can see
I mention that "give me your best argument against X" is a good prompt -- they can do that
And I also don't use them to edit code for me (right now) -- I type the code myself, TEST it, and internalize it
So for those cases, and many others, they are "spreading knowledge" to me, simply because I can directly query them without reading the manual (or suffering through slow web pages with ads on them)
The end game might be ads, which is depressing. But actually it's remarkable that you can run high quality models locally, whereas you could have NEVER run Google locally. I use LLMs as a better Google, as a sophisticated text calculator. But they are significantly more than that too
I have definitely run into cases where LLMs slow me down, but I now avoid those usage patterns
Yeah, the other day a front end dev created a branch in some elixir code. They added a pile of tests, and asked a (new hire) back end dev to finish off the work. The tests were 100% vibe coded. I knew the code well, and after looking realized that the tests could never ever pass. The tests were rubbish.
Crap part was, the new BE dev was totally lost for a long time trying to figure out how to make them pass. Vibe killed his afternoon.
> But UIs are not pure functions, they have a deeply effectful nature, and being reactive all those effects are highly “situated” if you will (to use Rich Hickey’s word).
Oh, but we do this in ClojureScript the whole time.
You can express events and actions in pure functions as data and then take care of the effects outside of the core of your application.
A great example of how to do this is the "re-frame" framework [1] [2]. The documentation is also a joy to read.
> An example of this impedance surfacing in backend programming is a nontrivial map/reduce pipeline. What is the shape of the document at stage six?
There's many ways to find that out in Clojure/Script. There's the built-in `tap>` function [3] which can be used for debugging. You can use that to visualize complex data with Portal. [4]
IIRC I stopped using it when Firefox ("Phoenix" at the time) was released.