5 ms·

Some excepts from the Conclusions section are fairly amusing: "One way to compromise between functional and imperative programming is recognize that every lan

by platz 11y ago

Some excepts from the Conclusions section are fairly amusing: "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."

jpgauthier 11y ago
The second quote is so true. I never thought of it that way!
- deleted 11y ago
  [deleted]
- deleted 11y ago
  [deleted]
- hcarvalhoalves 11y ago
  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.
  - vegabook 11y ago
    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.
  - rtpg 11y ago
    >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.
    - jandrese 11y ago
      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.
      - jpt4 11y ago
        >> 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_overview https://en.wikipedia.org/wiki/Lisp_machine#Technical_overvie... [1] http://home.pipeline.com/~hbaker1/LinearLisp.html http://home.pipeline.com/~hbaker1/LinearLisp.html [2] http://home.pipeline.com/~hbaker1/ForthStack.html http://home.pipeline.com/~hbaker1/ForthStack.html [3] http://dspace.mit.edu/handle/1721.1/6334 http://dspace.mit.edu/handle/1721.1/6334

by platz 11y ago

jpgauthier 11y ago

The second quote is so true. I never thought of it that way!

deleted 11y ago
[deleted]
deleted 11y ago
[deleted]
hcarvalhoalves 11y ago
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.
- vegabook 11y ago
  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.
- rtpg 11y ago
  >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.
  - jandrese 11y ago
    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.
    - jpt4 11y ago
      >> 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_overview https://en.wikipedia.org/wiki/Lisp_machine#Technical_overvie... [1] http://home.pipeline.com/~hbaker1/LinearLisp.html http://home.pipeline.com/~hbaker1/LinearLisp.html [2] http://home.pipeline.com/~hbaker1/ForthStack.html http://home.pipeline.com/~hbaker1/ForthStack.html [3] http://dspace.mit.edu/handle/1721.1/6334 http://dspace.mit.edu/handle/1721.1/6334