| > 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. |