Real Programming in Functional Languages (1982) [pdf](research.microsoft.com)
research.microsoft.com
Real Programming in Functional Languages (1982) [pdf]
http://research.microsoft.com/en-us/um/people/simonpj/Papers/other-authors/morris-real-programming.pdf
3 comments
The second quote is so true. I never thought of it that way!
[deleted]
[deleted]
This quote is so misleading.
Since when functional programming is "radical"? It's the essence of computing.
What we're seeing are other languages going back to the basics, after a detour in the "imperative is easy to learn" and "OO is reusable" lands.
Since when functional programming is "radical"? It's the essence of computing.
What we're seeing are other languages going back to the basics, after a detour in the "imperative is easy to learn" and "OO is reusable" lands.
machine code looks pretty much like the "essence of computing" to me, and that's about as far as you can get from functional programming. I think I would agree with you more if you meant the essence of computer "science". If I remember correctly there is, anyway, a theorem by Church and Turing that proves imperative and functional programming to be capability-equivalent. The argument is more about the superiority of functional programming in its benefits to software engineering and algorithm discovery by forcing rigour onto our mistake-prone brains.
>Since when functional programming is "radical"? It's the essence of computing.
It isn't representative of how processors work, unlike imperative programming. Even if the theory is there, the machine itself is imperative (most of the time), so there's a level of abstraction needed.
Though the theory could have started like that, the mechanisms are totally separated from the physical reality. In a field dominated by engineers (especially in a time where cycle counts mattered much more), that's what's going to happen.
It isn't representative of how processors work, unlike imperative programming. Even if the theory is there, the machine itself is imperative (most of the time), so there's a level of abstraction needed.
Though the theory could have started like that, the mechanisms are totally separated from the physical reality. In a field dominated by engineers (especially in a time where cycle counts mattered much more), that's what's going to happen.
Well, increasingly that's untrue as machine operation begins to become more data flow oriented. Even before it hits the machine optimizations are often better performed on analyses which are more "functional" in nature. SSA is not so far from a functional language.
There were honest to god LISP machines built back in the day. They never really caught on however. They were mostly oriented at the educational market, and didn't ship with such niceties like an OS or even a bootloader sometimes.
>> the mechanisms are totally separated from the physical reality.
> There were honest to god LISP machines
As LISP-flavored stack machines, yes [0]. Alas that Linear Lisp [1] never received a hardware implementation [2].
To those exploring high level language architectures, forget not also the noble SCHEME-79 chip [3]: a Von Neumannian register machine, but one which executes a SCHEME interpreter microcoded in LISP.
[0] https://en.wikipedia.org/wiki/Lisp_machine#Technical_overvie...
[1] http://home.pipeline.com/~hbaker1/LinearLisp.html
[2] http://home.pipeline.com/~hbaker1/ForthStack.html
[3] http://dspace.mit.edu/handle/1721.1/6334
> There were honest to god LISP machines
As LISP-flavored stack machines, yes [0]. Alas that Linear Lisp [1] never received a hardware implementation [2].
To those exploring high level language architectures, forget not also the noble SCHEME-79 chip [3]: a Von Neumannian register machine, but one which executes a SCHEME interpreter microcoded in LISP.
[0] https://en.wikipedia.org/wiki/Lisp_machine#Technical_overvie...
[1] http://home.pipeline.com/~hbaker1/LinearLisp.html
[2] http://home.pipeline.com/~hbaker1/ForthStack.html
[3] http://dspace.mit.edu/handle/1721.1/6334
My favorite part about this is the introduction, where the authors relate functional programming to Haiku and Karate. Haiku and Karate are both intricate, beautiful, highly regimented arts. But only one is useful in a bar fight, and the people who are its victims don't know about the craft, or why it's effective.
So, the paper asks: which is functional programming? Haiku or Karate?
(EDIT: And, more personal note: Dan, thanks for posting. :) I assume since you posted this later, you got it from my Twitter, in which case you should also look at the Butler Lampson/Erik Meijer talk that I heard it from, and which I've been trying to get you to watch: https://channel9.msdn.com/Shows/Going+Deep/E2E-Erik-Meijer-a...)
So, the paper asks: which is functional programming? Haiku or Karate?
(EDIT: And, more personal note: Dan, thanks for posting. :) I assume since you posted this later, you got it from my Twitter, in which case you should also look at the Butler Lampson/Erik Meijer talk that I heard it from, and which I've been trying to get you to watch: https://channel9.msdn.com/Shows/Going+Deep/E2E-Erik-Meijer-a...)
When I went to college
John Bachus, the inventor of FORTRAN was a computer science God. And when he becameba functional programming evangelist, we politely listened.
I did not becomeva convert until Scala came along as a way to mange large core clusters.
I did not becomeva convert until Scala came along as a way to mange large core clusters.
"One way to compromise between functional and imperative programming is recognize that every language has a functional subset, usually associated with the set of expressions in the language. However, it is rarely useful to take advantage of the functional subset via clever evaluation or compilation strategies because expressions in that subset usually represent very small intervals of computation or leave the functional subset via calls on functions with side effects"
"Functional languages as a minority doctrine in the field of programming languages bear a certain resemblance to socialism in its relation to conventional, capitalist economic doctrine. Their proponents are often brilliant intellectuals perceived to be radical and rather unrealistic by the mainstream, but little-by-little changes are made in the conventional languages and economies to incorporate features of the radical proposals. Of course this never satisfies the radicals, but it represents progress of a sort."
"A little appreciated role of functional programming, goto-less programming, and other stylish forms of programming is an indicator of a programmer's morale. When one comes across a program with a rat's nest of gotos, or large amounts of pointer arithmetic one says to himself, "This programmer was barely able to solve the problem he was working on. If he had the intellectual problem well under control, then he should have devoted some of his brainpower to making it look pretty according to generally accepted standards, e.g. eliminating gotos."