Live data from Hacker News

Low-Code and the Democratization of Programming

oreilly.com

91–98 of 98 posts

Re: Low-Code and the Democratization of Programming

#91
post #85
post #49

Earlier quoted context omitted.

So many good points here, best summary of the problem of no code I've read yet. Whether you write lots of code or no code, all the principles you mentioned remain i.e. testing, deployment complexity, maintainability, rollback, release strategies etc. If you tried to do all that in a no code environment it would be horrendous. If you skip it, as a non engineer might, you're courting catastrophe. No code will often mak…

I think this argument against low-code is based on a misunderstanding of how most companies are staffed. Truth: in normal companies, there are never enough software developers to build everything that needs building Consequence: tons of processes and people get by as best they can, their never-prioritized project languishing in IT's backlog, often manually processing things that could be trivially automated Consequen…

Not really. I've granted that there is a middle ground, it's just that you have to draw the line at systems that actually need proper engineering eg where security or performance has serious real world consequences. It's a question of where you draw the line. Use this for appropriate use cases but beware of abusing this stuff.

Re: Low-Code and the Democratization of Programming

#92
post #91
post #85

Earlier quoted context omitted.

I think this argument against low-code is based on a misunderstanding of how most companies are staffed. Truth: in normal companies, there are never enough software developers to build everything that needs building Consequence: tons of processes and people get by as best they can, their never-prioritized project languishing in IT's backlog, often manually processing things that could be trivially automated Consequen…

Not really. I've granted that there is a middle ground, it's just that you have to draw the line at systems that actually need proper engineering eg where security or performance has serious real world consequences. It's a question of where you draw the line. Use this for appropriate use cases but beware of abusing this stuff.

Every system should have proper engineering. Most systems need proper engineering. Few systems actually have proper engineering.

I've seen stuff that has core-business, real world consequences, to the tune of affecting company's quarterly results, run off an Excel spreadsheet. And I don't think this is abnormal in large business land.

So the line shouldn't be drawn at "Is this system too important to trust to low-code?"

It should be drawn at "Is this system important to us?" + "If so, are we willing and able to assign development resources at it, to do it properly?" + "If not, what do we need from a low-code interim solution to keep it safe and maintainable?"

If we can't fix it properly, then it's counterproductive to enumerate the ways the fix we can apply is less than perfect.

Re: Low-Code and the Democratization of Programming

#93

Earlier quoted context omitted.

I actually use FMP for a database at my wife's work. FMP is still shipping updates and new versions. Surprisingly you can pay to have your DB hosted on AWS. That said, it's very expensive.

Are there any FMP like low code products that would also allow user sign up/sign in? I believe the problem with Access/FMP were that they were single user or trusted user setups.

FMP supports multi-user setups. You can even use external auth servers including Google login now.

I don't know if you can create a "new user" flow in your app, but you can add/register users and assign them to permissions groups from the FMP admin dialog.

Re: Low-Code and the Democratization of Programming

#94
post #92
post #91

Earlier quoted context omitted.

Not really. I've granted that there is a middle ground, it's just that you have to draw the line at systems that actually need proper engineering eg where security or performance has serious real world consequences. It's a question of where you draw the line. Use this for appropriate use cases but beware of abusing this stuff.

Every system should have proper engineering. Most systems need proper engineering. Few systems actually have proper engineering. I've seen stuff that has core-business, real world consequences, to the tune of affecting company's quarterly results, run off an Excel spreadsheet. And I don't think this is abnormal in large business land. So the line shouldn't be drawn at "Is this system too important to trust to low-cod…

You said it really, we're already drowning in dodgy systems code or no code. I'm just concerned to not make the problem worse with an even more powerful way to cause a disaster. Think the excel spreadsheet powering the quarterly results on steroids.

I don't deny there's a place for no code, I'm just sceptical about intended uses. Not least because a lot of what is written are puff pieces by someone with an agenda. This is big business.

Re: Low-Code and the Democratization of Programming

#95

> Another way of looking at low-code is to take an even bigger step back, and look at the history of programming from the start. Python is low-code relative to C++; C and FORTRAN are low-code relative to assembler; assembler is low-code relative to machine language and toggling switches to insert binary instructions directly into the computer’s memory. That is the most stupid thing I've read in a while.

Agree! I think the problem is twofold.

First, it's not "low-code" or "no-code", it's high-level code vs. low-level code vs. non-traditional non-text-based code like labview. But it's still code, there's always the code.

Second, learning "code" or "coding" isn't the problem in democratizing "programming" in the first place. Code is the easy part. Software engineering, architecture, debugging & troubleshooting, logic, math, configuration management, project management - that stuff is the hard part. It's of absolutely no help to have a bunch of smart domain-experts happily "no-coding" away in matlab or labview or excel or ms. access and then stumbling right into the same bad engineering practices that you might find in struggling projects using traditional tools.

That's because we don't need "coders" or "programmers" at all. We need people to be engineers. And part of good engineering is picking the right tool and system to use, not jumping on the next over-hyped fad.

Re: Low-Code and the Democratization of Programming

#96
post #70

The problem with many low-code platforms is three fold: - many over-promise and under deliver. Low code platforms are great for simple CRUD apps, defined automations, etc. - some, like Bubble, are anti-code to their own detriment - code is good, your platform was created with code - only a few, like Budibase [1], Tooljet [2], n8n [3] are open source. I cannot understand how users are willing to bet their data and pro…

You can checkout Obsei as well: https://github.com/obsei/obsei. It is Apache 2.0 licensed. It an open-source low-code cognitive automation tool. It observes unstructured text from various sources like app reviews, social accounts etc and then apply NLP tasks like sentiment analysis, classification and then inform/intimate user at given platform like slack, api etc. Currently support text based automation workflows but in future plan to include audio, video, and image as well.

Disclaimer: I am creator of Obsei

Re: Low-Code and the Democratization of Programming

#97

The contributions of communities in the growth of programming languages is huge. If no-code/low-code is looking at a similar trajectory, open-source frameworks might prove to be the best options. Examples: ToolJet: https://github.com/ToolJet/ToolJet Obsei: https://github.com/obsei/obsei n8n: https://github.com/n8n-io/n8n

Thanks Navneeth for mentioning Obsei.

Re: Low-Code and the Democratization of Programming

#98
post #7

All this posts miss the best low code environments of all time: Microsoft Access and FileMaker Pro. Unfortunately these two never made it to Internet era in big time and we have greatly come down from 90s RAD movement.

Access, Visual FoxPro, Lotus Domino, and I am surprised no body mentioned FileMaker.

I still think Low-Code is a problem worth solving and it should start with spreadsheet like structure.

I am wondering if there are any Low-Code / No-Code solution for Web CRUD Apps? Something like Yahoo! Pipes...

Post reply on HN