10 ms·

Imperative vs Functional Programming

81 points by gtani 15y ago

sn 15y ago
What about dataflow programming? Shell scripting is one example. I think the same thing could be implemented using event driven programming, the event being the completion of some function, though that would be a little less clear.
Peaker 15y ago
He quotes the guy saying "Computers function by executing a series of instructions". This is no longer true, and becoming less true all the time. Using a massive amount of GPU's, and many CPU cores is no longer a simple series of instructions. Then, the more abstract model of functional programming allows the implementation more freedom when distributing work on the many cores/GPUs, and can make use of this new architecture. If we have even more radical changes in hardware architectures, it is almost certain that the more abstract models of programming will survive better than those tied to a particular hardware architecture (Von neumann model).
- tree_of_item 15y ago
  Adding lots of GPUs and CPUs doesn't make that not true. Those processing units still work by executing a series of instructions, they just do some fancy things with regards to the order of instructions and communication between units. It may be more productive to think of things in terms of a more abstract, functional model of computing, but in the end, for anything to actually happen, that abstract model must be translated in to some series of instructions. I think that's what the quote was trying to get at.
  - Miky 15y ago
    It would be quite possible to design a processor that is not designed around series of instructions at all, but something more akin to functional programming. In this case, everything will “actually happen” without any kind of series of instructions.
    - tree_of_item 15y ago
      Maybe my imagination isn't strong enough, but I don't see how a processor could work without being reducible to a series of instructions. The lowest level of "code" you give it might be more "functional", but there's a direct mapping between that and a sequence of states the processor goes through to actually do anything. In looking for such a thing, I've seen http://en.wikipedia.org/wiki/SECD_machine http://en.wikipedia.org/wiki/SECD_machine and http://en.wikipedia.org/wiki/Graph_reduction_machine http://en.wikipedia.org/wiki/Graph_reduction_machine, but I'm not sure either of these fit your description. Do you have experience with them or another machine you could share?
- wladimir 15y ago
  Then, the more abstract model of functional programming allows the implementation more freedom when distributing work on the many cores/GPUs, and can make use of this new architecture I have read this many times over the years and it sounds perfect. It would be great to have some form of programming that maps to parallel architectures without headaches and bug-prone extra work. Still, for GPU programming we're mainly stuck with things like OpenCL/CUDA, which are imperative like ever, and it's a lot of work to port non-trivial programs to them. Also, even with Haskell/Erlang/etc AFAIK you still have to do special handling to get programs to be efficient with manycore parallelism. And that's not even talking about GPU. Is this system ever implemented or does it just exist in theory?
  - gmt2027 15y ago
    The basic problem in porting to OpenCL/CUDA is identifying the mapping and reduction operations buried in imperative code. That these data-parallel operations are fundamentally functional is clearly reflected in the primitives that the Thrust and CUDPP libraries provide. The real challenge emerges during program restructuring and performance tuning. This requires intimate architectural knowledge and frequent trade-offs between conflicting optimisations.
    - wladimir 15y ago
      So we're already doing 'fundamentally functional' operations? That's an interesting way to look at it, but it's still driven from an imperative language. The grandparent post talked about functional programming in a functional programming language on a GPU. Is Theano a step in this direction? ( http://deeplearning.net/software/theano/ http://deeplearning.net/software/theano/ )
  - sedachv 15y ago
    All of this work has already been done at the first massively parallel (64k processors in early 1980s) supercomputer startup: Danny Hillis' Thinking Machines. Look at StarLisp, Paralations, and NESL.
  - anamax 15y ago
_delirium 15y ago
I actually like the machines/mathematics dichotomy in CS, though it often seems to come up as a one-versus-the-other holy war. I guess I'm actually okay with both of these statements, and am glad people are pushing both: 1. Computation is fundamentally a machine doing things; although of course these machines' operation is also analyzable via mathematics; and 2. Computation is fundamentally a mathematical phenomenon; although of course it is also implementable on machines. I guess there's a philosophical debate about which is more fundamental (does mathematics 'exist' ontologically?), but pragmatically I'm okay with considering them both fundamental approaches to CS.
- jpendry 15y ago
  sounds like this: http://en.m.wikipedia.org/wiki/Church–Turing_thesis http://en.m.wikipedia.org/wiki/Church–Turing_thesis
- jpendry 15y ago
  sounds like this: http://en.m.wikipedia.org/wiki/Church–Turing_thesis http://en.m.wikipedia.org/wiki/Church–Turing_thesis
ekidd 15y ago
Quoted by the article: Computers function by executing a series of instructions, at the level of machine language, which perform calculations and manipulate memory and I/O. Today, our computers increasingly have many cores, and many threads. On top of that, we often have to co-ordinate between dozens of separate servers, each with their own memory and I/O. In this environment, manipulating memory becomes tricky, because you must co-ordinate among anything from 2 to 2,000 simultaneous processes. This raises a whole host of issues: (a) direct interaction using locks and semaphores is hard to get right, (b) the memory in question may be located on separate machines, and (c) if you're running at a billion instructions per second with a 0.1 second lag between machines, simply defining "simultaneous" can give you a headache. And with the rise of GPUs for blazingly fast general-purpose computation, even the hardware itself is becoming deeply functional. We've come up with a whole host of strategies for tackling this problem: Worker queues, MapReduce, Erlang-style message passing, shared-nothing architectures backed by databases, and even eventually-consistent NoSQL systems. Each of these, in some fashion, represents a retreat from the old-school model of a single process manipulating global memory. In this world, functional programming adds one more tool to our kit. It treats mutation and global memory as a special case, and gives us a new vocabulary for working in this world: map, reduce, transactional memory, monads, and local state (via Haskell's ST monad, for example). Even if you work in traditional OO languages, this functional vocabulary will give you new ways to tackle hard problems.
d0m 15y ago
One thing to say is that OO doesn't mean no-functional and functional does't mean no OO. For instance, Python's String is functional since you can't alter it.. 'test'.replace('t', 's') will always return something new and does't not depend of anything but the string itself. I'm not saying python by itself is purely functional.. (as scheme is not purely functional). I'm saying that because I've had great success recently by using immutable objects in languages that aren't.. how to say, functional friendly?
- danssig 15y ago
  Smalltalk is a beautiful marriage between OO and functional programming.
- nickik 15y ago
  I always trie to explan that to people its not about FP vs. OO. You can have a very functional OO language (dylan or scala come to mind) or you can have a imperativ OO Language (Java). The real importend fight is FP vs Imperative. If the language is OO or not does not really matter.
  - thesz 15y ago
    For OO you have to have state. Objects should have identities which distinguish them. That means that two objects are distinct even if all their properties are equal. This break referential transparency. Two runs of "new Integer(2);" will be different. So you cannot have proper functional language with OO. Even if all your objects are immutable.
    - babel17 15y ago
      Yes you can. Check out my language Babel-17 (http://www.babel-17.com http://www.babel-17.com) .
      - thesz 15y ago
        >>So you cannot have proper functional language with OO. >Yes you can. Check out my language Babel-17 I failed to see how purely functional structured programming address the need of identity for objects. Could you elaborate a little more?
olalonde 15y ago
What would be a good first functional language to learn coming from an imperative/OO background?
- nickik 15y ago
  Depends on you you can either "jump in the deep end" or you can gratually move more to it. Gratually moving is good if you want to stay productive. (Scala, Common Lisp, dylan come to mind) Jumping in the deepend will totaly go against everything you learned but you will learn very fast. (Haskell, ML, Clojure and Scheme are probebly best here) Books: Land of Lisp/Practical Common Lisp for Commen Lisp Not sure about Scala Programming Dylan for Dylan Learn you a Haskell for Haskell Programming Clojure/Practical Clojure for Clojure Structure and Interpretation of Computer Programmes/The little Schemer for Scheme (Don't know a good book for ML)
  - _delirium 15y ago
    I'd put ML closer to the gradual camp, though it depends strongly on where you learn it from, and partly on which flavor you choose. I see a whole lot of procedural-flavored Ocaml, and it's fairly easy (like Lisp) to mix procedural and functional styles.
    - nickik 15y ago
      Ok, I didn't know that. I have never seen a line of procedural code in ML. Thx for the info.
  - olalonde 15y ago
    Yes, the plan is to jump in the deep end, unwire my brain and apply the concepts I learn to my day to day Ruby/Javascript programming as much as possible. I think I'll go with Haskell.
    - yogsototh 15y ago
      I am currently learning Haskell. I started by not really knowing where to start. Now I follow this advice, and until now I find it very helpful: http://stackoverflow.com/questions/1012573/how-to-learn-haskell http://stackoverflow.com/questions/1012573/how-to-learn-hask...
alecbenzer 15y ago
"programmers well versed in functional programming are extraordinarily productive in any language" This could just be due to the fact that people who learn functional languages are interested enough in learning languages that they're productive in most of them. If, for example, functional languages were the norm, and some people decided to experiment with OO languages, then it might be that people who knew OO languages would be the ones that were productive in any language.
- loup-vaillant 15y ago
  Except that FP basically dominates class based OO[1]. If FP were the norm, nobody would study class based OO. Remaining alternatives could be prototype based OO, bare-bone programming (assembly, C, LLVM), stack languages, and domain specific languages. [1]: http://www.loup-vaillant.fr/articles/classes-suck http://www.loup-vaillant.fr/articles/classes-suck
  - alecbenzer 15y ago
    That's an opinion, and it may have merit and be valid, but it still could be the case that people might want to experiment with OO languages, and also doesn't change the fact that people who know FP might just be better in any language because of their interest in programming languages, not because of the merits of FP.
thomas11 15y ago
There's a fantastic paper called "Why Functional Programming Matters" by John Hughes [1]. Most of you here will know it, but it's so good that I wouldn't want any newcomers to miss it. It's from 1984 and IMO still the best essay on the basic idea of FP. For Hughes, FP's fundamental strength is in program composition and modularity, and he shows this with relevant examples. [1] http://www.cse.chalmers.se/~rjmh/Papers/whyfp.html http://www.cse.chalmers.se/~rjmh/Papers/whyfp.html
agentultra 15y ago
How is functional style rooted in the "purpose" of the software and the "nature of the thinking" that programmers do? Well I would say that for now the nature of thought is still unknowable. The process of thinking is something a programmer acquires by rote training. I don't believe that there is a "style" of programming that is universally applicable or models the very nature of thought itself. Such is the stuff programmers dream of. Even language is an abstraction we put on reality. Mathematics is just another language and one many feel represents reality more succintly and accurately.
iwwr 15y ago
The contrast to imperative programming is not FP, but rather declarative programming. The idea of referential transparency comes from DP, not FP. Example: Prolog, a declarative language with many of the qualities of FP, yet not FP.
- silentbicycle 15y ago
  Prolog is not really declarative except for the pure core, though. Cuts, assert, retract, etc. break its referential transparency.
raganwald 15y ago
It might be true that functional programming is difficult to learn for programmers not well versed in mathematics. My response to that is: Toughen up, princess. Pithy, but also tinged with sadness. It's a response to the same argument against programming languages being "too powerful" or using "difficult to understand" pattern like parser combinators.
- gnosis 15y ago
  "It might be true that functional programming is difficult to learn for programmers not well versed in mathematics." This is only seen to be a valid complaint because mathematics education in the US sucks. As such, it's likely that future dominance in the functional programming field is likely to come from other countries.
- swannodette 15y ago
  I'm a fan of FP and I find most of the arguments being made here for FP over OO to be quite unconvincing. You don't need to understand mathematics anymore in FP than you need to in OO. If there is any mathematics in FP it's of the logical variety anyhow - which programmers are already familiar with.
  - raganwald 15y ago
    Since I don't have any training in Category Theory, I don't know what I don't know. I do know that it seems from the outside of the Ivory Tower that the explanations for FP are far more difficult to understand than the FP itself. But then again, perhaps if I had studies mathematics, I might have some additional insights into FP that go beyond knowing all of the jargon.
    - swannodette 15y ago
      You don't need to understand the Y Combinator to understand recursion. You don't need to understand the theory behind the Lambda Calculus to write anonymous functions. You don't need to understand Gentzen Calculi to write interesting Prolog programs. You don't need to understand the Curry-Howard isomorphism to understand static typing. These things deepen your understanding certainly, but not understanding them does not in any way limit our ability to write incredible programs.
joevandyk 15y ago
The facts of reality that give rise to the FP approach is the recognition that computation is essentially a process of inferring quantities. Its purpose is to aid in human thinking. And the conceptual faculty is a quantitative mechanism. This is laid out eloquently in David Harriman’s book “The Logical Leap”. See also “Concept-formation as a mathematical process” in OPAR. The computer is in essence a quantifying device. Its invention was motivated by man’s need to quantify. Anyone else tired of verbose writing?

81 points by gtani 15y ago

sn 15y ago

What about dataflow programming? Shell scripting is one example. I think the same thing could be implemented using event driven programming, the event being the completion of some function, though that would be a little less clear.

Peaker 15y ago

He quotes the guy saying "Computers function by executing a series of instructions". This is no longer true, and becoming less true all the time. Using a massive amount of GPU's, and many CPU cores is no longer a simple series of instructions. Then, the more abstract model of functional programming allows the implementation more freedom when distributing work on the many cores/GPUs, and can make use of this new architecture. If we have even more radical changes in hardware architectures, it is almost certain that the more abstract models of programming will survive better than those tied to a particular hardware architecture (Von neumann model).

tree_of_item 15y ago
Adding lots of GPUs and CPUs doesn't make that not true. Those processing units still work by executing a series of instructions, they just do some fancy things with regards to the order of instructions and communication between units. It may be more productive to think of things in terms of a more abstract, functional model of computing, but in the end, for anything to actually happen, that abstract model must be translated in to some series of instructions. I think that's what the quote was trying to get at.
- Miky 15y ago
  It would be quite possible to design a processor that is not designed around series of instructions at all, but something more akin to functional programming. In this case, everything will “actually happen” without any kind of series of instructions.
  - tree_of_item 15y ago
    Maybe my imagination isn't strong enough, but I don't see how a processor could work without being reducible to a series of instructions. The lowest level of "code" you give it might be more "functional", but there's a direct mapping between that and a sequence of states the processor goes through to actually do anything. In looking for such a thing, I've seen http://en.wikipedia.org/wiki/SECD_machine http://en.wikipedia.org/wiki/SECD_machine and http://en.wikipedia.org/wiki/Graph_reduction_machine http://en.wikipedia.org/wiki/Graph_reduction_machine, but I'm not sure either of these fit your description. Do you have experience with them or another machine you could share?
wladimir 15y ago
Then, the more abstract model of functional programming allows the implementation more freedom when distributing work on the many cores/GPUs, and can make use of this new architecture I have read this many times over the years and it sounds perfect. It would be great to have some form of programming that maps to parallel architectures without headaches and bug-prone extra work. Still, for GPU programming we're mainly stuck with things like OpenCL/CUDA, which are imperative like ever, and it's a lot of work to port non-trivial programs to them. Also, even with Haskell/Erlang/etc AFAIK you still have to do special handling to get programs to be efficient with manycore parallelism. And that's not even talking about GPU. Is this system ever implemented or does it just exist in theory?
- gmt2027 15y ago
  The basic problem in porting to OpenCL/CUDA is identifying the mapping and reduction operations buried in imperative code. That these data-parallel operations are fundamentally functional is clearly reflected in the primitives that the Thrust and CUDPP libraries provide. The real challenge emerges during program restructuring and performance tuning. This requires intimate architectural knowledge and frequent trade-offs between conflicting optimisations.
  - wladimir 15y ago
    So we're already doing 'fundamentally functional' operations? That's an interesting way to look at it, but it's still driven from an imperative language. The grandparent post talked about functional programming in a functional programming language on a GPU. Is Theano a step in this direction? ( http://deeplearning.net/software/theano/ http://deeplearning.net/software/theano/ )
- sedachv 15y ago
  All of this work has already been done at the first massively parallel (64k processors in early 1980s) supercomputer startup: Danny Hillis' Thinking Machines. Look at StarLisp, Paralations, and NESL.
- anamax 15y ago

_delirium 15y ago

I actually like the machines/mathematics dichotomy in CS, though it often seems to come up as a one-versus-the-other holy war. I guess I'm actually okay with both of these statements, and am glad people are pushing both: 1. Computation is fundamentally a machine doing things; although of course these machines' operation is also analyzable via mathematics; and 2. Computation is fundamentally a mathematical phenomenon; although of course it is also implementable on machines. I guess there's a philosophical debate about which is more fundamental (does mathematics 'exist' ontologically?), but pragmatically I'm okay with considering them both fundamental approaches to CS.

jpendry 15y ago
sounds like this: http://en.m.wikipedia.org/wiki/Church–Turing_thesis http://en.m.wikipedia.org/wiki/Church–Turing_thesis
jpendry 15y ago
sounds like this: http://en.m.wikipedia.org/wiki/Church–Turing_thesis http://en.m.wikipedia.org/wiki/Church–Turing_thesis

ekidd 15y ago

Quoted by the article: Computers function by executing a series of instructions, at the level of machine language, which perform calculations and manipulate memory and I/O. Today, our computers increasingly have many cores, and many threads. On top of that, we often have to co-ordinate between dozens of separate servers, each with their own memory and I/O. In this environment, manipulating memory becomes tricky, because you must co-ordinate among anything from 2 to 2,000 simultaneous processes. This raises a whole host of issues: (a) direct interaction using locks and semaphores is hard to get right, (b) the memory in question may be located on separate machines, and (c) if you're running at a billion instructions per second with a 0.1 second lag between machines, simply defining "simultaneous" can give you a headache. And with the rise of GPUs for blazingly fast general-purpose computation, even the hardware itself is becoming deeply functional. We've come up with a whole host of strategies for tackling this problem: Worker queues, MapReduce, Erlang-style message passing, shared-nothing architectures backed by databases, and even eventually-consistent NoSQL systems. Each of these, in some fashion, represents a retreat from the old-school model of a single process manipulating global memory. In this world, functional programming adds one more tool to our kit. It treats mutation and global memory as a special case, and gives us a new vocabulary for working in this world: map, reduce, transactional memory, monads, and local state (via Haskell's ST monad, for example). Even if you work in traditional OO languages, this functional vocabulary will give you new ways to tackle hard problems.

d0m 15y ago

One thing to say is that OO doesn't mean no-functional and functional does't mean no OO. For instance, Python's String is functional since you can't alter it.. 'test'.replace('t', 's') will always return something new and does't not depend of anything but the string itself. I'm not saying python by itself is purely functional.. (as scheme is not purely functional). I'm saying that because I've had great success recently by using immutable objects in languages that aren't.. how to say, functional friendly?

danssig 15y ago
Smalltalk is a beautiful marriage between OO and functional programming.
nickik 15y ago
I always trie to explan that to people its not about FP vs. OO. You can have a very functional OO language (dylan or scala come to mind) or you can have a imperativ OO Language (Java). The real importend fight is FP vs Imperative. If the language is OO or not does not really matter.
- thesz 15y ago
  For OO you have to have state. Objects should have identities which distinguish them. That means that two objects are distinct even if all their properties are equal. This break referential transparency. Two runs of "new Integer(2);" will be different. So you cannot have proper functional language with OO. Even if all your objects are immutable.
  - babel17 15y ago
    Yes you can. Check out my language Babel-17 (http://www.babel-17.com http://www.babel-17.com) .
    - thesz 15y ago
      >>So you cannot have proper functional language with OO. >Yes you can. Check out my language Babel-17 I failed to see how purely functional structured programming address the need of identity for objects. Could you elaborate a little more?

olalonde 15y ago

What would be a good first functional language to learn coming from an imperative/OO background?

nickik 15y ago
Depends on you you can either "jump in the deep end" or you can gratually move more to it. Gratually moving is good if you want to stay productive. (Scala, Common Lisp, dylan come to mind) Jumping in the deepend will totaly go against everything you learned but you will learn very fast. (Haskell, ML, Clojure and Scheme are probebly best here) Books: Land of Lisp/Practical Common Lisp for Commen Lisp Not sure about Scala Programming Dylan for Dylan Learn you a Haskell for Haskell Programming Clojure/Practical Clojure for Clojure Structure and Interpretation of Computer Programmes/The little Schemer for Scheme (Don't know a good book for ML)
- _delirium 15y ago
  I'd put ML closer to the gradual camp, though it depends strongly on where you learn it from, and partly on which flavor you choose. I see a whole lot of procedural-flavored Ocaml, and it's fairly easy (like Lisp) to mix procedural and functional styles.
  - nickik 15y ago
    Ok, I didn't know that. I have never seen a line of procedural code in ML. Thx for the info.
- olalonde 15y ago
  Yes, the plan is to jump in the deep end, unwire my brain and apply the concepts I learn to my day to day Ruby/Javascript programming as much as possible. I think I'll go with Haskell.
  - yogsototh 15y ago
    I am currently learning Haskell. I started by not really knowing where to start. Now I follow this advice, and until now I find it very helpful: http://stackoverflow.com/questions/1012573/how-to-learn-haskell http://stackoverflow.com/questions/1012573/how-to-learn-hask...

alecbenzer 15y ago

"programmers well versed in functional programming are extraordinarily productive in any language" This could just be due to the fact that people who learn functional languages are interested enough in learning languages that they're productive in most of them. If, for example, functional languages were the norm, and some people decided to experiment with OO languages, then it might be that people who knew OO languages would be the ones that were productive in any language.

loup-vaillant 15y ago
Except that FP basically dominates class based OO[1]. If FP were the norm, nobody would study class based OO. Remaining alternatives could be prototype based OO, bare-bone programming (assembly, C, LLVM), stack languages, and domain specific languages. [1]: http://www.loup-vaillant.fr/articles/classes-suck http://www.loup-vaillant.fr/articles/classes-suck
- alecbenzer 15y ago
  That's an opinion, and it may have merit and be valid, but it still could be the case that people might want to experiment with OO languages, and also doesn't change the fact that people who know FP might just be better in any language because of their interest in programming languages, not because of the merits of FP.

thomas11 15y ago

There's a fantastic paper called "Why Functional Programming Matters" by John Hughes [1]. Most of you here will know it, but it's so good that I wouldn't want any newcomers to miss it. It's from 1984 and IMO still the best essay on the basic idea of FP. For Hughes, FP's fundamental strength is in program composition and modularity, and he shows this with relevant examples. [1] http://www.cse.chalmers.se/~rjmh/Papers/whyfp.html http://www.cse.chalmers.se/~rjmh/Papers/whyfp.html

agentultra 15y ago

How is functional style rooted in the "purpose" of the software and the "nature of the thinking" that programmers do? Well I would say that for now the nature of thought is still unknowable. The process of thinking is something a programmer acquires by rote training. I don't believe that there is a "style" of programming that is universally applicable or models the very nature of thought itself. Such is the stuff programmers dream of. Even language is an abstraction we put on reality. Mathematics is just another language and one many feel represents reality more succintly and accurately.

iwwr 15y ago

The contrast to imperative programming is not FP, but rather declarative programming. The idea of referential transparency comes from DP, not FP. Example: Prolog, a declarative language with many of the qualities of FP, yet not FP.

silentbicycle 15y ago
Prolog is not really declarative except for the pure core, though. Cuts, assert, retract, etc. break its referential transparency.

raganwald 15y ago

It might be true that functional programming is difficult to learn for programmers not well versed in mathematics. My response to that is: Toughen up, princess. Pithy, but also tinged with sadness. It's a response to the same argument against programming languages being "too powerful" or using "difficult to understand" pattern like parser combinators.

gnosis 15y ago
"It might be true that functional programming is difficult to learn for programmers not well versed in mathematics." This is only seen to be a valid complaint because mathematics education in the US sucks. As such, it's likely that future dominance in the functional programming field is likely to come from other countries.
swannodette 15y ago
I'm a fan of FP and I find most of the arguments being made here for FP over OO to be quite unconvincing. You don't need to understand mathematics anymore in FP than you need to in OO. If there is any mathematics in FP it's of the logical variety anyhow - which programmers are already familiar with.
- raganwald 15y ago
  Since I don't have any training in Category Theory, I don't know what I don't know. I do know that it seems from the outside of the Ivory Tower that the explanations for FP are far more difficult to understand than the FP itself. But then again, perhaps if I had studies mathematics, I might have some additional insights into FP that go beyond knowing all of the jargon.
  - swannodette 15y ago
    You don't need to understand the Y Combinator to understand recursion. You don't need to understand the theory behind the Lambda Calculus to write anonymous functions. You don't need to understand Gentzen Calculi to write interesting Prolog programs. You don't need to understand the Curry-Howard isomorphism to understand static typing. These things deepen your understanding certainly, but not understanding them does not in any way limit our ability to write incredible programs.

joevandyk 15y ago

The facts of reality that give rise to the FP approach is the recognition that computation is essentially a process of inferring quantities. Its purpose is to aid in human thinking. And the conceptual faculty is a quantitative mechanism. This is laid out eloquently in David Harriman’s book “The Logical Leap”. See also “Concept-formation as a mathematical process” in OPAR. The computer is in essence a quantifying device. Its invention was motivated by man’s need to quantify. Anyone else tired of verbose writing?