3 ms·

Is there anything new going on here? No-code is something I see promoted. My kids have been taught versions of this in school. But is this showing up in job req

Is there anything new going on here? No-code is something I see promoted. My kids have been taught versions of this in school. But is this showing up in job requirements more and more as the years go by? Are people coming home at night from their jobs and using no-code graphical programming to work on some hobby project that controls something physical? Where is no-code being promoted by people that primary want to use it for themselves? Is there a $2 board trending with some Scratch like tool that really is useful? Is something respectable going on here? Do you consider minecraft and robloxs respectable answers? I want to be able to make a no-code CRUD forms like you could in Access and be able to use it 15 years later without having to pay a monthly fee. I would love to see google docs to commit to something like this so it's super popular. I am not bashing no-code and I have faith that something great can come out.

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

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