4 ms·

As someone who has programmed professionally in Java, Scala, and Lisp (including Clojure), I might be qualified to assert that your sports analogy is off the ma

As someone who has programmed professionally in Java, Scala, and Lisp (including Clojure), I might be qualified to assert that your sports analogy is off the mark. All of these programming languages can be effectively used to solve many of the same problems, though each language may excel at addressing certain kinds of problems better. For me, programming in a dialect of Lisp is just more fun than programming in the other languages. Java is not fun at all, in comparison. And that's largely due to the fact that it can be difficult in Java to write reusable code. Consequently, you either have to repeat yourself a lot or tie yourself up in knots to figure out a way to not repeat yourself. Repeating oneself is tedious and boring. On the other hand, static type checking can save you a lot of time debugging. But it can also slow you down. It's probably a net win overall for most problems, but for some problems, it is too restrictive. I find Scala to be a happy medium for most problems, but I often switch to Python for small programs, where the freedom from static typing can make development much easier and faster. I think the problem with Lisp is that most people just don't "get it". I'm not sure why they don't, but perhaps it's a fact that I just have to accept. On the other hand, I firmly believe that the state of software engineering would be greatly improved if most programmers did get Lisp. I can't say the same thing about Java, however. In Java there isn't really much to get that you wouldn't get by learning any other OO programming language.

6ren 15y ago
Came across this while researching Turing's proof that a turing machine can compute anything that is computable†. It's Church, comparing his and Turing's approaches: > computability by a Turing machine ... has the advantage of making the identification with effectiveness in the ordinary (not explicitly defined) sense evident immediately. (1937a: 43.) http://plato.stanford.edu/entries/church-turing/ http://plato.stanford.edu/entries/church-turing/ If we see imperative languages (e.g. Java) as descending from Turing machines, and functional languages (e.g. Lisp) as descending from Church's lambda-definability, the same observation seems to apply. It's not that Turing's approach is better, just easier to "get". † "computable" meaning "can be computed" (not "computable with a turing machine"). Turing doesn't prove this formally - it's an intuitive appeal, and no exceptions have been found. See section 9, page 249 (page 20 of the pdf) https://docs.google.com/viewer?url=http://www.cs.virginia.edu/~robins/Turing_Paper_1936.pdf https://docs.google.com/viewer?url=http://www.cs.virginia.ed...

6ren 15y ago

Came across this while researching Turing's proof that a turing machine can compute anything that is computable†. It's Church, comparing his and Turing's approaches: > computability by a Turing machine ... has the advantage of making the identification with effectiveness in the ordinary (not explicitly defined) sense evident immediately. (1937a: 43.) http://plato.stanford.edu/entries/church-turing/ http://plato.stanford.edu/entries/church-turing/ If we see imperative languages (e.g. Java) as descending from Turing machines, and functional languages (e.g. Lisp) as descending from Church's lambda-definability, the same observation seems to apply. It's not that Turing's approach is better, just easier to "get". † "computable" meaning "can be computed" (not "computable with a turing machine"). Turing doesn't prove this formally - it's an intuitive appeal, and no exceptions have been found. See section 9, page 249 (page 20 of the pdf) https://docs.google.com/viewer?url=http://www.cs.virginia.edu/~robins/Turing_Paper_1936.pdf https://docs.google.com/viewer?url=http://www.cs.virginia.ed...