8 ms·

Ha. I think Java is the best all round language. Oddly, it's usually not the best language for any specific thing :). Paradox :)

jharger 10y ago
Reminds me of this quote: "Perl is like vise grips. You can do anything with it but it is the wrong tool for every job." - Bruce Eckel
qwertyuiop924 10y ago
I think Lisp is the best all-rounder. If it isn't the best at something, you can MAKE it the best.
- jomamaxx 10y ago
  Lisp as a 'language' maybe, but the problem is it's more than syntax and compiler. The advantage of JVM, garbage collection, relative platform neutrality, docs that are really consistent, libraries that are very easily shared, and the huge amount of things built into the lang package over time, the number of Q/A on Stack Overflow, resources available, support, 3rd part libraries - these are things that Lisp really lacks, making it not a very useful thing all around.
  - qwertyuiop924 10y ago
    It depends on what lisp you pick. And while CL isn't my favorite, if you're a Common Lisp user, some of that stuff's already there for you. But yeah, the JVM is a great platform. But Java is inseparable from it, and Java isn't a great language.
  - _asummers 10y ago
    Lisp and JVM are not mutually exclusive, of course. There were JVM Lisps before Clojure (I don't know any off the top of my head), but Clojure is an extremely nice language to work with, if you've never worked with it.
- catnaroek 10y ago
  Could you tell me how to eliminate the notion of object identity from Lisp when it's unwanted? (FWIW, “just don't use eq” isn't good enough advice, because you can just mutate one of two supposedly “equal” objects to observe the difference between them.) This is crucial to make functional programming work.
  - qwertyuiop924 10y ago
    >Could you tell me how to eliminate the notion of object identity from Lisp when it's unwanted? So by "object identity," you mean doing equality comparisons with pointers instead of actually value equality. Just don't use eq. Use equal instead. >FWIW, “just don't use eq” isn't good enough advice, because you can just mutate one of two supposedly “equal” objects to observe the difference between them Yeah, that's true of every programming language in existance. What, do you want every equal object to be mutated, along with the one you mutated? That's just crazy talk. >This is crucial to make functional programming work. Well, if you're doing FP, than you aren't mutating values anyway. So just don't use eq. At this point, your question utterly baffles me. Come back with a better explanation, or some examples of what you want, and I'll try to give you a better answer.
    - catnaroek 10y ago
      > So by "object identity," you mean doing equality comparisons with pointers instead of actually value equality. Just don't use eq. Use equal instead. The problem goes further than that. “equal” doesn't really mean equal - it only means equal until the next mutation. Not very helpful in a language with unrestricted mutation. > Yeah, that's true of every programming language in existance. It isn't true in ML or Haskell. In those languages, mutation is strictly opt-in, on a per-type basis. When you don't use mutation, equality is by value. When you use mutation, equality is by object identity. You can't “accidentally distinguish” between two copies of the same immutable value. > What, do you want every equal object to be mutated, along with the one you mutated? That's just crazy talk. I want to distinguish between objects meant to be mutated and values not meant to. > Well, if you're doing FP, than you aren't mutating values anyway. So just don't use eq. If I'm doing functional programming, I want to mutate as little as possible, but certain things require mutation to be done efficiently. What I want is the language to help me distinguish between functional values and imperative objects. (0) ML: If you attempt to mutate a value, you get a compile-time error. (1) Racket: If you attempt to mutate a value, you get a runtime error. Pretty sensible in a dynamic language. (2) Common Lisp: Only primitives are values, and mutating anything else is permitted.

jharger 10y ago

Reminds me of this quote: "Perl is like vise grips. You can do anything with it but it is the wrong tool for every job." - Bruce Eckel

qwertyuiop924 10y ago

I think Lisp is the best all-rounder. If it isn't the best at something, you can MAKE it the best.

jomamaxx 10y ago
Lisp as a 'language' maybe, but the problem is it's more than syntax and compiler. The advantage of JVM, garbage collection, relative platform neutrality, docs that are really consistent, libraries that are very easily shared, and the huge amount of things built into the lang package over time, the number of Q/A on Stack Overflow, resources available, support, 3rd part libraries - these are things that Lisp really lacks, making it not a very useful thing all around.
- qwertyuiop924 10y ago
  It depends on what lisp you pick. And while CL isn't my favorite, if you're a Common Lisp user, some of that stuff's already there for you. But yeah, the JVM is a great platform. But Java is inseparable from it, and Java isn't a great language.
- _asummers 10y ago
  Lisp and JVM are not mutually exclusive, of course. There were JVM Lisps before Clojure (I don't know any off the top of my head), but Clojure is an extremely nice language to work with, if you've never worked with it.
catnaroek 10y ago
Could you tell me how to eliminate the notion of object identity from Lisp when it's unwanted? (FWIW, “just don't use eq” isn't good enough advice, because you can just mutate one of two supposedly “equal” objects to observe the difference between them.) This is crucial to make functional programming work.
- qwertyuiop924 10y ago
  >Could you tell me how to eliminate the notion of object identity from Lisp when it's unwanted? So by "object identity," you mean doing equality comparisons with pointers instead of actually value equality. Just don't use eq. Use equal instead. >FWIW, “just don't use eq” isn't good enough advice, because you can just mutate one of two supposedly “equal” objects to observe the difference between them Yeah, that's true of every programming language in existance. What, do you want every equal object to be mutated, along with the one you mutated? That's just crazy talk. >This is crucial to make functional programming work. Well, if you're doing FP, than you aren't mutating values anyway. So just don't use eq. At this point, your question utterly baffles me. Come back with a better explanation, or some examples of what you want, and I'll try to give you a better answer.
  - catnaroek 10y ago
    > So by "object identity," you mean doing equality comparisons with pointers instead of actually value equality. Just don't use eq. Use equal instead. The problem goes further than that. “equal” doesn't really mean equal - it only means equal until the next mutation. Not very helpful in a language with unrestricted mutation. > Yeah, that's true of every programming language in existance. It isn't true in ML or Haskell. In those languages, mutation is strictly opt-in, on a per-type basis. When you don't use mutation, equality is by value. When you use mutation, equality is by object identity. You can't “accidentally distinguish” between two copies of the same immutable value. > What, do you want every equal object to be mutated, along with the one you mutated? That's just crazy talk. I want to distinguish between objects meant to be mutated and values not meant to. > Well, if you're doing FP, than you aren't mutating values anyway. So just don't use eq. If I'm doing functional programming, I want to mutate as little as possible, but certain things require mutation to be done efficiently. What I want is the language to help me distinguish between functional values and imperative objects. (0) ML: If you attempt to mutate a value, you get a compile-time error. (1) Racket: If you attempt to mutate a value, you get a runtime error. Pretty sensible in a dynamic language. (2) Common Lisp: Only primitives are values, and mutating anything else is permitted.