4 ms·

Maybe you should try to understand the actual issue first, _before_ claiming that "but it is easy in my pet language" stuff ... Additionally, last time I looke

by soc88 15y ago

Maybe you should try to understand the actual issue first, _before_ claiming that "but it is easy in my pet language" stuff ... Additionally, last time I looked Cl wasn't really statically typed. Has that changed recently?

lisper 15y ago
Maybe if you stated what you think the actual issue is in clear, unambiguous terms instead of being pissy and snarky about it this discussion will not degenerate into chaos. No, CL is not statically typed. And your point would be...?
- soc88 15y ago
  Well ... maybe just click the link and read the article? It is pretty clear. Ahh, the famous behavior of Lisp fanatics. Tragic, how it is obvious to everyone – except themselves – why no one wants to use their language. > No, CL is not statically typed. And your point would be...? Uh ... what about a) Author complains about the inability of the compiler to prove some property of his code. b) Untyped languages – by definition – don't provide any substantial proving abilities based on types. c) Therefore, you are completely missing the point.
  - lisper 15y ago
    > Author complains about the inability of the compiler to prove some property of his code. No, the author is complaining about the complexity of the language. Maybe you should go back and re-read the article. Start with the title. > Untyped languages Lisp is not untyped. "Not statically typed" is not synonymous with "untyped." > Therefore, you are completely missing the point. Which of us is missing the point remains to be seen.
  - scott_s 15y ago
    Hey, you're both [edit: mistake, see below] new here and obviously knowledgable about the topic at hand. At HN, we try to maintain civility - it's an explicit goal of the community. What this implies is that if you're in a discussion with someone, and you realize they don't understand an important point of the discussion, instead of using sarcasm, it's much better to say "Oh, I see, you're missing point x."
    - lisper 15y ago
      > you're both new here My account was created 1458 days ago. Just how long does someone have to be here before you no longer consider them "new"?
      - scott_s 15y ago
        Sorry, I said "both" by mistake. You are an active and well-known contributor to HN, and I know you're reasonable, which is part of why I felt soc88 was being unreasonable.
- scott_s 15y ago
  The issue is with static typing. One can define a filterMap function in Scala much as you defined it in CL. The author's goal is to do that while also always statically knowing the most precise type of the returned collection. So, it's an issue that only comes up in a statically typed language. Of course, I don't program in Scala, so my explanation may not be accurate.
  - lisper 15y ago
    > The issue is with static typing. One can define a filterMap function in Scala much as you defined it in CL. The author's goal is to do that while also always statically knowing the most precise type of the returned collection. That's right. > So, it's an issue that only comes up in a statically typed language. No, that's wrong. You can do type inference in non-statically typed languages. Lisp compilers do this all the time.
    - scott_s 15y ago
      If a compiler infers types at compile-time for a dynamically typed language, I still consider that "static typing" because it's statically inferring the types. If the term "static typing" is the problem, then I can rephrase: it only comes up when you try to determine all types before executing the program.
      - lisper 15y ago
        That's right. At this point I would like to remind both you and soc88 of a parable: Patient: Doctor, it hurts when I do this. Doctor: Well, don't do that. (Soc88's response, in the context of this parable, is something along the lines of, "But anyone who doesn't do this is a moron.") Inferring types at compile time is necessarily hard. It is a corollary of the halting problem that no static type inference can be perfect. Therefore you have the following choices: 1. A simple compiler that sometimes fails to identify type errors at compile time 2. A simple compiler that sometimes produces false positives (i.e. signals a type error in a program that is in fact correct) 3. A complicated compiler. (Note that even a complicated compiler will also do 1 or 2 or both, but potentially less often than a simple compiler.) Those are your only options. Reasonable people can disagree over which is preferable.

by soc88 15y ago

lisper 15y ago

Maybe if you stated what you think the actual issue is in clear, unambiguous terms instead of being pissy and snarky about it this discussion will not degenerate into chaos. No, CL is not statically typed. And your point would be...?

soc88 15y ago
Well ... maybe just click the link and read the article? It is pretty clear. Ahh, the famous behavior of Lisp fanatics. Tragic, how it is obvious to everyone – except themselves – why no one wants to use their language. > No, CL is not statically typed. And your point would be...? Uh ... what about a) Author complains about the inability of the compiler to prove some property of his code. b) Untyped languages – by definition – don't provide any substantial proving abilities based on types. c) Therefore, you are completely missing the point.
- lisper 15y ago
  > Author complains about the inability of the compiler to prove some property of his code. No, the author is complaining about the complexity of the language. Maybe you should go back and re-read the article. Start with the title. > Untyped languages Lisp is not untyped. "Not statically typed" is not synonymous with "untyped." > Therefore, you are completely missing the point. Which of us is missing the point remains to be seen.
- scott_s 15y ago
  Hey, you're both [edit: mistake, see below] new here and obviously knowledgable about the topic at hand. At HN, we try to maintain civility - it's an explicit goal of the community. What this implies is that if you're in a discussion with someone, and you realize they don't understand an important point of the discussion, instead of using sarcasm, it's much better to say "Oh, I see, you're missing point x."
  - lisper 15y ago
    > you're both new here My account was created 1458 days ago. Just how long does someone have to be here before you no longer consider them "new"?
    - scott_s 15y ago
      Sorry, I said "both" by mistake. You are an active and well-known contributor to HN, and I know you're reasonable, which is part of why I felt soc88 was being unreasonable.
scott_s 15y ago
The issue is with static typing. One can define a filterMap function in Scala much as you defined it in CL. The author's goal is to do that while also always statically knowing the most precise type of the returned collection. So, it's an issue that only comes up in a statically typed language. Of course, I don't program in Scala, so my explanation may not be accurate.
- lisper 15y ago
  > The issue is with static typing. One can define a filterMap function in Scala much as you defined it in CL. The author's goal is to do that while also always statically knowing the most precise type of the returned collection. That's right. > So, it's an issue that only comes up in a statically typed language. No, that's wrong. You can do type inference in non-statically typed languages. Lisp compilers do this all the time.
  - scott_s 15y ago
    If a compiler infers types at compile-time for a dynamically typed language, I still consider that "static typing" because it's statically inferring the types. If the term "static typing" is the problem, then I can rephrase: it only comes up when you try to determine all types before executing the program.
    - lisper 15y ago
      That's right. At this point I would like to remind both you and soc88 of a parable: Patient: Doctor, it hurts when I do this. Doctor: Well, don't do that. (Soc88's response, in the context of this parable, is something along the lines of, "But anyone who doesn't do this is a moron.") Inferring types at compile time is necessarily hard. It is a corollary of the halting problem that no static type inference can be perfect. Therefore you have the following choices: 1. A simple compiler that sometimes fails to identify type errors at compile time 2. A simple compiler that sometimes produces false positives (i.e. signals a type error in a program that is in fact correct) 3. A complicated compiler. (Note that even a complicated compiler will also do 1 or 2 or both, but potentially less often than a simple compiler.) Those are your only options. Reasonable people can disagree over which is preferable.