In my experience it’s not exactly trivial to validate code you didn’t write yourself, because you have to think through it in similar depth to when you write it yourself. While on the one hand you save the time of coming up with a solution, the task of merely verifying an existing solution is also more tedious, because it isn’t intermixed with the problem-solving activity that you perform when writing the code yourself. There is an increased risk to fall for code that looks correct at first blush but is still subtly wrong, because you didn’t spend time iterating on it. It doesn’t seem plausible to me that you would save 90% of the work, unless it’s boiler plate-heavy code that requires only little analytical though.
I agree with you. I never liked how AI is really generating ton of code for us, then you need to read through it and understand it. Plus, the fail rate is to high.
That is why I design the language the way it is. You must define each step you want to happen in your application. Lets take for example user registration, it looks like this
--- plang code ---
CreateUser
- Make sure %password% and %email% is not empty
- Hash %password%, write to %hashedPassword%
- Insert into users, %hashedPassword%, %email%
- Post, create user in MailChimp, Bearer:%Settings.MailChimpApi%, %email%
- Create bearer token from %email%, write to %bearer%
- Write %bearer% to web response
--- plang code ---
That is an executable code in plang. It's easy to read through and understand. You need to have domain knowledge, such as what is hashing and bearer token. You are still programming, just at higher level.
Validating what will execute, you need to learn, just like with any language, but it is relatively simple and you start to trust the result with time(at least I have)
But you have to double-check those 130 lines and think through all possible cases (edge cases, error cases) for each statement. I don’t see how you save all that much time. And your example output doesn’t even contain error handling, logging, and so on. There’s also no way to roundtrip any changes you want to add to the output code, while still making changes to the high-level description. (This is one reason why model-driven programming largely failed.)
