search

scalapuzzlers / scalapuzzlers.github.com

Github Pages behind scalapuzzlers.com
www.scalapuzzlers.com
161 stars 53 forks source link

Puzzler 29 "Doesn't apply to me" #57

Closed skyluc closed 12 years ago

skyluc commented 12 years ago

Here's a puzzler which bit me a couple of time.

Suggestions to improve the solution section are most welcome.

cc @dotta, @dragos, @freekh, @tbje

demobox commented 12 years ago

Thanks, @skyluc ! Glad to hear from you ;-)

demobox commented 12 years ago

I like! (@libby girlfriend likes too ;-) ). Just a quick question: what's the motivation behind the first and last possible answers? I.e. what would be the expected "logic" to make them possible..?

Thanks!

skyluc commented 12 years ago

The first answer would be the result if StringBuilder was immutable. padding returns the parameter, not the result of the loop, so it wouldn't have changed. (This assumes that loop is behaving as 'planned', with the compiler wrapping the body into a function)

The last one, hmmm, it's a bit more tenuous. If append was mutating the StringBuilder but returning a copy of the original value (kind of like Map.put() in Java), then the apply calls would fail on those indexes. And I liked having an 'everything fails' answer :smile:

demobox commented 12 years ago

Ah, OK @skyluc , thanks for explaining that. Do you think it's worth also pointing out in the explanation that the reason why you get abc* in the first case is because the append function actually only gets called once..?

skyluc commented 12 years ago

Yes. I'll update the explanation with details of what is happening in each case.

demobox commented 12 years ago

@skyluc Looks like we have a case of "great minds think alike" with you and @som-snytt over at PR 56.

Do either of you have any suggestions about how would could either combine these or make them less similar? My initial feeling would be to create one combined puzzler and obviously credit both of you.

Any thoughts..?

som-snytt commented 12 years ago

"Hello, kitteh" is inherently funnier. Plus it already benefited from scala-user feedback.

So, while I'm not inclined to spend more time on this, feel free to do the open source thing.

Needless to add, but for the record, you could avoid this situation with timely updates. It's nice to have puzzlers that are clever and complete, etc, but it's easier to just republish than sweat it.

demobox commented 12 years ago

Fair point. Thanks for the feedback!

skyluc commented 12 years ago

Dang, I should have submitted earlier :smiley:

Yes, they are both using the same trick. I could change mine to use a different mutable collection, but that would still be the same reasoning, and having a import ...mutable... would make the solution more obvious.

I'm fine with either. I like the fact that mine also generate an exception.

demobox commented 12 years ago

Dang, I should have submitted earlier

Well, @som-snytt is right in pointing out that this would have been avoided if we had been able to review earlier. And, in fairness, that submission was indeed made over three weeks ago. @nermin ..?

som-snytt commented 12 years ago

If pressed, I would say the devious answer is appending one char, which makes it look like the foreach happens just once, which seems impossible. (Eta-expansion is hard to reason about, especially when you don't expect it.) A couple of people said it clearly doesn't compile, with other options throwing or doing what you expect (which both seem possible, except that no one expects the spanish inquisition).

demobox commented 12 years ago

Poke him with your soft cushions? ;-)

demobox commented 12 years ago

Integrated into http://scalapuzzlers.com/#pzzlr-027. Thanks, @skyluc and @som-snytt , and sorry about the mixup!

som-snytt commented 12 years ago

It's a great burden running the premier Scala puzzlers site. Wait, you took out the throws option? I could kind of reconcile myself to asterisks in lieu of spaces, and no 2.10 string interpolation which also apparently still makes some poor schmucks do a spit take. But no throws? Wait... it's open source... and maybe I don't deal well with editors... ok, maybe suggesting a throws option gives the game away, because then they'll think, how could it throw? Is there anything at stake here? Like StackOverflow rep? Now that would be a nice crossover feature, a correct answer boosts your SO rep. Moreover, contributing a puzzler should be worth like 500.

demobox commented 12 years ago

Wait, you took out the throws option?

Choices 2 and 4 should still allow the option of "fails with a runtime exception", i.e. throws - it was just re-phrased to line up with e.g. puzzler 2.

Would you prefer a phrasing such as "throws an exception"? Or, more specifically, "throws StringIndexOutOfBoundsException"?