Andrew Phillips

> Do you speak Dutch too ? :-)

Ik heb een tijdje in Nederland gewoond, ja ;-) Prettig weekend!

ap

> Especially now I won a copy of the book ! :-D

Gefeliciteerd en veel leesplezier!

ap

> The winners are:
>
> Jan Goyvaerts
> chris webster
> Palak Mathur
> Campbell Ritchie

Congratulations to the winners, and thanks to everyone for participating and having us on the Ranch. It's been a lot of fun!

@Chris, Campbell: Thank you for your generous gestures!

ap

> I guess I won't know them by heart when reading the book. Because if it was easy to remember, it wouldn't be a puzzle. :-)

*grin* And luckily (or should that be "unfortunately"?) there are enough puzzlers in the book that, even if you remember all the ones from the talk, you'll still have fun. More seriously, the discussion of alternatives and possible lessons/best practices in the book will hopefully be useful even for puzzlers for which you already know the answer.

Happy puzzling!

ap

> I'll watch the Scala Days session, thanks !

The recording of our 2014 Scala Days talk is also available on Parleys, by the way. I should add a warning, though: the more of these you watch, the greater the number of puzzlers in the book to which you'll already know the answer ;-)

Regards

ap

> The second is obviously a first edition printed by Caxton and Gutenberg themselves with solid leather covers and hand‑sewn pages.

...which just goes to show that Scala is actually quite a bit older than most people tend to think ;-))

Regards

ap

> Seems to be fun indeed - I failed on all of them ! :-)

Glad to hear they weren't all straightforward - I hope you feel you learned a little bit, too!

> You're not going to present a session on Devoxx by any chance ?

Not this year, unfortunately :-( Our session at Scala Days Amsterdam 2015 is available on Parleys, though (featuring me badly in need of a haircut, amongst other things ;-)).

ap

Hi Campbell

> Why is this edition of your book so much more expensive than this edition?

I have no idea - wonder where the expensive one came from? Of course, I'm proud of the book, but I hadn't realized it had made "rare collector status" already ;-)

Seriously, though: this listing is the "right" one.

Thanks for pointing that out!

ap

> Hello Not-Andrew ! ;-)

*grin*

> Do you guys also discuss patterns / best practices ?

In the book, we certainly try to point out guidelines or alternatives that will help you steer clear of particularly "puzzler-prone" areas - examples would be showing how to disable certain implicits that are problematic, or how to declare implicit conversions to avoid unexpected surprises.

I'm not sure whether we would classify this kind of advice as "patterns / best practices", but (where possible) we certainly try to provide useful "takeaway" information in the book so that you don't just understand the reasons for puzzling behaviour, but can avoid it in future.

Regards

ap

Hi German

> the book is complete related to language puzzles ? or also has some math/logic involved ?

The book presents examples of "puzzlers" in Scala - it's not a collection of programming problems or coding challenges, if that's what you were thinking. The definition of a "puzzler" that we use is a piece of code that you think should behave one way, but that actually behaves quite differently, in an unexpected or counter-intuitive way.

For example, you might expect both of the following println statements to throw a NullPointerException. If you try the code, you may get a different result:

val s1: String = s1 val s2: String = s2 + s2 println(s1.length) println(s2.length)

What we try to do in the book (and on the Scala Puzzlers site) is to collect such code examples, describe how they actually behave and explain why they do that. Understanding this is, we found, a fun way of challenging your own understanding of a language (Scala, in this case), and learning more about it.

One of Nermin's comments in a different thread contains a link to a sample chapter, in case you'd like to take a look!

Regards

ap

Hi Will

> Is there more explanation of the puzzles in the book than on the website?

Yes, one of the main goals for us in writing the book was to provide more detailed explanations than are available on the site, and also to discuss alternative approaches and possible best practices for avoiding the puzzling behaviour. See Nermin's comment in a different thread for a link to a sample chapter that should help demonstrate the difference.

Having said that, you'll probably get the most out of Puzzlers if you already have a reasonable degree of proficiency in Scala. The main aim of a puzzler is to highlight an example of the language behaving in an unexpected or counter-intuitive way. Having a reasonably clear expectation/intuition of how you think the language should behave is pretty much a prerequisite for that. If you're just learning the language, that expectation/intuition is something you're probably still developing.

We definitely don't want to make readers' heads hurt! Puzzlers should be fun and challenge your understanding of the language, not make you feel like you're sitting an exam. If that's how you're feeling right now, I'd suggest perhaps revisiting Puzzlers in a couple of months, when you feel you're reasonably proficient in Scala and want to "test your skill" ;-)

Regards

ap

Hi Narendra

> Keep writing such book

Thanks for the kind wishes! Luckily, we've already finished writing ;-) Just a quick warning: if you go through all the puzzlers on the site, you'll already know most of the answers for the book!

There's a lot more information in the book that isn't on the site, so I'd say the book is definitely still worth it, but you'll hopefully have even more fun reading if you don't go through the site just beforehand ;-)

Regards

ap

Hi Palak

> Or to rephrase my question how exciting is it going to be solving Scala Puzzlers?

That depends a lot on how much Scala experience you have, I'd say ;-) Only one or two of the puzzlers are the result of the behaviour of Java libraries or the JVM - the vast majority are puzzlers that try to highlight unexpected behaviour in Scala code. Put a different way, whilst the format of Scala Puzzlers is similar to Java Puzzlers, the "problems" are all different, and are based on Scala, rather than Java.

So if you have some experience with Scala, you should hopefully really enjoy the book! There's a link to a sample chapter in one of Nermin's comments in a different thread.

Regards

ap

Hi Yagiz

> Is it related to the Scala Puzzlers that are online?

Just on this part of your question: the puzzlers covered in the book are a subset of those listed on the site. In the book, we explain the reasons behind each puzzler in much more detail, talk about alternative approaches you can use, and suggest best practices for avoiding puzzling code. See Nermin's comment in a different thread for some links that will help you compare the two.

Regards

ap

Hi Atul

> What is the average length of the puzzles? Does it cover any design "gotchas"?

Thanks for your question! The chapters in the book - one puzzler per chapter - (see Nermin's comment for some more detail of the difference between the book and the Scala Puzzlers site) are 4-6 pages in length, on average. The code samples themselves are as short as possible - the principle being that if a one-line statement that seems obvious behaves in an unexpected way, that's even more puzzling than if a loooong block of code works slightly differently from what you might expect. The result is that the puzzler examples tend to be too short to get into the realm of "system design".

Some of the lessons the follow from a couple of the puzzlers could be classed as "design guidelines", but in the main the aim of Puzzlers is to teach you about a language feature, quirk or interaction that you were not aware of or - more valuable still - thought you had understood, but didn't understand completely.

Regards

ap