91–100 of 208 posts
They are already. I consult for a lot of hyper-early-stage YC startups as they formulate their plans and I've had two separate clients in the past 6 months go the no-code route to build their MVP. At first I was against it, but having seen these clients go through it I would say it is much cheaper and less risky and gives developers an extremely good blueprint for when the founders inevitably decide to go beyond the…
The good part of the bet is that most potential disruptions end not happening... But the exactly same median consensus is also reached about the disruptions that do end happening...
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…
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.
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…
- 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.
I've seen in my industry, we used to spend ages making the most ridiculously complicated front-ends for complex tasks. Now finally we're starting to accept that these orgs will have people who can smack out a bit of Python and suddenly we get to stop wasting our time and focus on supporting those who accept they have to code.
No code/low code will always remain toy and brittle outside of demo-esqe use-cases and those who are willing to open a file in notepad and tinker will retain a significant advantage over the rest.
Earlier quoted context omitted.
Yes, and I have never struggled to execute something complex as I have with no-code tools. Nocode usually makes the HelloWorld trivial and anything meaningful more challenging than it would be to do in a general purpose language.
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.
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!'
Earlier quoted context omitted.
Automobile engines are also very complex, but no one talks about no-mechanic cars. In highschool where I grew up, the bottom academic 50% of boys ended up being mechanics of one type or another. At one point in time, being an auto mechanic was an elite, rare profession, and that complexity was encapsulated as something that low-performing academic students could bank on for a career. I see the exact same thing with c…
I see it differently. 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 :)
I'd like to present a specific use case as an example of how domain-specific no-code tools can help.
I'm developing a tool for automated browser testing. This fits well into the description of being no-code and is being developed as an alternative to writing C#- or Java-based browser automation tests in Selenium.
The "code" that you write is more akin to configuration that defines what page elements you want to interact with, how you want to interact with them and what you expect to happen. There's more to it than that, but this is not a sales pitch.
My project is in direct response to the experiences my partner encountered when providing browser automation training to manual testers within businesses.
Browser automation testing requires, in broad terms, a small subset of what is offered by C# or Java, however a significant understanding of and familiarity with matters such as objects, variables, sane naming and debugging is required to even begin reaching competence.
Many manual web testers, who were very capable, were just not able to grasp coding matters sufficiently. Many were, but plenty were not. For those that barely could, I feel for the people who have to maintain what would then have been created in their businesses.
Programming that requires only a subset of a general-purpose programming language has the capacity of being implemented in a no-code tool if the scope of the programming needs are narrow.
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…
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