Well what if you take on an extremely ambitious project like writing a programming language complete with DAP step debugging, a full LSP, etc, etc?
That takes a lot of quality time to just figure out the right syntax and semantics, let alone having to figure out how all of these complex pieces fit together!
> However, the process was far more important than the product (again!). Not every whimsy needs to become a reality.
I mean, I get it, there's different kinds of people out there with different motivations, goals, spare time, etc.
But there's also a process of product design that I think the author is overlooking.
Lately I've been working and iterating on a number of DSLs, projects that might be a total waste of my time because they end up being poorly conceived or not very useful compared to a general purpose language!
I'm also working on a video game that is basically Magic: The Gathering meets StarCraft with Civilization style hex-grid conflict. It could be a total bust and entirely no fun to play (it's hard to tell if it's fun by itself because I enjoy working on the game while testing out the play patterns). It would suck to spend a couple of years on this if it's no good.
I very much enjoy the process of trying to figure out the best syntax and semantics for a new DSL or the process of iterating on gameplay elements when working on a game. The destination is also less important. I don't really expect anyone to use my DSLs or play my video games. I'm ultimately doing it for my own enjoyment.
Saying this, I am interested in the overall architecture and I've definitely learned from my mistakes, especially with creating DSLs. Like, having a TypeScript language server with a Rust runtime has some issues. It's kind of better to build the language server into the runtime so you're not maintaining multiple parsers, and depending on the language features, an additional pseudo-runtime in the language server.
This would be a sort of convergence? They were both right in part (Chomsky that there was structure there, Norvig that it could be sussed out using brute force statistics). As is often the case, when two smart people who have thought a lot about something complicated disagree, the truth comes out when their unstated assumptions are finally exposed to the light.
In this case, Chomsky's LAD almost certainly relies on Baldwin-effect structure to get around the paucity of stimuli, and the LLMs are just getting to "the same place" through sheer masses of data.
You're saying the same thing like it's relevant. What matters to me is that the source code is clearly stored encoded/compressed in the model. That to me means the license of the code should apply to the model. Now we just need somebody to ask it to decompress ("reproduce") AGPL code and its owners will have to release it under the AGPL as well.
Yes, this is sarcasm but that's how it should work. These models cannot be created without ingesting vast amounts of code created by human labor. The proponents of this kind of stealing argue that the models "generalize" and that somehow makes it right and legal. And here we have counterexample to their generalization argument.
Doesn't change the fact labor theft is still labor theft but it might make a difference to the letter of the law, hopefully.
I say hopefully because I believe all people who contribute to technical progress should be compensated according to their amount of work and skill level. But of course many "temporarily embarrassed trillionaires" disagree. I don't understand why but I am happy to know that if the tides turn they will be perfectly A-OK with me taking their work without credit or compensation.
Apparently it's possible to download a whole load of books illegally, but still train AI models on them without those getting pulled after you get found out.
The reason I'm mentioning this project is because the article questions where all the AI apps are. Take a look at the git history of these projects and question if this would have been possible to accomplish in such a relatively short timeframe! Or maybe it's totally doable? I'm not sure. I knew nothing about quite a bit of the subsystems, eg, the Debug Adapter Protocol, before their implementation.
I recently "vibe coded" a long term background job runner service... thing. It's rather specific to my job and a pre-existing solution didn't exist. I already knew what I wanted the code to be, so it was just a matter of explaining explicitly what I wanted to the AI. Software engineering concepts, patterns, al that stuff. And at the end of the day(s) it took about the same amount of time to code it with AI than it would've taken by hand.
It was a lot of reviewing and proofreading and just verifying everything by hand. The only thing that saved me time was writing the test suite for it.
Would I do it again? Maybe. It was kinda fun programming by explaining an idea in plain english than just writing the code itself. But I heavily relied on software engineering skills, especially those theory classes from university to best explain how it should be structured and written. And of course being able to understand what it outputs. I do not think that someone with no prior software engineering knowledge could do the same thing that I did.
reply