Build (still) in Public
I recently published the article NeoBASIC Language 🔰 Transpiler to C++ to publicize the project for this language I'm creating. Since then, I've been working on a tour (overview) on the website to describe the language, and also programming the compiler. There are other areas of work, but I thought it would be best to focus on these two tasks to at least introduce the language.
I've been using Python so far, and it's been very helpful in validating the grammar. Python's REPL is amazing. But the timing of the parsing kept getting worse until it took 20 seconds to process the demos. So instead of trying to optimize – I don't think it would improve much – I decided to switch to a compiled language. One that would at least help in this prototyping stage, until NeoBASIC is more established. I chose Go, inspired by the new TypeScript compiler; I'm migrating everything I've done so far. It's going to be a lot of work, I'll see if AI can help me with that. But since I'm not paying for any services, I don't know…
For now, it's not proving to be such a complex task; I think the biggest difficulty is balancing my job (which pays the bills) with this project. I wake up very early to try to code as much as possible before 9 am, and then I try to do something else at night—but some days are tough! Weekends are when I can get a lot more done. If anyone has any tips on how to achieve greater productivity with side projects, I would love to know.
In short, there's not much to report. The rest of this text is trivial, just another developer hallucinating…
Generated Code vs. Suggested Code
We can't confuse generated code with "suggested" or "auto-completed" code. (guessing) 99% of all machine code on the planet is generated by compilers, and not many people are checking or debugging this code because compilers work in a deterministic process. X goes in and Y comes out, and it will be like that indefinitely. You fix the bugs, compile the program, pass it on for production deployment, and go home to rest.
There was a time when programmers wrote machine code; everything by hand, pressing buttons and levers. Then compilers came along, and programmers had to adapt to languages like Assembly and Fortran. This happened in the 1940s and 50s. Since then, we've had to adapt to many technological changes, but we've managed to handle it well. In part because these were technologies that followed the scientific method: repetitive processes with the guarantee of reliability, validity, and objectivity of the results.
Two different computers, regardless of their architecture, can compile and execute the same program and the result will always be the same. Two programmers using the same prompt with the same AI-Chat can (?%) obtain different results. Not only will the result vary, but also the slop that may be present. And we must not forget: it is not a bug, it is a feature. Hallucination is something that's part of the process.
The Importance of Peace of Mind
I'm one of the many (??%) programmers who use AI daily. And I'm very happy. But I still write a lot of code, although now I'm using the TAB key a lot. And my perception of the code that VS Code suggests is that I'll never be able to trust it 100%. That makes a big difference. Whether, at the end of the process, we can still say that there was a reduction in time and greater productivity, only time will tell.
No financial institution will release AI-generated code into production that hasn't been fully read, reread, verified, debugged, and tested. I feel sorry for the programmers at these institutions who use AI and encounter a bug in production that causes financial and reputational damage to the company. A programmer whose work is constantly questioned, and labeled as unreliable, will have a permanent fear of being fired. This is yet another factor contributing to mental health issues in a field marked by toxic work environments.
I remember the Apache Maven landing page from a few years ago, with a banner at the top of the page showing a programmer observing the landscape while a computer running Apache Maven on the desk was doing all the work. We'll never be able to have that peace of mind with LLMs. We need to talk more about this, and the impact on our mental health. I used that banner as a thumbnail of this text. If you want to check the original site...
Mea Culpa
Yes, the title of the post was clickbait. I ended up not talking about vibe engineering, nor comparing it to vibe coding. Was that necessary?
This text reflects my point of view, and many people see what's happening differently. For me, the most relevant factor is that there's no general consensus, and that's why there's still so much noise preventing us from precisely defining how things will be in the coming years. Everyone has their opinion, and I think that's good. But the opinion of salespeople, or CEOs, shouldn't be so relevant in our decisions.
Top comments (0)