5 ms·
Low-code/No-code used to be called CASE back in the 90's. It had the same promises back then but is more popular today. I think the drive comes from management
by dtagames 4y ago
Low-code/No-code used to be called CASE back in the 90's. It had the same promises back then but is more popular today. I think the drive comes from management more than devs, who always imagine that they can get programming done without paying programmer salaries.
In some simple cases, non-devs can create their own software solutions with these tools. But it falls apart in two places: First in that the real complexity of software development is not syntax but architecture, and visual programming tools don't help with that. A big design or bad design is actually harder to work on in graphics than in text code.
The second issue is the one you point out: lack of portability. Most GUI code builders lock your results into their platform, limiting its usefulness in the real world.
There are cheap boards (like PyGamer) than can be programmed with a Scratch-like tool based on Google Blockly. That's the Microsoft MakeCode series. The good news is that it really writes Typescript under the hood and you can switch back and forth to see the real code -- or just edit the real code once the visual blocks become too complex or limiting.
I have a hard time imagining that anyone is being given no-code tools to take home. The whole audience for that is more office workers trying to create various kinds of reports. The no-code tools don't produce portable apps that you could ship to a customer. There are two low-code tools that are used professionally: things like LabView for controlling scientific devices and small robots, and tools like Jupyter which really isn't an IDE but is used like one by people who need to write formulas but not apps.
- tabtab 4y agoI actually like some of the ideas from CASE. For example, non-programmers (typically analysts) should be able to change attribute-oriented features without code changes. Menus, button titles, field titles, field length, required status, etc. should all be update-able without code changes. The idea kind of exists in "Table Oriented Programming" where much of the routine programming, field info, and navigation is controlled by tables, not by code. The problem has been that's hard to tweak such for special or specific needs. I've been working on how to get around this. I've stumbled upon "incremental draft rendering" where the attributes from the tables generate draft handling and markup in stages, which can then be custom tweaked as needed using an event-driven approach. But most programming languages are not designed for event-driven table oriented programming. Experiments continue though...