Recently James Ward, Developer Advocate at Typesafe, sat down with Bruce Eckel to talk about his new book Atomic Scala and the Scala Summit he is hosting this summer. Here is their conversation...
I used to write Java like I wrote Perl. Then I read Thinking in Java by Bruce Eckel and was transformed into a coder that understood OOP and consequently wrote much more maintainable and elegant code. Since then I've had the privilege of getting to know Bruce through a number of conferences he has hosted in his (and now my) home town of Crested Butte, Colorado. Bruce and I have had a number of very interesting conversations about learning Scala and tech conferences so I thought it would be fun to have a little QA with him for the Typesafe blog.
JW: When did you start learning Scala and why?
BE: I actually avoided it for quite awhile. I suppose I should have taken that as a sign; I ignored Java for some time as well. The upside of that has been that it got to a nice level of maturity before I dove in and I was able to benefit from that.
It was actually Dianne Marsh, my coauthor, who got the book started. She had been working with Scala for a while, and helped develop the Scala Koans. At the Java Posse Roundup in 2011 she told me she would like to write a Scala book. She claims I said something like, I'd like to be involved in that." Books are big projects, and I usually end up thinking later, "Why did I ever think this would be easier?" Plus we added a number of other significant constraints, like accommodating (dedicated) programming beginners and creating very small chapters, things which required a lot more discipline and work.
So the book was the primary motivator for learning the language.
JW: What are some of the challenges you had learning Scala?
BE: The biggest challenge was the "early adopter" syndrome. People who jump on board early tend to be those who are bored with the existing choices, and thus unusually bright. Very often they have no sympathy for those of us who learn more slowly, and once they understand something they can't see why it isn't transparent to the rest of us. You and I have had this ongoing learning challenge that's practically become a joke: monads. Everyone who explains monads first says that everybody else who has tried to explain them has failed, but THEY are going to do it right... then they go on to be just as confusing as everyone else. Eventually I'll figure out how to explain them clearly, but I'm not there yet.
Anyway, the basic attitude seems to be, "I figured it out, why haven't you yet?" This has been particularly bad with the newsgroups, although they've gotten better. I once had someone in a Scala newsgroup declare that identifier names were unimportant. This guy was probably some kind of genius, that he could look at any randomly-named identifier like y43x9q, and it would mean something to him. That might have been the most amazing thing I ever saw in a Scala newsgroup, but there were plenty of others.
Fortunately I've been round this block numerous times before. I don't feel stupid when these things happen; I just go at the problem from another direction (something I learned as a physics undergraduate). For example, I would change newsgroups and ask the question again, until I found a group that would answer it. There ARE friendly Scala newsgroups out there but sometimes you have to hunt around a bit to find them.
A lot of the blog posts also make assumptions about what you already know, so you just have to keep winnowing through them until you find something useful.
Oh, and books. I plowed through a lot of books, and every single one of them not only assumed you knew Java, but made references to it on virtually every page. If you weren't already comfortable with Java you couldn't learn Scala. I guess that's not the most horrible constraint in the world, but what if you don't have a Java background?
JW: How is Atomic Scala different than the other Scala books out there?
BE: This actually flows from the previous question. Dianne and I wanted to solve those problems. In addition, we observed that it would be possible to teach Scala to a beginning programmer and that if we did things right it would actually be an easier language to learn than Java. For example, in Java you have to teach them what a class is, and public static void main String, arrays, etc., before you can even write "hello, world." In Scala, you don't. It's much more like Python in that you can get results very quickly, and that means people are more likely to be successful -- they don't get bogged down with a lot of potentially scary baggage before they make something happen and feel a bit of success.
That's actually where the use of "atom" came from. You have probably read a few books -- David Allen's Getting Things Done is a good example -- where the chapters are really short and you get a sense of accomplishment and forward motion after each one. For that matter, you and I tried to do that with First Steps in Flex. Dianne and I wondered if it would be possible to make chapters so small that they only covered a single idea, and were thus "indivisible" -- just like an atom! So we started calling them atoms and that produced the name of the book. From that came the idea of the mid-century modern "atomic age" artwork on the cover, which took quite awhile to develop and refine. It also fits with other mid-century themes, in particular that we have all this new technology like atomic energy and the future looks very bright.
Our goal became to bridge the gap between the beginner -- either beginning programmer, or just Scala beginner with experience in another language -- and the rest of the books out there. If we can get them past this first set of hurdles then they'll be ready for the next step, probably Cay Horstman's Scala for the Impatient. As a result we explicitly don't try to cover the language comprehensively, but instead just try to cover the basic concepts enough to produce a good foundation so that the learner doesn't get intimidated when they encounter more advanced material. Achieving that, and doing so in a step-by-step fashion without any forward or external references, was the main challenge of the book, and much of the reason it took two years to write. (I'm still working on getting the ebook out, the main difficulty there being formatting code listings in a reasonable way).
JW: You've been going to tech conferences for a long time. Going meta for a moment, what have you learned about conferences and why do you host your own?
BE: Not just attending, but helping organize. My very first conference was put on by the late, great magazine Micro Cornucopia, where I had my first column. Great times. When I first started writing books I began getting invitations to speak at conferences, and ended up doing a lot of those (not particularly lucrative but a way to attend conferences without costing much). I eventually became part of the senior advisory board for the Software Development Conference (SDC, also now defunct) which at the time was the largest conference dedicated to general programming. I did that for something like eight years and learned a lot. I also had a lot of frustration because this was a for-profit conference and they typically did things in the interest of profit rather than improving the quality of attendee experience. The advisory board always pushed back on these decisions but ultimately we didn't control policy. Throughout all this, and with the rise of the Web which ultimately disrupted the SDC, I started wondering if there wasn't a better way of creating conferences, and started talking to people about it.
Fortunately, Martin Fowler stepped forward and said, "Let's do experiments," and so he and I created the Enterprise Architecture Summit, an invitation-only event that ran for something like 5 or 6 years in Crested Butte and produced a surprising number of books by attendees. During that time we tried lots of different ways of organizing the event, which was not a pre-planned thing. Most of the organizational ideas came from Martin; we started by writing discussion ideas down and using "dot voting" to organize them starting with most popular. We tried numerous approaches but one thing in common was that everyone was in a single discussion, which seemed like a good idea because then no one missed anything. But it had a huge drawback: you were trapped in the same room with no other choices. So if the conversation didn't interest you or someone wouldn't stop talking, you were stuck.
When Martin came across Open Spaces, that changed everything. People create multiple discussions in different rooms and you use the "law of two feet" if a discussion doesn't work for you for any reason, you use your two feet to go somewhere else. Not only does this structure give people more of what they want, more of the time, it encourages self-organization. The Java Posse Roundup has produced more and better activities than I could have imagined or planned myself. And once people see how it works and how easy it is, they go home and organize their own events. It's been amazing to watch.
JW: This summer you are hosting the Scala Summit in Crested Butte, which I'm very excited to attend! What can attendees expect from this conference?
BE: It's roughly modeled after the Java Posse Roundup, which has evolved into a structure that works very well. One of the problems with the Roundup was that Crested Butte is a resort town. So do we pretend that we don't do outdoor activities? I decided that transparency was the best choice so we set aside time for outdoor things like hiking, mountain biking, fishing, rafting and 4-wheeling. What's surprising is how some of the very best conversations happen during these times, probably because the "official" structure is removed. I'm sure some managers don't send people because it looks like too much fun, and I've even heard of a manager or two telling an employee that they can't go on the fun stuff and have to work all the time. I think that's short-sighted, but it's the price we pay for being transparent.
The Scala Summit began because a number of Scala leaders wanted to visit Crested Butte, probably because you've been talking it up to them (and other friends like Dick Wall and Bill Venners have been here numerous times already). Since Open Spaces are easy and fun -- it's all about spontaneous discussions and no one has to give (or listen to) formal presentations -- we decided to hold a conference. The folks who are coming are already an impressive bunch; I've put some of their names on www.ScalaSummit.com.
Although almost anything is a fair topic during Open Spaces (the test is simple: do people show up to your topic?), we've found it helpful to establish a theme to seed the discussion topics. This year it's simple: What are the interesting and challenging features of Scala 2.10? Of course, it's also likely we'll wander into upcoming or proposed features as well; having experts at the conference is going to make these conversations a lot easier.
JW: At Scala Days, Rod Johnson gave a keynote about where he sees Scala being in 2018. So, I'm curious, where do you see Scala in 2018?
BE: I've seen this evolutionary path before: C++ (I was on the C++ Standards Committee for its first 8 years) provided C programmers a path to a more powerful, object-oriented language. By providing even more power, Java attracted C/C++ programmers (despite numerous, now-entrenched design flaws). To me, Scala is the next logical step. In each case, the "next" language provided significant improvements over its predecessor. Languages that provide only minor improvements inevitably fail because of the cognitive effort of changing languages: if you're going to put in the effort, it better have a big payoff. On the cover of Atomic Scala we call Scala "the successor to Java" and by 2018 I think that opinion will be commonly held.
Five years is a longer and longer time in the world of technology, so of course there are a number of things that could disrupt that prediction. Processor technology could suddenly leap forward, putting us back into Moore's Law and giving Python an advantage (or a breakthrough in Python technology could make it transparently parallel). But even if that happened, it wouldn't mean you'd want to stop using multicores (where Scala shines) or give up the leverage of using Java libraries, or the benefits of functional programming. I think the leap in technology would have to be much more significant in order to prevent my prediction that Scala is the successor to Java.
JW: Thanks Bruce for taking time to chat with me! I'm looking forward to seeing developers discover Scala through Atomic Scala and interact at the Scala Summit.
