Re:On Programming Languages as Languages
by TuringTest on Thursday November 27, 2014 @11:59AM
(#8668018)
"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.
Re:On Programming Languages as Languages
by tel on Thursday November 27, 2014 @12:42PM
(#8668191)
I think much of modern PL research (and with a little poetic license, all of the original PL research) is actually dedicated to developing PLs as human languages for expressing pure, true thoughts.
What is "pure and true" in this context? That was the question which originally drove the invention of PLs or logical languages and answers were attempted near the beginning of the 20th century by Russell, Whitehead, Frege, and many others. Church, Curry, and Turing, notable names in early CS, were actually largely driven by Hilbert's mathematical program of formalizing mathematical logic.
So what does this effort look like today? PLs of this pedigree are barely at all interested in how binary codes work (unless they are the object of study, of course). Instead, they endeavor to provide valid logical frameworks of massive expressive power. Modern PLs in this vein can formalize mathematical logic through intuitionistic logic which is something like the logic most people learned in school but augmented with a notion of the limits of the Halting Problem. This means that it lives nicely between logic and computer science.
So why do we think that PLs are an object of computer commands? Because the popular ones which were both widely implemented and fast had that property. It's essentially a walk in the park to convert Assembly to machine instructions compared to an intuitionistic logic calculus. We then proceeded not by seeking to make Assembly more like its forebearing languages but instead to layer abstraction after abstraction atop it to make the fundamentally alien task at hand more manageable.
This is ultimately a flawed program judged that way. Furthermore, it's also less than half as old as the original PL research efforts, but it already had us develop many techniques for efficiently executing complex tasks on a computer. This is an important part of "computer algorithm design" but essentially a side-topic to the larger field of PL research.
Re:On Programming Languages as Languages
by lambda on Thursday November 27, 2014 @12:50PM
(#8668222)
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.
Re:On Programming Languages as Languages
by TuringTest on Thursday November 27, 2014 @01:54PM
(#8668442)
"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?
"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)
Re:On Programming Languages as Languages
by TuringTest on Thursday November 27, 2014 @12:15PM
(#8668084)
Earlier I posted a somewhat-related post at Ars Technica about using MS Office as a programming language in the way I describe above. You may find it interesting as well.
Re:On Programming Languages as Languages
by ranko on Thursday November 27, 2014 @12:50PM
(#8668228)
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.
Re:On Programming Languages as Languages
by mallamanis on Thursday November 27, 2014 @01:10PM
(#8668296)
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
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.
What is "pure and true" in this context? That was the question which originally drove the invention of PLs or logical languages and answers were attempted near the beginning of the 20th century by Russell, Whitehead, Frege, and many others. Church, Curry, and Turing, notable names in early CS, were actually largely driven by Hilbert's mathematical program of formalizing mathematical logic.
So what does this effort look like today? PLs of this pedigree are barely at all interested in how binary codes work (unless they are the object of study, of course). Instead, they endeavor to provide valid logical frameworks of massive expressive power. Modern PLs in this vein can formalize mathematical logic through intuitionistic logic which is something like the logic most people learned in school but augmented with a notion of the limits of the Halting Problem. This means that it lives nicely between logic and computer science.
So why do we think that PLs are an object of computer commands? Because the popular ones which were both widely implemented and fast had that property. It's essentially a walk in the park to convert Assembly to machine instructions compared to an intuitionistic logic calculus. We then proceeded not by seeking to make Assembly more like its forebearing languages but instead to layer abstraction after abstraction atop it to make the fundamentally alien task at hand more manageable.
This is ultimately a flawed program judged that way. Furthermore, it's also less than half as old as the original PL research efforts, but it already had us develop many techniques for efficiently executing complex tasks on a computer. This is an important part of "computer algorithm design" but essentially a side-topic to the larger field of PL research.
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.
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...
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)
http://arstechnica.com/gadgets/2014/11/preview-office-for-an...
"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.
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