The No-Code Generation is arriving
techcrunch.com
techcrunch.com
If it were easier to use a visual interface than code, then devs would figure it out and we'd all start doing it.
The "no code" revolution is probably more accurately the Microsoft Access replacement for our generation. Sleeker, cooler, more professional. But like Access, you have to replace it with real software when it starts getting complex.
1. Hide parts of the program (e.g. hidden cells on a spreadsheet; attributes of nodes in a visual programming environment)
2. Switch to text for the higher information density.
I think the burden of #1 quickly surpasses the burden of learning to work with #2.
Once it grows to any reasonable level of complexity it becomes more of a hindrance than a help.
Access was actually a great tool for allowing semi-technical people make quick apps, but almost every shop I've been in has needed to convert Access to grown-up software.
But the real fix is to simplify web stacks for smaller projects. We don't need Rube Goldberg routing engines/URL-prettifiers, ORM organics, Bootcrap organics (UI), Async/Await bloat, etc. We want our app track some local e-paper-work, not be Netflix. A Learjet will do, don't gear it for Jumbo Jets. Time for a KISS web stack to become a de-facto standard.
> But the real fix is to simplify web stacks for smaller projects
We've already done that. RoR, Django, ASP.NET MVC, etc. etc. It's super easy to get something working out of the box. But at some point, you still need to understand what your database is doing and optimize for it. Some level of complexity is inescapable.
And you could probably argue that as back-end has gotten simpler, complexity has just expanded to fill the void. Now we expect fancy JS interfaces on top of them, too. And phone apps.
I have no doubt all of the things I mentioned will get simpler, but I can't foresee anything that will make software devs irrelevant in on the immediate horizon. I suppose at some point BAs/PMs (people who gather requirements and draw wireframes) will be able to write code, and we'll start to compete more with skilled BAs. But that's still not the end of the entire profession. Gathering requirements is still hard.
Unless carefully planned out to be modular, you end up with a giant pile of technical debt that is
(a) pretty opaque in its error messages
(b) has poor error handling systems
(c) is brittle in its ability to handle changing file formats or business needs
(d) can only be tested end-to-end, with no space for small unit tests to act as guide rails
(e) makes it very easy to hide business logic all throughout the ETL process
Upside to this tool: It seems to be handling a lot of simple parallelization speedups behind the scenes for you, and catches most type-conversion errors.
Which, inevitably, starts to include things like macros, include files, looping constructs and eventually bits of perl or TCL.
Code is data, but the converse of that is that a sufficiently complex configuration file is just a piece of executable code.
I'd stay as far away from all of these tools as possible.
if you stop there though, you're missing out on the business opportunity. you can dunk on things on HN all you want but if these businesses are right and the demand for software has massively outstripped the availability of engineers then you're gonna make money in no code tools.
However, I can personally vouch for 2 champions in no code.
The big behemoth is Salesforce.com. The incipient champion is Bubble.io.
Cloud infrastructure ,API consumption and mobile usage are the paradigm shifting variables that were not present 10y ago.
The fact that cloud is getting (traditional) corporate green lights and that every employee is using software to do regular 9-5 work indicates that software creation is demanded at exponential scale.
> The end result is always back to code.
Sure. The same way the end result is always back to electrons flowing around. The abstraction layer that no code provides NOT TO YOU but to Michel the accountant is very relevant and will (10y from now) produce a new paradigm shift, as Salesforce pioneered the "no software" [1] SaaS 20y ago.
And the paradigm shift is not "0 code". It's "0 code to get thing rolling; and developing programming skills visually to later on have a more productive talk with coders"
[1] https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2F...
My experience has been different. When I worked for a travel company, it joined Salesforce. Shortly thereafter it had to hire a full-time Apex programmer to make Salesforce do all the things the Salesforce salespeople promised it would do without a programmer.
My experience with Salesforce.com is that it's only a no-code champion if your needs are so simple that you might as well not be using Salesforce.com - i.e., a simple CRM with a few plugins. The real strength of Salesforce.com is that you can use code to customize it and get the real utility you're paying for out of it.
It's "no software" in the sense that all SaaS systems are "no software". Realistically, Salesforce.com is very much enterprise software of the sort that requires real customization in the form of real code to implement the important business requirements.
However, I do think that you still need a dev mindset, with dev experience, to use it well. Principles like DRY, loose coupling, code organisation, consistent and informative naming, concise logic, etc adhere just as well. Those hard to transfer skills you build up over time. Although a junior may get things working very quickly, keeping things maintainable and extendable is just as hard, or even harder.
So like you said; I believe you still need to be a dev to deliver with these systems; 'end user programming' is not close outside Excel. People who know nothing about programming will generally make complete monsters with these systems, even after training (I saw it a lot with Outsystems when I click open a business flow).
Real enduser development revolutions we won't see this low-code wave, maybe the next somewhere around 2030?
Right. And that probably applies to many, if not all frameworks, by virtue (vice?) of their design. I don't know Mendix, but I've worked on programming frameworks like Rails, Flask and others, including some in-house company proprietary ones. You sometimes have to work around their limitations with custom code, awkwardly, even Rube Goldberg style at times.
And there can be instances or even categories of apps that can't be done using the framework at all.
The framework giveth and the framework taketh away.
Macromedia Dreamweaver was the big inflection point because the results could be deployed on the web, for anyone to see, regardless of what box they were running.
The problem I have is that it devalues the worth of actual programmers by making everyone think what we do is easy. It isn't. I see this all the time with do-gooder charities on TV "We're teaching kids to code, and next week they'll all be billionaires!" The present themselves as if a week in a makeshift classroom is all it takes to compile and deploy a Swift app.
I've thought about this since the early part of this year when a middle manager in my company's Communications department dismissively told me that she could do my job because, "I know code." What does that even mean?
Sure, that's not true. But they will gain a better understanding of how to organize and process information. This understanding will help them even if they don't end up in a software engineering career.
It's a signal to look for a better position somewhere else.
Sounds like you work at a company that considers tech to be "the easy part" or a cost center...
Frustrating. And I know how to read and write, but it doesn’t mean I could write a decent novel.
What a lot of people don’t understand about software development is that for any non-trivial project, “coding” is the easy part, the real challenge is in the managing of complexity.
Even if it were, that'd still be a far cry from becoming a billionaire from nil in a week.
Throughout my career in computing I have heard people claim that the solution to the software problem is automatic programming. All that one has to do is write the specifications for the software, and the computer will find a program [...]
The oldest paper known to me that discusses automatic programming was written in the 1940s by Saul Gorn when he was working at the Aberdeen Proving Ground. This paper, entitled “Is Automatic Programming Feasible?” was classified for a while. It answered the question positively.
At that time, programs were fed into computers on paper tapes. The programmer worked the punch directly and actually looked at the holes in the tape. I have seen programmers “patch” programs by literally patching the paper tape.
The automatic programming system considered by Gorn in that paper was an assembler in today’s terminology. All that one would have to do with his automatic programming system would be to write a code such as CLA, and the computer would automatically punch the proper holes in the tape. In this way, the programmer’s task would be performed automatically by the computer.
In later years the phrase was used to refer to program generation from languages such as IT, FORTRAN, and ALGOL. In each case, the programmer entered a specification of what he wanted, and the computer produced the program in the language of the machine. In short, automatic programming always has been a euphemism for programming with a higher-level language than was then available to the programmer. Research in automatic programming is simply research in the implementation of higher-level programming languages.
And it seems to me that progress is going in the opposite direction than "they" want. Every time you move up the abstraction stack, you're surrendering some decision-making to the lower levels. If the underlying technologies guess right every time, you have no need to understand what they're doing. The first time they guess wrong, you have to spend a lot of time understanding not only how the lower layers work, and not only why they did the "wrong" thing in this one instance, but how to fiddle correctly with the layer you're operating at to get the lower layers to behave properly. You can work quickly with the high-level abstractions only as long as you understand the lower levels reasonably well.
Optimal machine learning requires a good understanding of memory cache hierarchies, parallel instructions and complexity theory - not to mention the statistics and calculus that it's formed on. And "optimal" isn't some trivial "save a few seconds" but often "return an answer within the lifetime of the universe".
https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
If you're fine with lower performance (which is reasonable for a lot of application cases, so I almost entirely agree with you), you certainly don't have to deal with this.
SQL in a nutshell.
e.g. ad-hoc exceptions -> errors as plain values, but with "railway-oriented programming" techniques that make them as easy to work with as exceptions
e.g. runtime-managed garbage collection -> rust-style borrow checker ad-hoc in the compiler -> haskell/idris-style linearity in the type system
e.g. "magic" green-threading -> explicit-but-easy async/await
e.g. behind-the-scenes MVCC in databases -> explicit event sourcing
...and we call that specification a computer program.
Just imagine a world when we have these programming languages to help us encode the specifications for our software. Wild! :)
r such that r * r = x
print "Hello, World!"
fn (*) :: Num -> Num -> Num
fn (a * b) = [machine code goes here]
un (_ * d) n = n/d
un (d * _) n = n/d
un (_ * _) n = sqrt(n)
Also "anyway" a specification is always incomplete. It's part of the programmers' job to fill the gaps with something sensible, and when they have no idea what to do, to point out that some corner case was overlooked.
This is where programmers sometimes start to feel like Lieutenant Columbo: at first everyone is nice, but people become more and more irritated as the pesky cop asks more and more embarrassing questions.
You just summed up about 20% of my job
With the years and postmortems gone by it has grown half-assed attempts at version control, code review, unit testing, deployment pipelines, etc. Now it’s very obviously just a shitty, hobbled software development environment. It’s used primarily because the team that owns it is aggressive about blocking design reviews for “duplication of effort” if you propose to use normal software development tools anywhere near its domain.
<for list="a,b,c,d,e" param="letter">
<sequential>
<echo>Letter @{letter}</echo>
</sequential>
</for>
Let's just say that it was a more brutal age, and we were more accustomed to such horrors. :)
This is absolutely one of my biggest pain-points with "no-code" solutions. Even trying to track revisions to something relatively simple like a word document over time is a big pain compared to tracking revisions to source code or a configuration file. Trying to get a grip on how people are fiddling with a no-code product from the audit logs is incredibly difficult, never mind trying to track down a change from 1 year ago. Often changes won't appear on audit logs at all or they won't be explained in enough detail and the format of the logs will have little resemblance to how things are actually configured. You can use some no-code solution to modify a SQL query under the hood and the audit log will just say "THIS USER CHANGED THIS QUERY" and that's all the detail you get! It's frequently difficult to explain to your peers how you're going to change a system without showing them a bunch of screenshots and going "Well I'm going to tick this box and move the green rectangle over here and link it to the orange oval". Rolling back changes can often be impossible without rolling back EVERY change between now and when the first incorrect change was made.
I use code, and these problems just don't happen! It's only when people are using some wonderful "user-friendly" solution that things get so jacked up.
Especially when it is anything involving finances, even tangentially.
Making it easy for non-engineers to change business rules on the fly without a code deploy sounds nice in theory, until you think about it for a few more minutes.
The other thing is there may be no way for me to, say, get a list of all the forms associated with a certain table and the fields they contain in some programmatic way (without browser automation, which is something I use not infrequently with a no-code system) and APIs that are almost complete but not quite.
So then what do we actually mean by "no-code" these days? I think "no-code", today, has the unspoken implication of "graphical". Okay, so why are "graphical coding" systems (languages?) mostly unsuccessful? There are some clear exceptions like Unreal Engine's Blueprints and certain WYSIWYG web editors like Squarespace, but the great majority of programming is still done in what comes down to, at the end of the day, text files. There may be more and more elaborate editors built atop these text files, but the "bones" of the code is always available, and never too far out of reach.
My pet theory is that this last bit is the differentiator. In a totally graphical programming environment, the programmer never has to be exposed to the underlying format directly. This perhaps encourages proprietary stacks, where the GUI is all that's known and the substance of the "code" itself may never even be made available to those who seek it out.
Maybe this arrangement keeps these "languages" siloed, and therefore keeps them from gaining real traction. It's hard for a thriving ecosystem to evolve around a closed format. Competing tools, editors, compilers, open transfer via regular files, translation, etc are all stifled. You end up totally dependent on one company for all of your needs. For some projects the value-proposition still works out; for most it doesn't.
If so, here's my proposal: instead of focusing on all-in-one no-code environments, focus on creating graphical tooling for existing languages. Or even, creating new (text-based!) programming languages that are designed from the get-go with advanced (graphical?) tooling in mind, while still having that real, open, core source-of-truth underneath it.
We've seen echoes of this already: Rust's features would make it nearly unusable without its (excellent) user-friendly tooling. Design apps like Sketch can output React source code. Pure-functional languages like Clojure really thrive with an editor that has inline-eval. I think if "no-code" is ever going to catch on for real, it needs to be less afraid of code.
On the other hand: is the value-add really the graphical interface, or is it the "height" of the language?
In the latter case, maybe it's more important that we explore even-higher-level languages, and set aside the graphical part as a distraction. Or, maybe we combine the two goals: create higher-level-languages that also lend themselves to graphical UIs, but are still grounded in formalized text underneath.
Every time we go to some other way of describing a document we lose all that text editing infrastructure, which is such a huge setback that no alternate solution has yet hit a widespread critical mass, only specific niches in specific domains.
Which doesn't make text good, it makes it worse-is-better!
As I see it, the probable way forward would not be in language design, but in formats and editors. Breaking through the dependency will be a slow process.
These kinds of full-featured IDEs tend to lead to knowledge gaps, in my experience. I'm not really a Java programmer, but I've helped more than one Java developer (usually junior ones, to be fair) with build issues. This is because when I use Java, I write it using vim and either `javac`and a Makefile, or else the command line interface of a Java build tool (ant, maven, gradle, etc). That has given me a good understanding of the Java build process, that I've found many users of Eclipse or IntelliJ do not have.
As such, I think your proposal may have legs, because it could allow less technical users access to the programming environment, while retaining a text-based interface for more expert users.
People on HN seem to think programming languages should be designed for a text editor as the primary way of editing, and I think that's a mistake that holds programming culture back (and is why we see these "graphical" languages go too far in the other direction, because the only way to get people to take a proper language editor seriously is to make a language that's impossible to edit in a text editor). Having a canonical plain text representation is important. Having good diff/merge is important. Editor customizability is important. But if you embrace the IDE and build an IDE-first language, without abandoning those parts, you can get a much better editing experience.
Where visual tools help is in UI building and layouts. That's exactly what I built Slashdiv for: create a UI and output React code.
Inductive progamming is very much a branch of machine learning and that's the reason most haven't heard of it (i.e. it's machine learning that is not deep learning). The main approaches are Inductive Functional Programming (IFP) and Inductive Logic Programming (ILP, which I study for my PhD). IFP systems learn programs in functional programming languages, like Haskell, and ILP systems learn progarms in logic programming languages like Prolog. And that is why neither is used in industry.
That is to say, both approaches work just fine - but they're not going to be adopted anytime soon (if I may be a bit of a pessimist) because most programmers lack the background to understand them and they can't be replaced by a large dataset.
A quick introduction to Inductive Programming is on the wikipedia articles:
https://en.wikipedia.org/wiki/Inductive_programming
I suggest to follow the links to the article's sources and to search for IFP and ILP systems separately. Two prominent representatives are Magic Haskeller (IFP) and Aleph (ILP):
http://nautilus.cs.miyazaki-u.ac.jp/~skata/MagicHaskeller.ht...
https://www.cs.ox.ac.uk/activities/programinduction/Aleph/al...
More can be found on the inductive-programming.org website:
https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.590...
I suspect that "code" will just keep on getting higher and higher level.
This means that humans will be able to express themselves and have an outlet to automate this.
Maybe the real question will be at what point will people say the specification "is not code".
and what will it be? English? Mathematical notation? doxygen? A notebook? Latin?
Also, this must be where “patching” code came from. Earlier in my career, I never understood the reference when they said they released a new patch.
There's some value in having abstractions being more visible. I don't think that strictly speaking something like Node-Red qualifies as 'no code'. But it made me understand that, given that so much of development nowadays consists of 'gluing' code together, there's potential for such tools. Even if some of the boxes happen to allow you to write code.
At some point, all you care about is inputs and outputs. We are missing a better way to do these things.
Yes, and: you understate the downside.
While No Code (nee Visual Programming, CASE Tools, whatever) may handle 90% of the use cases, the remaining 10% become dramatically harder. Because now you're fighting the framework. Which is an angry 800lb gorilla sitting between you and your work.
Faced with the same challenge, I went in the opposite direction.
Typical strategy of BizTalk, Talend, SeeBeyond, many many others is some kind of patch cord flow chart style programming, with Access VBA style event hooks for script extensions.
I created a stupid simple framework and API optimized for our domain (medical records). Think serverless computing and awesome DOMs for HL7 and adjacent data formats.
Onboarding for our SeeBeyond-based projects was 3 to 6 months. Using my stack was 1 to 2 weeks. (One of the weeks was teaching healthcare domain experts some Java, Eclipse IDE, and version control.)
Further, in my experience, none of these No Code solutions have useful exception handling, logging, fault/error recovery, and other misc devops type stuff. So are an absolute nightmare to support in production.
That is a great point. Whenever I've tried a no-code solution I end up dropping it and going back to code. Some insurmountable roadblock appears that if I had started with code I won't be in this mess.
I've also made the mistake of recommending no-code solutions to my business - trying to reach for the golden ring of self-sufficiency. Seems great at first and then you end up trying to "debug" a no-code framework that you have little of no insight into.
This is true for all of us - it's just that the level of abstraction each of us is comfortable with is different.
Not sure why people don't understand the value of raising the level of abstraction for more people to participate in software creation. It seems like an obviously valuable and worthwhile objective, even if it does look different to the way I build software.
When I use a "no-code" product it's usually not more than a few months before I start using it's API and adding small bits of code here and there to do things not natively supported by the product. You would have to have a puritanical fervor and a lack of sense to want to eliminate all semblance of code from a product made out of code.
It's almost as if after seeing you could add images to Microsoft word documents you saw an article coming out about how Written English was going to be replaced by Hieroglyphics and soon we could communicate with nothing but Emoji and talking about how the next generation won't be literate. The sentiment in this thread is mostly a reaction to irritating and implausible clickbait.
a standard newspaper article then ? https://cheezburger.com/6860549/14-hysterical-headlines-that...
actually I'm pretty sure that there were a ton of articles in the vein of what you're saying circa 2000 when emojis rised in popularity
At maximum that a gui represents a bad abstraction that can't be used by non coders effectively to produce code save for when actual code exists that sufficiently specifies the program. For example a gui builder can help you build your web based store but is insufficient to build the tool that builds the store.
All I can think of is how Windows used to be administered almost entirely through the GUI but eventually PowerShell was invented and its popularity grows year over year. How is that even possible when the "no-code" way to administer Windows must clearly be better and more accessible and user friendly and coding is old fashioned and borderline obsolete? Every company with their heads on straight would fire anybody who uses PowerShell and replace all their admins with unskilled high school graduates. There is not enough room in town for both no-code and code solutions, so I expect Microsoft to remove PowerShell in it's next update.
There's definitely a place for a la carte pricing for server-based software ("serverless" which of course includes servers, you silly person) and there's a place for very high-level code in domain-specific languages to solve immediate business problems ("no code" which of course includes writing code, you silly person) so just learn the shibboleth and try to avoid sounding silly.
/s
Yes. Also CASE tools, those with a code generation feature.
https://en.m.wikipedia.org/wiki/Computer-aided_software_engi...
Pun unintended :)
For instance, I've done some work with node-based editors like Node Red and Max MXP, and while they are nice for simple cases, invariably they reach a tipping point where you end up with a giant graph which is far less navigable and comprehensible than a set of source files.
There's no escaping complexity.
Epigram 93, Alan Perlis
That said, maybe this time is (a bit) different. Machine learning is markedly more mature today and could take no-code farther than it has in the past.
But seeing how pretty much everyone else here is also expressing skepticism, let me play devil's advocate.
I recognize that the utopian promise of no-code is nonsense. There will always be feature demands that violate the "on-rails" nature of the environment, and either require supplementary code, or require waiting for the platform's coders to code up support, or require rebuilding the application from the ground-up.
That said, there are all sorts of applications that really are so narrow that an existing GUI can accommodate them. Other posters here have called out Excel/Sheets as an example; Wordpress, Squarespace and WYSIWYG web page editors are another. As a coder, I always feel frustrated by WYSIWYG interfaces' side effects, limitations, and inevitable bugs, but people do use them all the time, productively.
Of course, both web editors and spreadsheets do involve the ability to write code! It's just that the code's role is very narrow and limited to a small expressive range (CSS, say, or various SUMs and HLOOKUPs).
When the domain is relatively narrow and its boundaries are pretty clear, no-code can be wonderful. The real question, right now, is whether applications that are innovative can be built using "no-code" tools that necessarily assume all sorts of limitations.
I have seen some clever and impressive uses of, say, Airtable + Zapier + Typeform. That sort of "API-weaving" seems to me the most promising direction for no-code. I'm more skeptical of the projects, like bubble.io, which try to be a sort of Photoshop-for-building-applications.
My wife was able to setup a WordPress site that sold fundraiser raffle tickets for her Rotary Club. The event was on local TV and handled a spike in traffic – thousands of ticket sales in a few hours – with no problem. This whole thing cost her less than $300, which would only get a few hours if she had to hire a dev.
I kept on telling her I was on standby and could help out, but she didn't need it once. She built the entire thing with WYSIWYG and WordPress plugins.
No-one is saying you build your tech startup with no-code WYSIWYG. But imagine if my wife's no-code skills (in her place, WordPress) became as common place as knowing Microsoft Office.
A more physical analogy is that I do DIY — including internal wiring of the house. I’m comfortable doing that because I’ve read through the whole of the regulations and have a degree-level education in Physics and understand the risks. If a stranger asked me whether they could wire their house through Youtube videos I still wouldn’t happily say yes — even though theoretically there’s enough good information out there to wire a house.
That is, an approach of the user not understanding these things and so deliberately going for a black box, just-works-in-exactly-this-way solution that's centrally tested, audited and maintained across the no-code platform is actually pretty great for security.
Having an understanding of how these things work, even a really good one, does not preclude mistakes if you want to do things customly - on the contrary this only ever increases the surface area for mistakes.
You might argue, and it often is argued in engineering (use the auth provided by your framework, well-trusted ecosystem libraries, etc), that it's better to just rely on known good solutions even when you do have a great understanding of the principles for this reason.
In my own experience this hasn’t been the case — the alternative of the user not understanding a problem is not going with an authoritative approach, but simply not to think or care about the problem.
Even when relying on ‘good’ solutions you need the requisite knowledge to judge what is good — otherwise people, engineer’s included tend to view such solutions as unnecessary. In your example, an authorization framework will have a selection of different protocols from OAuth, Basic, LDAP and so on — all of which are ‘good’. Without understand authorization and authentication could you really select between them?
In my opinion, the reason that Excel has such a commanding lead in that space is more due to familiarity, compatibility, and that Excel is still just one of the nicest spreadsheet apps to use.
To build complex things with "no code" tools, you need to adopt the coding mindset anyway. You end up discovering concepts like modularization, abstraction, you end up internalizing what the "no code" building blocks actually do, vs. what they advertise to be doing. But by then, what you're doing is just writing code in an extremely inefficient, unergonomic and probably visual way, and you'd be better off having learned a programming language.
It's not always perfect. As adoption and complexity increases, teams often find themselves bumping up against the limits of the tool eventually, and need to bring in specialists to help. But even then, it seems much better than the alternative of trying to code your own CRM system from scratch.
However, the ending is completely inexplicable:
> The No-Code Generation has the potential to finally fill that missing productivity gap in the global economy, making our lives better, while saving time for everyone.
What gap is this referring to? The gap between productivity and compensation? How does increasing productivity "fill" it? It's also pretty funny to define a generation by the productivity software that's available.
Interested in hearing more.
Which tools have you evangelized?
When computers were still a fairly new phenomenon, it was assumed that they would be an absolute game-changer and that productivity would go through the roof, objectively quantified in terms of revenue per employee. Productivity has in fact gone up, but not by leaps and bounds, and this is a puzzle to economists and other social scientists who study this sort of thing.
Hacker news is filled with programmers who feel proud about their craft, and, judging on the comments here, feel threatened.
Yet it seems most of these people have never been in a big company where 90% of the world's business software is used, had to deliver something half-assed due to this ridiculous gap, which the business is elated for the next 10 years, with the programmer ashamed.
That's the value of software - supporting business processes. You can cut a lot of corners if you achieve that.
Yep, people sure write a lot of code in Excel.
(Well, what do you think formulas are?)
As far as general "low code" or "no code", I've seen that promise for many decades. They keep reinventing failed ideas under new names. Clickable wizards, rule lists, and drag-able flow-charts can only take you so far. The devil is in the details, and these don't handle details well. And they are hard to factor.
Your Uncle Bob may be able remodel your house for cheap, but what do you do when rain leaks in and the lights stop working? Or worse, catch on fire?
Remember: Total Cost of Ownership.
He started of the talk describing Regex, and how it came to be, and basically showed how that functions have been/could be formally described in papers the same way that Regex is used.
In the same way regex formalized the notation for string parsing, so too will the next language regular function expression formalize. Perhaps computer meta notation is the source of true no-code solutions? Perhaps instead of reading articles about "The Unreasonable Effectiveness of Regex," in the future, we'll be reading about "The Unreasonable Effectiveness of Computer Science Metanotation."
I also understand that what no-code solutions we are typically talking about is a user interface that is graphical, drag-and drop. But who is to say we don't create a tool that does that with CSM?
[1]: https://www.youtube.com/watch?v=qNPlDnX6Mio&ab_channel=Erlan...
Someone once said that D/F makes it easier to express what you intend, but imperative makes it easier to figure out what's actually happening. One improves writing, the other improves reading (or at least debugging).
So, great lock-in capabilities? I can see why money is pouring into these tools.
What's interesting is that many users build quite complex formulas and spreadsheets, yet Excel's formula and VBA syntax is (in my opinion) harder to learn than other programming languages. For example, I'd argue a language like Ruby is simpler in many aspects than using VBA or building complex formulas.
Like Microsoft, Google Sheets also has quite an ugly, clumsy feel to its syntax.
The terrible programmable usability of these products (Excel and Sheets) could only have come from the mind of a developer (harsh I know, but true).
People just kind of default to {do some magic} on [various things] -> (Some result that looks about like I was expecting).
What’s really interesting is Spreadsheets tend to have bugs where the result is incorrect but reasonably close to reality. Aka 38 vs 35 not Null Pointer Exception, this makes them in many ways seductively dangerous in a this looks close therefore it must be easy to fix way.
And eventually require VBScript if you want to really automate anything anyway.
Edit: I know there are lots of people on the Internet saying you can simulate Turing machines in excel, but they're usually manually unrolling the computation in successive rows, which doesn't really count. For one thing, this style of simulation doesn't even allow one to make an infinite loop, let alone a more complex self-contained loop.
That and Microsoft's insane theory that about 50% of user input is dates.
=RIGHT(A5, SEARCH("FOO",A5))="BAR"
I know unemployed programmers so it's no shortage of supply.
Sounds like we will all soon be writing custom code for NoCode products, which is basically where we are anyway.
I always see this, but can you name a single popular app that is just a "basic CRUD", with no specific business logic?
I'm not saying it doesn't exist but I genuinely cannot think of a single one
I am yet to meet the mythical CRUD app that could be created without code.
Now, if you go into "low code" as in a very high-level opinionated framework+language, that can work. But if you start from CRUD generation, you won't reach anywhere useful.
I guess 'useful' is in really who you are asking; people working in department X in country Y of huge intl corp Z are usually not very happy what the 'headoffice' bestows upon them as software packages. Restrictive, everything has to be coordinated with those scary people from IT etc etc. To be able to change that without breaking the bank can be very empowering and has been the domain the domain of low-code (and no-code) tools forever; from Excel, MS-Access to Wordpress to less well known systems.
One of the biggest electronics retailers in the EU has a central, restrictive, very annoying massive enterprise CMS which is pushed down by the headoffice; every local country started pushing out WP sites; low code (html/css (they have to use the house-style, so they copy that from the main site), the rest is plugins and some shortcodes) needed and cheap while not having to wait for 6 weeks for permission to change 1 sentence 'by IT in the homeland'.
The reason we use text is because it is information dense, portable, and easier to refactor. If drawing lines between shapes could have these same properties I am sure we would use them.
We are not manufacturing work for ourselves, we are not hiding "the good stuff" in the back to force people to continue to pay us.
If someone comes up with a perfect no-code solution it will be a multi billion-dollar revolution.
People always resist the next level of abstraction. Either because they have to relearn something, or because there's some status associated with it being hard, or something else. It's just the nature of people for most to resist the new abstraction.
This doesn't mean the perfect no-code solution is here, but just because people are dismissing it at first also isn't evidence that it's not.
I think there's a lot more we could do with just visualizations around making the regular programming tooling way better: http://worrydream.com/#!/LearnableProgramming
wut?
1. As many others point out, "no-code" is just a different way of representing code/logic. The skills are the same, except for typing.
2. Even if it did take off, someone still has to maintain the code for the no-code tools. I guess eventually the no-code tools are meant to be written in no-code. This doesn't happen overnight.
1. Sales for a No Code product talks up how you will not need programmers to create solutions
2. Company buys No Code product deploys it to users
3. A few users "get it" and create solutions with no code
4. Something in the environment changes, or the original creators of the solution move on from the company and the "no code" solution breaks, no one can fix it or understand what broke or even really explain the "solution"
5. Devs / SysAdmins now have to detangle and figure out how these "no code" solutions works, what they were suppose to be doing in the first place, and figure out why they do not work any more. Often times this results in the dev / admin just redoing everything properly, in a proper programming enviroment because there was no logic to no-code solution
There's a reason excel is so ludicrously wildly popular as a business tool. It lets accountants do things you used to need a programmer for. That the automation may eventually grow so complex as to require a programmer anyway is not relevant to the utility of excel.
You also end up with a TON of XY problem "solutions"
It is a nightmare 90% of the time
>>There's a reason excel is so ludicrously wildly popular as a business tool.
Because it allows lower wage workers to implement half baked solutions, and manipulate data in away that executives want regardless if it accurate, true, or reliable?
I will agree that Excel is a poster child for "no code", it has EVERY problem of no code in spades, I wish i could get back even 1/10th of the time I have wasted in my career trying to decipher some of the moronic things I have seen people do in excel.
and do not get me started on people that treat Excel as a Database, Literally pulling in an entire table with a Select * SQL Query then using some excel function to do sorting and filtering.....
Or to phrase it more generously: It allowed people to create the tools they needed to make their lives easier without engaging the services of a professional programmer.
I know that to the professional programmer this is a high-crime worthy significant prison time, but to me it is basically the point of personal computing.
it is like "Write one, Run Anywhere" code... It has been promised by vendor after vendor who all have slick sales people that promise the world, and deliver something less functional than excel
The problem isn't coding or not coding or whatever. It's the problem of expressing complex logic and calculations to meet your ends. If you can't express those ideas on a computer then you're not going to get anywhere making software.
The problem is that kind of thinking is hard, and requires the use of something more complex than the no-code tools available now or in the foreseeable future. The nifty part about programming is the concepts are transferable to other areas. No-code tools generally don't offer that - you learn how to do Minecraft or Excel, but then when you're out of that tool your skills don't apply. I see this with young people frequently now. For example, a bunch of Excel VBA functions that do essentially the same thing but with a number in their name to determine some functionality. When asked why they don't they just pass the number as a parameter to a single function the answer is that's too difficult and what they have works fine. This is from a recent graduate in engineering.
Making software without coding doesn't really do anything but let you assemble pre-made parts. That's fine for some relatively simple thing, but will never give you the power of coding.
This transcends programming. It is fundamental to basic success in life. You have to know how to form ideas, express those ideas, and then act on those ideas.
I had a very little bit of U.S. Army training. (Nice people, turned out not to be my thing.) One of the things that we were taught is that a big reason some armies are more successful than others is because some train their soldiers to think, others train them to blindly follow orders.
Another arena where we see this is education. There is no shortage of people graduating from high school and college who can pass written exams through memorization. But there is a massive shortage of people graduating from high school and college who can think.
“No code” is always what software vendors sell in the beginning. Eventually, they win a large enough audience that they have to add full programmability, if only to automate the testing and management of things, and someone waves enough money at them to allow for some custom thing or other.
I use a LOT of co-ops to develop full applications using Oracle's low code solution, because we don't need anything more complex than that. Complex shit should be done by our ERP, I'm just turning a manager's spreadsheet and half baked business process into a well built system. Plus, I use the low code solution as a training ground for our more complex technologies, its great for weeding out the duds.
You should still have a programmer do the work though. I have seen far to many smart business analysts fail because they get hung up on the programming basics.
I'm a professional dev myself, but I don't see why everyone should have to, or feel like they have to, learn how to code, or even make stuff using "no-code".
In general, kids and adults alike, but especially kids, should spend more time being active and outside, not sitting down in front of computer screens.
Not everyone is cut out for or interested in coding, just like not everyone is cut out for or interested in medicine, law, a trade or literally every other imaginable field. And that's not a value judgement or a judgement of people's intelligence or lack thereof (unlike a lot of techies, I don't believe we're smarter than everyone else), it's just fact.
Ability to code gives you a particular mindset that makes it much easier for you to work with computer technologies. It's helpful, but on the other hand you could argue that all other technologies we use in daily life have been sufficiently abstracted away that you can get away with not knowing how they work.
The real reason why coding is a big topic in society is that, for the past two or three decades, programming has been an easy way to move up one or two socioeconomical classes. Most well-paying fields are nowhere as easy in terms of workload or required education. Of course, if everyone became a programmer, the payoff wouldn't be as high anymore, but there's lots of money to be made right now by pointing to college dropouts made tech billionaires, or fat FAANG paychecks, and selling people coding bootcamps.
(Or, in less cynical terms: the demand for software developers still outpaces supply; this manifests as a background social pressure to create more software developers.)
It fails every time with much wasted effort and gnashing of teeth. The reason is because once you've specified your requirements in enough detail for a machine to understand and reasonably act on, your spec -- or diagram, flowchart, whatever -- is isomorphic to constructs in some programming language. So you haven't made code go away, only transformed it -- into something that is, all things considered, vastly more cumbersome than text to work with.
So yes, I think no-code has been with us for a long time and will continue in various forms.
As others have pointed out, the desire to build things without coding knowledge has always been there, and there will always be a place for it. An ice cream shoppe should probably use Squarespace instead of hiring a coder for thousands more.
However, until we have sufficient AI, executives will always request features that can't be achieved with whatever no-code building blocks are available. Contrary to others, I do think there will come a day where the human computer programmer is completely obsolete, but we are definitely not there yet.
>Today’s new workers know how to dive into systems, pipe different programs together using no-code platforms
I was thinking, not the ones I know. Maybe they are out there somewhere? The only people I know who can dive into systems and pipe programs together are people with programing experience.
There are many situations where a non-engineer with some programming experience can very quickly string together a few "no-code" tools to build a workflow/tool that scratches 90-100% of their itch.
"Some programming experience" meaning: they understand basic IFTTT logic and can configure API access using a tutorial.
The piping of programs is now done by sync integrations built into the tools, third-party tools like Zapier, or other services that can map and standardize API output.
All the solutions I used were mostly tailored to a single use case, and they made it easy to get 95% of the work done. I'll even include interface builders as no-code.
Then getting to the finish line has always involved writing serious code that would plug itself to the proprietary API whatever No-Code-Solution-du-Jour supported. Of course, if the company selling the no-code goes under, good luck!
Then there's collaborative work and source control support. Most folks are comfortable with GSuite-Style collaborative work but that really doesn't scale.
But there's still a fundamental issue. Every time I worked with non-technical folks using no-code, there was a subset of users that just "got it" almost right away and would end up exploring and maxing out what the tool could do. But the majority of users seemed to be confused and could not move past the hand-holding tutorials. It's almost as if the former could describe what they want so well that it's not ambiguous...
Actually -- programmers' opinions on no-code solutions are irrelevant. The non-programmers' ones are more important.
No-code solutions are ok for quick prototyping of automating processes that are not the core of the business. When you start using them you have to define the step where you will switch to a more maintainable solution.
This is the same as deciding when to use a shell script and when to decide to rewrite the script in a stronger programming language.
Recently I taught my wife how to write HTML. Last month she completed designing a pretty functional ticketing system working alone for 1 month on Microsoft Sharepoint. The system is complete with provisions for case escalations, teams / emails alerts, reports, groups etc.
Visual drag and drop tools are not going to make coding obselete in the forseeable future. But they can be very useful in well defined domains.
I am currently working on a 'no-code' drag and drop tool for data transformation. I have been able to create transforms that cover ~95% of cases. But there always going to be edge cases I can't cover. So I have included the ability the write some Javascript. ;0)
I could see something like that succeeding in the modern era if you make it easier to share - you needed Stagecraft to run anything made by it. Anything modern with this grid+rule system like that already?
I think this kind of reaction is inevitable when people with power and privilege feel threatened by another group who are claiming some power for themselves.
Here's what the article was really about:
> The key here is that no-code tools aren’t successful just because they are easier to use — they are successful because they are connecting with a new generation that understands precisely the sort of logic required by these platforms to function.
It may be a poorly written click-baity article or you may think the conclusions are wrong but you can't dismiss the reality that a generation of people are being exposed to programming concepts in an entirely different way to our experiences. This is fascinating whatever you think about the tools themselves. Isn't the interesting discussion to be had here more about what this will mean for end-user software going forwards?
- Does this trend maybe mean that it's vitally important that we build some forms of open standards around this kind of technology?
- Should we rethink programming education for young people knowing that many are likely to have exposure to concepts no-code introduces?
- What does FOSS look like with no-code - do we need some serious FOSS tools in this space?
I think there are a lot more interesting avenues to explore beyond "I don't like this trend" and "we've seen abstractions get higher-level before and we haven't been put out of a job yet so what's all the fuss about".
But the article is just very self contradictory. It doesn't make sense to say "The No-Code Generation is arriving," while also saying that "Lua has never been more popular," or that we just had "the largest increase among all of the [Advanced Placement] organization’s dozens of tests" or "Meanwhile at top universities, computer science has emerged as the top or among the top majors, pulling in hundreds of new students per campus per year." Quite clearly, besides "no-code" platforms, there quite clearly is a growth in interest in traditional coding tools as well.
FOSS traditionally has little interest in this because FOSS volunteers like to write code and, like HN, do not believe (to which I agree) that it is more efficient/flexible than writing code.
These tools have their purposes, but they are not new by any means and this 'generation is not coming', it was there since the 70s. Here is a package from the early 80s [0] which is still supported because people still use it; I for one know a large steel processing plant that runs on it since the beginning of the 80s until now; the guy who wrote the bespoke ERP system cannot actually code well; he stinks (he knows it; I knew him well when I still lived close to him), but it worked well for them with this 'low-code tool' for all these decades.
As I said somewhere; the problem is that FOSS is not interested and that the commercial tools belong either to tiny companies who can be wiped out tomorrow (by 'something') and huge companies who can cancel the product or only have cloud versions so you are locked-in completely. And a lot of people find that scary while almost all textual programming languages and frameworks are open source and free as in speech and beer.
Until that ratio shifts I'm skeptical.
Even the on premise installs are not enough; you need a lot more. I saw a lot clients choosing Outsystems because you could eject to readable c# or java. Not sure if anyone ever did but I know it was used as a reason to pick them over others. At least they spent time making the ejected code looking ok: many do not have the option and then you have, at most, an on-premise blob which, probably you cannot use after the company gets sold, dies or gets into legal issues.
I share the skepticism from other commenters in this thread. Maybe it's just anecdata, but I don't see my peers using super high level GUI replacements for data analysis. My friends in marketing, engineering, biotechnology, and using the same tools as the millennials before us: Excel / Google Sheets. In fact, most learned how to use those tools on the job or in college, not from their earlier education.
> Whereas just a few years ago, a store manager might... put their sales data into Excel and then let it linger there for the occasional perusal, this new generation is prepared to connect multiple online tools to build an online storefront (through no-code tools like Shopify or Squarespace), calculate basic LTV scores using a no-code data platform and prioritize their best customers with marketing outreach through basic email delivery services.
I have seen people using Squarespace, but again, I've seen older millennials pick up such software just as readily. My friends that are fluent in data analysis acquired their proficiency through traditional, code-heavy approaches (R, Python, a good dose of command-line interfaces).
I guess my point is that, if you want to fill this "missing productivity gap in the global economy", mere exposure to Minecraft and website builders is not a substitute for a comprehensive C.S. curriculum.
- https://web.archive.org/web/20201026181132/https://techcrunc... (seems to successfully load then fails after a few seconds)
E.g. Unity is "no code" for a lot of stuff (putting scene together), but you also need code for other stuff.
Essentially for those tools to succeed they must allow mixing their abstractions and visuals with lower level code, in my opinion.
Even "no-coders" should have a working knowledge of basic programming logic so when things don't work as they should, you know where to start looking.
The purpose of programming is to tell the computer what to do. To tell someone or something what to do you have to "talk to" them. You need some language to do that. And when you are talking to a computer, the languages they understand are called programming languages, in other words "code".
Another way of looking at is that English is code as well. It is code we use to communicate with humans.
Now maybe there is some visual language that could be used to communicate with a computer effectively, but then that is a language too, and thus is code.
What "no-code" could ultimately be is a system where the computer asks you to choose from set of options and based on your choices incrementally generates a program, a bit like when you install Linux it asks you a set of questions, and you answer and in the end you have a working system which you created without talking in code, unless yes/no is considered a trivial (binary) code as well. But it is a very limited set of programs you can create that way in a limited time.
Is in this context "no-code" synonymous with "low-code"? Or are there differences?
The author ended up buying a used Commodore 64 for his son.
He touched this topic again in his blog in 2011 [2] (scroll to "encouraging kids to program"; he also participates in the comment section).
I personally think single board computers seem to keep tinkering and line coding alive.
1: https://www.salon.com/2006/09/14/basic_2/
2: http://davidbrin.blogspot.com/2011/06/milestones-leading-up-...
These tools include a number of SAAS startups whose marketing departments definitely did not pay Techcrunch any money to get plugged in this article.
Your job or career as a software engineer is not threatened, though the title was intended to make you feel that way in order to bait clicks. Assuming you don’t work on Excel, that is.
I believe part of the success of Excel was simply that it was installed on every computer. Engineering students learned Matlab because it was "free" for their use thanks to generous site licenses. In fact, Matlab was an early no-code tool in a sense, allowing students to do calculations without learning FORTRAN.
In my own workplace, a handful of people have gotten into using Python for trivial tasks because nobody could tell them No. They could even try it at home if they felt that it wasn't going to be approved at work.
If you've ever seen a UE4 Blueprint you'll see this can be even worse than just writing the code out.
I'd be very much against teaching this, you learn no real skills. Congrats, you know how to make a Blueprint in one specific tool. You can't get a programing job or even use another tool easily.
My related comment from a past, similar discussion: https://news.ycombinator.com/item?id=20042225
Right, Lua. That's how much the "no code" generation is arriving?
> In business today, it’s not enough to just open a spreadsheet and make some casual observations anymore.
Using office applications is also "no code". Spreadsheets have some aspects of code in that there are formulas that use the value of other formulas, but it's not really code.
"No code" arrived about forty years ago. With the advent of personal computers in the home and in offices, most computer use since then has been by non-coders.
> [T]his new generation is prepared to connect multiple online tools to build an online storefront (through no-code tools like Shopify or Squarespace), calculate basic LTV scores using a no-code data platform and prioritize their best customers with marketing outreach through basic email delivery services. And it’s all reproducible, as it is in technology and code and not produced by hand.
Well, reproducible today, and maybe a week or two hence, until some details in the technology change. Invariably, the technology either has no regression tests which cover your use case, or else consciously declares your use case irrelevant. You know, they "prioritized" the software for "their best customers"; too bad that wasn't you!
Since it's online SaaS, you can't even do the usual troubleshooting of comparing the behavior of the old and new version of a program. Between two refreshes of a browser, the black box can change what it is running.
In prior decades, you might use some query language to scan a customer database to prioritize them according to "best", and export the results to some word processing mail merge to generate correspondence. All "no code".
This article is really about shifts in the kinds of tools that no-coders are using, away from locally installed or in-house software toward SaaS.
Even back then it seemed like a dumb idea that was doomed to fail. Feels like it ideas like it keep coming back. For some reason, there isn't the same push in engineering. Can you imagine someone trying to sell the idea that anyone can design and build a bridge? Yet in software, we refuse to accept development as something that requires specialist skills.
But a website is not a bridge – the stakes are low, and yes, for many basic use cases, Squarespace suffices as the intermediate that enables "anyone" to build a website.
Actually, revisiting the bridge idea – for a sufficiently small creek, yes, anyone can design and build a bridge (simply chop a tree and fell it across). So I guess the question becomes – what kind of bridge are you asking for? A bridge designed to support large volumes of cars absolutely requires specialists, and those specialists should feel no fear from the companies that sell plywood to toss onto creeks.
No-code is great when it improves someone's ability to complete a task. Excel is still a great program, and learning VBA was my first introduction to programming. What isn't great is when companies lean on low/no-code solutions because they want to be cheap rather than do things properly.
You see this in how excel is used and abused.
But this time it's different! No it is'nt.
Users are now eMp0wErEd! You give 'em this drag and drop interface and they will cHanGe thE wOrlD!! No they won't.
Trying to make 100% of your solution no-code is a fool's errand at best, and a tragic whale hunt on average. Especially, if you set out to achieve a no-code solution from day 1.
There are certainly trivial problem domains where no-code solutions are good answers (e.g. IFTTT). But, there isn't much money or glory in solving trivial problems.
Solutions like Access and Excel are "good enough" for 80% of the work, but the clunky coding integerations made the last 20% customization a real pain.
In time, they also discover no-code is not portable, you are tied more tightly to a particular framework. No-code may be more difficult to version control.
This fad has happened a number of times: SQL, CASE, 4GL languages (more like an analogy - people discover that 4GL langs are limited and move to 3GL), spreadsheets, XSLT...
Are all tools with programmatic capabilities low-code? Where do we draw the line? Or is this just a new paradigm, and eventually all platforms/tools/products/SaaS-companies are low/no-code? It seems like there's room for distinction here.
It’s the logic and process flow that is hard. It’s the edge cases that bites you, because you didn’t account for it.
The code is just the translation of your logic and process flows, into something that a compiler can understand, so that it can be reassembled into binary code.
Regardless, these no-code tools will just add another layer, which will require some specialist to know how to use such tools.
It would make more sense to say that the more we code, the more possibilities for no-coders.
No-code will be like not having a pre-frontal cortex... (not that everyone engages it that often). Anyone who can code is already part way towards being able to "think with a computer." Coders can solve problems that brains alone can not.
You still have to understand CS concepts and ideas. Heck, I even created a reusable component to do async polling. (Because how do you explain that as a single integration.. you really cant')
This is nothing but PR drivel to suggest that we can get millions of kids as cheap labor to be spring developers on their platform.
The result is as incompetent as it sounds: hiring developers to write code and yet not expect them to write code. I am always surprised that any employer would buy into this stupidity, but it’s the common approach.
Even worse when master data is hardcoded into applications. It still happens especially when a vendor can make an ongoing revenue stream from it.
Just look at languages like LabView. Anything above a small sized program quickly devolves into a mess of shapes.
Perhaps Visual programming can help out in creating building blocks of functionality, that depends on lower level abstractions and lower level code.
Anything more than one level in VP is confusing.
I think the proper term for these products should be "Low(er)-Code".
And can it really be called no-code if new technology could be encoded reliably at scale in that one higher level of technology?
The kind where the data type you need already has code for it and just needs configuration.
And the kind that needs code to implement the data type you need.