After seeing the no-code movement over and over again, I do not believe that this time it is any different. From MS Access days, Adobe's Dreamweaver, and many other forms of no-code solutions, the environment that supports no-code requires a tremendous amount of code. Knowing how to code can help you optimize, automate, configure no-code solutions. The end result is always back to code.
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.
> automatic programming always has been a euphemism for programming with a higher-level language than was then available to the programmer
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".
Security is also something to be mindful of. A lot of my work as a professional vulnerability researcher is just using my low-level knowledge to circumvent higher level abstractions people usually ignore. The abstractions aren't seeming to slow down and I fear soon only a few will be able to peak into most or all of level needed to provide reasonable security. Whenever I see a system built with "Automated" technologies, I usually start there to find flaws. In order to truly utilize high level abstractions it is useful to actually understand what provides them.
I feel like I was lucky to have started learning computers when I did in the late 80's. There weren't nearly so many "time saving" abstractions back then, so if you wanted to see anything happen, you had to have a good understanding of what was going on under the hood. Although it was at times frustrating back then to put so much effort into something as simple as drawing a circle on a screen, I'm fortunate that I was forced to spend so much time internalizing the details - I don't know if I would have the patience to learn it all if I was starting right now if I could see that shortcuts existed.
It really depends on the specific person. I started programming in 2006 at 21yo and I don't feel like I missed anything at all. Spent a lot of time reading and researching things anyway. Higher abstractions doesn't necessarily mean lower complexity.
Hmm - I don't see much people tinkering with machine code, even compiler bugs are rare and programmers don't normally need to understand what their compilers do.
If you're working with HPC applications, your choice of compilers and sometimes higher level specifications you may write in C, C++, or (gasp) Fortran often do demand you think about what your compilers are doing or choose compilers to think better for you.
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.
These folks are working on bootstrapping a full Linux distribution solely from a small amount of machine code plus all the source code of the distribution:
I find a lot of useful abstractions end up getting implemented twice: once in a "magical" way where you rely on the runtime to manage it according to a bunch of cobbled-together ad-hoc rules, then again in a "principled" way where it's under the programmer's control and can be reasoned about, but still (almost) as usable as if it were working by magic.
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
> 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.
A sister team at my company is quite proud of its rules engine that allows non-programmers to quickly implement business policies using its DSL in a web UI.
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.
>version control, code review, unit testing, deployment pipelines, etc.
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.
Whenever someone is championing a "no code" or "configuration driven" solution for business processes all of these things you just described are alarm bells ringing in my head.
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.
What if a no-code system was built atop a text-based language that lived in a regular file-system workspace? The "no-code" part would just be a fancy IDE, but the code would still exist to be edited directly, tracked with git, whatever else.
You'd need to make sure that edits in that fancy IDE can be sensibly diffed/merged at the level of that text-based language. I've never seen good diff/merge for a graphical format, so I think this kind of "no-code" ends up being just code.
I'm doing something like this for a system that's configured via web-interface. It has a stable, readable export format which I'm tracking with Git. So we can actually have a diff and reviews of the changes.
They store so much, why not a changelog? It baffles me.
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.
I'm having flashbacks to attempting keystroke automation which works 90% reliably until a field is added via an update and breaks EVERYTHING until you workaround it.
I was almost bitten by a project like this, despite ample protests the whole way long that "configuration" was just becoming a "crappy programming language". All too often I still have to deal with someone who thinks because logic hinges on a value in a JSON file, they've magically abstracted away the concern of what it is that the code should be doing.
Man, I'm not from the Java world, but these days I had to deal with it for a project and had to mess with ant builds, which I have never dealt with before. I was totally baffled. I just do not understand why would anyone subject themselfs to such levels of pain.
The above describes what is today called program synthesis, i.e. generating a program from a complete specification. There is a parallel discipline, of inductive programming, or pgoram induction, which is the generation of programs from incomplete specifications, which usuall means examples (specifically, positive and negative examples of the inputs and outputs of the target program). Together, program synthesis and program induction, comprise the automatic programming field, which has advanced a little bit since the 1980's, I dare say.
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:
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):
Neat! Thanks for posting this. I bumped into Genetic Programming a few times when I was studying evolutionary algorithms. Program induction seems bigger, more modern, and more sophisticated.
Some of the IFP systems actually use a evolutionary algorithms, I believe- ADATE in particular, though I can't find an actual instance of it online, or any other information but a mistitled paper:
I see where you're going here. It might help if we construct a specific syntax and grammar for writing specifications for software. It'll be helpful for all of us if we can make our specifications as clear and efficient as possible. We could even call this combination of a syntax and grammar a programming language.
Just imagine a world when we have these programming languages to help us encode the specifications for our software. Wild! :)
That’s a specification that gives you no knowledge how to solve the problem. You can definitely have precise specifications that do not directly correlate to machine instructions.
I like this answer because it says it will require someone with specific knowledge and specific training doing a specific job anyway...
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.
A key distinction here is whether you could write your no-code system using your no-code system. If you no-code system is self-hosting, then you've made a higher-level programming language. Otherwise, it's a tool that lives on some dimension other than "programming language".
This is a good insight. So, clearly, higher-level languages have been an enormous success. But "no-code", as we mean the term today, has still (mostly) been a failure.
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.
The common denomination in textual coding is text itself: There were historically some differences by locale, encoding, and line ending, but we have managed to converge on a sufficiently encompassing standard with UTF-8 text that the rest can reasonably-if-imperfectly be dealt with by the text processing code, and this is the source of friction: our text editors and terminal emulators are great - so great, that it's hard to get out of the path dependency involved in utilizing them. It isn't just the interactive cursor, or copy-paste, or search-and-replace, or even regular expressions...it's decades of accumulated solutions that can handle every concievable text problem.
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.
I think there's real value add from a language that's designed to work in an IDE-first way, that uses the GUI not to replace text but to enhance it. The best example I know of this is Scala's implicits: they're not visible in the code itself, but in an IDE you can see where they're coming from (e.g. ctrl-shift-P in IntelliJ), so they're a great way to express concerns that are secondary but not completely irrelevant (e.g. audit logging - basically anything you'd consider using an "aspect" or "decorator" for). Another example is type inference (which a lot of languages have): your types aren't written in the program text, but they're available reliably when editing, so you can use them to express secondary information.
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.
> 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.
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.
I can't agree more. When I started working on Slashdiv, I had looked at the existing NoCode platforms and came to the conclusion that code is the most succinct representation of logic and graphical tools will have to get users to jump through hoops to create basic logic (programmer here, no surprises!).
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.
I agree. This goes back even further than that. In the 80's various "construction set" programs were all the rage. They were essentially no-code programs, many disguised as games. Later there were 16-bit solutions, like a program called "Can Do" for the Amiga. (I'm not entirely sure of the title, but I remember the splash screen had a voice shouting "I Can Do; you can, too!")
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?
> 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?
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...
> 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?
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.
> We're teaching kids to code, and next week they'll all be billionaires!
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.
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.
The remaining 10% become dramatically harder. Because now you're fighting the framework.
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.
My experience with SSIS 2012, Microsoft's low-code ETL tool, suggests that you're trading code for a giant config file.
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.
A third of the websites in the world use wordpress which can certainly be configured using "no-code" and yet it's being sold as something brand new. Excel is everywhere and allows for "no-code" automation. No-code has been around forever and for some reason incremental improvements to something utterly pervasive is a revolution that will be embraced by the next generation.
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.
I get this hunch that no-code is attractive because it hides the true costs. You can apparently hire cheaper labor, but you don't see the maintenance costs. You can also apparently delegate coding tasks to non-coders, which might help you squeeze the budget bubble around the business. But there's costs to that as well in terms of making people less effective at their normal work.
the reality is that even the no-code advocates are fully aware of this. I was surprised that webflow let me publish "No code is a lie" on their blog. https://webflow.com/blog/no-code-is-a-lie
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.
Software engineers spend every day trying to automate away their jobs, and it's hardly a conservative field.
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.
I think this is just it: text has a higher information density than (say) visual programming tools. At some point you quickly reach an amount of threshold of complexity where you either need to:
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.
No code can be great if you want to spin up something simple quickly.
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.
Granted, it's a good way to prototype ideas. Less analysis is needed when one converts from Access to the new thing because the ideas are road tested. But one problem is that modern web stacks are a bloated incoherent mess that take an army of specialists to manage. That may be part of the reason for the resurgence of "no code" tools.
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.
Oh yeah, Access was great for prototyping and I've argued as much here several times. I've built Access prototypes in earlier jobs.
> 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.
A lot never will though. I don't see no-code replacing many custom developed applications. It see it making apps accessible for processes that used to managed by spreadsheet and email.
I think the core of the issue is that real problems contain a lot of complexity, and code is still by far the most efficient way to encode complex logic.
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.
I've been using Mendix for a while now (for a client), which is more low-code than no-code. I enjoy it quite a bit. It's very easy to add a new entity (table) and some screens for CRUD stuff. Even without code you can customise quite a bit, but there's always Java (server) and JavaScript (client) actions. Nevertheless, as with many frameworks, it gets awkward when you move too far away from the 'intended use cases'.
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.
Mendix & Outsystems are pretty popular in the enterprise space and they work quite well. Like you say, don't move too far away from the intended space, but the LoB (line of business) space is vast for big enterprises and that's what these tools are for. There is no need to do 100% as you can get to 80-90% and the rest you don't do with those packages; you do with code. Why is that a problem; you use different frameworks / languages / dbs / etc with code too; these systems are no different; use them what they are meant for and do the rest with other tools. Ofcourse there is more than enough work to be had just creating departmental LoB apps to last you 1000s of lifetimes, but that's another story.
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?
> Nevertheless, as with many frameworks, it gets awkward when you move too far away from the 'intended use cases'
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.
People would rather learn [high-level abstraction] than to learn [low-level abstraction]. But guess what..[high-level abstraction] IS [a kind of abstraction].
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.
Because they're pretending that this next [high-level abstraction] will be replaced by another style of [high-level abstraction] as if [high-level abstraction] is nothing but a scaffold to let us ascend to the true productive glory of [high-level abstraction]. It ignores the fact that it's not unheard of for platforms which started out no-code later REGRESS and introduce coding features such as APIs because as it turns out, no-code is intrinsically limited in a lot of very significant ways.
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.
> 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.
Perhaps because many believe that at minimum existing solutions don't successfully present a useful abstraction whereas people have been over promising for decades.
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.
> knowing how to code can help you optimize, automate, configure no-code solutions. The end result is always back to code.
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.
I share your view that the limits of no-code have been proven time and time again. Just ask the countless devs who have added custom code to WordPress or Squarespace sites.
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.
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"
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.
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.
Exactly this. I've never seen anyone set up Salesforce themselves, I'd even go so far as to suggest that Salesforce is wilfully so opaque purely to enable a commercial ecosystem of "certified" chancers and ne'er-do-wells who you have to call every time anything goes wrong.
I'm trying to think of a historical analog.. something that was always on the cusp of discovery and often hyped up but either never realized or only realized after many many delays. My partially educated mind thinks of two things -- alchemy and the philosopher's stone -- and flight.
My historical analogue is the telephone. Adoption and the number of switchboard operators was growing so fast that it was said that at that rate everyone would have to be an operator. Then direct-dialing became a thing that replaced switchboards. If software continues to eat the world, no-code/low-code a matter of when, not if.
these companies only need to move the needle a little bit to be wildly successful and usher a new set of internal applications that end-users can put together. Will it be children programming our internal enterprise apps? Maybe not. But there are a whole lot of folks who have the need and the desire to get some internal things built, and with these new tools (retool especially), it's not that hard. Calling it no-code does these tools a disservice. It's really block-oriented programming with a variety of complex blocks.
"No code" as a term sounds like "serverless": There's a blatant contradiction in the terminology, but if you point it out, people begin to snicker up their sleeves at the person who reads the words as if they were English.
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.
It is different this time. I am a really good coder but I am using no code tools as much as I can. I only use code for new projects if I absolutely must.
I'm a huge skeptic of no-code among my friends and colleagues.
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.
Let me add to this. My viewpoint is similar to yours, and I have some anecdotal info to support this devil's advocate.
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.
I’m skeptical of no-code solutions because every once in a while, a user does
something really problematic without knowing that they do — this isn’t a criticism
of the user; how can they be expected to understand, let’s say, security, if they
don’t have a rudimentary understand of cryptography or client/server models?
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.
The security example is a really interesting one because what you describe as a weakness of no-code viewed another way is a huge strength.
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.
I think your counterpoint is a good one — but I would argue that it has
the implicit assumption that such users will and can delegate to authority.
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?
The other problem with "no code" is that code is more than just text on the screen. It's a way of thinking. A very formal and precise way of thinking, which is what you need to have to be able to make a computer do what you want, and not do the things you don't want it to do.
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.
I totally agree, and look at the success that Salesforce.com has had. I have seen numerous examples where a reasonably tech savvy person on a sales or support team has been able to put together a totally acceptable workflow to manage their team without having to deal with any product managers, qa, developers, or IT personnel. It can save a tremendous amount in both development and opportunity costs.
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.
I have used excel a lot in my career, but I don't think I have ever created or even seen VBA in any spreadsheets. I think it probably varies a lot by domain, but if I were to guess I would probably say that far less than 1% of Excel spreadsheets use VBA. And a lot of spreadsheets that do are probably good candidates to be rewritten in some other tool.
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.
This mostly reads like marketing copy for the tools mentioned. In my experience, they're good - even great - at some things but also limited once your needs become more complex. And excel is not going away anytime soon.
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.
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.
It's almost as if journalism involves sifting through the PR pitches in your email inbox, and deciding which ones make good enough copy to hit your weekly/daily news story quota.
I have no idea what the name of this "gap" is. But, there are still countless workers trudging through mind-numbing tedium who could regain hours or days per week with a moderate application of no-code. I've helped several do just this.
I honestly thought this was by design. If not by design, I find it difficult to explain the fact that so many developers create CRUD apps as a means to earning a living and have done for decades.
Excel. Users are often already using it, but have absolutely no idea what they could do with advanced formulas or super minimal vb script. There are still people sanitizing 300k line spreadsheets (hunting spaces etc) by hand.
The gap between business demand for functionality which improves customer experience and productivity, and IT capability to provide said demand.
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.
Excel is still the biggest and most successful no-code tool. The real problem with no code, is the tools take a lot to learn well and it rarely transfers between roles at the same job.
I've seen end-user-built-app Excel code enough times to have a distaste. Maintenance is 2/3 of average software cost, and that [bleep] ain't maintainable. It's good for prototyping, but shouldn't remain in production for anything of importance.
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?
There was a post on here a few weeks ago that discussed code as the translation between the desire for a particular behavior from the person coding, and the machine instruction that needs to be executed. The comment section had a video of Guy Steele talking about growing computer languages, and was trying to make an argument for Computer Science Metanotation being one of them. [1]
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?
I find declarative and functional (D/F) code is often difficult to debug. It's generally easier to break imperative code into fractal-like steps, sub-steps, sub-sub-steps etc. D/F just can't be dissected fractal-ish like that nearly as easy. It's just a magic property of imperative code that's hard to replicate in other paradigms. It's why imperative still dominates after 50+ years of D/F attempts.
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).
On the other hand, imperative code sometimes makes it very difficult to compare what is happening with what you want to happen (problem specification).
And some of the most advanced Excel spreadsheets make use of Visual Basic to automate processes. Even with no code solutions, The most advanced users will want to automate and integrate, using code.
"Excel is still the biggest and most successful no-code tool"
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).
I don’t think most people have issues with programming because of syntax. It’s the lack of visual feedback that’s making things so difficult. Click on one of those cells and it’s color coding which cells make up that formula. Sum(everything in this box) is really easy to get where a foreach loop doing the exact same thing is more abstract.
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.
My company is pushing Python to mechanical engineers as an alternative to complex spreadsheets (with many sheets, complex formulas, and VBA). In practice it's already a massive pain to just get a working installation with the correct modules. Even if I make a working script, 95% of my colleagues can't run it. While Excel is just there, everywhere.
Ever seen Smartsheets? I know someone I'd have described as "nontechnical" several years ago who is practically building business-specific applications complete with frontend interfaces and backed by spreadsheets and almost all of this person's code is formulas, which are very "functional programming." This person has asked to be coached in writing a "real" programming language and it's a challenge to think of how to approach the problem based upon the person's existing skillset and understanding, which is entirely backwards (FP instead of imperative) from the usual student's!
Every no code solution has such scripts under the hood and most let you edit them. However, drag and highlight a row of cells and click sum, min, or max and your not editing code directly which is really all there is to the ‘no code’ concept. There are plenty of ways in these tools to select a bunch of data and click make a chart, but guess what that’s just another way to write some code.
Formulas (at least the kind people typically use) are not Turing complete, so they are not as powerful as what most people associate with the word "code".
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.
The No Code generation has been arriving and departing in the last 4 decades. No Code is code you don't control and that often turns out to be the main bottleneck.
"The stakeholders who desire applications are not willing to buy it at it's current price; either because they know that the application is not valuable or do not know the application is valuable."
Kind of, but the real way I see it is: “there is a whole wide swath of problems that would benefit from simple programming/automation, but they aren’t ROI positive to pay a professional programmer to do.” So the no/low code stuff can change that and lower the barrier to introduce automation and programmability to a big tranche of problem areas that aren’t served by ‘traditional’ development. I don’t see that as a bad thing.
There’s plenty of people who knows how to program. There are not as many who know how to program and have the patience, inclination, and social skills to figure out what the programs actually need to do.
Not surprised everyone on HN is hating on this. While there is merit to the argument that working on a high abstraction level is limiting and fragile there are two main points nerds ignore. 1) This is a great enabling tool for non tech folks who 99% of the time need a basic CRUD app. A whole new world is opened to them and they and the world is better for it. 2) The people who can get the most out of these tools, sadly, are the people on this thread. Its the folks who understand the low level well who can be super effective at the high level. If you understand CSS you can be a beast on Webflow and 10X your speed of development. But sadly this is unlikely to happen because these people sit on a high horse and look down on these tools and I suspect are a little insecure about how it can impact their value prop. So they never will take the leap and not realize the gains in productivity.
It would not be popular mostly; these are departmental apps in big corps built on top of subsets of the 1000s of tables. They can contain some business logic, but that can be ‘no code’ as well (flow chart kind of stuff); these systems are usually not the nicest to use, however much (!) nicer than the systems the tables originally belong to. So see it as a small team/person needs to enter certain type of data; they can learn to wade through miles of SAP menus, or someone clicks together a little crud (web) app that does exactly that and cannot do anything else. There are many 1000s of these cases, but they do not get popular as they stay inside the companies (departments) they are created in.
The big spreadsheets that everybody in a department use always evolve into a mess full of VBA.
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 the definition of code is missing; as a coder, all the graphical settings etc is also code and in that sense, there simply are no no-code solutions. But if we say configuration (with dropdowns and checkboxes and such) vs code is no-code then there are and I have seem these work in actual companies. We delivered quite a lot of these when I still did that type of thing; for instance, a lot of the internal (intranet) software for political parties and unions in my country we just generated with our own point/click code generator. It was simply crud with roles/permissions etc on top of their internal (ms-sql or access at the time) and many of these applications were used for many years internally. But I agree ; if you call a spade a spade, only 'low-code' exists and no-code shouldn't be used. That's fine.
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'.
I used to work for a company that marketed themselves as “low code” and we built custom business systems. The hard part was getting the data model right, which mostly involved understanding the customers business domain properly through long meetings. Then we could create a system that had 80-90% of necessary functionality literally within minutes just by clicking some buttons. All the simple CRUD, e.g., Create Order, Edit Customer, List all deliveries within the
last six weeks, etc., were then ready. After that there’s a lot left in the budget for writing the code for the company specific business logic and often some integrations.
I agree with your point but I have to disagree on Webflow. There's no way that Webflow helps me in any way as a professional developer, other than to be able to empower my clients to do lightweight work I don't want to do. For my part, I'm much faster on a text-editor than on opening and closing side panels and selecting the specific padding field to set the value.
Salesforce pushes this, first with Process Builder, now with Flow. I'm doing a small project for a charity using Flow, as a programmer my main frustration is all the pointing and clicking instead of just typing into an editor, but I can see the appeal to non-programmers.
I've been a programmer for 36 years, and I'm half "this has been worked on for decades and it hasn't taken off" and "this has been worked on for decades, maybe someone will get it right some day".
I always say: We ( Software developers ) are ALREADY working as high a level as possible, and invest aggressively when we can see we can cut out work that does not add business value. Compare local data centers, to AWS, to Kubernetes.
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.
I agree - but I also think a perfect no-code solution will meet initial resistance. Just like binary to assembly did, and assembly to C did, and C to python did, etc. etc.
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.
"no code" is just "somebody else's code" with a GUI. We're more than just a generation away from being able to generate meaningful application outside of the original toolings scope without coding it at some point in the pipeline
Always keeping a sharp eye out for denial, I believe this seems completely obvious to people that actually write code and/or build software for a living.
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.
While somewhat true, my experiance with these types of products see this following reoccuring pattern
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
This pattern is not even limited to no-code. You could just substitute "No Code" for mongodb (or coffeescript, or AngularJS, or pretty much any of the short-lived tech that we used or watched people use over the last several decades). Some new hotness catches on and some doesn't. It's really too early to tell for No-Code, but proclaiming its arrival is also premature. Not that the media/marketing machine has any problem beating the drums about unproven tech. But yeah, I feel like I've seen this cycle dozens of times in the last decade of auditing failed software projects that someone is looking to salvage.
No Code is not new, it has been around for decades and decades.
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
Sounds like the marketing was correct: they were able to create solutions without hiring programmers to do it.
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.
Technically yes, but most of the time it wholly inefficient, not very secure, many times not even accurate or has very little in way of data validation (like 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.....
> 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?
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.
I am glad to see the development world using the same statements from the sysadmin world were we have "The cloud is just someone else's server that you do not control"
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.
It's the problem of expressing complex logic and calculations to meet your ends
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.
Love when "No code" solutions come up every so many years just to simply die off.. I remember teaching myself VB6 in sixth grade and after realizing the reason "No Code" solutions are misleading are 1. There isn't really such a thing and 2. The power of computers comes precisely from the ability to.. code them at a meaningful level of abstraction. Don't get me wrong, "No code" may have a purpose, but I see that purpose being more in line with mock-ups and concept tests; not eliminating code.
Indeed! Look around at any mature software and you start to notice that it can be worked with at multiple levels. Perhaps it’s a bunch of built-in features to most users, with a smaller group of users tailoring things with “add ons” and “plug-ins” and “apps”, and finally an even smaller group who writes their own extensions or integrates another application with the API.
“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.
Low code is very useful in creating basic crud apps and workflows. Hacker news is full of experts who know everything, but our teams are not all posting here. If you adopt a good low code framework that you understand inside and out, then you can achieve a lot of output with an inexperienced team.
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.
Taking a step back, I personally question why being able to code should be considered important?
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.
> Taking a step back, I personally question why being able to code should be considered important?
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.)
I'm old enough to remember "CASE tools" from the 80s and 90s. In the 2000s, we were told that architects would design a system in UML, and thr machine would generate the code for it from the UML.
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.
A few weeks back I was sitting at an outdoor table in Florence, Oregon, not exactly a high-tech hotspot. At the next table two ladies that I arrogantly categorized as type "nail salon employee" were chatting about this and that but pretty soon their conversation turned to pivot table mastery, and that's where they got really quite excited.
So yes, I think no-code has been with us for a long time and will continue in various forms.
It feels like it wasn't written by anyone who knows much about the actual nature of programming computers.
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.
I was going to post this same quote as the only bit of substance from the article.
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...
I think that no-code enables non-programmer to produce more workable prototypes without any help from programmer. This speeds up the iteration. If a prototype is proven to be useful, then it can be given to professional programmers to hash out the details and build a robust version.
Actually -- programmers' opinions on no-code solutions are irrelevant. The non-programmers' ones are more important.
This is exactly how we use no-code at my startup. It allows non-programmers to iterate with the product manager on a solution's design before it makes it to the dev team's plate.
The problem is that it's never how those solutions are sold, and rarely how they are bought.
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.
I am neither a skeptic nor a believer. But I want to share this story that happened. In 2005 when I started my first job, our first project was building a case ticketing system. It took us 6 developers, 2 testers and 1 PM to deliver the first iteration of the project after 3 months. Those were the waterfall days.
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.
As someone who has been programming professionally since the 80s, I have seen the idea of 'no code' system development being hyped every few years.
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 got into programming from a no-code tool as a kid: Stagecraft. An education/gamedev tool aimed at kids and looking back it was really neat. You had a grid and gave rules to objects on the grid by pattern-matching the surrounding grid cells. Right arrow key makes the player move right, if the cell to the right is empty. If there's a block already to the right but an empty square beyond it, move the player and the block. You just laid out a "start" state and a "final" state and whenever the start state was met, it would replace with the end state. A ton of basic (and not-so-basic) games and fun things could be made really easily with this. More advanced users could do something closer to traditional programming by giving objects variables and manipulating those, making "folders" of rules that controlled which ones could run, etc. I made a fairly full-fledged short JRPG in it, and other people's projects were even better. Frankly, I finished more gamedev projects playing around with that than I ever did after learning to code!
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?
Off the top of my head, PuzzleScript[0] sounds similar. There are some really good games written in it too. Although since the rules are written in text and pretty opaque, one wonders if a GUI tool to write PuzzleScript rules might make it more accessible.
The problem with every no-code solution I've seen is that it is dependent on a sufficiently detailed specification with defined handling of edge cases and errors and exceptions... and at that point your specification starts to look an awful lot like code.
I think a lot of people who've commented clearly feel threatened by the concept of no-code and have default knee-jerk reaction anytime it's mentioned (how many comments are about the article vs the concept). Maybe there's also a theme of being troubled by the notion that the masses might cause a mess with these tools and shouldn't be trusted.
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".
> - What does FOSS look like with no-code - do we need some serious FOSS tools in this space?
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.
I don't read the skepticism as "I don't like this trend," but rather "this trend is not new." And I agree with you that the relationship that people have with computers is fascinating. But as others have pointed out when you tell people "You can do all this stuff without coding," but when what you're really doing is making it easier for people to code while calling it "not code," you're forcing them to reinvent this history of computing, but now they don't have the language to connect what they're doing to what the industry has been doing since 1959.
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.
This has been there for the past 40 years at least; there were dbase tools, case tools, rad tools, 4gl etc. One reason I know of from experience from no/low code use by companies and why they gave it up over the past 25 years I have been working professionally in software dev is not that they were too inflexible (they were but that was not the issue; companies grew around the processes, not processes around companies); it was because all of them were proprietary and they got sold and killed off. There are hardly any open source ones or stable ones (as in price/support/upkeep etc) (which you need if you want to run your corps erp etc in top for decades), especially in the past. Now it is even worse; for the 80/90s ones, when you had it locally installed, it would still work now, but with the cloud, it is just waiting for the company to shut the doors or getting sold and gone is your company infrastructure.
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 guess I'm a member of this "No-Code" generation?
My friends and I were playing Minecraft when we were 12 years old, and we're entering the workforce now.
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.
"No Code" needs to embrace code. They are just tools and/or higher abstractions. Embrace the fact that at one point you need to go down the abstraction layers and enable the users to do this, and do it well.
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.
Spreadsheets also brought in the "no-code" generation. Letting financial analysts do in-depth analysis without writing code or even understanding code at all. And it shows, logic errors abound in complicated spreadsheets and they often ignore corner cases.
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.
I think "no code" is a misguided project, a rebel without cause.
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.
>Of course, no-code tools often require code, or at least, the sort of deductive logic that is intrinsic to coding. You have to know how to design a pivot table, or understand what machine learning capability is and what it might be useful for. You have to think in terms of data, and about inputs, transformations and outputs.
Is in this context "no-code" synonymous with "low-code"? Or are there differences?
A great 2006 essay on the other side of this coin is "Why Johnny Can't Code" by David Brin [1]. From the lead paragraph: "BASIC used to be on every computer a child touched -- but today there's no easy way for kids to get hooked on programming."
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.
Article TLDR: Workers over ~30 love Excel. Younger workers are willing to try new webapps that are like Excel, but with squircles and in the cloud.
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've watched non-programmers get into the use of software tools for their jobs. From what I can tell, the main factor driving success is making the tools accessible, to the point where they don't have to be requested. This lowers the emotional barrier to entry. Folks don't have to justify it, and can use it for tasks that might even seem too trivial to discuss.
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.
> There has been a proliferation of guides and online communities to teach kids how to build their own games and plugins for these platforms (Lua has never been so popular).
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.
When I was at university, one of our professors was really big on Executable UML (exUML)[1], where by using a subset of UML to model the problem, code would be automatically generated.
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.
No, I can't imagine someone trying to sell the idea that anyone can design and build a bridge.
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.
Software has an increasingly large impact on people's lives - including their safety. Consider [ransom attacks on hospitals](https://arstechnica.com/information-technology/2019/10/hamst...) as just one example. Even ignoring bad actors, people have made billion-dollar mistakes in Excel (there was even a recent article about how contact-tracing data being handled in Excel was lost. That can lead to real deaths, too).
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.
The problem is, in the software world that log across a creek is added to and added to and suddenly its 10 logs duct taped together crossing an ocean for trucks to drive on.
The best I have been able to achieve is a solution which initially requires fully-custom code, and then evolves into something where the most maintenance-heavy parts are data-driven and managed via a web interface by the business.
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.
Depends on what you’re trying to build. It’s pretty useful for generic CRUD apps, which is 90% of business apps when you strip out the marketing speak and design...
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.
What will happen is, the no-code generation will rediscover that Turing-complete machines are great, and code is the easiest form to express arbitrary algorithms.
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...
I think that no-code and low-code a real movements, and are going to be popular. But the terms are too broad to have a productive discussion about what their power really is.
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.
Our software is slow enough and the people who make it already removed enough from what's actually happening without espousing yet another level of abstraction which will make all of this worse. The idea we need so much software it's unrealistic to expect enough people to actually learn to write it we need visual tools to allow people without expertise to create it instead?
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.
Being able to code is an essential part of complete integration with the next stage of development for the human mind: attaching a computer to your brain.
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.
I've worked on a "no code" platform before (HP-OO).
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.
As a JavaScript developer looking at past JavaScript jobs clearly No Code is a very real thing, but it only means not writing code yourself.
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.
As a counterpoint to this I hate it when data is treated like code. Need to create a new cost center? Raise a change request. Get an IP addressed added to a list in a firewall? CR. Bureaucracies thrive on this stuff.
Even worse when master data is hardcoded into applications. It still happens especially when a vendor can make an ongoing revenue stream from it.
I always laugh when the "No-Code" tools I'm forced/required to use have a section/editor/process for writing code or using external code. Maybe I haven't had much experience with the "No-Code" tools, but it does seem like a sham.
I think the proper term for these products should be "Low(er)-Code".
Would be a catastrophe because I haven't seen a no-code system that can successfully reproduce and elevate itself into a fungible foundation on which significant new technologies can be build --- like for example CPU microcode breathes life into the hardware and makes it execute all that assembly code, a simple concept which has produced trillions and trillions of economic value and is not just done yet. The leverage from the combination of engineering and the sciences we have in building computation and presentation systems has IMO not be used fully by a long way. Maybe we will go faster until we can elevate technology one level higher, but I don't see it coming just yet, where these so-called "no code platforms" could become the new microcode. This is complimentary to my observation that a huge mass of people have not yet overcome and probably will never overcome the stage of technology consumption as apposed to creation in their lifetimes.
And can it really be called no-code if new technology could be encoded reliably at scale in that one higher level of technology?
No-code is useful for building enough of the app to figure out whether there's a market for it in the first place. It's not fair to compare it to building the actual product with an actual team -- a more realistic alternative would be outsourcing the prototype/beta to some random team.
Code is the closest to a bike for a mind, we're still not there with languages design etc. but I don't think there will ever be a no-code generation, maybe for building some or even most software, but we already have wordpress.
No code generation is a bit like building a living room with ikea parts. You can only do so much with that. As opposed to hiring a pro carpenter and crafting pieces or in building it to walls etc.
To the people that say that true No-Code will never happen:
It has always been possible to create software without writing code, it's just that historically it has been expensive.
Instead of getting away from code, why not try to make code simpler? Let the businesspeople write scripts in BASIC, and keep them away from the messy Python and JavaScript.
After spending few days dealing with protobufers, authentication libraries and cookies. I disagree that the non code movement is even an option. Not for us backend engineers.
a bunch of fools running around in a company, creating shitty tools with wizards. we've seen it all before, and it will be the scientists and engineers who will have to clean it up and put out the fires, after they are long gone.
