121–130 of 208 posts
At the same time, "traditional" software development isn't going anywhere soon. In the short to medium term it may even become more valuable and sought after because an increasing number of technically minded people will enter the market at this new level of abstraction and never learn traditional software development at all.
Earlier quoted context omitted.
100%. I worked at a company that really went in hard on Agilent Vee for hardware testing in the early 2000's. Absolutely a thing where a manager saw a "Hello World"-like demo and was so impressed that they went 100% full buy in. Besides the obvious UI issues (like the fact that you couldn't really zoom out, you could just pan around your code), we had a bunch of engineers that still needed to do things like "get the…
Yeah the main issues with visual programming are: - Logic tends to take up a lot more screen space than real code - There is no defined way to read the code. In real code you start top left and read left to right and down, but in visual code if there are lots of "paths" then your eyes end up darting around everywhere.
My main issue with low-code/no-code is that it attempts to solve the complexity problem, without understanding what "complexity" is. Code is perceived to be complex, but when you look deeply into what people mean when they say that, it's almost entirely a social perception. They see these weird characters and it looks like gibberish and they assume that the people who understand this gibberish are somehow on another…
Earlier quoted context omitted.
I almost put in my original comment that no-code/low-code becomes more useful as it gets more specific to a domain. Game dev is a perfect example - building complex shaders becomes much easier with a visual editing tool. I think of Google Sheets as a highly useful tool in this space. Same for Google Data Studio.
Isn't the domain of most no-code/low-code "business process"? It's some glue between systems to collect or input data. It allows the expert on the business process to directly translate the manual process without others.
Execs seem to love them.
They never seem to go far.
I am not speculating on why they never make it. It's easy to see why execs love them.
We just keep looking at this from a developer perspective, but from a business perspective it's there.
The problem we should be solving is not the accessibility of code itself, but the accessibility of toolchains.
The most confusing thing about learning to make software isn't writing a Hello World program or a Fibonacci series loop. It's figuring out what to do with that code once it's written.
People don't interact with terminals and shells anymore, but guess what nearly every Hello World program is written for? A shell.
We have a lot of tools that try to hide the toolchain, and even the shell itself, from the uninitiated developer.
Unfortunately, hiding the complexity of the very system you are writing code for causes more problems than it solves.
How can you learn to get input from the user if you don't even know how to use a shell? How can you start using libraries if you don't know where they are, or how they are distributed to the user? How do you configure the correct environment variables if you don't even know what shell you are running or how/where it was initialized?
We should instead be doing the inverse: do everything we can to show new programmers the system they are using. Show them all the pieces of the puzzle, and how those pieces fit together, because our new programmer's primary goal is to make new puzzle pieces.