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

141–150 of 152 posts

Re: True Scala complexity

#141

Post by scott_s »

soc88 wrote: post #138
scott_s wrote: post #124

Earlier quoted context omitted.

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

I disagree. The problem here is that those claiming “it is easy in language A” haven't even understood the problem. People should first actually understand the problem, only after that a discussion about solutions makes sense.

That's not the problem, it's a problem. That is, it's a problem in this discussion, but I feel it has been dealt with well. The author's main point, though, was not about the specific example. That was to illustrate his larger point, which was about the complexity that arises when rich features interact.

Re: True Scala complexity

#142

Post by soc88 »

lisper wrote: post #137
scott_s wrote: post #131

Earlier quoted context omitted.

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.

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

4. A simple compiler that sometimes requires a type annotation.

> Those are your only options. Reasonable people can disagree over which is preferable.

Ah ok. Being right seems to be more important to you than having a honest discussion.

Have fun, I'm out.

Re: True Scala complexity

#143

Post by lisper »

soc88 wrote: post #142
lisper wrote: post #137

Earlier quoted context omitted.

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

4. A simple compiler that sometimes requires a type annotation. > Those are your only options. Reasonable people can disagree over which is preferable. Ah ok. Being right seems to be more important to you than having a honest discussion. Have fun, I'm out.

> A simple compiler that sometimes requires a type annotation.

It is easy to show that that will not solve the problem. If your language is Turing-complete, then you can embed (say) a Lisp interpreter and arbitrary Lisp code within it. The only way your compiler can be complete and correct for your language is for it to be complete and correct for this embedded Lisp. This is a fundamental result. There is no way around it.

Re: True Scala complexity

#144

Post by lisper »

scott_s wrote: post #140
lisper wrote: post #137

Earlier quoted context omitted.

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

I don't disagree with your points, but now that we've established that, that is why your original example does not solve the problem as presented in the post. The problem inherently has to do with statically inferring types.

That depends on what you consider to be "solving the problem." Do you want to "do this" or do you want to be free from pain? You can have one or the other, but not both.

OF COURSE static type inference is hard. That's a straightforward consequence of the halting problem. Pointing to defmethod is just an oblique way of making the point that perfect type inference is NOT NECESSARY for getting things done. You can choose to lament the complexity of Scala (and static type inferencing in general) or you can use Lisp or Python and trade certain compile-time guarantees for simplicity. Like I said, reasonable people can disagree over which is preferable.

What reasonable people cannot do is insist that there is a single perfect solution that is both simple and error-free. Anyone who believes that has not understood the implications of the halting problem.

Another thing reasonable people cannot do is frame the tradeoff as a binary choice: either you use static type inferencing, or you give up all compile-time guarantees. That is simply not true, as is amply demonstrated by e.g. the SBCL compiler. It's a complex, multi-dimensional space of tradeoffs in language design, compiler complexity, and different kinds of compile-time guarantees. It's INHERENTLY complicated. The best you can hope to do is find a reasonable point in the design space for your particular quality metric. For the OP, Scala isn't it.

Re: True Scala complexity

#145

Post by scott_s »

lisper wrote: post #144
scott_s wrote: post #140

Earlier quoted context omitted.

I don't disagree with your points, but now that we've established that, that is why your original example does not solve the problem as presented in the post. The problem inherently has to do with statically inferring types.

That depends on what you consider to be "solving the problem." Do you want to "do this" or do you want to be free from pain? You can have one or the other, but not both. OF COURSE static type inference is hard. That's a straightforward consequence of the halting problem. Pointing to defmethod is just an oblique way of making the point that perfect type inference is NOT NECESSARY for getting things done. You can choos…

Since the OP uses Scala to solve his problems, I have a feeling that Scala is, to him, a reasonable place in the design space. Scala allows a function much like your example. He used that example not say "This is a failing of Scala, and why I will not use it," but to say "This example demonstrates a complexity that is a natural consequence of the design of Scala." In other words, he said something quite similar to what you said.

Re: True Scala complexity

#146

Post by jonshea »

extempore wrote: post #111
jonshea wrote: post #65

If anyone is able, would you please explain to me these two questions from the quiz? I’m stumped. Why does `toSeq` compile, but not `toIndexedSeq`? Set(1,2,3).toIndexedSeq sortBy (-_) Set(1,2,3).toSeq sortBy (-_) Why does `h` compile, but `f` does not? def add(x: Int, y: Int) = x + y val f = add(1,_) val h = add(_,_)

toIndexedSeq takes a type parameter (I'm not sure why - it appears unncessary) which means the result of toIndexedSeq is not known when it is attempting to infer the Ordering. toSeq doesn't take one, it's known to be Seq[Int]. The other looks like some quirk of partial application. It's unlikely there's any fundamental reason, only an implementation imperfection.

Good to know. Thanks Paul!

Re: True Scala complexity

#147

Post by lisper »

scott_s wrote: post #145
lisper wrote: post #144

Earlier quoted context omitted.

That depends on what you consider to be "solving the problem." Do you want to "do this" or do you want to be free from pain? You can have one or the other, but not both. OF COURSE static type inference is hard. That's a straightforward consequence of the halting problem. Pointing to defmethod is just an oblique way of making the point that perfect type inference is NOT NECESSARY for getting things done. You can choos…

Since the OP uses Scala to solve his problems, I have a feeling that Scala is, to him, a reasonable place in the design space. Scala allows a function much like your example. He used that example not say "This is a failing of Scala, and why I will not use it," but to say "This example demonstrates a complexity that is a natural consequence of the design of Scala." In other words, he said something quite similar to wh…

> Scala is, to him, a reasonable place in the design space

Reasonable perhaps, but manifestly not ideal or he would not be complaining about how complex it is.

> he said something quite similar to what you said

Well, I didn't actually say much, I just posted a snippet of code and left people to draw their own conclusions. Why soc88 chose to start a fight I can only guess, but it seems to be not uncommon behavior among people trying to defend untenable positions.

Re: True Scala complexity

#148

Post by scott_s »

lisper wrote: post #147
scott_s wrote: post #145

Earlier quoted context omitted.

Since the OP uses Scala to solve his problems, I have a feeling that Scala is, to him, a reasonable place in the design space. Scala allows a function much like your example. He used that example not say "This is a failing of Scala, and why I will not use it," but to say "This example demonstrates a complexity that is a natural consequence of the design of Scala." In other words, he said something quite similar to wh…

> Scala is, to him, a reasonable place in the design space Reasonable perhaps, but manifestly not ideal or he would not be complaining about how complex it is. > he said something quite similar to what you said Well, I didn't actually say much, I just posted a snippet of code and left people to draw their own conclusions. Why soc88 chose to start a fight I can only guess, but it seems to be not uncommon behavior amon…

What you said two posts up about inherent complexities, not at the beginning.

Re: True Scala complexity

#149

Post by Peaker »

gclaramunt wrote: post #128
Peaker wrote: post #73

Earlier quoted context omitted.

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

Well, Scala has advantages and disadvantages over Haskell, but I wouldn't say it is more "powerful" than Haskell.

Consider the implementation of a properly lazy "const" function in Haskell:

  const x _ = x
And in Scala:

http://apocalisp.wordpress.com/2010/04/21/a-proper-constant-...

Not sure about Coq, but Agda is Turing Complete (you just need to turn off termination checks) and Epigram also supports general recursion as well as structural recursion with total functions.

Re: True Scala complexity

#150

Post by soc88 »

scott_s wrote: post #141
soc88 wrote: post #138

Earlier quoted context omitted.

I disagree. The problem here is that those claiming “it is easy in language A” haven't even understood the problem. People should first actually understand the problem, only after that a discussion about solutions makes sense.

That's not the problem, it's a problem. That is, it's a problem in this discussion, but I feel it has been dealt with well. The author's main point, though, was not about the specific example. That was to illustrate his larger point, which was about the complexity that arises when rich features interact.

The issue the author mentioned has already been solved in a much more easy and efficient way, without trying to use every feature of the type system.

Now the question remains: Should a language make almost-impossible and dangerous tasks easy or hard? I certainly prefer a language like Scala, which makes easy things easy, hard things possible and dangerous things hard, instead of the other way around.

Post reply on HN