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 three largest values from this array" and it just turned into the most ridiculous bubble-sort implementation you've ever seen.
Its pretty hilarious seeing some of the old screenshots now [1].
Anyways, I think it will always be really easy to sell some simple demos on low-code/no-code, but then the second you need something slightly outside the eco-system it just turns into a substandard mess that doesn't work well with source-control (or diffs) and in general is just harder than the code-full solution.
- 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.
> Maybe designing models is better than writing low level code for control algorithms?
If you need both the code and the model, then generating the code from the model is also much easier than proving that your handwritten C code behaves exactly like the model used for verification. Having visual control flow for complex control systems might be less error prone than manually writing C (or Rust or Zig or $flavour_of_the_day) code. You probably know that, but other folks shouldn't forget that automotive and aerospace control software often means "programming errors might result in people getting injured or worse".
Control systems have always been designed in a connected box fashion. Before gui software existed. Visual coding is just an extension of what was being done on a blackboard
Disclaimer: I work for Zapier.
Great example of where low-code is a better alternative for a very narrow use case of development.
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.
Vcs integration and merge were also a big pain so most of the development was done on a single computer in the lab by many people.
The hardware that runs the LabVIEW code is solid tho and once you wrestle LabVIEW into doing what you want it works well
We also had a ton of horrendous LabView spaghetti which was even worse.
So it might be that node based programming is a good way to allow non-devs to interact with parts of an otherwise code based solution, inside niches. Examples that come to mind are eCommerce shopping rules. They can be complex, and really arbitrary, and in many ways having a developer implement them is really inefficient. Giving a node based pipeline editor for shopping cart rules would be a boon for power-users and take time off the dev's hands to focus on implementing the surrounding ecommerce solution, something you definitely don't want to be writing in a graphical editor.
The more narrow the domain, the easier it gets to figure out a low-/no-code environment that will work for the users. But the smaller the base of purchases. And distilling the complexity to just the right level still takes some really bright domain experts with extremely good intuition of where the most profitable use cases lay (the hardest role to fill) and highly empathetic coders (also hard to fill) who work well together (extremely rare), or a single person who embodies both (unicorn).
If energy and money were no object, low-/no-code is absolutely A Thing. I believe there is some kind of emergent Shannon–Hartley theorem behavior here, where complexity down a communications network with certain noise/bandwidth/etc. properties has some suspected hard physics-as-we-know-it limits.
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.
Who cares? When I'm writing toy command line apps, complexity is never going to be the problem, certainly not in the 'what do I print to the terminal' part of the code. And if I'm writing actual software where complexity is actually an issue, the odds that this code has any business writing directly to standard out in the first place are infinitesemal. Your language is optimized to do stuff I'm never going to care about. How silly.
However, perhaps it's not _just_ about the short sightedness of inexperienced devs who get tricked into thinking a language is all that because of optimisations to the 'write some toy stuff' process flow.
Think about it, how would you write a tutorial or 'sales pitch' for a dev environment/programming language _without_ focussing on how easy it is to write Hello World and other toy projects?
How would you highlight how the namespacing system seems like overkill for an app whose entire codebase is half a page of text in a large font, but is actually really good at making an easily navigable codebase once we hit the 5 personyears level? I really have no idea how you would show it. You could talk about it and pray that the reader is familiar enough with the challenges of codebases that have grown beyond 'one person tinkering around for a weekend', but almost by definition I don't think you can bash that down into a tutorial or pitch you can consume in 5 hours, let alone 10 minutes.
Still, languages could do more. I think most languages are just kinda bad at natively supporting the idea of DAG-based modular isolation: As code bases grow larger you want to be able to strictly enforce the ability to take a much smaller chunk of that base, draw a circle around it, and say: This can be understood on its own, it is dependent only on these things, and only these parts are 'public API', 'public' here meaning: accessible to other circled-off parts of the entire code base.
Maybe because it demos bad. And that's a real shame. It's many orders of magnitude more important than 'You can just write `puts` to echo to terminal, and there is no need to declare a method for the main entrypoint!'
It could even be a relatively fake example and I think it would still land if your audience has had experience exploring large codebases
The problem is this can get pervaded quickly.
In most extreme cases, the 'example' is literally only useful for hello-world style things, and anything more complex requires digging deep into docs to understand (I can think of at least one .NET library where this 'blogger-friendly' API structure exists...) And then as alluded to, every example shows this simple case that doesn't help anyone know how to configure things in ways that are testable/etc.
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 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 and architecture 30 years ago than they do today, but maybe I'm in a weird bubble. I'd think with the opportunities for the far more opaque operations and algorithms that deep learning has given us, people will understand even less about computers in the future.
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...
That being said, we've always built knowledge on top of the backs of others and never really had to deal with supporting its weight without necessarily knowing the basics. It would really make for an interesting case study if it led to the collapse of society.
I don't think it's this, and I don't think programming is so hard (it's the business logic that is hard when you have to specify it exactingly, to reference the thread.) I think that the manufacturers of the various computers we use make it unbelievably difficult and scary to touch anything, and cast quite a bit of suspicion on you for even wanting to change anything.
Those kids are generally more ignorant of how software systems work than someone who grew in the 2000s.
We now have a "digital native" generation coming of age for whom the only thing they have known is a ubiquitous internet. We might expect that they would be more intimately familiar with the workings of the technology that has surrounded them than we could ever be.
Yet the opposite seems true, and I think you've put your finger on a primary reason — they've only interacted with devices that are basically appliances — you turn it on and use the app, but it is very difficult to get inside either the hardware or software. So, it just becomes another box that either works or doesn't.
It is not dissimilar to the generations of people who grew up with automobiles. the more "user friendly" they technology gets, the fewer people even understand what goes on 'under the hood'. If you don't need to understand how to change a tire or change the oil, or check the valve backlash, because these are rare events, few people even have a clue how to do it, unless someone took a special effort to teach them and they took a special effort to learn.
Kind of a sad paradox.
elements
shape Wrapper
text Label
style Wrapper
fill: blue
style Label
content: Click Me
fill: white
I actually pointed out in the training that this is still coding - at least at a scripting level - with all the pitfalls that involves. Nobody there really understood, and some actively tried to deny this point of view (I thought that was a bit weird and culty, but there you go).
One problem is that if you, as J Random HR Employee, implement something with a bug in it (which you will do at some point), you may not be well equipped to diagnose and fix the issue. It's not that hard, not at this level, but the training sort of glossed over that.
And then I asked a question about the fact that all these services that were being integrated together were distributed, so what happens when something fails part way through a flow? What happens with consistency across the different systems you're integrating? Well... it depends on the adapter for each specific integration, but in most cases you're supposed to implement failure handling yourself.
In fairness they showed us an example with failure handling and enforcement of consistency for something that integrated perhaps half a dozen systems together... and it looked pretty complex, just as you'd expect it to.
And that's where I think these things fall down. You can build a happy path flow pretty quickly - in fact I suspect a lot of non-programmers could do that - but it's what happens when things go wrong where it gets really gnarly.
Basically, if something goes wrong either IT or DevOps are getting a call, or somebody in a business, HR, or finance function is manually logging into a bunch of systems to update them and bring them into a consistent state.
I don't think this is terrible necessarily, but I do think the capabilities of these low/no code solutions - particularly with respect to their use by non-techies - are way oversold.
I see the exact same thing with code: the complexity is eventually abstracted away until it becomes a vocation that doesn't require a college degree (think mechanical engineer vs mechanic, computer scientist vs programmer).
I see the low-code stuff as an opportunity to let the business-folks handle the usecases where the complexity is low, and value of rapid iteration with deep domain-knowledge is more valuable.
Also, they might get a better understanding of why the code stuff might make sense when stuff is actually getting complicated :)
Most cars have automatic transmissions now. Cars don't have manual chokes anymore. They're reliable enough now that most people don't need to know anything about repair, engine or otherwise, whereas that used to be widespread knowledge.
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"
One of the core errors of the most breathless low-/no-code advocacy is that they clearly see that code as it stands today is very complicated, but they think it's all accidental complexity. If we just did the right things... if we just made it easy enough... if we just had the right visual user interface... all this complexity could go away! And then anyone could code! And lo, Utopia would emerge.
There is a grain of truth in this. Code does have accidental and unnecessary complexity. Some traditions and codebases have more, some have less. The low-/no-code approaches can help with this... though I have to qualify it a bit because at times they add their own accidental complexity to problems that traditional approaches don't. But they can be easier sometimes, certainly.
The problem is that even a hypothetically perfect low-/no-code solution with absolutely zero accidental complexity still wouldn't do anything to eliminate the essential complexity of the problems people want solved. I don't care how amazing your no-code UI is. I don't care how visual it is, and how you can grab any 12-year-old off the street and show them your UI and they can grasp everything that's going on. I don't care how much work you put into it. If someone tries to use it to create a tax preparation service, they are going to ram face first into the brick wall of the essential complexity of the problem.
No matter what you do, there are going to be people in the future who have developed a skill set in dealing with that sort of thing, and it isn't going to be a skillset everyone develops to the same degree. Even if you stipulate a domain expert who knows literally everything about the tax code, it will still be a distinct skill to learn how to explain that correctly to a computer, even a zero-accidental-complexity computer.
It is further inevitable that the people dedicated to that will have their own toolset that tunes the expertise and power level to the fact that they are able to pour more time into developing skills that have a longer-term payoff than people who are "programming" for six hours a year.
It is literally impossible for low-/no-code to take over. Even if I pushed a magic button that replaced everything in the world with low-/no-code solutions right now, the world would still bifurcate into the people who further develop their skills with the system, learn how to use it efficiently and effectively, and people who do other things like build houses, provide clean water, etc. The only way to make it so there is no such thing as a "programmer" is to forcibly cap the capability of the universal low-/no-code system so low that there is no way to become better at it, which is just inconceivable.
I started my career at a company that sold a graphical programming product. It's exactly the typical "no code" thing described elsewhere. Nodes and edges to implement Ifs, Loops, actions, subroutine calls, etc.
We sold this to customers but also had an in house professional services type department that used it. Those folks were indeed at a whole nother level with that tool and knew all kinds of tricks and had developed special scripts to transform the XML formatted files that the "programs" were saved in, etc. They had developed a long slew of best practices to try to tame some of the problems of the tool.
Then someone added a "execute arbitrary javascript" action and it was open season on everything...
I think when I left someone was working on a linter!
Some stack that avoids all that complexity would be technically "low-code". But the format of the low-code stacks people push around today is incompatible with general development, and doesn't actually make most of the complexity go away.
A perfect equivalence is if you were to do math exercises but instead of operators you used written English prose to describe what you are doing.
Much less intimidating, but mind blowingly verbose
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.
It's same reason why design starts on napkins, then wireframes, and then low def, high def and eventually a fully interactive prototype.
In software we dive into code way to eagerly and way too early in the product process.
Equating no/low code tools to full on dev is impossible. Just as you wouldn't/shouldn't equate a design prototype to napkin scribbles.
Low code doesn't help at all? It's still code.
> Low code allows "less" sunken cost when the inevitable misalignment of requirements happen.
Sunken cost is about investment already incurred that can't be recovered. It's very likely that low code increases software sunk cost problems.
If you use low code as a prototype thing to throw away, that's almost a complete waste of investment.
Wrong low code often is much harder to programmatically test for correctness and debug, so you often need a larger investment to fix it.
The problem these days is everyone wants great software (big tech impostor syndrome) without splurging on software talent like big tech. That’s the sweet spot low code companies target when marketing.
Graphical coding is bad in general. It’s not just paid products. I’ve had the misfortune of using Apache NiFi - which is “low code data movement”.
Honestly: if you come to such a (dubious) conclusion, the conclusion is actually likely true (with respect to you), because if you were smarter, you would sooner or later realize the mistake in this flow of thoughts.
You realized where the mistake in your flow of thoughts is. This is, as I wrote, a good sign.
If you want to become smarter in math: Plan to understand work that some Fields medalists of your choice produced. If available, get a modern textbook treatment of their work (these, in most cases, are better for understandable than their original papers). Of course, you won't understand much at the beginning. So you know in what areas on mathematics you have deep knowledge deficits. So get some good textbooks on these topics to fill these knowledge deficits. Iterate.
-
If you want to become smarter in physics (the following advice is what a good friend of me gave who I really trust regarding this): Start with the 10 books of "Course of Theoretical Physics" by Lev Landau and Evgeny Lifshitz.
> https://en.wikipedia.org/wiki/Course_of_Theoretical_Physics
Having read these books should (according to him) give you at least some very basic foundation of physics on which you can then, as a next step, build by reading much more advanced textbooks.
I get your point. But without low/no-code tools I would argue a lot of simple workflows have to be implemented using code. These usecases, where the technology-side is simple, is a good fit for low/no-code platforms IMO
I've seen teams spend a lot of time in low/no-code tools and either it grows more complex than actual code or they resort to the escape hatch (node that executes user defined code) and the visual tool basically becomes a container for actual code.
Also, the dream usually is put the effectiveness of software developers into the hands of people who are not software developers. However, it never seems to fail that the low/no-code work ends up back in the lap of software developers because of the typical product/project delivery lifecycle.
The ideal state alluded to is that Dev teams write modules that cleanly 'plug in' to the flowchart mess, but the reality is that a Dev team that can write code at that level (in a modern world, it implies at least an abstract/subconscious understanding of mid-advanced FP-ish concepts, including merging Procedural things like calling the bizarre webservice you're probably integrating with, while striving for idempotency based on the provided args/context.)
At that point, said devs likely are of a skillset they could build a framework for lower TCO, or at the very least are productive enough that they aren't the problem.
What they meant was "the end of on-prem software and its installation headaches" because the software was in the cloud - which was innovative at the time.
What appeals to people in "The End of Code" is the end of being forced to use a superficially illegible formal language.
At the same time, on a deeper level there are things that can be hard to deal with like asynchrony, performance, etc. These are not social but inherent in computing architecture etc.
whether you think it's complex or not, we're hiding information on procedural tasks from users in the products we build because information to someone who is not a programmer IS complex
You CANNOT solve complexity by just making things "visual". Biggest low/no-code mistake.
Code is really just a formalized expression of what you want. It happens to be used for very complex problems, because it's very good at solving complex problems. This in and of itself does not make code inherently complex.