
The “No Code” Delusion - ealexhudson
https://www.alexhudson.com/2020/01/13/the-no-code-delusion/
======
sequoia
I was once at a company (X) that acquired another company (Y), and Y's main
product was a graphical programming tool. Y advertised that their tool could
speed application development up 10x.

My (nontechnical) manager asked me "why don't you use Y's tool to build the
project you're currently working on?" I answered with the following metaphor:

Imagine you have to pick a bike to go on a trip. You're travelling on a well
paved road through the woods. If you take a light & narrow wheeled racing
bike, you'll travel much much faster than if you ride a knobbly wheeled
mountain bike with suspension, as long as you stay on the road. As soon as you
need to go off the road and cut a new path, you are going to wish you had that
mountain bike, and the road bike is actually going to make you go much slower
or just stop altogether.

So does the "speed bike"/advanced framework make you go faster? Yes, _as long
as you stay on the road_ (i.e. constrain your requirements to their feature
set). The moment you need to "go off-road" (i.e. do something the framework
doesn't do), such tools actually make it difficult or impossible to make
progress.

This is why, for a complex applications (most commercial software), I prefer
the mountain bike. Yes, it's slower on certain paths, but when we need to "go
off-road" I don't slow to a stop.

~~~
smhenderson
Reminds me of something Bruce McKinney said about Visual Basic when I was much
younger and beginning to learn about computers in general, I'm paraphrasing
here but the gist was "Visual Basic makes 95% of your task easy and the other
5% impossible".

Of course Bruce is a hard core programmer so he went on to show you how to do
the 5% in VB using some crazy hacks or, better, do it in C/C++ using COM and
glue it onto your VB code using the common MS interface of the day (pre .Net
that is).

I've forgotten more of it then I remember but I do remember really enjoying
reading anything Bruce wrote!

[http://www.vb.mvps.org/hardweb/hardbook.htm](http://www.vb.mvps.org/hardweb/hardbook.htm)

~~~
JadeNB
> "Visual Basic makes 95% of your task easy and the other 5% impossible".

Think what you will of the readability of Perl, but it's hard to beat its
motto: "making easy things easy and hard things possible."

~~~
smhenderson
Indeed. When I was finally exposed to Unix (SCO, yuck!) and Linux (Slackware,
yay!) it was because I was trying to learn C and wanted free tools because I
couldn't afford any commercial stuff at the time. But before I did much with C
I became quite proficient with Perl. This really wasn't that long after
absorbing all the VB material I could find at the time so it was interesting
going from the one to the other, not to mention the OS differences.

I still love using Perl 5 today even though it's totally out of style at this
point. VB? Not so much! :-)

~~~
JadeNB
> I still love using Perl 5 today even though it's totally out of style at
> this point.

Same here!

~~~
smhenderson
I suspect there's more of us than we think!

------
swalsh
I've spent a long time trying to build "No Code" solutions. Probably 3
different products, 3 different companies. But once, I tried something
different. I pushed back, instead I proposed we build a domain specific
language using Ruby. I already had some trust with my boss... and he was
pretty convinced it was going to fail, he had zero faith these smart (but non-
technical) users could successfully use it. But he was willing to let me fail.
So we tried it, and really surprisingly, they caught on very quickly, and they
were producing complex content within a week.

"No Code" solutions are like asking your user to communicate using
pictographs. It's possible, but language allows users to communicate in better
detail faster. In school I learned how to write, I'm probably not anywhere
close to writing a novel. I'm a terrible writer, but I can write an email.
Frankly, that get's me pretty far.

~~~
detaro
Did you do anything special presentation/interface-wise?

My impression is that a good part of it for many is not making them realize
that they are "programming" until they've already accepted that they can do
it, because otherwise they "know" that it is too difficult.

~~~
cr0sh
> because otherwise they "know" that it is too difficult.

This is something that frustrates me in general, and I'm sure others, too:

That there seems to be among a certain population of people a mindset that
declares failure before they've even tried. Or, they try, but at the first
hint of failure or trouble, they declare that they can't do it, and stop.

So what is different about those people who don't do this? Why do they instead
take up new challenges, and when they fail, try again. When they run up
against difficulty, they step back, think about their options, perhaps consult
experts in the domain, and continue on?

And how do we get the former group to join the latter?

I know there isn't an easy answer to this, if there is one at all; I know I'm
not the first to observe this issue either - it's likely something that has
been observed and wondered upon for thousands of years.

...but nonetheless, it continues to be frustrating.

~~~
jimbokun
My suspicion is that it's not really that they aren't capable of programming,
they just find it boring and would rather be doing something else.

~~~
dkersten
I think its a matter of motivation. They’re not sufficiently motivated to push
through the boredom or frustration they feel at the start. That’s ok, most
people don’t beed to learn it, but as I say in another comment here, I do
believe that most people can learn if they have a problem that they could
solve with programming that the want to solve badly enough.

Most people don’t care enough though and life’s too short to spend on
something when other things are more important to you.

------
rchaud
I think those with a programming background take terms like "no code" far too
literally. For those who've worked in finance IT, you may know of staff who've
build incredibly elaborate models in Excel, and then have come to you when
they need something that can't be done in Excel.

"No code platforms" will likely work the same way. These platforms provide
just enough interactive/dynamic functionality for non-programmers to build a
decent prototype of what they're trying to create. They can then take this to
their dev team (if they have one) and ask for refinements.

Even if the end result requires a full rebuild, I'd wager the devs would be
happier because they wouldn't waste time building something based on vague
specifications communicated by a non-technical staff member. They'd have a
prototype to work off of, and can ask clarifying questions that will be easier
for the stakeholder to answer because they can see where the devs are coming
from, instead of simply speaking in abstractions about something that doesn't
yet exist.

~~~
flarg
I have spent 5 years on and off in the no code space and IMHO you're almost
spot on. Almost all standard enterprise platforms are non complex and can be
delivered in no code solutions, requiring maybe 5pc as real code. Failing to
acknowledge this is why IT organisations in large enterprises are typically
sidelined by shadow IT teams, who often deliver great solutions in Excel and
Oracle Apex.

~~~
gnud
A large part of my job is writing custom logic for an enterprise application
with much-touted "no-code" facilities.

You _always_ need code. Some customers don't need much, but they all need
_some_.

The first example that comes to mind is duplicate detection. Sure, the basics
are simple. No two agreements of the same kind for the same customer. A lot of
no-code solutions struggle at this point.

But then you get to the slightly more complex requirements. You _can_ have two
agreements of the same kind for the same customer, as long as they are not
overlapping in time. But if customer B is a subsidiary of A, and A already has
the agreement, then B cannot have its own, if A's agreement is marked
"company-wide". This also goes for C, which is a subsidiary of B.

I've yet to see a no-code solution that makes this sort of thing accessible to
non-programmers. And programmers will prefer just writing the code.

------
mikece
I've been hearing about "no code" or "no programmer required" business
solutions for over 20 years. Cynically, I encourage this thinking because my
billable rate to untangle someone else's hot mess when urgent deadlines are
looming goes up. Practically speaking, if the business problems being solved
are complex you might be able to pull off a low-code solution but without
knowledge and practice of the essential architectural patterns of software
development a novice will paint themselves into a corner before they even know
what they are doing, requiring an expert to come in an clean things up.

~~~
osullivj
Nearly 40 years for me; I remember reading about The Last One [1] back in 81.

[1]
[https://en.wikipedia.org/wiki/The_Last_One_(software)](https://en.wikipedia.org/wiki/The_Last_One_\(software\))

~~~
brazzy
The pipe dream is far older than that.

Around 1960 some people seriously claimed that within about 5 years there
would be no more professional programmers because with this new language,
everyone could write the software they need themselves, since it was so easy
to use.

The language was COBOL.

Oh, and look, this one still seems to be around:
[http://www.makeyourownsoftware.com/](http://www.makeyourownsoftware.com/)

~~~
zokier
> Around 1960 some people seriously claimed that within about 5 years there
> would be no more professional programmers because with this new language,
> everyone could write the software they need themselves, since it was so easy
> to use.

Of course that prediction seems quaint now, but I posit that the prediction
failed because they greatly underestimated the increase in demand of software
as much as overestimated the expressiveness/productivity increase of COBOL
(and later systems).

Heck, considering what a professional programmers job might have been like in
the 50s, its not far fetched at all that such profession indeed has
disappeared as modern programmers work at such a different level of
abstraction

~~~
brazzy
Yes, given that back then people were typically working in assembler (with
frequently changing platforms, to boot) and writing relatively simple data
processing applications, the claim is somewhat understandable.

But I think the main thing it failed to take into account is more how hard it
is to translate business requirements into complete and unambiguous
instructions.

~~~
goatlover
The even bigger thing is how better tools and abstraction create more demand
for code, as more can be done. The entire history of computers has seen
software demand increase over time.

------
mmerlin
"Low Code" is currently where it's at.

Intelligent subject-matter experts who are non-programmers can build 80 to 90%
of their business info capture and reporting requirements inside the walled
garden of their chosen platform.

Programmers are called in temporarily to complete the final 10 to 20% of the
LowCode app, and integrate with external services.

It's been happening since Excel, through to Wordpress and nowadays splintered
into 100's of directions and platforms from Wix to Podio to Notion.so

~~~
yebyen
I'm compelled to invoke the "Ninety-Ninety" rule when I hear about solutions
like that, although I'm sure it works sometimes, in my experience it usually
turns out more like this.

The first 90% of the work takes 90% of the time, and the remaining 10% of the
work takes the other 90% of the time!

~~~
lucasverra
Isn't the majority of software following this rule ? This is not specific of
low/no code environment

~~~
BigJono
Yes it is, but if you're doing the first 90% properly you have a much better
shot at mitigating the difficulty of the last 10%.

I think there's some vague point in any project where it goes from being
'easy' to 'hard' to add new stuff. Basically the only factor that matters for
productivity is how long you can delay that point. If you just do the first
90% as quickly and cheaply as possible, you're just resigning yourself to
hitting that point as early as possible.

~~~
yebyen
I think this is best explained without exaggeration by the famous Design-
Stamina Hypothesis[1], which states the notion that time spent on Design is
something which you can trade away to improve development speed, is reliably
false in the long-term (even if it seems to be working in the near term.)

The graphic also suggests that there is an inflection point, as you suggest,
before where time spent on design really is just slowing you down in the
beginning of your project, but also that the costs of waiting too long to
switch modes (from doing no design, to doing good design) after you have
crossed that line, are substantial and compounding; the longer you wait, the
more your lack of good design costs.

And of course, not pictured, is "bad design" which can be even worse than no
design. Trying to find that inflection point and put it on your development
schedule in advance is also a bit like trying to catch a falling knife (not
likely to succeed.)

[1]:
[https://martinfowler.com/bliki/DesignStaminaHypothesis.html](https://martinfowler.com/bliki/DesignStaminaHypothesis.html)

------
chrisweekly
Reminds me of being warned, over 20 years ago, that the viability of my new
career as a web developer was in doubt thanks to tools like FrontPage and
Dreamweaver.

~~~
sgift
Frontpage and Dreamweaver ... never before could you produce so much bad code
in so little time. And never before did the person who had to clean it up to
have any chance of breaking out of the box and change something hate you so
much. Especially if said person was you six month later.

~~~
tonyedgecombe
I always thought the failure of tools like Frontpage and Dreamweaver was a
reflection on the inadequacies of HTML/CSS/JavaScript as much as the tools
themselves.

If I want to typeset a book or magazine I'm not going to start by writing
PostScript or PDF files in VIM. If I want to design a tool then Autocad is
likely to be my starting point. Why should the web be any different, why do I
need to learn some arcane text based language when all I want to do is adjust
the margins on an image or include some data in a page.

Sometimes I feel this industry is going backwards rather than forwards.

------
Wowfunhappy
There's no such thing as "no code". There's just interfaces which are more-or-
less capable, and more-or-less intuitive. Any time you define a set of
instructions for a computer to execute, you are creating code.

We use Scratch at my Girls Who Code club. It requires students to consider
branching paths, and data types, and asynchronous execution. It does _not_
require the students to _type_ , but thank god for that, because they're 9
years old and type at approximately 1 words per minute.

Scratch is still code just like Java, and Lego Mindstorm's EV3, and Automator,
and IFTTT. Not all of these systems are Turing complete, and each one contains
different restrictions in an attempt to stop users from shooting themselves in
the foot: Java doesn't have manual memory management, Automator doesn't have
conditionals, and IFTTT is limited to a single trigger and action. But
there're still code. Users of these tools need to carefully consider input and
edge cases, and test and iterate to see if the code is doing what they
intended.

IMO, the primary reason "professional programmers" type their code is because
once you know what to type, keyboards are fundamentally faster than mice.
That's also why Excel power users frequently rely almost entirely on keyboard
shortcuts, and why the command line for an experienced user is often faster
than a GUI.

\---

Edit: BTW, for the same reason that HTML isn't a programming language, I don't
consider most "website builders" to be code, even though I _do_ consider IFTTT
to be code.

Code in this context means creating instructions for a computer to follow.
Laying out elements on a page (which then adapt to different screen sizes
based on predefined behavior) is just that, laying out elements.

I don't know about you, but I can feel myself entering a "coding mindset" when
I load up IFTTT—it's simpler than writing Javascript to be sure, but it's the
same type of brain muscle, and there's no avoiding it.

~~~
satyrnein
This made me wonder: which side would other activities fall on, if event
handling was the defining characteristic of "code"?

Not code - Excel, SQL, HTML, CSS

Code - Email inbox rules, IFTTT. Alarm clock?

~~~
Wowfunhappy
Hmm, y'know what, I'm now reconsidering that part of my post.

Setting an alarm clock is definitely _not_ coding. All the instructions are
built into the clock:

    
    
        if (currentTime == alarmTime) {
            soundAlarm();
        }
    

All the user does is set the value of alarmTime, a single variable.

But, what if the user can choose from a set of alarm sounds? I feel like
that's still not coding, but I also can't describe how it's different from
IFTTT.

There's a spectrum here for sure—any time you interact with a computer, you're
giving it instructions. I was thinking about this in terms of the mindset
required. When I volunteer at GWC, there's a very specific skill that I see
the students coming to grips with over the course of the class. I don't have a
word to describe it.

~~~
satyrnein
Yeah, I was thinking of the alarm clock app on your phone rather than a
hardware clock by the bedside, so you're practically hitting "add rule, set
trigger, define action" much like IFTTT or email inbox rules.

When I've taught (adults) some basic coding, it's typically been state that's
the challenging concept. You have a bunch of logic, but what was the state of
your program (or the world) when the logic executed? If it's not what you
expected, how did it get into that state? These questions seems fundamentally
different to me compared to working on an Excel spreadsheet (which of course
can still be complicated and have bugs).

------
heinrich5991
The shown C code has a buffer overflow vulnerability:

    
    
        #include <string.h>
        #include <stdlib.h>
        
        char *add_domain_name(char *source) {
            const size_t size = 1024;
            char *dest = malloc(size+1);
            strncpy(dest, source, size);
            strncat(dest, "@example.com", size);
            return dest;
        }
    

`strncat` takes as a third parameter the maximum length of the appended
string.

    
    
            strncat(dest, "@example.com", size - strlen(dest));
    

would be correct.

~~~
gengkev
This isn't even quite right, since the first argument of strncat needs to be a
null-terminated string, and strncpy may not null-terminate. I would honestly
just give up and write

    
    
        size_t len = strlen(source);
        char *dest = malloc(len + sizeof("@example.com")-1 + 1);
        strcpy(dest, source);
        strcpy(dest + len, "@example.com");

------
emilecantin
I read somewhere a quote that stuck with me: "No tool is ever going to free us
from the burden of clarifying our ideas."

And that's how I view my job as a software developer: clarifying ideas.

Any "No Code" tool is still going to either force you to clarify your ideas,
or have a large amount of assumptions. "Idea People" and "Business" don't like
that, so they'll probably end up delegating the use of "No Code" tools to
programmers of some sort.

~~~
worldsayshi
There are plenty of tools that _help us_ in clarifying our ideas though. Take
mathematical notation for example. Or music notation. Or a CAD program.

All are examples of domain specific tools that allow the user to specify their
intention in a non-ambiguous way. And they also allow the user to think about
and experiment with the problem space.

I think what we need is something akin to this. The "business logic" that we
are talking about here is to me a non-infinite domain. It should be possible
to boil it down into a domain specific tool that is more helpful than a
general purpose programming language.

~~~
bitcuration
Business domain vs. Math., that's an interesting comparison. The problem is
that business domain is exact an "infinite domain", in comparing with Math. Or
to say that the competitive nature of business is very much reliant on its
ability to break its domain boundary. Again, not so much in the case of Math.

~~~
marcosdumay
> Again, not so much in the case of Math.

I will resonantly disagree here. Math is successful exactly because each time
it had a rule that was problematic, people just extended it.

And the success of modern (20th+ century) Math is caused exactly by the fact
that we got an inifinitely extensible language, so nobody has to ever break it
again anymore.

------
honkycat
My response to "No Code" solutions:

If there was a faster and easier way to develop software, we would be doing
it. We are already using the easiest to understand tools we can find to
develop the best software possible.

There is no secret programmer cabal where we are holding hostage the REAL
tools we use to develop software, and we keep them secret and hidden while we
fuck around every day.

For someone to develop a "no-code" solution that fits the huge variety of
tasks developers are doing every day, they would be a genius in the same vein
as Turing. They would be billionaires.

~~~
coffee
> If there was a faster and easier way to develop software, we would be doing
> it. We are already using the easiest to understand tools we can find to
> develop the best software possible.

Not really.

As we evolve software development, historically, we've done this through
adding new layers of abstraction.

Assembly --> C --> Interpreted Code (Java, Ruby, etc...)

Why isn't the next layer of abstraction simply what is being termed as "No
Code" today?

~~~
Bartweiss
> _Why isn 't the next layer of abstraction simply what is being termed as "No
> Code" today?_

Cynically? Because people were also selling "no code" ten years ago, or even
further back.

I know that sort of inductive argument doesn't actually work. We went through
a dozen nonsense models of infections, but germ theory was actually correct in
the end. AI has seen frauds and baseless hype since the mechanical Turk, but
there still came a point when computers won at chess and Jeopardy. But it's a
pretty good warning sign.

The gradual progression of abstractions still caps out somewhere around Python
and Rails. We have drag-and-drop website makers, and visual tools for
"plumbing" ML flows backed by pandas, or engineering calculations backed by
Matlab. They mostly work, and people who know the underlying tools sometimes
use them for speed while mixing in actual code as needed.

Meanwhile, promises of codeless business apps don't seem rooted in any of
those advances, and continue on from their dysfunctional predecessors. And
people actually making business apps in a hurry pull from NPM or PyPI without
ever touching "no code" tools. It seems like we might get much closer to that
layer within a decade or so, but I don't think we're there yet.

~~~
coffee
> Cynically?

No, not cynically :-)

> Because people were also selling "no code" ten years ago, or even further
> back.

Not really sure it matters when it starts. Sometimes markets aren't ready and
products are too early.

What matters is are these solutions providing value to people today, and is it
enough value for them to buy/spend time on/etc...

Seems there is enough value today, with a mature enough market, based on the
results these platforms are experiencing.

> I know that sort of inductive argument doesn't actually work.

Then why waste time making it in the first place? :-)

------
rglover
For what it's worth, tools like Webflow (and their CMS feature) are incredibly
well-done.

From a front-end development perspective, no code is legitimate and practical
_today_.

From a back-end or business-logic perspective, no code is more difficult
because a lot of it is bespoke (except for things like generating a PDF from
HTML).

It's not a binary "killer," but it's certainly a smart thing to play with as a
programmer. I've saved a ton of time on things like marketing websites and
CMS-level work using Webflow. With time and iteration, I'd imagine some pretty
neat and powerful stuff will appear.

Read: don't be naive/stubborn; give it a try.

------
Eikon
While I agree with the author, it's only true when speaking of software that
requires custom logic.

For instance, "no-code" website creation offering has done wonders in
replacing the "install wordpress on a very crappy cheap host and let it rot
with vulnerable plugins" paradigm.

~~~
Piskvorrr
Is that very different from the websites of the 90s? I distinctly remember
creating a somewhat-dynamic site in FrontPage, then rendering it into static
HTML and FTPing it to the webserver.

Perhaps this was an impedance mismatch: "web requires coding" \- it mostly
doesn't, most people would be okay with a better HTML editor, and providing
that via WP was a historical quirk.

~~~
rchaud
Those would be examples of static sites, which are "read only" to most users.
Wix, Squarespace etc can handle form submissions and online payments of
course. And with third party solutions like Intercom and Optimizely, things
like customer support chat and A/B testing can be done with pretty much no
code.

~~~
ptx
Web hosting companies in the old days often provided a collection of CGI
scripts that users could invoke from their HTML pages, things like counters,
e-mail form handlers, guestbooks and other popular functionality.

------
lidHanteyk
I agree with the author in all points about the no-code movement and goals,
but disagree with the larger points about software development and engineering
in the business setting.

In particular, the attractiveness of no-code should not be that one does not
have to have in-house software development, but that one has less technical
debt and thus smaller technical interest payments. Businesses will always have
problems with computers, because computers are rigid and unyielding, while
businesspeople are soft and compromising.

It is all to easy to read the beginning few paragraphs as the sourest of
grapes: The businessperson, having embraced fax, email, paperless, Web, and
mobile, is nonetheless no closer to having embraced computer. The "traditional
sense" of creating software is derided as "expensive, in short supply, and
fundamentally [not quick at] produc[ing] things." But that is all explained
neatly by market forces: Developers are expensive because competency is rare
because understanding is low because computerizing is a painful commitment
because operationalizing a business is equivalent to automating it away.
Computers reveal the rent-seeking and capitalization simply by being
themselves on their own.

------
neilwilson
Fred Brooks - No Silver Bullet: Essence and Accidents of Software Engineering,
IEEE Computer, Vol. 20, No. 4 (April 1987) pp. 10-19.

[https://www.cgl.ucsf.edu/Outreach/pc204/NoSilverBullet.html](https://www.cgl.ucsf.edu/Outreach/pc204/NoSilverBullet.html)

Read and inwardly digest

~~~
keawade
Yes!

I think this line in particular is a good TL;DR of the issues discussed in the
linked article:

> The complexity of software is an essential property, not an accidental one.
> Hence descriptions of a software entity that abstract away its complexity
> often abstract away its essence.

------
slumdev
Robotic Process Automation (RPA) is the new "No Code". And it will fail the
same way every other "No Code" fad has failed over the years, no matter how
successfully McKinsey sells it for the next few years.

It will never completely disappear, but there is no future where a BA with an
overhyped macro suite replaces the whole of software engineering.

~~~
jordanbeiber
RPA just seems crazy... I mean, I see the golden shimmer, but why do so many
enterprises refuse to actually, you know, solve the problem?

I have, btw, just finished reading “the phoenix project”. Brilliant book!
Having lived through pretty much that story a couple of times, the solution is
just that simple. Not easy, but simple.

Been around a while, at several big companies, I know most of them will do RPA
(they are of course the ones having a blockchain project plodding along), but
only a few will go down the “software company” route. It’s kind of tragic.

~~~
alicorn
There is a competition between RPA and automation by Python ongoing in my
workplace. We are low on devs and high on buzzword-susceptible non-technical
managers. The argument that it is a lot smarter to hire a few more devs that
would add a lot more value to the company, especially given that we have
already made significant inroads in 'proper' automation, than pay for a
proprietary tool that is essentially an overhyped Selenium browser falls on
deaf ears, since learning is hard and klickety klick is simple and easy to
outsource. So it goes.

~~~
jordanbeiber
I’m sorry to hear.

The RPA abstraction just seem so fragile and unflexible. I _had_ to build
“rpa” like solutions to problems in the late 90s using tools like scriptit,
and later vbscript. Crap software have no APIs...

I guess, it’s the same type of companies, still with the same type of
software.

------
mellosouls
This reminds me of Gartner's "Citizen Developer" line used to sell expensive
software to gullible managers.

I note there is - strangely - no corresponding "Citizen Management Consultant"
role.

[https://www.gartner.com/en/information-
technology/glossary/c...](https://www.gartner.com/en/information-
technology/glossary/citizen-developer)

------
satyrnein
While everyone is right that a "no code" platform cannot replace all
developers, if you take away the extreme framing, there is an interesting
trend occurring. These days, business power users can accomplish a lot with
tools like Excel (this one was always true), Google Forms, Salesforce,
Airtable, Looker, and so on. People can define entities, custom fields,
workflows, reports... things that used to be feature requests for developers.

Of course, many developers have had the experience of having to come in and
deal with some insane Excel spreadsheets, but many of us have also been called
into deal with crazy legacy systems built by professional developers. That
itself is not an indictment.

As these tools grow, presenting new and lower cost ways of getting a certain
class of activities done, I think we would be well served to figure out how to
play nicely with these tools. (It's not like we want to spend our time
building custom CRUD apps anyway.)

------
q3k
This delusion is especially visible in the DevOps space. For some reason we
have decided as an industry that instead of writing some code in whatever
'real' language we will base operational work on YAML with ad-hoc templating
and stringly-typed programming constructs.

The main culprits are Ansible/Salt and all the string-templating based tools
for Kubernetes (Helm/Kustomize/...).

Especially with tools like Helm I believe we reached peak insanity levels.
Instead of using a general purpose or configuration-specific (like
Jsonnet/Cue/Dhall) programming language to build and then emit in-memory
objects to YAML manifests, the industry is using YAML to define templated YAML
and then parametrize this templating with even more YAML.

Now we just write complex declarative configuration with no debugging
facilities, a non-existent type system, inversion of control that usually ends
up working against us and no way to interact with external data apart from
stringing everything together with fragile shell scripts. But hey, there's no
need to write a single line of Go/Python/Java/Ruby!

~~~
UserIsUnused
Thank god trends like Pulumi and the new AWS sdk is emerging.

General purpose programing languages are getting more expressive by the day,
why do we use data serialization languages instead for configs? it doesn't
make any sense.

Configuration is code not data.

~~~
solatic
> General purpose programing languages are getting more expressive by the day

You know, once upon a time, we understood that declarative approaches to
software engineering were superior to imperative approaches, when declarative
approaches are feasible. Declarative approaches are much safer and easier to
test, at a cost of only being able to express what the tool accepting the
declarative approach can understand. Imperative approaches are _strictly
worse_ for any problem set where a declarative approach solves the problem
within performance requirements. The additional expressiveness of languages
like Pulumi is the _last_ thing I want.

YAML is a horrible language for declarative system configuration because a)
any sufficiently complex system will require you to generate your declarative
codebase in the name of maintainability, b) generating code for any language
where whitespace is significant will lead you to an early death, and c)
stringly-typed languages are fundamentally unmaintainable at sufficient scale.
But this is not an indictment of a declarative approach! It is an indictment
of YAML.

> Configuration is code not data.

Data > code. Data does not need to be debugged. The best code you can have is
deleted code - deleted code does not need to be maintained, updated, or
patched. Code is a necessary evil we write in order to build operable systems,
not a virtue in and of itself.

~~~
UserIsUnused
There are declarative general purpose programing languages.

That data you are talking about does need to be debugged, like Helm charts and
pipeline definitions. Sure data is better, but config is code, not data.

~~~
solatic
Generators need to be debugged, not data. It's very easy to test a generator -
a few unit tests checking whether, for a given input, the generator produced
the expected output, and you're set. Data sometimes needs to be cleaned, but
there's no such thing as a bug in data.

Whether the generated declarative output produces the expected behavior on the
part of the tool interpreting the declarative output is part of the _tool 's_
contract, not the generator or the declarative output. If you need to check
the tool's behavior then either a) you wrote the tool or b) you're writing an
acceptance test for the tool, which is an entirely different endeavor.

~~~
UserIsUnused
Things like pipeline definitions and helm charts are generators.

~~~
solatic
No, Helm uses charts (data) to generate object definitions (in YAML). Helm is
the generator.

There's nothing that prevents you from writing a unit test that runs `helm
template` directly to check whether a given chart with given values will
produce a given set of YAML files.

------
markmiro
I like to think of the no-code stuff like this:

\- People who are into this stuff know there's something to it, but as a
movement, we don't know exactly what it is.

\- My personal feeling is that any no-code tool should be useful enough that I
would use it. I want some no-code to make me feel for my career a bit.

\- The "threat", I think, is very real. For example, whenever I see myself
following a set of rules to write software and not thinking, I start to wonder
if some abstraction is lurking in there. Maybe the solution is a programming
library, but increasingly, I think there's opportunity for this stuff to be
more visual.

Why visual?

\- UI programming is necessarily visual, and a visual tool for building
interfaces makes sense

\- Tools around managing software development. GitHub is IMO a no-code tool.
VSCode is. Many IDEs are.

Why not visual? Algorithms and business logic. Like the author, I'm
unconvinced that flow diagrams will provide enough flexibility to be useful
for all but the simplest cases.

I guess my feelings aren't that different from the author's but I think the
difference is I'm optimistic that the movement will be generative.

~~~
jimbokun
I don't think your career is any danger from better tools. (At least short of
full-AI, which would put every career in danger.)

All kinds of amazing visual interface building tools have been created, that
are very easy to use, easy to teach, easy to get started, and are very
powerful. I'm still not sure that a better UI development tool than Hypercard
has been invented yet.

So why do professional programmers still exist? Because most people don't want
to do even that level of software development. Either they find it beneath
them, find it boring, get frustrated when they want to do something that
stretches the tool's capabilities, don't want to be responsible for fixing
bugs and maintenance, etc. etc. etc.

It's not that most professionals are not smart enough to be programmers. It's
that they dislike it enough to pay someone else to do it for them, or would
just rather focus their time doing other things they enjoy more or believe to
provide more value.

~~~
scroot
> So why do professional programmers still exist? Because most people don't
> want to do even that level of software development. Either they find it
> beneath them, find it boring, get frustrated when they want to do something
> that stretches the tool's capabilities, don't want to be responsible for
> fixing bugs and maintenance, etc. etc. etc.

I'm not so sure about this. Hypercard was extremely popular among non-
programmers in its heyday. It is not their fault that Apple, who had no idea
what to really do with the software, let it die on the vine.

Computer companies have inclucated a computing culture that places a sharp
perceptual divide between users and programmers, leaving little room for
anything in between. My belief is that this has happened for wider
structural/economic reasons (contemporary emphasis on consumerism, short term
thinking, etc) rather than any general distaste for "real computing" among
regular people.

If we do not provide regular people with "Hypercard-like things" and instead
give them shrinkwrapped solutions, we will of course have the perception that
they have no interest in what we call -- for lack of a better term -- end user
programming.

------
statictype
This rings very true.

We sell an integration platform-as-a-service[1] and it offers a 'low code'
visual environment to stitch together integrations.

But from pretty much the start, we built-in support to drop down to Javascript
to build logic and we think we hit a sweet spot there.

You can visually string together most components but drop in a bit of script
to concisely define some hairy transformation or complex logic.

These kinds of low code environment are great for doing customizations or
enhancements or integrating many things together. It's very much not an
optimal solution for building entire applications or software solutions.

There's also the issue of tooling. There's a huge amount of infrastructure
built around maintaining large application code bases (version control,
merging, diffing). If you want to build large pieces of software in a no-code
environment you still need all of those tools - except they don't exist and
are non-standard.

[1] [https://lucyinthesky.io](https://lucyinthesky.io)

~~~
sytringy05
+1,000,000

As the article points out, the problem with these is they are sold as a silver
bullet and companies who don't know any better will spend millions building
putting a lot of code in the script nodes on their "low code" platform.

Code that can't be unit tested properly, that has at best some really crappy
tools for automation and limitations that drive everybody crazy (ie getting
logs into es/splunk or whatever - syslog UDP over the internet ftw!)

You are clearly a responsible vendor, I wish the others I deal would be honest
with their customers about what the low codes do well vs what they dont

------
nslindtner
The quote that sticks with me is "New Blocks means new builders".

I'm pretty sure this new 'movement' will gain a lot of steam. Probally mostly
because of the 'no developer'-dreams.

But the most value I find, is when working with very structured people - who
understand data AND LOGIC - but doesn't know how to code. They do not have to
write a spec, but can instead make a working prototype pretty quickly.

I actually think the biggest change from earlier on, is that the 'No-Code'
doesn't seems to be a dead-end. As it has been earlier.

If you grow out of the No-Code tools, it possible to replace parts of the No-
Code expirience using microservices and serverless.

------
blaze33
Once read how the "no code" trend isn't really more than a marketing one. Went
more or less like this: it will be great to build software without having to
write code: you'll just have to specify what your program does. Except that a
program's exact specification is the definition of its code and that the job
of writing such exact specifications is what developers do. Conclusion: any
"no code" tool will just be another way to write code ;)

Obviously the trick is in the difference between exact and fuzzy
specifications. As a software engineer I could say my main job is to translate
approximate specifications of business needs into a list of specific
instructions on how to solve them i.e. code that can run on a computer. We'll
probably have better tools and more efficient abstractions to do so but we'll
still have to write some code.

I guess the "no code" topic could better be treated as "years of experience
vs. hours of training". During my first job I once had to use a graphical
programming tool to design and run computer simulations of a power plant: just
connect some predefined building blocks, input some simulation parameters in
each block and voilà! Except that the simulations quickly started to require
hundreds of said building blocks, so that my coworkers spent their days
clicking around only to start over when we needed to use different simulation
parameters. Got trained a few hours on how to use the graphical tool but
couldn't accept I now had to click and input numbers all day long... Somehow
found that an old user manual actually existed and discovered that I could
instead write plain text files to specify the computer simulations. It used a
very verbose ad-hoc language so I wrote a Python script to generate the files
I needed and when the requirements changed I could redefine the simulation in
minutes instead of days. Later got fired for being some sort of troublemaker
but I now work as a fullstack dev in Python and Javascript.

------
richardlblair
No code has been a thing for a long time. I don't think we need to be so
defensive, though. The limitations of this approach haven't changed in the
decades since its first inception.

I think it's a little ignorant and short sighted to speak down on the current
trend. The reality is, there used to be a whole host of no-code products that
solved a whole host of problems. We haven't outgrown those problems, but the
solutions we had didn't scale well with the technologies we use today.

We need similar tools to those that we had before, updated and adapted for
modern technology. Some of the new tools go a step further, which is
incredible. Think about every aunt and uncle who have an idea that would solve
a problem they and 10 of their friends have. Those 11 people are super stoked
about the tool that Aunt Linda built. Why can't we let them have that?

------
segmondy
The "No Code" movement is not a delusion. Most of us in tech are very ego
driven and don't think this will happen, the majority is not in tech and want
this to happen. It will happen.

~~~
busterarm
I feel like everyone misunderstood what the "No Code" movement is supposed to
be about.

It's "No Code is the Best Code". The idea is that the code you should be
writing should be things that are the core of what your business does. Those
things should be sufficiently hard to replicate. Everything else should be a
commoditized product or open source infrastructure that you deploy.

This way you avoid time reinventing the wheel or, much more importantly,
making your product something that's easy to commoditize!

I've worked at companies with hundreds of complex Java microservices that
essentially replicate built-in functionality provided by NGINX, HAProxy, etc.
Literally for no other reason that the people making the decisions know how to
write code, but they don't know how to productionize and configure NGINX or
HAProxy.

These companies are more than happy to waste hundreds and thousands of man-
hours building and maintaining this code that isn't their product versus
hiring more competent ops folks to stand up infrastructure or train developers
on cross-functional skills.

When the size of your engineering org starts climbing into the hundreds and
thousands, NIH Syndrome kicks into high gear. Heck, I'd actually say it starts
around 30.

------
CraigJPerry
Is it no code or no programmer that’s the goal. The latter seems reasonable if
you’re software product customer that would like to trim out the person
between you and the product that seems to be slow only to misunderstand what’s
needed.

E.g. if you could get the end product with Less waiting and miscommunication.
I can see that being a sales pitch that resonates

~~~
satanspastaroll
>or no programmer

That seems to be the gist of it. SaaS seems to tackle this specific issue by
trying to move everything away from the customers in the first place. Don't
need sysadmins or software devs(here) if they're in the cloud(over there).

Their pricing model is often advantageous to smaller companies aswell; only
paying for what you use, even if that price is ridiculous per unit sold, it
still often beats hiring dedicated staff. This effect lessens over time as
company grows.

------
rsclient
The add_domain_name code has another buffer overflow problem

    
    
      const size_t size = 1024;
      char *dest = malloc(size+1);
      strncpy(dest, source, size);
      strncat(dest, "@example.com", size);
      return dest;
    

The first strncpy will not append a NUL character when strlen(source) is
exactly equal to size; the rules for strncpy and NUL termination are just
about useless outside of a few specialty cases.

(heinrich5991 found a seperate problem with the strncat).

IMHO, this helps prove the point about levels of abstraction. The only reason
that we argue over the idea that higher level == better is that we're
programmers, and we argue over everything :-)

~~~
Accujack
I have a hard time taking the author seriously if he confuses low level vs.
high level languages for primitive vs. advanced in language design.

------
cuhpajo
Everyone seems to want to make an analogy for why no-code tools are bad, or
will end badly.

But I've watched countless numbers of individuals start & build full web apps,
websites, mobile apps, and more - all without code.

No-code tools are viable to use to build a product or business, and they're
here to stay.

They're not here to "take dev jobs", but they are here to empower the 99.5% of
people that don't know how to code.

Imagine what features more advanced no-code tool platforms like Webflow.com &
Bubble.io will have in 5 years.

While y'all discuss pros/cons, we'll be busy building.

------
axilmar
I've read plenty of comments about this article the last few days, it has made
the rounds in popular sites, and the verdict is the same as the author's.

What's surprising is that no one sees the elephant in the room: the problem
with coding is that the abstractions available in coding are the same one
offered by operating systems: files, processes, threads, mutexes, sockets etc.
These are the wrong types of abstractions for the majority of cases!!!

What we should have instead is data, functions, events and channels.

If we had that, then we wouldn't need to have articles about 'no code', we
wouldn't need visual programming tools.

The abstractions we have now only get in the way of programming. They make
development really slow. If we had the set of abstractions mentioned above, it
would have been a lot easier to create solutions!

I am not saying that the abstractions we have now are totally useless; they
are not, of course, because they allow us to make things, but they aren't what
we need in most cases.

------
adamsea
Well, you could argue that _all_ software applications -- web browsers, word
processors, etc, are highly abstracted instances of graphical domain-specific
programming languages.

I actually think this is a useful way to think about things. We _all_ are
computer programmers - every single user. We just operate at different levels
of abstraction, and use different tools or languages to program the machine.

So then, rather than "No Code" vs "Code", it becomes "What is the cost of a
higher-level abstraction" vs "What is the cost/benefit of a lower-level
abstraction".

And if it makes sense to name one level of abstraction "code", and a level
above that "not code", then, so be it.

[EDIT: I think some useful examples are Sketch, Unity, Pro Tools, Photoshop,
etc. Graphical interfaces for users to perform complex operations with a high
level of abstraction. I guess I am arguing for, strictly speaking, considering
all software user interfaces as highly abstracted DSL's.]

------
cm2012
As a marketer, I always look for no code solutions first. API integrations?
Use Zapier. Email form integration? Sumo or similar. Triggers? Google tag
manager. Etc. The reason being that the dev team at any company never has time
for new projects.

~~~
Piskvorrr
So, instead of "learning a new language", they're "configuring a new
integration"? Guess how much these differ...spoiler: two marketing labels for
the same thing.

~~~
cm2012
I can train one of my juniors in how zapier works in an afternoon. Teaching
them (or myself) a programming language would take years and be more error
prone.

~~~
ebiester
I can teach IF, FOR, and the basics of python in a week. I can teach ruby in
about the same. For what they are going to need for a low code solution,
that's enough. You don't need to teach all of programming - only a subset that
would be covered in a low/no code solution.

If you don't believe this, look at how many non-CS professionals have learned
VBA as their excel-fu reached a limit. Even if it's not clean to start, the
natural human curiosity starts to take over.

One of the better programmers I ever knew had a high school education and was
working in an airplane maintenance facility when he was frustrated with the
tools he had and just started learning VBA on his own.

~~~
satyrnein
I think you might be underestimating what these tools can do. I'm not the
person you're replying to, but I have also seen a junior marketing person
create a Web form to be sent to clients (using Jotform or similar), have it
output to a Google sheet, have Zapier pick it up and move it to Airtable,
where he defined a bunch of extra fields for internal staff to annotate the
submissions, all while getting notifications when certain conditions were met.

Not only could he not learn enough python in a week to do this, but the
professional developers on my team could not do this in a week.

~~~
Piskvorrr
This actually feels very unixish. `form | sheet; crontab: zapier | airtable`.
Simple tools that can be simply combined - I feel similar about Tasker, where
I can combine various building blocks without worrying about compiling an app.
(It does get cumbersome without an IDE)

------
DonaldFisk

        BASIC was an attempt to allow people to write software
        in what looked like English, and indeed it was extremely
        successful (cf. Visual Basic).
    

The language designed to look like English was COBOL. BASIC looked nothing
like English. The reason it became popular was because you could develop
programs interactively - edit, run, load, and save programs - without ever
leaving the system. It was still programming, though (as was COBOL).

Visual Basic was released many years later, and looked very different from the
original BASIC.

~~~
collyw
Wasn't the main reason for VB's success the fact that it had a really good GUI
builder and that a version was integrated into Excel?

~~~
Turing_Machine
Yes, the VB GUI builder was excellent (as compared to the language itself,
which was meh, IMO).

Some people even used it to build GUIs for applications where the bulk of the
code was written in another language.

VBA was in all the Office applications... Excel, Word, Powerpoint, Access...

------
RickJWagner
The idea isn't new. I first saw it as '4GLs', which were higher-level
languages. Later we had rule engines and now AI.

Programmers never go away, though. Besides the need to write the
customizations that the higher level languages miss, there is the need for
disciplined thinking and testing. No matter how simple the tools become, the
need for these remain.

~~~
brazzy
You forgot about "model-drive development". And before that, COBOL was sold on
the same pipe dream.

------
malux85
Cute article, but worthless and shallow.

Sure you can replace 4-5 lines of python with some box-based UI rule system,
but anybody who’s not first week out of a 2 week coding boot-camp knows that
the devil is in the detail. What if instead of “display error” it’s “try again
if it’s a mail server error up to a maximum of 4 tries then email the
administrator and save debugging info”

Then what about a loop? Have you ever tried to debug a loop in a UI
programming environment? What about a complex loop with custom data types and
no ability to see a stack trace or variable list? You gotta put print dialogs
and system exits all over the place, and oh, the print dialog only prints a
small string? Now you gotta do 1 variable at a time, 200 times to debug. Now
I’m showing this to the “non-coder” who’s thinking “this is a giant headache”
- and you know what??? HE IS RIGHT, because we have both been forced to use
this crappy, blunt tool. Wasn’t this supposed to make things EASIER? Now the
business guy AND the programmer are tied up trying to shoehorn what would
otherwise be trivial for the programmer into this weeks novelty rinky-dink “no
code” tool

Ui drag and drop replacements only work for trivial examples, or they become a
giant unmaintainable spaghetti diagram that’s so complex you can’t even follow
the lines, let alone understand program control flow.

The fundamental problem with existing software is composability. Us geeks have
it at the command line, but regular users can’t pipe their brower through grep
them to their printer,

Users are stuck with the fixed options available at software design time, if
we could standardise a composable interface on all software (I don’t think
“bytes” is the right abstraction for this, it’s too low level) then users can
start dynamically composing their own solutions, which will take a decent
shift in thinking for most people - but a generational cycle will fix it if
young kids grow up taking composability for granted

~~~
commandlinefan
That's... exactly what the article says.

------
AmericanChopper
I think we’ve already been moving closer and closer to “no code” simply
through the evolution of programming languages and tools, much more than we
have through the advancement of specific “no code” frameworks.

Programming languages are becoming higher and higher level. Abstracting more
and more boilerplate and plumbing. Then you have frameworks specifically
designed to fill that role, and package repositories, further reducing the
amount of code you have to write.

The outcomes are that:

1) Your source code has a much higher ratio of business logic to everything
else

2) Your business logic is expressed in less lines of code, and in ways that
are increasingly becoming more similar to their natural language
representation

We haven’t reached “no code”, but we are currently at “much less code”, and a
lot of projects can be achieved with “very little code at all”.

------
thrower123
I've seen this so many times - rather than just write code to do something,
wouldn't it be grand if the users could plug their code in with some scripting
language or twiddle some configuration and poof! magic! new features just
happen!

It's one of those things that looks grand on the whiteboard and fantastic on
the slide deck, but holy fucking christ when it comes down to implementing it
and moreover, having to support it forever after, the pain spirals. Users
can't actually implement their plugins, so you end up writing them for them,
in a gimped DSL or scripting language, and all the initial choices that were
made become ossified, because you then can't ever risk breaking some potential
plugin code out there that depends on the API.

------
ivan_ah
> “No Code” systems are extremely good for putting together proofs-of-concept
> which can demonstrate the value of moving forward with development.

Another positive aspect is the ability to teach junior coders. One of the
coolest things on that front is MIT App Inventor
[https://appinventor.mit.edu/](https://appinventor.mit.edu/) — a webapp for
creating Android apps using Blockly-style blocks, see screenshot here here
[https://appinventor.mit.edu/explore/designer-
blocks#blocks](https://appinventor.mit.edu/explore/designer-blocks#blocks)

I was super surprised to see middle-school kids building real .apk and running
on their phone.

------
gerbilly
What makes programming difficult isn't the syntax, it's the need to define the
problem in an completely unambiguous and consistent manner.

~~~
mark-r
You forgot a couple of things. You need to define the problem in a way that's
complete (no missing corner cases) and be able to debug it when it goes wrong.

~~~
gerbilly
Good points.

I think it's interesting to compare source code and legal documents.

A similar need for precision, internal consistency, lack of loopholes is
needed when drafting a legal contract or legislation.

This is all done in natural language, but it doesn't make it magically easier.

~~~
mark-r
I often am thankful that I work with software and not contracts. Could you
imagine writing software where the instructions are not guaranteed to work the
same each time, and there is no way to test before going into production?

------
hyperpallium
"The last one" avoided the need to code back in 81
[https://wikipedia.org/wiki/The_Last_One_(software)](https://wikipedia.org/wiki/The_Last_One_\(software\))
and no one has coded since.

But abstractions and declarative languages have their place. Consider
relational algebra and SQL, and all the little declarative languages _within_
other languages, like regular expressions, printf/scanf format strings, even
char escape sequences.

But these require a _lot_ of thought and talent to up with, and to design
(e.g. codd didn't design SQL). Whereas TFA is talking about whole languages,
and designed ad hoc.

------
ajnin
"No Code" tools do have an actual advantage in that they only allow to create
valid programs. They don't prevent bugs however so that advantage is pretty
tenuous, it's akin to a type system that works as you go.

The main disadvantages are that they are harder to edit, copy, reuse, and
quickly become a tangled mess when programs grow in size.

Maybe there is a middle ground to find somewhere, keep text for editability
and because our whole education system is based on it and I'm pretty sure
humans have dedicated brain structures to process language, write basic blocks
in a regular programming language, and create DSLs to write "business logic"
in.

------
awkward
The current focus No Code will create a large number of tools a skilled
technologist can use to improve productivity. The new tools will open up
problem domains where the time and budget wasn't there before. It's clearly
not going to replace code, for reasons that everyone has enumerated here.

The reason it's getting VC attention right now, though, is because No Code is
a way to discipline the market for programmer salaries. Even if the effect of
it is more glue code over more protocols, the goal is to shift jobs from
engineers to technicians.

------
joddystreet
We tried building NoCode (used to be hosted at noapp.mobi), I think around
January 2017. The project has been abandoned since then, you can find the
project at -

1\. Docs - [https://github.com/veris-
pr/v3-docs/wiki](https://github.com/veris-pr/v3-docs/wiki)

2\. Core - [https://github.com/veris-pr/v3-core](https://github.com/veris-
pr/v3-core)

3\. Backend - [https://github.com/veris-
pr/v3-api/tree/develop](https://github.com/veris-pr/v3-api/tree/develop)

4\. Mobile App - [https://github.com/veris-pr/v3-app/tree/feat-
offline](https://github.com/veris-pr/v3-app/tree/feat-offline)

5\. Mobile App - [https://github.com/veris-
pr/v3-client](https://github.com/veris-pr/v3-client)

Quick demo (forced under 2 minutes time, we tried to take this to TechCrunch),
[https://www.youtube.com/watch?v=HfZT75rduPg](https://www.youtube.com/watch?v=HfZT75rduPg)

This was a POC project. It was quite suitable for simple business process
management based apps. One of our customer has been using a conference room
manager built on this platform, for 3 years now.

------
npollock
"No code" does not equal "no programming". For me, programming is 90% about
how I structure/organize a process, 10% is the expression of said process
through code.

------
bitwize
I keep saying it. Whatever non-code representation you may have for your logic
-- dataflow diagrams, interpretive dance, Minecraft redstone, whatever -- you
need to make it unambiguous enough that a machine can act on it in a well-
defined way, and once you do that what you have is isomorphic to a construct
in some textual programming language. And lines of text are going to be easier
to input, edit, and maintain than your chosen representation, barring some
_major_ UI revolution.

------
miguelmota
The problem with "No code" platforms is that you're relying on magic provided
by the platform tools so when it's time to extend or modify the code it's a
total nightmare (remember Dreamweaver?). In a sense it's vendor lock-in. "No
code" systems work for simple things like visual layouts (Squarespace) or IFTT
GUIs for simple actions but anything beyond will be a hassle to maintain and
extend when you need to.

------
rvense
I'm not really sure I'm seeing anything that isn't the logical continuation of
the move from low-level languages to higher level languages, and from lots of
bespoke software to frameworks and libraries.

A big pile of Zapier gunk might be brittle, but I think tools like it are a
natural progression in a society where everything is dependent on computers.
To me it's part of "Everyone should learn to code".

------
janci
Visual tools work great for creating models (i.e. entity diagrams). There is
no reason why not generate 90% of the typical business CRUD app boilerplate
from such model. Also business rules tend to be simple (decision tables,
process workflows), no need to "code" these. If they are not simple enough for
business user, representation in code will not help, so business rules should
be kept simple.

What I lack in visual/no-code environments: easy bidirectional integration.

The no-code environment should be able to call into external service (REST,
SOAP) or external library (any language) and represent this call as a Black
box. The interface should be simple to be able to easily create the missing
functionality in best-suited language for the task. But more importantly, the
external implementation should be allowed to use all the powerful high-level
abstractions that the no-code environment presents to the user. Otherwise, the
external service will need to re-implement many of the useful functions of the
no-code environment. You then lose all the benefits of the no-code counterpart
and this transition is hard.

------
TrackerFF
The closest I've been to "no code" is using LabVIEW, Function blocks diagrams
in PLCs, and more recently Node-RED.

I've seen engineers (with self-professed terrible programming skills) build
working things with those tools - and yes, there's some code here and there.
But those have been for rather specialized and smaller tasks...I can only
imagine what a HUGE LabVIEW project would look like.

------
dscpls
This says it's very either or, and I think misses the point of a lot of nocode
tools.

One of the best measures of tools is their composability. Can you use this for
what it's good at, and integrate that solution with another tool that's much
harder to use but can solve the last 5-10% that's just too hacky or not
supported directly by this tool?

For my that's where zoho creator falls down a bit. Their APIs are just web
form post handlers. But it works!

We're doing a lot of stuff on webflow by dropping some custom javascript in
there to hook it up to an API or do some very data-driven stuff beyond their
interactions.

The point is, nocode isn't just for proofs of concepts, although it's great
for that.

When evaluating nocode tools, look for integration/extension points, and think
about your migration path should you need to replace it. Hopefully you're
succefful enough to need that but don't build 100% of your app by hand because
10% actually needs hand-written code.

------
BerislavLopac
The obligatory Commit Strip: [http://www.commitstrip.com/en/2016/08/25/a-very-
comprehensiv...](http://www.commitstrip.com/en/2016/08/25/a-very-
comprehensive-and-precise-spec/)

------
reallydontask
Microsoft are pushing the concept of citizen developer like crazy with their
Dynamics 365 platform and things like Flow, Logic Apps and PowerApps.

Having worked on that space, I find the potential users (that are not
developers) to be pretty limited, YMMV

------
kaikoenig
I think no code has its place. I view that as a step/experiment towards a
common "language/notation" to describe how a business interacts with its
surroundings that is not Java or the likes. Will be really interesting to see
where this all leads or if it blows over.

BTW - of course we are also build such a thing at Bitspark -
[https://bitspark.de/slang/](https://bitspark.de/slang/) or
[https://github.com/bitspark/slang](https://github.com/bitspark/slang)

------
richieb
As I recall, Assembler was the first "no-code" tool. After all you could get
rid of all those pesky programmers who knew all the number codes for
instructions. Anyone could write "ADD R, R2". See!

------
IC4RUS
The article mentions that, if you are not free to go, then the police must
read you your Miranda rights. This appears to be a common understanding as
well.

However, other sources I've read state that police don't necessarily have to
do this unless they want your testimony to be court-admissable
([https://www.nolo.com/legal-encyclopedia/police-
questioning-m...](https://www.nolo.com/legal-encyclopedia/police-questioning-
miranda-warnings-29930.html)).

So I'm a bit confused - could someone clear this up for me?

~~~
fargle
In the US - See [https://www.nolo.com/legal-encyclopedia/police-
questioning-m...](https://www.nolo.com/legal-encyclopedia/police-questioning-
miranda-warnings-29930.html) for example.

Read carefully and you will notice:

\- they don't _have_ to Mirandize you even if arrested or detained. If they
don't, your answers and evidence based on them will _probably_ be
inadmissible, _if_ your lawyer is not an incompetent boob.

\- they don't have to Mirandize you at all with no penalty _unless_ you are
detained or arrested. If you are "free to go", for example if asked a question
at a traffic stop, Miranda is irrelevant. What you say will always be used
against you.

\- _always_ , in all circumstances, assume that your statements WILL BE USED
AGAINST YOU.

\- At a traffic stop, you say "here is my license and registration" and
"please, thank you, have a nice day". NOTHING else, which is quite a bit
harder to do than it sounds.

When in an adversarial position with the police, it's best to remember that it
is literally not their job to be helping you. It's not their job to be "fair"
or to be your ally. They are ALLOWED TO LIE to your face, and might do so.

But the rest of the time, which is most of it, they _are_ your ally. You will
know which time is which - act accordingly. In all cases, respect is wise, is
warranted, and is well deserved. Remember the number of our friends in blue
who have died because of some bad person. And note that until they understand
you, they may quite reasonably assume you are one. Don't be an A-hole and
prove it to them. Don't lie, it would be obvious, suspicious, and insulting.
Just say nothing or shrug. Don't be a dick and try to argue - save that for
the courtroom which is when it is appropriate.

But you still don't ever have to say things like "Gee I thought I was _only_
doing 80" or "I didn't see that guy, he musta came outa nowhere"...

------
agent86
As someone who has been managing Low Code/No Code on a large scale for a major
enterprise from before this became buzzword soup, I can categorically state
that the benefits are real.

HN isn't the intended market here, and that disconnect is shown in the
currently leading comment thread which is talking about DevOps deployment.
DevOps is way beyond what this space currently targets and is working to
achieve.

To be crystal clear, Low Code/No Code is not going to replace a company's
custom developed application that drives their core business. It isn't even
going to replace the need for custom application development throughout an
enterprise. This is an augmentative technology stack intended for a different
audience.

What it does do is empower non-IT employees to become what the industry likes
to call "Citizen Developers". Think more Excel/Access less <insert favorite
language/framework here>.

Where this technology currently shines brightest is at the lowest levels of
work. Every enterprise has pockets where work is getting done from Excel
spreadsheets, Access databases, email chains, SharePoint/Office documents and
worse. Essentially work that could be done easier and better with an
application, but where the current enterprise cost, developer availability,
political/agility issues, or simple knowledge that the problem exists prevents
that application from being created.

The best products in this space allow IT to setup a space where non-IT staff
can create applications within the confines of the environment to address
these problems. For example, a department can go in on their own and replace a
shared spreadsheet that is locked all the time from coconcurrent use with
something that is truly multi-user. On top of that, they get to enhance their
process and improve productivity by having it generate emails to someone when
work is needed, or automatically create new tasks when certain statuses are
encountered, and other similar things associated with "modern" technology.
They do all of this on their own without needing formal IT development
resources.

There are obvious benefits to an enterprise here - like replacing multiple
unsupported/bespoke solutions with a single known and supported platform - but
there are multiple side bonuses as well. For an example of one, the best
products in this space have great APIs. The staff making/managing these
applications may not even know they exist, and certainly can't write against
them, but now IT has a standardized way to get this data somewhere else when
needed. Data driven organizations can use this to drive what I call "Small
Data", which is applying Big Data practices/analytics to low level work
product to improve processes.

The next major development in this space will be low code/no code
integrations. When you're talking about these low levels of work, they are
generally mid-process actors. Work comes in, gets done, and is handed to the
next in line. That data largely gets to these teams from some kind of export
process in the upstream system - CSV dump, daily email, etc. - and then needs
to get fed back up via a similar or worse method. You can use the
aforementioned API to fix this, but that again requires developer resources.
This may be doable to for interacting with a core upstream system but it isn't
always available when you have two bottom level processes looking to
communicate.

The ability for "Citizen Developers" to be able to obtain the data they need
from an upstream process, complete the work on it inside their application,
and then return the results back to the upstream process or next process in
line without having to write code or otherwise manually intervene will further
drive productivity and usefulness in this space.

~~~
chasingthewind
I don't think the intent here was to say that LC/NC isn't "real" but that it
has been oversold.

At my last company they attempted to implement a project in a low code
framework and they eventually had to pull back significantly because the
requirements were simply too complex for the framework to handle in a
reasonable fashion.

The lesson is "use the right tool for the job."

~~~
agent86
Completely agreed! A key portion of managing these platforms is understanding
what should NOT go in them.

Because the products are designed for low or no code development they are
inherently limited in what they are capable of doing. This is the obvious
trade off for the simplicity of that platforms.

Initial analysis to make sure the platform fits the requirements is very
important. Also important is understanding that many projects may start on
this platform, grow in functionality over time, and eventually need to go
beyond the limitations of the platform. I call these applications "graduates",
and you need a method to manage the transition out of Low/No Code platform to
something else.

------
uberdru
And using our new graphical "workbench", your business users will be able to
integrate applications without placing any burden on your development teams.
Sign here. . .

------
loh
I agree with the author for the most part.

An exception to this rule is that in terms of front-end (or end-to-end)
testing, if an application is deterministic, you most certainly don't need to
write any code to create tests for it. You can record actions and snapshots
and replay the actions and compare snapshots. There can often be more to it
than that (like filtering dynamic elements/attributes and pattern matching),
but for the most part, this approach works quite well.

------
l4r5
I use this metaphor: If you only learned 50 words from a new language, that
may be enough to have a great 2 week vacation but it won't be enough to
actually life somewhere else and do successful real legal business.At least it
will be quite hard to do so.

Learning a language to be able to do that will take some time and training.
But once you learned it, life will be much more easier and success will be
easier.

Computer languages are called "languages" for a reason.

------
ravivyas
Disclaimer: I work at a low-code startup.

If anyone discounts nocode/lowcode they are missing the forest for the trees.

NoCode always existed, the term is getting popular now. Wordpress is a nocode
website builder.

When you hit a 3rd party API, you are reducing a part of the problem to
nocode. Would you care if the API was written in C/Java/Python or was a Zapier
interface?

Can nocode/lowcode reduce bottlenecks or speed up developer of critical but
not urgent things/components definitely.

------
Twirrim
I've luckily missed all the "no code" stuff. This has so many shades of that
"no ops" nonsense that was being peddled about 5-10 years ago, which seems to
be rooted in similar misunderstandings.

If you want to run your company on a "no code" basis, good luck with that! I'm
sure your Finance and product managers won't complain at all when they have
their VBA macros taken away.

------
ptah
> software developers are expensive

in most businesses the business experts are more expensive. wasting their time
with building systems can be costly

------
throwaway55554
> Increasingly popular in the last couple of years, I think 2020 is going to
> be the year of “no code”: the movement that say you can write business logic
> and even entire applications without having the training of a software
> developer.

Last couple of years? I'm sorry, how long have you been in the industry
because the industry has talked about that forever.

------
ewgoforth
The idea that you can write software without having to learn to code goes all
the way back to COBOL in the fifties. It was a big step forward in abstracting
some of the details. As languages have progressed they abstract away details,
but you still have to be able to think like a programmer, especially if you
want your code to be performant.

------
scottlocklin
I'm looking forward to the day when someone builds a labview type thing for
some other common programmer function. Labview was literally an extinction
event for instrumentation software engineers. Month long projects done in
minutes.

Same thing will eventually happen with something like devops, regardless of
what programmer bros think.

------
boyadjian
Whatever the abstraction of the language you use, you still have to code. It's
just a different type of coding.

------
streetcat1
The no-code solution would probably come from machine learning, and not from
automating logic-based programming.

------
imvetri
I have a working concept for "no framework Code" in front end web development.
[https://github.com/imvetri/ui-editor#ui-
editor](https://github.com/imvetri/ui-editor#ui-editor)

------
mc3
"No code" doesn't mean no logical thinking, no worrying about changing
requirements, no version control, no uptime and performance considerations, no
cost considerations, no analysing requirements, ... very little of what a
coder does is write code!

------
TruffleLabs
Change control is always a people problem re: “change control” becomes a
software problem rather than a people problem.

Changes are made by people and the changes affect people. Software can help
track, control, sustain. But the actual change start with people.

------
xiwenc
The delusion is thinking "no code" solves all your (classical) problems. It
does not. No code is the future riding the waves of simplifying programming.
Like going from C -> Java -> Python -> (Low code) -> No code

------
0x8BADF00D
I always thought "no code" was a meme. Best example of "no code" were the
traders I used to support working at a bank, they had these massive Excel
sheets with weird macros that would break in non-deterministic ways.

------
Animats
I miss the days when you could create a web site without coding. Remember
Dreamweaver?

------
yters
Why does the common non programmer need a visual UI? Why so allergic to typing
text? The rest of the average office worker's job takes place through the
traditional CLI known as English (or other language).

~~~
AnIdiotOnTheNet
Discoverability is vastly superior in visual interfaces.

------
alxlaz
I was pretty young back then but I do remember a lot of these things being
driving forces behind 4GL and 5GL languages. I played with a lot of these
things because I was just getting into programming and I was still at the
"syntax is hard, maybe what I need is a simpler language" phase...

A lot of these things failed for reasons that are, I think, fundamentally
unavoidable if your goal is to not learn anything and just do it:

\- Tools that emphasize (or function exclusively based on) configuration over
over code are limited by things that you can configure. As soon as you stray
beyond that, you not only have to code, but you have to code for a system that
has _a lot_ of implicit behaviour. That's a hellish experience if you're an
inexperienced programmer. Figuring out why your code produces a result other
than what you expected is hard enough. Figuring out why your code produces a
result other than what you expected _because there 's a default configuration
flag_ that alters its behaviour (or, worse, that alters the result after your
code correctly computes it) is way more complicated.

\- Tracking changes in systems that emphasize (or function exclusively based
on) configuration over code is insanely difficult, and reverting systems back
to a specific state is pretty hard, too. This may be less of a problem today,
in the age of containers, I guess.

\- _Validating_ changes in such systems is even more difficult than that,
because a lot of the logic is implicit and hidden from sight. If you have to
make a change in a system you're not too familiar with, reading the code can
give you an idea about what behaviour would be affected. If your change breaks
something, reading the code can help you debug things. If there's no code to
read, or you can't do it in the first place, and changing the header of a
column just broke your reporting tool, you're going to spend a few fun
evenings at the office poking it with a stick until it un-breaks.

\- Tools that emphasize integration of separate tools over coding result in
systems that aren't very fun to maintain. Changes in the way components
interface were a problem even in the early 00s, and they weren't on a
rolling/continuous release schedule, weren't delivered "as a service", and
"move fast and break things" was just called being sloppy. Integrating a dozen
third-party modules today requires full-time maintenance, from someone who can
definitely code.

I do think that making it possible for end-users to automate their work is a
direction worth pursuing, but this isn't the way to do it, and I think there's
a wealth of lessons from two decades of failures to learn.

IMHO, some broad directions worth pursuing would be:

\- A simpler and more stable development framework. Keeping up with JS and CSS
frameworks (many of which exist precisely because pure JS and CSS are pretty
painful to use if you want to develop a desktop-like application) is hard even
for people who use them professionally. There's no way you can ask business
people to keep up with _that_. A more stable framework, that hides the fact
that browsers were never meant for application development well enough (even
if that means less flexibility) could go a long way towards making things
easier.

\- Better DSL integration in business tools. A lot of the business logic is
written in the same language as, and embedded in, the overall application
logic. That doesn't necessarily have to be the case. Template engines are
sufficiently advanced today that you can do a lot with them, and I've seen
people without much programming knowledge being able to use them productively.

\- Oh and if we're being honest: better code quality where code really can't
be eschewed. Virtually every business app I've seen in the last ten years is
the same story: a user needs a change, they can articulate it perfectly well,
they can describe the logic in pretty good details, sometimes they can even
give you an Excel sheet that implements it so that you can see a few examples.
The only reason why they can't make the change themselves is that sorting a
table by date instead of name doesn't involve replacing SORT_BY_DATE with
SORT_BY_NAME in a template, it involves changing half a dozen SQL queries, two
hardcoded parameters in some JS function calls, and introduces a subtle bug
because passing SORT_BY_DATE in that function call actually modifies the table
in place, which is a global variable, and that table is then reused by another
function which assumes it's sorted by name.

~~~
tabtab
Re: _" A simpler and more stable development framework. Keeping up with JS and
CSS frameworks (many of which exist precisely because pure JS and CSS are
pretty painful to use if you want to develop a desktop-like application) is
hard even for people who use them professionally. There's no way you can ask
business people to keep up with that. A more stable framework, that hides the
fact that browsers were never meant for application development well enough
(even if that means less flexibility) could go a long way towards making
things easier."_

Indeed! We need a GUI/desktop-oriented markup _standard_ for in-house and
custom CRUD. It's a big market that shouldn't ignored at the expense of other
markets (such as sales-oriented websites).

All the companies who want a chunk of Microsoft's business should get together
and help define such a standard. Google, IBM, Oracle, Amazon, Apple, do you
hear that? The MS pie is waiting to be sliced up for YOUR benefit. Get on it!

------
mootzville
"no code" will work when the halting problem is solved...

------
zubairq
Having made a no code tool myself at yazz.com I definitely agree with many
parts of this article. For prototypes or very simple one screen crud apps no
code can be the right fit

------
jacquesm
I'm super skeptical about anything that claims to be 'no code'. That said, I
had an in depth look at Mendix and I have to say I'm impressed.

~~~
rchaud
It depends on the use case. For processes that are stable and where most edge
cases have been solved, no-code is ideal. Take Salesforce for example. You can
build a number of mini-applications, like say a university application
tracking system, simply by throwing together built-in components in SF.

------
winrid
By "No Code" I like to think people mean "the code is already done and all the
abstractions defined suit my needs as desired".

------
scarface74
This is not new. There were plenty of companies promising the ability to
create applications without writing code since the 80s.

------
m0zg
There's a variant of this fallacy where people are sold on GUI frameworks in
which design is separate from the code that drives the logic (i.e. XAML). The
argument is, the designers can't code, and the coders can't design. That too
doesn't really work if you want great UI, and it complicates the lives of both
the designers (tooling is shitty) and the devs (the databound visual tree code
is opaque AF and therefore impossible to debug).

------
tomelders
This really resonates with me, but I don’t agree with it.

It resonates because there’s a problem with software development that remains
unarticulated. It seems no one is happy. Developers aren’t happy, and the
stake holders aren’t either.

For stakeholders, the people originating the ideas, signing the cheques and
bankrolling the entire endeavour, programming really is a money pit, and
programmers really are a pain in the ass. So no wonder people are so enchanted
by the idea of software that doesn’t require code or coders. All they want is
for their grand ideas to be realised as they imagine them. How hard can that
be? If Computers can be made to identify faces, or translate French into
Chinese, then surely their vision of an app that figures out the most
efficient way to deliver parcels should be a walk in the park!?

For me, herein lies the problem. Computers are seen as magical devices capable
of anything. Software, or code, merely the spells and incantations that breath
life into those machines and commit them to do your bidding.

But! They are not magical devices. Code is not spells. Programmers are not
magicians. There are constraints. Boundaries. Limitations. Great software is,
in some way, defined by those boundaries. Great software is created not by
people who believe that computers and code can be made to do anything. Great
software is not the product of whim and whimsy. No. Great software is created
by people who know the constraints, but see the opportunity within them.

Take for example, the Spreadsheet. No accountant, or any other form of number
cruncher was involved in the conceptualisation, implementation, or evolution
of the spreadsheet. The spreadsheet was born out of the minds of people who
understood the capabilities of computers and code, and saw how they could be
used to approach a problem from a different angle.

I would argue that the most significant event in the evolution of the web —
after it’s invention — was Ajax. Yet no one, not even the people who first
implemented XMLHttpRequest, fully understood its true potential until Jesse
James Garrett came along and clarified the concept and significance.

HTTP had existed since 1996, and four years later, Roy Fielding gave us Rest —
The recipe to a dish we already had the ingredients for.

What’s my point? I suppose I may have gotten off track. My point is this: The
problem is not that code is hard, or programmers difficult. The problem is
that software — which was once borne out of opportunity that only the
programmer could see — is now born of the whim and whimsy of people who know
nothing of what a computer can do, or how it does it. Software is the folly of
people who believe in magic. People who aren’t thinking “what can this machine
do”, but rather “make this machine do what I demand”.

------
davidpolberger
No-node app builders are certainly no panacea, and I say that as a co-founder
of an app builder (Calcapp). However, if your requirements fall into a domain
that is common enough that no-code tools exist, people who don't consider
themselves developers can often get a solution in place remarkably quickly.
Database apps (CRUD) appear to be the target of most no-code products --
define your tables, build your user interface, bind fields to columns and
you're good to go.

Of course, a real pitfall is that you often bump into the limitations of your
chosen platform after having completed 80 percent of the work, and then you're
either stuck or need to devise elaborate workarounds.

We see many app builders that truly use no code in the traditional sense. The
simpler of these tools essentially only allow users to wire together pre-
fabricated building blocks, like content screens, chat rooms and the like.
More powerful app builders allow logic to be described using visual flow
charts.

We have taken the approach of trying to cater to spreadsheet users, and put
formulas at the front and center of everything. (Much like Microsoft
PowerApps, in fact, though Calcapp precedes it.) Formulas enable complex ideas
to be expressed. Ultimately, we put our faith in users having an easier time
learning a reactive, functional programming language than they would have
learning a traditional, imperative programming language. Fundamentally, the
reactive model enables users to express relationships between entities without
having to concern themselves with ordering. Supporting only pure functions,
with no side-effects, means that we can cache results aggressively, much like
a spreadsheet.

There are limits to this approach, though. If you want users to press a button
and have different things happen depending on a condition, how would you
approach this? Currently, you can't, at least not with Calcapp. Taking actions
in response to an event being fired is, per definition, something that
requires an imperative approach.

With some trepidation, we're working on enabling formulas to be "run," but
only in response to events being fired. These formulas would have access to
non-pure functions (changing global state) and even an assignment operator (as
well as semicolons, so that multiple statements can be executed). We will
likely call them "action formulas."

The challenge is that all this should feel familiar and logical to an Excel
user. For instance, we're introducing anonymous functions (lambdas), which can
run asynchronously in response to, say, a user pressing a button in a message
dialog, but lambda parameters will have default names, meaning that using
"arrow syntax" (like in Java and ES6) to name parameters will be optional.
We're trying hard not to introduce syntax that would look strange to an Excel
user.

I think it's reasonable to refer to app builders supporting spreadsheet-like
formulas as "no-code tools." However, what about app builders supporting
imperative programming, using a text syntax? We're well aware that we could
introduce functions like WHILE, DO and FOREACH that together with lambdas
would turn Calcapp into a full (Turing-complete), imperative programming
language. Can such a tool still be considered to be a no-code tool?

Probably not. I suppose that's why there's an additional moniker: low-code.

~~~
commandlinefan
> if your requirements fall into a domain that is common enough that no-code
> tools exist,

… then you can quickly and easily, with very little cost, produce something
that anybody else can quickly and easily, with very little cost, produce. Try
not to be too surprised when it doesn’t turn out to be particularly valuable
or helpful.

------
anigbrowl
_At the heart of the issue is the concept that “computer programming” - which
is to say, writing code - is a constraint on the development of software. That
there is some “higher level” on which people can operate, where development is
much simpler but the end results in some way the same.

Specifically, the idea of writing business logic in text form according to the
syntax of a technical programming language is anathema. To make an analogy:
it’s a little bit like saying all software developers are like car mechanics,
who get into the guts of an engine. But most people just need to be able to
drive the car, and a simpler interface can be put on top of the machine (a
steering wheel and some pedals)._

This is a bad, bad analogy. There _is_ a higher level on which people can and
do operate, and it's called 'drawing flowcharts'.

The correct analogy for the case of a car is not abstracting the work of car
mechanics to be more like a car dashboard, but making it easier to view car
schematics as opposed to textual descriptions that convey the same information
but have to be processed in linear rather than holistic fashion.

To be sure, there are many 'build without code' tools available that over-
simplify or promise that to never expose the user to any complexity, and that
is indeed a delusion at best and a lie at worst. But the idea that complexity
can only be effectively represented in textual form by elaborate syntax is
equally absurd; it's simply a product of what technology was practical at the
time. It's not better, as such; it's just what he have a lot of.

Consider assembly language. I love it; it is so basic that it takes me back to
the delight of understanding _Towers of Hanoi_ type problems and I get a kick
of out of reverse-engineering things in a debugger. But writing any kind of
large project in assembler is not a good idea if you want anyone else to get
involved, because it's not very accessible - hence the popularity of high
level languages.

But high level languages are in many ways a product of keyboard input and
monitors as assembler was a product of punch cards and blinkenlights. They're
great, but they're also hard to read - and so as time has gone by things like
syntax highlighting and autocompletion have become standard in editors. You
_could_ learn to code without any syntax highlighting; it didn't exist when I
started. You _could_ learn to just read everything in assembler.

But once you have a useful tool available, demanding that people refrain from
using it because it makes things too easy is just expressing a sort of anxiety
about the existence of shortcuts that were not available to you, and the
resulting ability of others to catch up to you in less time than it took you
to learn.

So it is with the 'no code' trend. People who spent a long time learning to
code _have_ developed very valuable engineering skills, but that doesn't make
the more high-level component-assembly approach of no-coders invalid. The no-
code people want to focus on domain problems (which they often understand
very, very well) and not get caught up on the minutiae of language syntax;
they're comfortable with the fact that someone else has been able to automate
that in such a way that the computer does most of the work. Fighting this
trend is like getting hung up on the inadequacies of Lego - all that
blockiness, the general inefficiency, and path-dependency problems of building
things out of lego rather than making them from scratch - while overlooking
the fact that it's so easy that kids can do it and that it's a fantastic way
to quickly prototype any sort of toy you want.

 _In the first [flowchart] example, I need to know how the visual environment
works. In the second, I need to know a language and a development environment.
But both of those are skills that are easily acquired._

No! one of these things is _not_ like the other. It's waaay easier to
understand flowcharts than it is to acquire all that syntactical and semantic
knowledge. This isn't to deny the utility of text for specificity, but to
point out that it only seems equivalently easy because the author _already_
learned to write code and has _not yet_ learned visual programming in depth. I
encourage people who doubt this to spend some time building actual electronic
circuits. After all, programming is just high level circuit design, so it
should be easy, right? And if you're already good at electronics, why not just
get into making your own components? After all, making electronic components
like capacitors and resistors is just high level material science, right? Real
programming is about pulling stuff straight off the periodic table and just
working out the math, right?

Of course it isn't, circuit design is its own discipline in which you spend a
great deal of time wresting with (or exploiting) the fuzziness and quirks of
electrical current flow instead of being able to take exactitude and precision
for granted, and so on down. Conversely, the path forward for established
coders in an increasingly modular world is exploiting their acquired skills of
extreme precision and efficiency to make better modules that do things by
magic and finally fulfil the promise of libraries to provide collections of
functions that Just Work and do so reliably and speedily enough that they
don't need to be rewritten over and over and _it doesn 't matter_ what
language paradigm the downstream user has in mind.

In the article's example, all the downstream user cares about is whether the
email validator is RFC5321/2 compatible and what speed throughput it has. It
_shouldn 't matter_ how it was made, the same way it _doesn 't matter_ to an
electronics hobbyist precisely how a 555 timer works* and it doesn't matter to
a low-level circuit designer how it gets manufactured.

* although when you do start caring about how a 555 timer works, this is the most fun way to explore it: [https://www.adafruit.com/product/1526?gclid=CjwKCAiAx_DwBRAf...](https://www.adafruit.com/product/1526?gclid=CjwKCAiAx_DwBRAfEiwA3vwZYsrg7fyuqAmhQniEp7m5Gj_jvwuSUMd-ce9dRAh0cSGuPPivgMfVzhoC7h0QAvD_BwE)

------
tomerbd
anyone tried bubble?

------
Piskvorrr
TL;DR: it all boils down to reinventing Common LISP.

