
On Programming Languages as Languages - acangiano
http://programmingzen.com/2014/11/27/programming-languages-as-languages/
======
TuringTest
_" We can look at programming languages in two possible ways. They can be a
means for us to instruct the computer, and incidentally communicate with
fellow programmers, or they can allow us to communicate with other programmers
in specific terms that are ultimately executable."_

If anyone doubted this, of course an essential purpose of programming
languages is for communicating with humans. The computer only needs the binary
code that triggers the microprocessor's electric signals in the right
combinations.

What's a shame is that the common features of these languages have been shaped
more by the needs of the machine than the needs of the developers - and not
just that: by the needs of 1950's computers.

A lot of developers understanding of what a programming language is has been
shaped by those early efforts, and dragged through 60+ years of PL history.
More modern languages have overcome the most glaring inconveniences of early
languages, but the core assumption -that a PL's purpose is ultimately and
exclusively as a tool to convey instructions to the machine- remains
unchallenged.

But that's not an essential property of human-machine languages, and
programming doesn't _need_ to be that way. From the fields of End-User
Development and semiotics applied to Human-Computer Interaction come some
alternatives that propose an understanding of programming which is closer to
the second way to look at PLs, as a tool for human comunication.

An interesting possibility is using computers in a way close to the
"augmenting the human intelect" vision that existed before programing
languages. In this approach, you don't have the loom-like vision of programs
as sequences of instructions that are number-crunched by the machine, but as
sets of symbols intended to be shown to humans, who would reason about them
and extract meaning.

In this view, data and code are interleaved as a single entity, and not all
content in the program needs to be executable - only some bits are crunched
and passed to the processor for execution as a side-effect of using the tool,
but the whole thing is intended as a sort of interactive novel that the user
reads and steers to create some content or the other. (This is the approach of
Literate programming, and is also related to Live Programming).

This can be taken to the extreme by creating instruction sets that work as
recipies and can produce different executable code, so their meaning changes
depending on the context on which they're executed. Configuration files and
XML domain-specific languages may work this way, and it's a very natural way
to reason for the human mind, yet this approach has not been fully explored by
general-purpose programming languages.

~~~
lambda

      More modern languages have overcome the most glaring 
      inconveniences of early languages, but the core 
      assumption -that a PL's purpose is ultimately and 
      exclusively as a tool to convey instructions to the 
      machine- remains unchallenged.
    

I really feel like you're selling an awful lot of the programming language
design world short here. An awful lot of what programming language design is
about is making it easy to precisely express what you mean, in a way that will
make sense to future programmers, be robust in the face of changes, and so on.
It has been a long time since it has merely been a way to convey instructions
to the machine.

    
    
      Configuration files and XML domain-specific languages 
      may work this way, and it's a very natural way to reason 
      for the human mind
    

Your mind must work fairly differently from mine if you find XML a natural way
to reason.

You seem to be ignoring all of the tools for building embedded domain specific
languages in Lisp, Scheme, Ruby, Haskell and various other language, logic
programming languages which are much more declarative, and so on.

Literate programming has existed for years, but never really caught on because
it turns out that one of the best ways to express the meaning of a lot of code
(especially code for a large project that changes fairly often) is via the
code itself, not a bunch of natural language prose associated with it.

~~~
TuringTest

      "I really feel like you're selling an awful lot of the programming language design world short here."
    

You may be right about that :-) Although now I realize my words didn't exactly
convey what I intended to say, see below.

    
    
      "An awful lot of what programming language design is about is making it easy to precisely express what you mean, in a way that will make sense to future programmers, be robust in the face of changes, and so on."
    

Actually this is more what I was actually thinking when I said "the core
assumption remains unchallenged". There are ways to program that don't assume
you're trying to build a robust, unambiguous and precise meaning (and which
are therefore much more adequate for non-technical users). But these ways have
not been explored in depth, and are not known to the general mass of
developers.

There is a lively conversation at the original blog, would you mind to move
the conversation there, to keep it at one place?

[http://programmingzen.com/2014/11/27/programming-
languages-a...](http://programmingzen.com/2014/11/27/programming-languages-as-
languages/#comment-28865)

    
    
      "Your mind must work fairly differently from mine if you find XML a natural way to reason."
    

I was not thinking of XML as natural, but of "creating instruction sets that
work as recipies and can produce different executable code, so their meaning
changes depending on the context on which they're executed". :-D This is the
way that humans follow instructions when they receive orders. It's what makes
the following a joke:

Q. How did the programmer die in the shower?

A. He read the shampoo bottle instructions: Lather. Rinse. Repeat.

P.S. (BTW, how do you create those intended quote blocks? I don't know how to
do it)

------
ranko
Reminiscent of Weinberg's 1971 "Psychology of Computer Programming", which
discusses programming as a human activity. This is from chapter 1:

"Programming is, among other things, a kind of writing. One way to learn
writing is to write, but in all other forms of writing, one also reads. We
read examples—both good and bad—to facilitate learning. But how many
programmers learn to write programs by reading programs?"

He goes on to discuss programming as an individual and social activity, with
the principle that it's a human activity at root.

------
mallamanis
There is some recent research has shown that programming languages present
some "naturalness":

Hindle, Abram, et al. "On the naturalness of software." Software Engineering
(ICSE), 2012 34th International Conference on. IEEE, 2012.
[http://macbeth.cs.ucdavis.edu/natural.pdf](http://macbeth.cs.ucdavis.edu/natural.pdf)

