The Wasteful Legacy of Programming as Language

This is yet another exhortation to "visual" programming.

Ironically, the author seems to believe that programming language syntax can done away with since the textual representation of a programming language is just an incidental detail, yet he simultaneously believes that the syntax is so central to what makes a programming language that by getting rid of it you'll be left with something conceptually independent from the features in any particular language.

I'll just quote a couple paragraphs from the article to illustrate how confused it is:

> In a program written in this way, using garbage collection is just a matter of plugging the right run time support, which you could get along with the system or you could buy from a third party. Instead, we erroneously consider garbage collection as a fundamental attribute of the language in use. As another example, in a language agnostic system we would would be able to create and call closures by just adding a simple module to the system, not by devising yet another language that supports closures as a first class citizen.

> But the advantages don’t stop there. Without the need for a language, it also disappears the need for a compiler. Everything is such a system is already parsed and ready to use. When we combine pieces of code they already know how to glue themselves to each other, so there is no need for a linker either.

This article touches on some interesting ideas, but doesn't hint at the enormous amount of work that would need to be done to even see if they are feasible, let alone implement them. The author also makes important mistakes regarding PL implementation. Examples follow.

"Without the need for a language, it also disappears the need for a compiler. Everything is such a system is already parsed and ready to use."

A compiler is not just a parser! In fact, the parser is generally regarded as the easy, tedious part of a compiler. This confusion between the syntax of a language and its semantics undermines most of the purported benefits of his proposed "languageless system".

"Whatever the form used to interact with the program, a language-less system doesn’t care if parts of the program are shaped as s-expressions or C blocks: it just combine them as needed to create a program."

The difference between s-expressions and C blocks is not superficial: s-expressions present a natural API to the syntax of the programming language itself, allowing Lisp's distinctive feature: macros. Language syntax and language capabilities are not so easily separable!

"In a program written in this way, using garbage collection is just a matter of plugging the right run time support, which you could get along with the system or you could buy from a third party."

Performant garbage collection algorithms need guarantees about the code they manage (eg. the ability to distinguish pointers from integers for precise GC, and write-barriers for incremental GC). Choice of GC algorithm affects the compilation and capabilities of your entire program, and even the ways you can interact with other programs! You can't just mix and match PL features you find from various languages and expect them not to conflict.

This article is nonsense. The author is belittling pretty much everything that has been achieved in computer science over the past decades without provide any examples or theories as to what could be done better.

This article seems to be also proposing... a programming language. Or at least "environment". Visual programming is something people have proposed, as is interactive manipulation of an "actual" parse state, as with some of the Smalltalk environments. But then you still have different choices of abstractions, like what object model you use, or what concurrency model. I don't think you can avoid that by renaming it from "language".

You could program in raw machine code, then sure, no separate language, "just" instructions for the computer. But then each machine has a different... language, too.

Or you could program in "pure mathematics", expressions, etc., but then you have a choice of which formalism to use for that. I doubt there will be only one.

If you want a programming language for which parsing is trivial, code is stored in a pre-tokenized manner and there is a direct correspondence between tokens and machine primitives, Chuck Moore's ColorForth[1] foots the bill. It's orders of magnitude simpler than what most of us would consider a programming language, but you can still build powerful abstractions and extend the language to add features like garbage collection, type systems[2] (not built in the same dialect of Forth, but you get the idea) and so on.

[1] http://www.colorforth.com/cf.htm [2] http://home.vrweb.de/stephan.becher/forth/

"After some time he asked me if I was aware of the work by Chromsky [sic] on formal languages. I told him that yes, Chromsky work was a basis for much of the developments in theoretical computer science."

Really? You couldn't proof-read long enough to notice two misspellings of the single most recognizable name in modern linguistics, and you want people to read your blog post on that same subject?

It is clear that the author hasn't actually done any work on, or even deeply thought about, computer languages. Claiming that a whole field is misguided and hinting at a much superior approach without going into any details is a special form of trolling.

This is very close to describing (in very vague terms and not too great on the detail) a part of my present side project, and as such I completely believe in it [and respectfully disagree with most of the other comments here]. If I don't achieve it - I'm pretty sure that someone else will, and it will (in whatever form) make a significant impact....

Though not great on the _how_ i think this article is at the very least forward thinking. I'm not sure why everyone else here has to try to box a relatively original thought in with whole bunch of old failed ones to drag it down (like the 'visual programming languages' we all know and hate).

Rubbish.

Visual programming is becoming more common, but it is coming from the text environment. IntelliJ is showing the way: wizards that are embedded in your text editor, so you hardly notice them (e.g. renaming a variable.)

That's where the technical leverage is: improving our current development environments, not in completely changing the way we write code.

"the only difference between a Java programmer and a C# programmer is that they use somewhat different keywords and have to program against a different run time library"

yeah well, most people spend their time combining libraries and making them interact with each other, so it is actually kind of a big difference.

No.

Now, if one uses a homoiconic language, visual and text programming can potentially become (mostly) equivalent concrete syntaxes for the same abstract syntax.

See Android App Inventor, which uses visual blocks that compile to a subset of (kawa) Scheme.

The author completely misses the point that programming languages are every bit as much human-to-human interaction as human-to-machine, i.e. programming languages happen to be textual representations because they are "human languages"!

%s/Chromsky/Chomsky/g