4 ms·

This comment is slightly OT, but this post prods at something I've been thinking about lately. Pessimistically, most programming is just writing a CRUD app with

by aj_g 9y ago

This comment is slightly OT, but this post prods at something I've been thinking about lately. Pessimistically, most programming is just writing a CRUD app with a layer of business logic over the top. Why haven't we been able to abstract or at least vastly accelerate that? Does anybody have any related reading/longform articles on this idea?

BjoernKW 9y ago
I've been irked by this issue for quite some time. My temporary conclusion is that the MVC pattern and defining constraints in a text-based programming language (as opposed to the visual drag-n-drop languages commonly used in software generation systems) is the best abstraction we can come up with without making the framework so rigid it suffers from leaky abstractions and hence comes apart rapidly. It might seem like mostly clerical work and it isn't exactly accessible to non-programmers but the tools and frameworks commonly used for creating CRUD apps already abstract away a lot of the plumbing code that used to be necessary to do this. Although on the surface most CRUD apps at least conceptually look exactly the same the devil often is in the details: Legacy databases, weird interfaces and data formats, data has to be imported from Excel, you name it. Regenerating / modifying an app upon model changes can become particularly arduous depending on how frequently those changes occur. If your data model conforms to some constraints though creating a run-of-the-mill CRUD app with tools like Spring Boot, Swagger and a generic, declarative UI is both fairly easy and robust. As soon as the UI has to accommodate more specific use cases or you want to provide a more focused, less one-size-fits-all UX a mostly automatically generated UI however will fall apart rather quickly again. By the way, at its core Uber is a CRUD app, too, isn't? Perhaps we don't need a generalised CRUD app generator but rather very specific app generators like this one.
jtmarmon 9y ago
we have, to some degree. see: parse, firebase, etc. but the reality is most people need more fine grained control than is simple to layer over a crud interface. there's a reason parse shut down: as soon as people's apps had an inkling of success - and often times, even before that - people need to do more than just CRUD

by aj_g 9y ago

BjoernKW 9y ago

I've been irked by this issue for quite some time. My temporary conclusion is that the MVC pattern and defining constraints in a text-based programming language (as opposed to the visual drag-n-drop languages commonly used in software generation systems) is the best abstraction we can come up with without making the framework so rigid it suffers from leaky abstractions and hence comes apart rapidly. It might seem like mostly clerical work and it isn't exactly accessible to non-programmers but the tools and frameworks commonly used for creating CRUD apps already abstract away a lot of the plumbing code that used to be necessary to do this. Although on the surface most CRUD apps at least conceptually look exactly the same the devil often is in the details: Legacy databases, weird interfaces and data formats, data has to be imported from Excel, you name it. Regenerating / modifying an app upon model changes can become particularly arduous depending on how frequently those changes occur. If your data model conforms to some constraints though creating a run-of-the-mill CRUD app with tools like Spring Boot, Swagger and a generic, declarative UI is both fairly easy and robust. As soon as the UI has to accommodate more specific use cases or you want to provide a more focused, less one-size-fits-all UX a mostly automatically generated UI however will fall apart rather quickly again. By the way, at its core Uber is a CRUD app, too, isn't? Perhaps we don't need a generalised CRUD app generator but rather very specific app generators like this one.

jtmarmon 9y ago

we have, to some degree. see: parse, firebase, etc. but the reality is most people need more fine grained control than is simple to layer over a crud interface. there's a reason parse shut down: as soon as people's apps had an inkling of success - and often times, even before that - people need to do more than just CRUD