Live data from Hacker News

Will low and no code tools ever truly disrupt tech development?

stackoverflow.blog

141–150 of 208 posts

Re: Will low and no code tools ever truly disrupt tech development?

#142

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…

I always have the same response to discussion of low/no-code and graphical programming environments:

If you think it will make things easier you have confused typing to be "the hard part"

If you think it isn't real programming, you again have confused typing to be "the hard part"

Re: Will low and no code tools ever truly disrupt tech development?

#143

Earlier quoted context omitted.

I 100% agree on the savings of real developer time when end users can self service. At the same time, I've also seen users do incredibly crazy things because either they didn't know any better or just didn't bother to "read the code". Good example of this is people just keep creating Statuses in JIRA until you end up with "Which of these 264 'Completed' statuses is the one I want?". It's similar to the Ops person "He…

> At the same time, I've also seen users do incredibly crazy things because either they didn't know any better or just didn't bother to "read the code". Good example of this is people just keep creating Statuses in JIRA until you end up with "Which of these 264 'Completed' statuses is the one I want?". Why is this a problem? Programs are a means to an end. The 264 Jira statuses are messy and could be done away with,…

> Why is this a problem? Programs are a means to an end. The 264 Jira statuses are messy and could be done away with, but would a clean solution actually change anything for the better? In a significant, "it was worth spending the money on a real developer" way?

"Let's not waste money on a programmer so instead everyone in the company wastes millions of man-hours every month slowly filling things the wrong way!"

There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough.

- The Art of Unix Programming

Re: Will low and no code tools ever truly disrupt tech development?

#144
post #30

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…

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…

So counter intuitive Scratch ?

Re: Will low and no code tools ever truly disrupt tech development?

#146
post #30

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…

The graph makes for a good laugh. Also, I want to agree, but algorithm code can look ridiculous in any language, graphical or not. I think graphical coding and "real" coding will merge from both ends. An advanced IDE today is already sort of beginning to look graphical.

I think this is very right. We have only scratched the surface in terms of creatively experimenting with the IDE UI to give the developer more ways to quickly explore and refactor code. Text in/text out is a serious loss in fidelity from the overall input/output capabilities of a computer.

Re: Will low and no code tools ever truly disrupt tech development?

#147

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…

I basically agree that most complexity lies in correctly formulating ideas -- though depending on language, there is a great deal of time and effort wasted on the overhead of expressing those ideas.

For example, Javascript's stdlib has long lacked tools for simple data transformations (group array items by a function, transform values of an object by a function, etc). These operations can still be accomplished, but only by writing bug-prone manual transformations or using third-party packages like Lodash. There is no standard idiom for expressing these ideas, which causes significant overhead.

No-code/low-code, in contrast to general purpose languages, is savagely optimized for idiomatic expression of a small set of ideas, at the expense of the ability to express any arbitrary idea.

Re: Will low and no code tools ever truly disrupt tech development?

#148

Earlier quoted context omitted.

To expand on this, you will have to house the complexity somewhere. For low/no code tools, it's swept under the rug, or rather, under layers of abstraction. I don't think it's a good idea (in a disruptive-amount of cases) to deviate from the simplicity of straight forward code. We are growing closer and eventually will realize as a society that programming doesn't have to be hard or scary. I'm sure that the futuristi…

> I'm sure that the futuristic lay-person will have a better basal understanding of technology and how it's made. I feel like we actively discourage people from having an understanding of technology for fear that they will understand it and complain about it and/or be in a better position to judge the quality of alternatives to our products. As a result, it seems like more people understood basic computer operation a…

University professors in recent years have been finding themselves shocked that students don't understand how file systems work[1]. Additionally I recall hearing a teacher say that they were trying to teach something in a computer lab, and none of the students knew how to work a windowing system or multitask, and they only operated by having every program maximized and using one at a time, likely because it's the computing paradigm they grew up on, using smartphones and tablets.

I think the idiot-proofing of modern computing is only making people less aware of how computers work. Think of how many 20-something programmers got into programming from learning how to make Minecraft mods. Or even just learning to install a mod in the old Java version of Minecraft or any other PC game, where you had to dig into weirdly-named folders, copy-paste files into various directories, maybe modify a data file here and there. Kids growing up on the iPhone version of Minecraft are never being exposed to the basics of how their device works.

https://www.theverge.com/22684730/students-file-folder-direc...

Re: Will low and no code tools ever truly disrupt tech development?

#149
post #56

Earlier quoted context omitted.

This isn't just true of NoCode, it's endemic to young tools. These products are over-optimized toward low friction on-ramps because the only thing that matters is growth in DAUs. NoCode is just attractive because it propagates the myth that you can do things without programmers, and programmers are expensive. So you've got low friction + perceived lower cost == more users signing up.

Java is somewhat legendary for being rather overly wordy. But, if a new language starts off its list of 'why should you use this' with comparing how to write to the console (java: `System.out.println`, other languages: a simple `puts` or `printf`) always strikes me as silly and turns me off of the language. Who cares? When I'm writing toy command line apps, complexity is never going to be the problem, certainly not i…

If I made a tool that was good for large codebases, I'd demo it by making a video ostensibly demonstrating someone unfamiliar with a large codebase reading a simple JIRA ticket for the first time and then using the IDE/language/toolset to explore the codebase and figure out what actually needs to be done, the whole time narrating and pointing out each feature of the language, tool, IDE, etc that makes this experience quicker, easier, better.

It could even be a relatively fake example and I think it would still land if your audience has had experience exploring large codebases

Post reply on HN