Live data from Hacker News

True Scala complexity

yz.mit.edu

121–130 of 152 posts

Re: True Scala complexity

#121
post #80
post #17

Earlier quoted context omitted.

See my examples below for how to do it in Gosu (via enhancements). In C# it's pretty much the same (via extension methods). Both are statically typed languages. Again, not 100% the same as Scala, and each comes with a different set of tradeoffs than the Scala approach (i.e. they're statically dispatched in Gosu), but they're certainly both reasonable, and much "simpler", solutions to the problem of "how do I add a fi…

You pretty much point to solutions which don't solve the problem mentioned in the blog post at all and seeing how C# extension methods basically reintroduced instanceOf checks as an implementation necessity I'm pretty sure that extension methods are the wrong way to go.

I don't remember C# extension methods being particularly prone to incur instanceOf checks, but I could be missing something; can you expand on this?

Re: True Scala complexity

#122

First, I think a blog post ending with "bring on the flames" should have comments enabled, otherwise it's not really fair. It comes across as whining without wanting to listen to advice or a response. Second, I think the blog post is useful because it shows what's wrong with some (fortunately very small) part of the Scala ecosystem, and because it points to a way to fix it. Here's a quick recap: The author tries to a…

I think you missed his real point, which was in the "Acknowledging Problems" section. Simply, what I got out of his post is that the individual features of the language interact in deep and complex ways. I don't use Scala, but that sounds like a fair and interesting point to make.

Re: True Scala complexity

#123

First, I think a blog post ending with "bring on the flames" should have comments enabled, otherwise it's not really fair. It comes across as whining without wanting to listen to advice or a response. Second, I think the blog post is useful because it shows what's wrong with some (fortunately very small) part of the Scala ecosystem, and because it points to a way to fix it. Here's a quick recap: The author tries to a…

First, I think a blog post ending with "bring on the flames" should have comments enabled, otherwise it's not really fair. It comes across as whining without wanting to listen to advice or a response. Speaking as someone who sometimes writes controversial things and never enables comments on my posts... I view collections of comments as discussions. Readers often form into communities, like Hacker News. If there are…

I actually agree. I prefer to see discussions take place across blogs or in actual communities.

Re: True Scala complexity

#124
post #12

Earlier quoted context omitted.

In Gosu, it's pretty much the same (though enhancements are statically dispatched and thus subject to a different set of limitations): enhancement MyEnhancement : T[] { function filterMap() { . . . } } Roughly the same in C# with extension methods, though with C# you explicitly import the extension method while in Gosu they're automatically always there (sort of good, sort of bad). Again, not exactly the same as the…

Both you and jashkenas are missing the point. The examples you are giving are also pretty easy to do in Scala. The more complex method he is proposing (filterMap) cannot be done at all in the languages you mention, though he only uses it precisely to get the most complex kind of method that Scala collections offer. But it is also possible, and I just blogged about it here: http://dcsobral.blogspot.com/2012/01/adding-…

Instead of getting bogged down in his specific example (the tree), I think it's more helpful to focus on his larger points in "On Acknowledging Problems" (the forest).

Re: True Scala complexity

#125
post #98
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...?

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.

Re: True Scala complexity

#126
post #100
post #98

Earlier quoted context omitted.

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 de…

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

Re: True Scala complexity

#127
post #98

Earlier quoted context omitted.

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

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.

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

Re: True Scala complexity

#128
post #73

First, I think a blog post ending with "bring on the flames" should have comments enabled, otherwise it's not really fair. It comes across as whining without wanting to listen to advice or a response. Second, I think the blog post is useful because it shows what's wrong with some (fortunately very small) part of the Scala ecosystem, and because it points to a way to fix it. Here's a quick recap: The author tries to a…

> Even with the flag disabled, Scala will be a more powerful language than any of the alternatives I can think of. How is Scala more powerful than Haskell, Agda, or Coq?

I guess it depends on the definition of "powerful". Scala unlike Haskell, has first class modules ( aka OO ) and unlike Coq (And Agda, I presume) is turing-complete. ( Not that those things really matter to make an awesome language :) ) But for mature statically typed langs running JVM, Scala is the most powerful ...

Re: True Scala complexity

#129
post #100

Earlier quoted context omitted.

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 de…

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

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

Re: True Scala complexity

#130
post #129

Earlier quoted context omitted.

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

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

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.
Post reply on HN