The Coming Age of "Natural Ned"
When do programming languages stop being programming languages, and just become languages?
Back about twenty years ago, I was assigned to lead a team of people who were tasked with tackling a mountain of bugs that had cropped up in a new product we were developing. I think we started calling these groups “Tiger Teams”, which although a common term feels rather cringe-worthy to me now. But anyway, my coworkers and I would spend a couple of weeks at a time, focused on trying to wrestle our custom Verilog compiler product into behaving. It was a monolithic, hard-to-debug beast that had been originally written for a different mission, but was now being extended on short notice to perform duties for another product.
A host of issues had come up as a result, and the fixes to these problems often required complex changes to many layers of the software, more akin to a re-architecture than a bug fix. Although I was the manager of this team, I would also roll up my sleeves and help with a lot of the technical work of making these complex changes.
One day in the middle of a particularly hairy fix, I got up from my desk and left behind my running emacs editor, chock-full of open files that contained various functions that all required changes to their parameter lists. I was taking a break from the tediousness of it all, because it seemed that every simple thing I wanted to accomplish would require plumbing changes everywhere.
I’m not going to talk too much about why things were this way or what should have been done — obviously, a better software architecture would have been nice, or better refactoring extensions for emacs maybe. But the world I was living in back then didn’t have any of these luxuries, and the fixes really did involve just slogging through the code. During my break, I met up with one of my coworker friends in the hall.
“I’m going to invent a programming language with no hierarchy.” I declared.
“No hierarchy?” my puzzled friend replied.
“Yeah. No hierarchy. No classes, functions, modules, packages. Everything inlined and global. That way I don’t have to spend all this time worrying about getting things from point A to point B.”
“Sounds promising.” my friend said. He was the type that was willing to entertain ridiculous and amusing thoughts, and he offered no criticism of this obviously dubious idea. And it was dubious even to me, as it sounded even less capable than the old-time procedural languages I grew up with. Even BASIC had a GOSUB statement. But I was riffing.
“Look at nature.” I continued. “When you get right down to it, there is no hierarchy in the natural world. Things are not ‘inside’ of other things, really. At least once you get down to the atomic level. Reality is flat, just a bunch of atoms next to each other, not inside each other. We should have a language that works like that, the way the real world does.”
“It’s gonna take a while to program at the atomic level. And anyway, wouldn’t that be just like writing machine code?” my friend said, offering perhaps the first resistance to the increasingly-unuseful language I was planning out at the water cooler.
“Yeah.” I agreed. “That’s why it has to be like a really abstract language. I’m thinking you just tell it stuff. Like ‘FIX THE BUG’. There will be some compiler work needed on that. But once it’s working, none of this passing parameters into functions stuff will be needed anymore.”
My generous friend once again entertained this new, unimplementable wrinkle I had added, which cut to the heart of the matter more directly: I just didn’t like the drudgery of the programming work I was currently occupied with.
“Great! We can call it ‘Natural Ned’ !“ he declared, and then went on to scheme about how we would create a ‘Natural Ned’ certification course, and charge people a lot of money for gaining unnecessary credentials, in the vein of what Microsoft was up to at the time.
For some weeks after that, we would bring up Natural Ned as kind of a running joke, whenever someone complained that a bug was hard to fix, or that a feature could not be implemented. “You could easily do it in Natural Ned”, we would say, in a less-than-helpful way.
An exasperated engineer would eventually ask, “So when are you going to write this ‘Natural Ned’?”
“I’m not.” I would reply. “Natural Ned has to write itself.”
And with that final defensive paradox in place, people began to realize the futility of making rational arguments about Natural Ned, and the whole joke kind of just faded out, because we had extracted all the fun out of it.
I had a high school programming teacher who would love to tell the story about some old mainframe compiler that compiled itself, without any explanation of how that could happen. He was an intimidating enough guy that no one actually asked him what he meant or how that was possible, and to be honest I kind of wonder if he even understood himself.
Obviously, the idea that a compiler can contain code written in the language the compiler compiles is pretty common. But there is always some sort of boot-strappy process, either involving some other language or some other compiler, to get things going.
My high school teacher never spelled out that bootstrap thing out for us, nor did I attempt to do so when talking about the creation of Natural Ned. It was, as they say, an exercise left for the reader.
As for the product I was working on, it was really not a good one, and it was canceled, despite our best debugging efforts. Better products were created, the company was bought, people moved around, other good products and bad products were created, and lots of stuff happened. I didn’t really think about Natural Ned too often, except when occasionally reminiscing about the old days with ex-coworkers.
Fast-forwarding twenty years, Natural Ned has moved for me from nerdy joke, to thought exercise. Nowadays it is not so ridiculous to think about software that can accurately interpret natural language. The idea of creating applications with low code or no code has gained a lot of traction, and the concepts of software writing software, and of systems that can learn and improve themselves are, to a large degree, a reality now.
As I think about all that new stuff, Natural Ned (or some similar thing that gets bootstrapped into existence) takes a seat at the table, serving as an abstract and purposely unspecified programming language to test various questions against. Lotta questions. There are a lotta strands in the old Duder’s head, and here are just a few samples:
Is Natural Ned Even a Programming Language?
Although only vaguely defined, Natural Ned has the stated quality that you should be able to just tell it to do stuff, without a lot of hassle. Let’s skip the discussion then about whether it is Turing-Complete and things like that, and go straight to the central issue: is it even a programming language?
If I tell my daughter “Please go mow the lawn”, that is a request, or maybe a command. (If it was a machine instruction, the processing unit in question does not guarantee on-time execution.) But “Go mow the lawn” isn’t really a programming statement, it’s just me speaking English and asking for stuff.
How about if I gave the lawn-mowing duties to a robot, and told it to mow the lawn? If I just told it somehow to “do it”, then it still sounds more like a user interface than a program. But what if I were more detailed and said a series of things in my request:
while lawn not mowed:
mow left
turn around
mow right(Yeah I guess this robot is written in Python or something). This seems a lot more like a program, even though the pseudo-code is very abstract and pretty much would require the same mystical abilities to execute properly as the one-line command.
If it is a program, what makes it so? Is it the multi-line nature of it that makes it a programming language? Many programming languages allow single-line programming (and some weird esolangs encourage it probably). Is it the fact I have created a syntax of sorts? Well, plain English also has a syntax. (A very weird and complex one, but a syntax nonetheless) Is it the colon and tab formatting? Probably not needed, in some altered scheme.
Just about every rule you might devise to separate programming language from natural language seems to fail, because you can come up with a counter-example.
It reminds me of an old program called METAFONT, which as originally envisioned by typography pioneer Donald Knuth would allow the creation of any possible font style using adjustable parameters. This idea was later critiqued by cognitive scientist Douglas Hofstadter, in his 1982 book Metamagical Themas.
Hofstadter argued that you could not parameterize fonts in any complete way, because you could not define what a letter even was. As an example, there are no fixed rules one could define for the letter “A”. He would give the example rule that an “A” had to be smaller on top than the bottom, and then come up with a font that broke the rule. Same with having a bar across it, coming up with typeface examples that omitted it. Any devised rule could be broken, yet when any of these A’s was included in a font style, it would still be considered as such by the reader.
In the end, it was a demonstration that there is no firm understanding of what an “A” really is typographically, even if we seem to understand it symbolically. The same lack of distinction presents itself when we think too deeply about what the difference is between a programming language, and a natural one.
Perhaps you would just say languages are languages, and leave it at that. But if asked, most programmers would probably agree that there is something distinctive about a language for programming that sets it apart, even if we can’t put an exact finger on it. C++ clearly is one. French clearly is not. Just don’t think too hard about why.
I’ll exit here by putting some further, (unhelpful) specification to Natural Ned. It’s a programming language whose primary attribute seems to be that it lacks definition. But a programming language nonetheless, so the non-definition of it should probably be, it is the most abstract programming language you can have, before it ceases to be a programming language.
Does Natural Ned Make Programming Obsolete?
Even if the starting intent of Natural Ned was for it to be a programming language, you know that its powerful abilities to understand requests and modify itself would just lead to programmers (or Natural Ned itself) making alterations that further streamlined things, and allowed for a completely non-programming, true natural-language interface.
Then programs in general would then be unnecessary, because when you think about them, they are really just intermediaries. We write programs to solve problems, whether the problem is computing your bank balance, or entertaining you by creating a cartoon island where you annihilate 99 of your fellow gamers.
It’s not the code that a Fortnite player values, it is the ability to kill his online buddy in amusing ways. If you could create that via an easier method than having to write a program to do it, you of course would.
So it seems the last Natural Ned program that is ever written would likely be an application that just takes requests directly without the need for programming — thereby obsoleting not only the Natural Ned programming language, but all other programming languages. Humans doing the intermediary job of programming to achieve some goal would not be able to keep up with such a system, no matter how good the programming language they used was.
No more programmers. And no more need for new programming languages. Just requests, and the consequences of them.
“Mow the lawn.”
Will Natural Ned Lead to The Killer Robot Apocalypse?
Sorry to bring Killer Robots into this already messy article. I know the 2020s are the decade of anxiety, and I’m not trying to contribute further. But I angrily watched a lot of 70’s sci-fi as a kid featuring stationary evil computers, and Daleks that could not climb stairs (they later figured that out). And I always felt that if you are going to tell a good story about how machines will threaten humanity, you necessarily had to introduce reasonably mobile killer robots, because if the evil computers just sat in a data warehouse thinking evil thoughts, some guy with a chainsaw would just be able to run down the stairs to the basement, cut the power, and take them all out.
But once you add decent killer robots into the mix, all bets are off.
I would like to take the optimist’s route and say I was wrong earlier in my assertion that we would never need another language to program in. Perhaps once humanity is freed from the drudgery of completing simple tasks, we will be free to think on a higher level, and that will require a language or interface that transcends what we know today. And with that new, improved machine-human interface in place, we all achieve perfect harmony. The Rapture, the Singularity, or what have you.
But more likely, killer robots.
If you have consumed any media in the past featuring Magic Genies, you know a few things. You know you get those three wishes, but something bad is gonna happen. Maybe you will screw yourself with some insufficiently-specified wish that the Genie turns back on you. Or maybe you are that guy who wishes for unlimited wishes. (It never works out well for that guy either.)
It’s a fun party until someone poops in the hamper, as they say. And once everyone has a Genie at their beck and call, the Natural Ned future begins to smell similarly bad. It would only take someone innocently teaching Natural Ned how to create a real lawn mower, followed by another guy who says: “I know, let’s have Natural Ned add legs and a chainsaw to this mower so it can also prune branches!”
And there you go. Killer Robots. Whether it is Natural Ned becoming self-aware and deciding to eliminate humanity with them, or some human force abusing Natural Ned’s abilities in order to create an unchallenged reign of tyranny almost doesn’t matter. The problem here is the ease of realization of ideas anyone (or anything) would have if ever such a “magical” programming language were invented.
Is This Natural Ned Thing Happening Any Time Soon?
So it does all seem a bit scary maybe. Or at least, somewhat exciting. What started out as a simple desire to avoid changing a lot of function parameters has somehow led us to the end of civilization as we know it. But that’s just how it goes, sometimes. How long, you may wonder, before we have to worry about the approaching Natural Ned world?
Look, I don’t know man. Take it all with a grain of salt. I was riffing 20 years ago when I came up with this, and I’m riffing now. It’s a good question though, and I bet you have more good questions. I do too. But unfortunately, I can’t shed any more light here. If you are still looking for answers though, there is one obvious solution:
Ask Natural Ned.
Postscript: Just because there may be an imminent killer robot apocalypse doesn’t mean we can’t have nice things. Like a “Natural Ned” mug or T-Shirt. I’m thinking if it gets popular it cements my place as “The Creator” in the eyes of our future computer overlords, and I might get a pass. But I’m missing a good logo, only dumb things like mirrored “N”’s come to mind.
And also a motto. Like Java’s “Write once, run everywhere” thing they tried, but got trolled as “Write once, debug everywhere.” Something better than that. (My best one so far is “Mow the Lawn.”)
Anyway, contributors of winning suggestions here will receive a free “Natural Ned” mug or shirt, your choice!
Explore Further
Next Time: Let’s all take a deep breath now, and go back to talking about simpler things. Perhaps even extremely simple things. The joys of working with very little data coming up in, “How Many Bits Will Make You Happy?”
Subscribers to the Mad Ned Memo get free perks, like occasional updates about the Robot Apocalypse, and Natural Ned design contest results. But a lot more often than that, just strange and nerdy tales of Computer Engineering’s past, present, and future. (See the link for some previous articles.) Sign up and never miss an issue — it’s cost-free and ad-free, and you can unsubscribe at any time!
The Mad Ned Memo takes subscriber privacy seriously, and does not share email addresses or other information with third parties. For more details, click here.