4 ms·
I have been hopeful for this for a long time - it's not so much that I expect it to stop the need for a developer, but rather that it will allow a developer and
by ebiester 9y ago
I have been hopeful for this for a long time - it's not so much that I expect it to stop the need for a developer, but rather that it will allow a developer and domain expert to work together more efficiently.
The ideal case, in my mind, is a case where apps can scale. A user needs a simple tool, so they build it in a UX-friendly way, which has limitations but can reach some basic data sources and can do some basic CRUD.
Then, the user starts reaching a point where they need to scale. Then, something like VBA can be written by the user or by some developer, and tied into the UX. Indices can be added to the database, and to a DBA it looks like any other CRUD app. Views and materialized views can be used to add information from other parts of the database.
If there's one difficult part, the system can call a service that has access to the database and can do computing more directly, communicating through a standardized JSON system. (Perhaps something like JSON API.)
Then, the tool starts getting popular, and is straining at the seams. Instead of having to create an entirely new project, the project can be exported using a translation layer to a pure programming language, with tests built automatically. Developers can then take it in any direction necessary.
The biggest problem is that it's hard to progressively scale small apps - every time a small tool created outside IT gets created, it expands until it starts being dangerous - excel anyone? - and then IT is brought in to build a full scale system that solves all the problems. IT then gets angry at the users for creating a useful tool instead of getting dragged out into the funding-design-create-test-bugfix process.
And that's why the No Code sounds so appealing. It's a structural PITA to scratch your own itch.
- shams93 9y agoWe have had this in the DSP field since the 1990s with pure data, and before that the closed source Max, now a part of Ableton Live 10. Faust is another example of a graphical coding tool for DSP, in the case of Faust you can export C++ that you then include in a larger C++ based application.
- kevin_thibedeau 9y agoThese kinds of tools are only viable for their narrow problem domains. Code will always rule for general purpose development. At least until AIs are good enough to produce usable results from a problem description. Electrical Engineering has already trod this path. Before HDLs became good enough for logic synthesis, FPGAs and ASICs were developed with schematics or manually mapping circuits into the target architecture. That process doesn't scale well as you end up wrangling with 2D spatial representations and constantly fiddling with low level details. Now, HDLs are the primary means of developing such hardware and the vertical tools are limited to specific data processing niches where there is some productivity advantage in reusing established design methodologies.