7 ms·
That was not the question. It is trivial to do that in Scala for the use case mentioned. The problem is adding it as an "instance" method to a collection and e
by soc88 15y ago
That was not the question. It is trivial to do that in Scala for the use case mentioned.
The problem is adding it as an "instance" method to a collection and expecting that it is usable by something not being a collection at all.
- lisper 15y agoI have no idea what you mean by "adding it (which "it"?) as an "instance" method to a collection". You can do this: (defmethod filter-map (f (c (eql some-particular-collection))) ...) but I suspect that's not what you meant. I also can't make heads or tails out of "expecting that it (which "it"?) is usable by something not being a collection at all." I'm not even sure that's proper English, let alone semantically meaningful.
- soc88 15y agoMaybe 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 agoMaybe 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 agoWell ... 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 agoHey, 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 agoSorry, 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 agoThe 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 agoIf 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 agoThat'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.
- a_strange_guy 15y agoWell that is the beauty of it. In Scala methods/functions that come after the dot are privileged. In a language with multiple dispatch they are not. So CL solves the problem without adding more complexity, whereas in Scala you have to extort yourself to shoehorn some functionality after the dot.
- soc88 15y agoCL isn't even statically typed. Everything is easy if you don't expect that the language gives you any useful guarantees.