There's some irony in the fact that LLMs are in large part possible because of open source software.
From the tools which were used to design and develop the models (programming languages, libraries) to the operating systems running them to the databases used for storing training data .. plus of course they were trained mostly on open source code.
If OSS didn't exist, it's highly unlikely that LLMs would have been built.
Not really. This db allows traversing the (deeply nested) data structures without loading them into memory. Eg. In Clojure you can do
```
(get-in db [:people "john" :address :city])
```
Where `:people` is a key in a huge (larger than memory) map. This database will only touch the referenced nodes when traversing, without loading the whole thing into memory.
So the 'query language' is actually your programming language. To the programmer this database looks like an in-memory data structure, when in fact it's efficiently reading data from the disk. Plus immutability of course (meaning you can go back in history).
People use software for specific features, but most software have lots of features people never use or need. A lot of modern software is designed to handle lots of users, so they need to be scalable, deployable, etc.
I don't need any of that. I just need the tool to do the thing I want it to do.
I'm not thinking about end users, I just need to solve my specific problem.
Sure there might be better pieces of software out there, which do more things.
But the vibe coded thing works quite well for me and I can always fix it by prompting the model.
For example, I've vibe coded a tool where I upload an audio file, the tool transcribes it and splits it into 'scenes' which I can sync to audio via a simple UI and then I can generate images for each scene. Then it exports the video.
It's simple, a bit buggy, lacks some features, but it does the job.
It would have taken me weeks to get to where I am now without having written one manual line of code.
I need the generated videos, not the software. I might eventually turn it into a product which others can use, but I don't focus on that yet, I'm solving my problem. Which simplifies the software a lot.
After I'm finished with this one, I might generate another one, now that I know exactly what I want it to do and what pitfalls to avoid. But yeah, the age of industrial software is upon us. We'll have to adapt.
How about you try vibe coding a banking app or tax filing or pay roll app?
Most commercial software is nowadays integrated into the real world in ways that can't be replicated by code alone, software which isn't like this can be easily replaced yes, but that kind of software already had free alternatives.
In the dial-up era, the industry was young, there were no established players, it was all a big green field.
The situation is far from similar now. Now there's an app for everything and you must use all of them to function, which is both great and horrible.
From my experience, current generation of AI is unreliable and so cannot be trusted. It makes non-obvious mistakes and often sends you off on tangents, which consumes energy and leads to confusion.
It's an opinion I've built up over time from using AI extensively.
I would have expected my opinion to improve after 3 years, but it hasn't.
I'm very skeptical about such a future. The 'world' is already high tech. We're already drowning in products and entertainment.
At the same time, a million people talk to chatgpt about suicide each week, there's an epidemic of loneliness, mental health issues, wars, famines, pollution, climate change and the list goes on.
Work is not just about earning wages. A lot of people find a sense of purpose, a sense of belonging, community, pride and joy in the work they do.
For many it's also about the hierarchy, the title, the career ladder, etc.
I for one don't see how more automation / tech is going to fix the fundamental problems that the previous waves of automation have left behind.
Easy. You're 3x more productive for a while and then you burn yourself out.
Or lose control of the codebase, which you no longer understand after weeks of vibing (since we can only think and accumulate knowledge at 1x).
Sometimes the easy way out is throwing a week of generated code away and starting over.
So that 3x doesn't come for free at all, besides API costs, there's the cost of quickly accumulating tech debt which you have to pay if this is a long term project.
You conflate efficient usage of AI with "vibing". Code can be written by AI and still follow the agreed-upon structures and rules and still can and should be thoroughly reviewed. The 3x absolutely does not come for free. But the price may have been paid in advance by learning how to use those tools best.
I agree the vibe-coding mentality is going to be a major problem. But aren't all tools used well and used badly?
The population (especially the youth) is anesthetized by social media, shorts, fear-inducing news, economic hopelessness, climate extremes..
In the meantime, everything is getting integrated - banks, tax systems, tech platforms. Now this age verification..
And of course, AI is being implemented everywhere so that no one can evade the big brother.
As it stands now, this Internet is no longer salvageable imo.
Doesn't Clojure already support all of those features ?
Eg.
> transducer-first design, laziness either eliminated or opt-in
You can write your code using transducers or opt-in for laziness in Clojure now. So it's a matter of choice of tools, rather than a feature of the language.
> protocols everywhere as much as practically possible (performance)
Again, it's a choice made by the programmer, the language already allows you to have protocols everywhere. It's also how Clojure is implemented under the hood.
-> first-class data structures/types are also CRDT data types, where practical (correctness and performance)
Most of the programs I worked on, did not require CRDT.
I'm inclined to choose a library for this.
> first-class maps, vectors, arrays, sets, counters, and more
Isn't this the case already ? If Clojure's native data structures are not enough, there's the ocean of Java options..
Which leads to a very interesting question:
How should the 'real' AGI respond to your request ?
> first-class maps, vectors, arrays, sets, counters, and more
That's my mistake; this line was intended to be a sub-bullet point of the previous line regarding CRDTs.
> the language already allows you to have protocols everywhere
The core data structures, for example, are not based on protocols; they are implemented in pure Java. One reason is that the 1.0 version of the language lacked protocols. All that being said, it remains an open question what the full implications of the protocol-first idea are.
> You can write your code using transducers or opt in for laziness in Clojure now. So it's a matter of choice of tools, rather than a feature of the language.
You 100% can. Unfortunately, many people don't. The first thing people learn is (map inc [1 2 3]), which produces a lazy sequence. Clojure would never change this behavior, as the authors value backward compatibility almost above everything else, and rightly so. A transducer-first approach would be a world where (map inc [1 2 3]) produces the vector [2 3 4] by default, for example.
This was mentioned by Rich Hickey himself in his "A History of Clojure" paper:
(from paper) > "Clojure is an exercise in tool building and nothing more. I do wish I had thought of some things in a different order, especially transducers. I also wish I had thought of protocols sooner, so that more of Clojure’s abstractions could have been built atop them rather than Java interfaces."
From the tools which were used to design and develop the models (programming languages, libraries) to the operating systems running them to the databases used for storing training data .. plus of course they were trained mostly on open source code.
If OSS didn't exist, it's highly unlikely that LLMs would have been built.
reply