6 ms·
Well said. This is exactly what we find when building applications with Lowdefy [0]. Because we are writing applications in a “schema”, implementations becomes
by gervwyk 5y ago
Well said. This is exactly what we find when building applications with Lowdefy [0]. Because we are writing applications in a “schema”, implementations becomes more and more consistent. To the point where if I pick up an complex application written by a colleague, it takes me only minutes to understand what has been done and start contributing. In an enterprise space, this greatly reduces risk in project handover.
Since the logic operators and ui blocks are consistent and tested across all apps, code errors reduces over versions. But implementation errors still exists. This normally happens because the app builder does not fully understand the application data.
So by using a DSL we effectively reduce the moving parts. With the remaining problem being - does the developer understand the data - and as a business, this is where you want developers to spend their time to extract the most value.
[0] - https://github.com/lowdefy/lowdefy https://github.com/lowdefy/lowdefy
- tomnipotent 5y ago> Because we are writing applications in a “schema” I call this "metadata-driven programming", and try to use it whenever I can get away with it. It's amazing what you can pull off with a FSM, external configuration, and some ingenuity.
- gervwyk 5y agoTotally. Most developers stop at decoupling the ui components, backend connections etc. It is not very common to see developers extract the application logic to be configurable from these components. Logically loaded React classes is a common example of this. Filling up these components with bugs and making them hard to test. Once I experienced how well it works to abstract logic from components my code simplified immensely and writing good tests became easy. And then making the logic configurable truly elevated the capabilities of our “meta-driven programming”.