5 ms·

I agree that a Turing machine is imperative...when I refer to machines I am generally referring to an inflexible approach to solving problems, not so much how c

by Edmond 13y ago

I agree that a Turing machine is imperative...when I refer to machines I am generally referring to an inflexible approach to solving problems, not so much how computers execute instructions. As humans I think we need the ability to be messy and imprecise in order to be creative. >The reason we tend to think in imperative terms is one of familiarity That's debatable given that both approaches have been around for about the same length of time with different outcomes in terms of adoption.

codygman 13y ago
> That's debatable given that both approaches have been around for about the same length of time with different outcomes in terms of adoption. If unix had been created in LISP or ML, I believe we might be in the opposite position. Though that hinges on a LISP unix being as successful as the C one.
- mike_hearn 13y ago
  But before UNIX there was Symbolics, and Symbolics failed in the market whereas UNIX succeeded.
  - codygman 13y ago
    Was that because C was better than Lisp though, because of timing, or because the people working on UNIX's goals were more closely aligned with the industry as a whole? There are of course many other things it could have been, but these are the first that come to my mind.
andrewflnr 13y ago
I'm writing OCaml now. I'm being messy and creative all over the place, sketching out ideas, and simply not trying to compile them until I think it'll work. I do this precisely because OCaml maps naturally onto how I think about the problems I'm working on right now. It's pseudocode until I run make, at which point the computer is running very useful checks on my reasoning. The "inflexible approach to solving problems" you refer to has, as far as I can tell, nothing at all to do with "machines", except perhaps in an exceptionally abstract sense, in the form of virtual machines designed for thinking about. On the other hand, problem solving doesn't get much more flexible than raw assembly. My point stands. I think the early adoption of imperative languages was more due to pragmatism than elegance[0]; at first, you had to stay close to the machine to get anything done, at first because that's all that existed (Fortran beat Lisp into existence by a year) and then for performance. Remember, Fortran was still basically a shortcut for assembly, while Lisp started as a purely mathematical abstraction, designed expressly for thinking about, that some goofball wrote an interpreter for. [0] This principle is still clearly in force today. We wouldn't bother with C++ and JVM languages and Unix so much if pragmatism wasn't paramount. I'm using Fortran as my example of an early imperative language. There might have been earlier ones (maybe a version of COBOL?), but since they were imperative it doesn't materially affect my point.

by Edmond 13y ago

codygman 13y ago

> That's debatable given that both approaches have been around for about the same length of time with different outcomes in terms of adoption. If unix had been created in LISP or ML, I believe we might be in the opposite position. Though that hinges on a LISP unix being as successful as the C one.

mike_hearn 13y ago
But before UNIX there was Symbolics, and Symbolics failed in the market whereas UNIX succeeded.
- codygman 13y ago
  Was that because C was better than Lisp though, because of timing, or because the people working on UNIX's goals were more closely aligned with the industry as a whole? There are of course many other things it could have been, but these are the first that come to my mind.

andrewflnr 13y ago

I'm writing OCaml now. I'm being messy and creative all over the place, sketching out ideas, and simply not trying to compile them until I think it'll work. I do this precisely because OCaml maps naturally onto how I think about the problems I'm working on right now. It's pseudocode until I run make, at which point the computer is running very useful checks on my reasoning. The "inflexible approach to solving problems" you refer to has, as far as I can tell, nothing at all to do with "machines", except perhaps in an exceptionally abstract sense, in the form of virtual machines designed for thinking about. On the other hand, problem solving doesn't get much more flexible than raw assembly. My point stands. I think the early adoption of imperative languages was more due to pragmatism than elegance[0]; at first, you had to stay close to the machine to get anything done, at first because that's all that existed (Fortran beat Lisp into existence by a year) and then for performance. Remember, Fortran was still basically a shortcut for assembly, while Lisp started as a purely mathematical abstraction, designed expressly for thinking about, that some goofball wrote an interpreter for. [0] This principle is still clearly in force today. We wouldn't bother with C++ and JVM languages and Unix so much if pragmatism wasn't paramount. I'm using Fortran as my example of an early imperative language. There might have been earlier ones (maybe a version of COBOL?), but since they were imperative it doesn't materially affect my point.