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.
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.
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.
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.
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.
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 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.
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.
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.
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?
> 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.
> 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.
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.
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:
> 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.
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
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 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.
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.
>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.
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.
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.
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.
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.
> 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 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.
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.
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:
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".
> 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.
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.
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.
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.
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.
"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.
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.
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 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.
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.
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.
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.
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!
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.
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).
"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.
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.
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.
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.
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.
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.
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.
>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?
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.
"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
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.
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
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"
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.
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.
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.
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 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.
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".
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.
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.
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.
278 comments
[ 2.8 ms ] story [ 279 ms ] thread- https://outline.com/XZYvKa
- https://web.archive.org/web/20201026181132/https://techcrunc... (seems to successfully load then fails after a few seconds)
If it were easier to use a visual interface than code, then devs would figure it out and we'd all start doing it.
The "no code" revolution is probably more accurately the Microsoft Access replacement for our generation. Sleeker, cooler, more professional. But like Access, you have to replace it with real software when it starts getting complex.
1. Hide parts of the program (e.g. hidden cells on a spreadsheet; attributes of nodes in a visual programming environment)
2. Switch to text for the higher information density.
I think the burden of #1 quickly surpasses the burden of learning to work with #2.
Once it grows to any reasonable level of complexity it becomes more of a hindrance than a help.
Access was actually a great tool for allowing semi-technical people make quick apps, but almost every shop I've been in has needed to convert Access to grown-up software.
But the real fix is to simplify web stacks for smaller projects. We don't need Rube Goldberg routing engines/URL-prettifiers, ORM organics, Bootcrap organics (UI), Async/Await bloat, etc. We want our app track some local e-paper-work, not be Netflix. A Learjet will do, don't gear it for Jumbo Jets. Time for a KISS web stack to become a de-facto standard.
> But the real fix is to simplify web stacks for smaller projects
We've already done that. RoR, Django, ASP.NET MVC, etc. etc. It's super easy to get something working out of the box. But at some point, you still need to understand what your database is doing and optimize for it. Some level of complexity is inescapable.
And you could probably argue that as back-end has gotten simpler, complexity has just expanded to fill the void. Now we expect fancy JS interfaces on top of them, too. And phone apps.
I have no doubt all of the things I mentioned will get simpler, but I can't foresee anything that will make software devs irrelevant in on the immediate horizon. I suppose at some point BAs/PMs (people who gather requirements and draw wireframes) will be able to write code, and we'll start to compete more with skilled BAs. But that's still not the end of the entire profession. Gathering requirements is still hard.
Unless carefully planned out to be modular, you end up with a giant pile of technical debt that is
(a) pretty opaque in its error messages
(b) has poor error handling systems
(c) is brittle in its ability to handle changing file formats or business needs
(d) can only be tested end-to-end, with no space for small unit tests to act as guide rails
(e) makes it very easy to hide business logic all throughout the ETL process
Upside to this tool: It seems to be handling a lot of simple parallelization speedups behind the scenes for you, and catches most type-conversion errors.
Which, inevitably, starts to include things like macros, include files, looping constructs and eventually bits of perl or TCL.
Code is data, but the converse of that is that a sufficiently complex configuration file is just a piece of executable code.
I'd stay as far away from all of these tools as possible.
if you stop there though, you're missing out on the business opportunity. you can dunk on things on HN all you want but if these businesses are right and the demand for software has massively outstripped the availability of engineers then you're gonna make money in no code tools.
However, I can personally vouch for 2 champions in no code.
The big behemoth is Salesforce.com. The incipient champion is Bubble.io.
Cloud infrastructure ,API consumption and mobile usage are the paradigm shifting variables that were not present 10y ago.
The fact that cloud is getting (traditional) corporate green lights and that every employee is using software to do regular 9-5 work indicates that software creation is demanded at exponential scale.
> The end result is always back to code.
Sure. The same way the end result is always back to electrons flowing around. The abstraction layer that no code provides NOT TO YOU but to Michel the accountant is very relevant and will (10y from now) produce a new paradigm shift, as Salesforce pioneered the "no software" [1] SaaS 20y ago.
And the paradigm shift is not "0 code". It's "0 code to get thing rolling; and developing programming skills visually to later on have a more productive talk with coders"
[1] https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2F...
My experience has been different. When I worked for a travel company, it joined Salesforce. Shortly thereafter it had to hire a full-time Apex programmer to make Salesforce do all the things the Salesforce salespeople promised it would do without a programmer.
My experience with Salesforce.com is that it's only a no-code champion if your needs are so simple that you might as well not be using Salesforce.com - i.e., a simple CRM with a few plugins. The real strength of Salesforce.com is that you can use code to customize it and get the real utility you're paying for out of it.
It's "no software" in the sense that all SaaS systems are "no software". Realistically, Salesforce.com is very much enterprise software of the sort that requires real customization in the form of real code to implement the important business requirements.
However, I do think that you still need a dev mindset, with dev experience, to use it well. Principles like DRY, loose coupling, code organisation, consistent and informative naming, concise logic, etc adhere just as well. Those hard to transfer skills you build up over time. Although a junior may get things working very quickly, keeping things maintainable and extendable is just as hard, or even harder.
So like you said; I believe you still need to be a dev to deliver with these systems; 'end user programming' is not close outside Excel. People who know nothing about programming will generally make complete monsters with these systems, even after training (I saw it a lot with Outsystems when I click open a business flow).
Real enduser development revolutions we won't see this low-code wave, maybe the next somewhere around 2030?
Right. And that probably applies to many, if not all frameworks, by virtue (vice?) of their design. I don't know Mendix, but I've worked on programming frameworks like Rails, Flask and others, including some in-house company proprietary ones. You sometimes have to work around their limitations with custom code, awkwardly, even Rube Goldberg style at times.
And there can be instances or even categories of apps that can't be done using the framework at all.
The framework giveth and the framework taketh away.
Macromedia Dreamweaver was the big inflection point because the results could be deployed on the web, for anyone to see, regardless of what box they were running.
The problem I have is that it devalues the worth of actual programmers by making everyone think what we do is easy. It isn't. I see this all the time with do-gooder charities on TV "We're teaching kids to code, and next week they'll all be billionaires!" The present themselves as if a week in a makeshift classroom is all it takes to compile and deploy a Swift app.
I've thought about this since the early part of this year when a middle manager in my company's Communications department dismissively told me that she could do my job because, "I know code." What does that even mean?
Sure, that's not true. But they will gain a better understanding of how to organize and process information. This understanding will help them even if they don't end up in a software engineering career.
It's a signal to look for a better position somewhere else.
Sounds like you work at a company that considers tech to be "the easy part" or a cost center...
Frustrating. And I know how to read and write, but it doesn’t mean I could write a decent novel.
What a lot of people don’t understand about software development is that for any non-trivial project, “coding” is the easy part, the real challenge is in the managing of complexity.
Even if it were, that'd still be a far cry from becoming a billionaire from nil in a week.
Throughout my career in computing I have heard people claim that the solution to the software problem is automatic programming. All that one has to do is write the specifications for the software, and the computer will find a program [...]
The oldest paper known to me that discusses automatic programming was written in the 1940s by Saul Gorn when he was working at the Aberdeen Proving Ground. This paper, entitled “Is Automatic Programming Feasible?” was classified for a while. It answered the question positively.
At that time, programs were fed into computers on paper tapes. The programmer worked the punch directly and actually looked at the holes in the tape. I have seen programmers “patch” programs by literally patching the paper tape.
The automatic programming system considered by Gorn in that paper was an assembler in today’s terminology. All that one would have to do with his automatic programming system would be to write a code such as CLA, and the computer would automatically punch the proper holes in the tape. In this way, the programmer’s task would be performed automatically by the computer.
In later years the phrase was used to refer to program generation from languages such as IT, FORTRAN, and ALGOL. In each case, the programmer entered a specification of what he wanted, and the computer produced the program in the language of the machine. In short, automatic programming always has been a euphemism for programming with a higher-level language than was then available to the programmer. Research in automatic programming is simply research in the implementation of higher-level programming languages.
http://web.stanford.edu/class/cs99r/readings/parnas1.pdf
And it seems to me that progress is going in the opposite direction than "they" want. Every time you move up the abstraction stack, you're surrendering some decision-making to the lower levels. If the underlying technologies guess right every time, you have no need to understand what they're doing. The first time they guess wrong, you have to spend a lot of time understanding not only how the lower layers work, and not only why they did the "wrong" thing in this one instance, but how to fiddle correctly with the layer you're operating at to get the lower layers to behave properly. You can work quickly with the high-level abstractions only as long as you understand the lower levels reasonably well.
Optimal machine learning requires a good understanding of memory cache hierarchies, parallel instructions and complexity theory - not to mention the statistics and calculus that it's formed on. And "optimal" isn't some trivial "save a few seconds" but often "return an answer within the lifetime of the universe".
https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
If you're fine with lower performance (which is reasonable for a lot of application cases, so I almost entirely agree with you), you certainly don't have to deal with this.
https://bootstrappable.org/
SQL in a nutshell.
e.g. ad-hoc exceptions -> errors as plain values, but with "railway-oriented programming" techniques that make them as easy to work with as exceptions
e.g. runtime-managed garbage collection -> rust-style borrow checker ad-hoc in the compiler -> haskell/idris-style linearity in the type system
e.g. "magic" green-threading -> explicit-but-easy async/await
e.g. behind-the-scenes MVCC in databases -> explicit event sourcing
...and we call that specification a computer program.
Just imagine a world when we have these programming languages to help us encode the specifications for our software. Wild! :)
Also "anyway" a specification is always incomplete. It's part of the programmers' job to fill the gaps with something sensible, and when they have no idea what to do, to point out that some corner case was overlooked.
This is where programmers sometimes start to feel like Lieutenant Columbo: at first everyone is nice, but people become more and more irritated as the pesky cop asks more and more embarrassing questions.
You just summed up about 20% of my job
With the years and postmortems gone by it has grown half-assed attempts at version control, code review, unit testing, deployment pipelines, etc. Now it’s very obviously just a shitty, hobbled software development environment. It’s used primarily because the team that owns it is aggressive about blocking design reviews for “duplication of effort” if you propose to use normal software development tools anywhere near its domain.
Let's just say that it was a more brutal age, and we were more accustomed to such horrors. :)
This is absolutely one of my biggest pain-points with "no-code" solutions. Even trying to track revisions to something relatively simple like a word document over time is a big pain compared to tracking revisions to source code or a configuration file. Trying to get a grip on how people are fiddling with a no-code product from the audit logs is incredibly difficult, never mind trying to track down a change from 1 year ago. Often changes won't appear on audit logs at all or they won't be explained in enough detail and the format of the logs will have little resemblance to how things are actually configured. You can use some no-code solution to modify a SQL query under the hood and the audit log will just say "THIS USER CHANGED THIS QUERY" and that's all the detail you get! It's frequently difficult to explain to your peers how you're going to change a system without showing them a bunch of screenshots and going "Well I'm going to tick this box and move the green rectangle over here and link it to the orange oval". Rolling back changes can often be impossible without rolling back EVERY change between now and when the first incorrect change was made.
I use code, and these problems just don't happen! It's only when people are using some wonderful "user-friendly" solution that things get so jacked up.
Especially when it is anything involving finances, even tangentially.
Making it easy for non-engineers to change business rules on the fly without a code deploy sounds nice in theory, until you think about it for a few more minutes.
The other thing is there may be no way for me to, say, get a list of all the forms associated with a certain table and the fields they contain in some programmatic way (without browser automation, which is something I use not infrequently with a no-code system) and APIs that are almost complete but not quite.
So then what do we actually mean by "no-code" these days? I think "no-code", today, has the unspoken implication of "graphical". Okay, so why are "graphical coding" systems (languages?) mostly unsuccessful? There are some clear exceptions like Unreal Engine's Blueprints and certain WYSIWYG web editors like Squarespace, but the great majority of programming is still done in what comes down to, at the end of the day, text files. There may be more and more elaborate editors built atop these text files, but the "bones" of the code is always available, and never too far out of reach.
My pet theory is that this last bit is the differentiator. In a totally graphical programming environment, the programmer never has to be exposed to the underlying format directly. This perhaps encourages proprietary stacks, where the GUI is all that's known and the substance of the "code" itself may never even be made available to those who seek it out.
Maybe this arrangement keeps these "languages" siloed, and therefore keeps them from gaining real traction. It's hard for a thriving ecosystem to evolve around a closed format. Competing tools, editors, compilers, open transfer via regular files, translation, etc are all stifled. You end up totally dependent on one company for all of your needs. For some projects the value-proposition still works out; for most it doesn't.
If so, here's my proposal: instead of focusing on all-in-one no-code environments, focus on creating graphical tooling for existing languages. Or even, creating new (text-based!) programming languages that are designed from the get-go with advanced (graphical?) tooling in mind, while still having that real, open, core source-of-truth underneath it.
We've seen echoes of this already: Rust's features would make it nearly unusable without its (excellent) user-friendly tooling. Design apps like Sketch can output React source code. Pure-functional languages like Clojure really thrive with an editor that has inline-eval. I think if "no-code" is ever going to catch on for real, it needs to be less afraid of code.
On the other hand: is the value-add really the graphical interface, or is it the "height" of the language?
In the latter case, maybe it's more important that we explore even-higher-level languages, and set aside the graphical part as a distraction. Or, maybe we combine the two goals: create higher-level-languages that also lend themselves to graphical UIs, but are still grounded in formalized text underneath.
Every time we go to some other way of describing a document we lose all that text editing infrastructure, which is such a huge setback that no alternate solution has yet hit a widespread critical mass, only specific niches in specific domains.
Which doesn't make text good, it makes it worse-is-better!
As I see it, the probable way forward would not be in language design, but in formats and editors. Breaking through the dependency will be a slow process.
These kinds of full-featured IDEs tend to lead to knowledge gaps, in my experience. I'm not really a Java programmer, but I've helped more than one Java developer (usually junior ones, to be fair) with build issues. This is because when I use Java, I write it using vim and either `javac`and a Makefile, or else the command line interface of a Java build tool (ant, maven, gradle, etc). That has given me a good understanding of the Java build process, that I've found many users of Eclipse or IntelliJ do not have.
As such, I think your proposal may have legs, because it could allow less technical users access to the programming environment, while retaining a text-based interface for more expert users.
People on HN seem to think programming languages should be designed for a text editor as the primary way of editing, and I think that's a mistake that holds programming culture back (and is why we see these "graphical" languages go too far in the other direction, because the only way to get people to take a proper language editor seriously is to make a language that's impossible to edit in a text editor). Having a canonical plain text representation is important. Having good diff/merge is important. Editor customizability is important. But if you embrace the IDE and build an IDE-first language, without abandoning those parts, you can get a much better editing experience.
Where visual tools help is in UI building and layouts. That's exactly what I built Slashdiv for: create a UI and output React code.
Inductive progamming is very much a branch of machine learning and that's the reason most haven't heard of it (i.e. it's machine learning that is not deep learning). The main approaches are Inductive Functional Programming (IFP) and Inductive Logic Programming (ILP, which I study for my PhD). IFP systems learn programs in functional programming languages, like Haskell, and ILP systems learn progarms in logic programming languages like Prolog. And that is why neither is used in industry.
That is to say, both approaches work just fine - but they're not going to be adopted anytime soon (if I may be a bit of a pessimist) because most programmers lack the background to understand them and they can't be replaced by a large dataset.
A quick introduction to Inductive Programming is on the wikipedia articles:
https://en.wikipedia.org/wiki/Inductive_programming
I suggest to follow the links to the article's sources and to search for IFP and ILP systems separately. Two prominent representatives are Magic Haskeller (IFP) and Aleph (ILP):
http://nautilus.cs.miyazaki-u.ac.jp/~skata/MagicHaskeller.ht...
https://www.cs.ox.ac.uk/activities/programinduction/Aleph/al...
More can be found on the inductive-programming.org website:
https://www.inductive-programming.org/ip-systems.html
https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.590...
I suspect that "code" will just keep on getting higher and higher level.
This means that humans will be able to express themselves and have an outlet to automate this.
Maybe the real question will be at what point will people say the specification "is not code".
and what will it be? English? Mathematical notation? doxygen? A notebook? Latin?
Also, this must be where “patching” code came from. Earlier in my career, I never understood the reference when they said they released a new patch.
There's some value in having abstractions being more visible. I don't think that strictly speaking something like Node-Red qualifies as 'no code'. But it made me understand that, given that so much of development nowadays consists of 'gluing' code together, there's potential for such tools. Even if some of the boxes happen to allow you to write code.
At some point, all you care about is inputs and outputs. We are missing a better way to do these things.
Yes, and: you understate the downside.
While No Code (nee Visual Programming, CASE Tools, whatever) may handle 90% of the use cases, the remaining 10% become dramatically harder. Because now you're fighting the framework. Which is an angry 800lb gorilla sitting between you and your work.
Faced with the same challenge, I went in the opposite direction.
Typical strategy of BizTalk, Talend, SeeBeyond, many many others is some kind of patch cord flow chart style programming, with Access VBA style event hooks for script extensions.
I created a stupid simple framework and API optimized for our domain (medical records). Think serverless computing and awesome DOMs for HL7 and adjacent data formats.
Onboarding for our SeeBeyond-based projects was 3 to 6 months. Using my stack was 1 to 2 weeks. (One of the weeks was teaching healthcare domain experts some Java, Eclipse IDE, and version control.)
Further, in my experience, none of these No Code solutions have useful exception handling, logging, fault/error recovery, and other misc devops type stuff. So are an absolute nightmare to support in production.
That is a great point. Whenever I've tried a no-code solution I end up dropping it and going back to code. Some insurmountable roadblock appears that if I had started with code I won't be in this mess.
I've also made the mistake of recommending no-code solutions to my business - trying to reach for the golden ring of self-sufficiency. Seems great at first and then you end up trying to "debug" a no-code framework that you have little of no insight into.
This is true for all of us - it's just that the level of abstraction each of us is comfortable with is different.
Not sure why people don't understand the value of raising the level of abstraction for more people to participate in software creation. It seems like an obviously valuable and worthwhile objective, even if it does look different to the way I build software.
When I use a "no-code" product it's usually not more than a few months before I start using it's API and adding small bits of code here and there to do things not natively supported by the product. You would have to have a puritanical fervor and a lack of sense to want to eliminate all semblance of code from a product made out of code.
It's almost as if after seeing you could add images to Microsoft word documents you saw an article coming out about how Written English was going to be replaced by Hieroglyphics and soon we could communicate with nothing but Emoji and talking about how the next generation won't be literate. The sentiment in this thread is mostly a reaction to irritating and implausible clickbait.
a standard newspaper article then ? https://cheezburger.com/6860549/14-hysterical-headlines-that...
actually I'm pretty sure that there were a ton of articles in the vein of what you're saying circa 2000 when emojis rised in popularity
At maximum that a gui represents a bad abstraction that can't be used by non coders effectively to produce code save for when actual code exists that sufficiently specifies the program. For example a gui builder can help you build your web based store but is insufficient to build the tool that builds the store.
All I can think of is how Windows used to be administered almost entirely through the GUI but eventually PowerShell was invented and its popularity grows year over year. How is that even possible when the "no-code" way to administer Windows must clearly be better and more accessible and user friendly and coding is old fashioned and borderline obsolete? Every company with their heads on straight would fire anybody who uses PowerShell and replace all their admins with unskilled high school graduates. There is not enough room in town for both no-code and code solutions, so I expect Microsoft to remove PowerShell in it's next update.
There's definitely a place for a la carte pricing for server-based software ("serverless" which of course includes servers, you silly person) and there's a place for very high-level code in domain-specific languages to solve immediate business problems ("no code" which of course includes writing code, you silly person) so just learn the shibboleth and try to avoid sounding silly.
/s
Yes. Also CASE tools, those with a code generation feature.
https://en.m.wikipedia.org/wiki/Computer-aided_software_engi...
Pun unintended :)
For instance, I've done some work with node-based editors like Node Red and Max MXP, and while they are nice for simple cases, invariably they reach a tipping point where you end up with a giant graph which is far less navigable and comprehensible than a set of source files.
There's no escaping complexity.
Epigram 93, Alan Perlis
http://www.cs.yale.edu/homes/perlis-alan/quotes.html
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.
As others have pointed out, the desire to build things without coding knowledge has always been there, and there will always be a place for it. An ice cream shoppe should probably use Squarespace instead of hiring a coder for thousands more.
However, until we have sufficient AI, executives will always request features that can't be achieved with whatever no-code building blocks are available. Contrary to others, I do think there will come a day where the human computer programmer is completely obsolete, but we are definitely not there yet.
>Today’s new workers know how to dive into systems, pipe different programs together using no-code platforms
I was thinking, not the ones I know. Maybe they are out there somewhere? The only people I know who can dive into systems and pipe programs together are people with programing experience.
There are many situations where a non-engineer with some programming experience can very quickly string together a few "no-code" tools to build a workflow/tool that scratches 90-100% of their itch.
"Some programming experience" meaning: they understand basic IFTTT logic and can configure API access using a tutorial.
The piping of programs is now done by sync integrations built into the tools, third-party tools like Zapier, or other services that can map and standardize API output.
I know unemployed programmers so it's no shortage of supply.
Sounds like we will all soon be writing custom code for NoCode products, which is basically where we are anyway.
Yep, people sure write a lot of code in Excel.
(Well, what do you think formulas are?)
As far as general "low code" or "no code", I've seen that promise for many decades. They keep reinventing failed ideas under new names. Clickable wizards, rule lists, and drag-able flow-charts can only take you so far. The devil is in the details, and these don't handle details well. And they are hard to factor.
Your Uncle Bob may be able remodel your house for cheap, but what do you do when rain leaks in and the lights stop working? Or worse, catch on fire?
Remember: Total Cost of Ownership.
He started of the talk describing Regex, and how it came to be, and basically showed how that functions have been/could be formally described in papers the same way that Regex is used.
In the same way regex formalized the notation for string parsing, so too will the next language regular function expression formalize. Perhaps computer meta notation is the source of true no-code solutions? Perhaps instead of reading articles about "The Unreasonable Effectiveness of Regex," in the future, we'll be reading about "The Unreasonable Effectiveness of Computer Science Metanotation."
I also understand that what no-code solutions we are typically talking about is a user interface that is graphical, drag-and drop. But who is to say we don't create a tool that does that with CSM?
[1]: https://www.youtube.com/watch?v=qNPlDnX6Mio&ab_channel=Erlan...
Someone once said that D/F makes it easier to express what you intend, but imperative makes it easier to figure out what's actually happening. One improves writing, the other improves reading (or at least debugging).
So, great lock-in capabilities? I can see why money is pouring into these tools.
What's interesting is that many users build quite complex formulas and spreadsheets, yet Excel's formula and VBA syntax is (in my opinion) harder to learn than other programming languages. For example, I'd argue a language like Ruby is simpler in many aspects than using VBA or building complex formulas.
Like Microsoft, Google Sheets also has quite an ugly, clumsy feel to its syntax.
The terrible programmable usability of these products (Excel and Sheets) could only have come from the mind of a developer (harsh I know, but true).
People just kind of default to {do some magic} on [various things] -> (Some result that looks about like I was expecting).
What’s really interesting is Spreadsheets tend to have bugs where the result is incorrect but reasonably close to reality. Aka 38 vs 35 not Null Pointer Exception, this makes them in many ways seductively dangerous in a this looks close therefore it must be easy to fix way.
And eventually require VBScript if you want to really automate anything anyway.
Edit: I know there are lots of people on the Internet saying you can simulate Turing machines in excel, but they're usually manually unrolling the computation in successive rows, which doesn't really count. For one thing, this style of simulation doesn't even allow one to make an infinite loop, let alone a more complex self-contained loop.
That and Microsoft's insane theory that about 50% of user input is dates.
=RIGHT(A5, SEARCH("FOO",A5))="BAR"
However, the ending is completely inexplicable:
> The No-Code Generation has the potential to finally fill that missing productivity gap in the global economy, making our lives better, while saving time for everyone.
What gap is this referring to? The gap between productivity and compensation? How does increasing productivity "fill" it? It's also pretty funny to define a generation by the productivity software that's available.
Interested in hearing more.
Which tools have you evangelized?
When computers were still a fairly new phenomenon, it was assumed that they would be an absolute game-changer and that productivity would go through the roof, objectively quantified in terms of revenue per employee. Productivity has in fact gone up, but not by leaps and bounds, and this is a puzzle to economists and other social scientists who study this sort of thing.
Cf. https://en.wikipedia.org/wiki/Productivity_paradox
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.
Is in this context "no-code" synonymous with "low-code"? Or are there differences?
1. As many others point out, "no-code" is just a different way of representing code/logic. The skills are the same, except for typing.
2. Even if it did take off, someone still has to maintain the code for the no-code tools. I guess eventually the no-code tools are meant to be written in no-code. This doesn't happen overnight.
1. Sales for a No Code product talks up how you will not need programmers to create solutions
2. Company buys No Code product deploys it to users
3. A few users "get it" and create solutions with no code
4. Something in the environment changes, or the original creators of the solution move on from the company and the "no code" solution breaks, no one can fix it or understand what broke or even really explain the "solution"
5. Devs / SysAdmins now have to detangle and figure out how these "no code" solutions works, what they were suppose to be doing in the first place, and figure out why they do not work any more. Often times this results in the dev / admin just redoing everything properly, in a proper programming enviroment because there was no logic to no-code solution
There's a reason excel is so ludicrously wildly popular as a business tool. It lets accountants do things you used to need a programmer for. That the automation may eventually grow so complex as to require a programmer anyway is not relevant to the utility of excel.
You also end up with a TON of XY problem "solutions"
It is a nightmare 90% of the time
>>There's a reason excel is so ludicrously wildly popular as a business tool.
Because it allows lower wage workers to implement half baked solutions, and manipulate data in away that executives want regardless if it accurate, true, or reliable?
I will agree that Excel is a poster child for "no code", it has EVERY problem of no code in spades, I wish i could get back even 1/10th of the time I have wasted in my career trying to decipher some of the moronic things I have seen people do in excel.
and do not get me started on people that treat Excel as a Database, Literally pulling in an entire table with a Select * SQL Query then using some excel function to do sorting and filtering.....
Or to phrase it more generously: It allowed people to create the tools they needed to make their lives easier without engaging the services of a professional programmer.
I know that to the professional programmer this is a high-crime worthy significant prison time, but to me it is basically the point of personal computing.
it is like "Write one, Run Anywhere" code... It has been promised by vendor after vendor who all have slick sales people that promise the world, and deliver something less functional than excel
Are all tools with programmatic capabilities low-code? Where do we draw the line? Or is this just a new paradigm, and eventually all platforms/tools/products/SaaS-companies are low/no-code? It seems like there's room for distinction here.
It would make more sense to say that the more we code, the more possibilities for no-coders.
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.
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.
But this time it's different! No it is'nt.
Users are now eMp0wErEd! You give 'em this drag and drop interface and they will cHanGe thE wOrlD!! No they won't.
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?
[0] https://www.puzzlescript.net/
I think the proper term for these products should be "Low(er)-Code".
So yes, I think no-code has been with us for a long time and will continue in various forms.
The problem isn't coding or not coding or whatever. It's the problem of expressing complex logic and calculations to meet your ends. If you can't express those ideas on a computer then you're not going to get anywhere making software.
The problem is that kind of thinking is hard, and requires the use of something more complex than the no-code tools available now or in the foreseeable future. The nifty part about programming is the concepts are transferable to other areas. No-code tools generally don't offer that - you learn how to do Minecraft or Excel, but then when you're out of that tool your skills don't apply. I see this with young people frequently now. For example, a bunch of Excel VBA functions that do essentially the same thing but with a number in their name to determine some functionality. When asked why they don't they just pass the number as a parameter to a single function the answer is that's too difficult and what they have works fine. This is from a recent graduate in engineering.
Making software without coding doesn't really do anything but let you assemble pre-made parts. That's fine for some relatively simple thing, but will never give you the power of coding.
This transcends programming. It is fundamental to basic success in life. You have to know how to form ideas, express those ideas, and then act on those ideas.
I had a very little bit of U.S. Army training. (Nice people, turned out not to be my thing.) One of the things that we were taught is that a big reason some armies are more successful than others is because some train their soldiers to think, others train them to blindly follow orders.
Another arena where we see this is education. There is no shortage of people graduating from high school and college who can pass written exams through memorization. But there is a massive shortage of people graduating from high school and college who can think.