[bitwize]

The thing is, there's already a powerful AI technology we can use to solve the "boilerplate code" problem.

It's called Lisp. You know, Lisp, the language for AI written way back when brand-new Cadillac Eldorados with tailfins were still on the road that is self-reflective enough to make writing "programs that write programs" an absolute doddle? :)

Good luck getting bigco to sign off on a Lisp project, though. Even if it is of demonstrably profound practical utility.

You're right -- we have a huge problem with trying to trowel the new hotness (currently, "AI/ML" aka statistics) instead of taking advantage of tools that are highly suited to purpose. Instead of letting us use those tools, bigcos instead subscribe to the "programmer-clerk" myth in which programming is a menial task of mostly rote coding undertaken by minions in legion strength. And this affects not only the tools we use but our processes and professional values.

[blunte]

The underlying language doesn't actually matter as long as you can deliver the toolkit. I do agree that Lisp(y) language(s) may be very well suited, but I don't care.

I just want us to stop reinventing the wheel hundreds of times each year. At least paper shuffling and fax sending took long enough that you could get a coffee and have a chat while it was happening. Now instead we toil over configuration files (which ironically Rails, my daily toolbox, aimed to solve a decade ago).

I should be able to define a few data models and relationships, processes, and some business rules. The rest absolutely should be generated for me. If cars worked like this, we would still be custom building wooden wheels.

[bitwize]

> The underlying language doesn't actually matter as long as you can deliver the toolkit. I do agree that Lisp(y) language(s) may be very well suited, but I don't care.

Languages matter. Lisp offers second-to-none metaprogramming capability and it's metaprogramming, not "libraries", that will bring the boilerplate problem under control. Other languages may be able to do the same, just not as well; Smalltalk and Ruby can "fake it". Metaprogramming lets you put patterns into reusable libraries, not just data and functions.

> I should be able to define a few data models and relationships, processes, and some business rules. The rest absolutely should be generated for me.

So you want CASE tools from the 80s-90s? Or "autogenerate applications from UML" from the 2000s? Because uh, there are reasons why those failed. Among them:

1) Code that's generated by machine still has to be maintained by humans. I work with one of the low/no code tools that promise to do everything for you. Lately I spend my days toiling over its flowcharts rather than configuration files, trying to figure out what broke when it stops working, because it doesn't have nearly the debugging capability that JavaScript has and even crude tools like "debug by printf" are off limits.

2) Systems that run in the real world are subject to real-world constraints. You have to integrate with other, very specific systems, you are subject to performance and scalability constraints that vary by application, etc. These are constraints that require solutions to be engineered.

You're going to still have plenty of work to do after you've defined your data models and business rules, no matter what tools you use. The question really is how much friction the tools impose when completing that work.