Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

True Scala complexity

yz.mit.edu

Post reply on HN
Print view View original

91–100 of 152 posts

Re: True Scala complexity

#91

Post by pron »

soc88 wrote: post #87
pron wrote: post #85

I think that the source of the problem is that Scala is simply not an opinionated language. You can go functional, you can go OO; you can go immutable, you can go with locks etc. And because it tries to do everything it falls on its face, but worse than that - its users don't really know HOW you're supposed to use it. I always like to contrast Scala with Clojure and Erlang. Both are very opinionated: they have a phil…

Both "more opinionated" languages are considerably slower than Scala, so sometimes it is necessary to fall back to "ugly, imperative" code and those languages make sure you will hate that experience. The difference imho is that Scala doesn't punish you for trying to be fast where necessary. Apart from that I would really like to where Groovy or Kotlin are "more elegant or simpler". I would have probably looked into t…

Actually falling back to ugly imperative and super-fast code in Clojure is extremely easy, and its integration with Java is a pleasure. But I don't want to pit a specific language against Scala. My point is that it isn't clear (to anyone possibly), what Scala IS, other than a kitchen-sink language for programming concepts.

Some things in Scala are easy and some things are hard, but it's not always clear why. I'd expect the "good" things (whatever is considered good by the language designers, their expert opinion, that is) to be easy and the "bad" things hard. But in Scala it seems that whether something is easy or not depends on how well it fits with the language's algebraic model, and not how well it fits with recommended practice. Immutable is easy (that must be good, no?), but mutable is just as easy (so, wait, I'm supposed to... what exactly?); functional is easy, but so is imperative; implicits are easy but extension methods, as the blog post shows, can be really hard; type inference is easy except when it's not. See the problem?

Re: True Scala complexity

#92

Post by a_strange_guy »

soc88 wrote: post #83
lisper wrote: post #5

Earlier quoted context omitted.

Common Lisp: (defmethod filter-map (f (a array)) ...)

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.

Well 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.

Re: True Scala complexity

#93

Post by soc88 »

lisper wrote: post #90
soc88 wrote: post #83

Earlier quoted context omitted.

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.

I 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 mea…

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?

Re: True Scala complexity

#94

Post by soc88 »

a_strange_guy wrote: post #92
soc88 wrote: post #83

Earlier quoted context omitted.

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.

Well 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.

CL isn't even statically typed. Everything is easy if you don't expect that the language gives you any useful guarantees.

Re: True Scala complexity

#95

Post by soc88 »

pron wrote: post #91
soc88 wrote: post #87

Earlier quoted context omitted.

Both "more opinionated" languages are considerably slower than Scala, so sometimes it is necessary to fall back to "ugly, imperative" code and those languages make sure you will hate that experience. The difference imho is that Scala doesn't punish you for trying to be fast where necessary. Apart from that I would really like to where Groovy or Kotlin are "more elegant or simpler". I would have probably looked into t…

Actually falling back to ugly imperative and super-fast code in Clojure is extremely easy, and its integration with Java is a pleasure. But I don't want to pit a specific language against Scala. My point is that it isn't clear (to anyone possibly), what Scala IS, other than a kitchen-sink language for programming concepts. Some things in Scala are easy and some things are hard, but it's not always clear why. I'd expe…

> See the problem?

No. Must be because I actually use the language instead of trying to bash it to advertise another language. :-)

I'm still excited to see another language solving the problem mentioned in the article. At the moment it really looks like as Scala gets bashed for the complexity of something not possible in any other language out there.

Re: True Scala complexity

#96

Post by [deleted] »

pron wrote: post #91
soc88 wrote: post #87

Earlier quoted context omitted.

Both "more opinionated" languages are considerably slower than Scala, so sometimes it is necessary to fall back to "ugly, imperative" code and those languages make sure you will hate that experience. The difference imho is that Scala doesn't punish you for trying to be fast where necessary. Apart from that I would really like to where Groovy or Kotlin are "more elegant or simpler". I would have probably looked into t…

Actually falling back to ugly imperative and super-fast code in Clojure is extremely easy, and its integration with Java is a pleasure. But I don't want to pit a specific language against Scala. My point is that it isn't clear (to anyone possibly), what Scala IS, other than a kitchen-sink language for programming concepts. Some things in Scala are easy and some things are hard, but it's not always clear why. I'd expe…

[deleted]

Re: True Scala complexity

#97

Post by pron »

soc88 wrote: post #95
pron wrote: post #91

Earlier quoted context omitted.

Actually falling back to ugly imperative and super-fast code in Clojure is extremely easy, and its integration with Java is a pleasure. But I don't want to pit a specific language against Scala. My point is that it isn't clear (to anyone possibly), what Scala IS, other than a kitchen-sink language for programming concepts. Some things in Scala are easy and some things are hard, but it's not always clear why. I'd expe…

> See the problem? No. Must be because I actually use the language instead of trying to bash it to advertise another language. :-) I'm still excited to see another language solving the problem mentioned in the article. At the moment it really looks like as Scala gets bashed for the complexity of something not possible in any other language out there.

Yeah, I'm sorry about that. That was not my intention. But you're right, I have grown disillusioned with Scala, partly because of stuff like the examples in the pop-quiz section of the post, but mostly because of the other things I mentioned.

But I don't agree with your analysis. I won't go into the question of whether or not the feat mentioned in the post is possible in other languages or not, but I do know that if I came to a rather experienced Scala programmer and asked him off-hand if the tasks attempted in the post are easy, I suspect that the answer would be "yes". Scala is just... surprising like that.

Re: True Scala complexity

#98

Post by lisper »

soc88 wrote: post #93
lisper wrote: post #90

Earlier quoted context omitted.

I 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 mea…

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?

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...?

Re: True Scala complexity

#99

Post by a_strange_guy »

soc88 wrote: post #88
nickik wrote: post #19

Earlier quoted context omitted.

Some languages show that you can do these things in a simple way. For example I impmentet a Persisten Vector for Dylan (very common lisp like language) in about 3 sessions. It was the first time I wrote dylan code befor that I only read on dylan. Its working and fiels like a "native" collection allready. I guess it would take me the same amount of time fully understand this article. Other people in this thread have s…

I still have not found a single comment showing "how easy it is in other languages". Do you have a link?

I'm not Parent, but I think that this is his implementation: https://github.com/nickik/Persistent-Vector-in-Dylan/blob/ma... The last part (line 222+) is what defines it as a sequence in Dylan.

Dylan (and other multi-dispatch languages) don't have the problem of "adding methods to objects/classes", because methods are standalone entities (first-class, whereas in Scala the are not) that exist independently of the data they operate on.

so you can just "add" a method to something by defining it:

    define method upcase(s :: String) => (ret :: String)
      // code here
    end method upcase;

    "abc".upcase // => "ABC"
    // is just sugar for
    upcase("abc") // => "ABC"
so you could define 'forward-iteration-protocol (a method that returns 8 values) on anything in Dylan (built-in or not) to make it a "Sequence".

Re: True Scala complexity

#100

Post by soc88 »

lisper wrote: post #98
soc88 wrote: post #93

Earlier quoted context omitted.

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?

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...?

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.

Post reply on HN