Brian Hanafee

Author
+ Follow
since Jan 31, 2013
Brian likes ...
Mac Scala
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
5
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
3
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Brian Hanafee

Perhaps the next big thing, but grounded in some older principles. Chapter 3 attempts to put Reactive into some historical context. The actor model goes back to 1973, and there is a bit about what has happened since then.

The book is intended for developers who have some experience in distributed development and want to extend their knowledge into Reactive design. Most of the examples in the book are in Java and Scala, with a few nods to JavaScript along the way. If you are a greenhorn in the sense that you do not know either of those languages or do not have any distributed systems experience, I think you will find the book difficult. The concepts cross languages but sometimes seeing a bit of code is what it takes to reach understanding.
Thanks for the warm welcome. I look forward to answering whatever questions I can!
The core principles of reactive design are described in the Reactive Manifesto. Reactive design itself is too broad to call a pattern, in the same way that object-oriented is too broad to call a pattern. It's an approach. Within the approach, there are many patterns. The book describes what we consider the most important of the Reactive patterns.

The general category of problems that are addressed by Reactive patterns are those of distributed systems. At the scales of modern systems, the possibility of failure of one or more of the parts is quite high. Trying to maintain the illusion that remote interactions are simple synchronous calls just like a local function call leads to brittle systems that are hard to scale and that do not handle failure at all well. Asynchronous programming is hard. Reactive design provides a layer of abstraction so that the hardest parts of asynchronous programming are hidden. Developers can focus on the domain models.

An experienced developer who is beginning to learn about Reactive design would be comfortable reading the book. A beginning developer would be better served building a solid foundation in programming, then approaching Reactive as part of learning to handle distributed systems in general.
One of the other posts here provided a large and possibly even intimidating list of functional programming resources. You needn't master all of that to understand the book. Having a basic understanding is useful. It would help to understand the very strong bias in favor of immutable data structures. You also will need to be comfortable with the idea of passing functions as values to other functions.

Java is used where it produces a readable example. The book switches to Scala when the Java syntax interferes with readability, as it expresses some functional concepts only with great verbosity. If you understand Java, you might occasionally have to look up a few features or new library packages but should be able to follow even without being steeped in functional programming knowledge. Knowing at least the basics of Scala is helpful.

Nilanjan Raychaudhuri wrote:Scala in Action is updated to 2.10. So go grab a copy



What is going on with the publication dates? They've been all over the place in the past month.
11 years ago

Joe Harry wrote:If I think about it, my java skills which are imperative by the way is definitely not advisable to be transferable to Scala style of functional programming. All I can take from Java are just the libraries.



That might be a little extreme. There are times when an OO approach does make sense. Scala blends them, so you can have it both ways. Try to find a functional solution first, but keep OO approaches in your toolbox. Many of the OO solutions in Scala are an improvement over their Java counterparts, resulting in less code to implement the same or more functionality. Traits, for example, are an OO solution that combines benefits of Java interfaces and Java abstract classes. Getter/setter pairs are completely unnecessary. Scala also has real closures rather than the broken inner class concept. The result is that many of the GoF patterns become invisible parts of the language that just work rather than tedious boilerplate. Also the type system (abstract types, variance/contra-variance notations, etc.) moves much more of the type checking from the runtime to the compiler where it belongs, so that more powerful libraries can be created without sacrificing correctness.
11 years ago
Apologies for mentioning an O'Reilly book while the forum is promoting Manning press, but I have been really happy with the book Testing in Scala by Daniel Hinojosa. It's not exactly an "online" resource, but is available from the publishers site in DRM-free ePub, MOBI and PDF formats.
11 years ago
Second question first: Yes! You can use any of the Java libraries. Interoperability is definitely a strength. Once you try using the Scala collections library, you probably won't want to use the Java collections, but it's all there. Many of my Scala projects have long lists of Java library dependencies (Joda time, for example). Importing a Java class or interface is really no different than importing a Scala class or trait, except of course Scala-specific features aren't available. It's also quite easy to create Scala objects that extend or implement Java classes and interfaces.

The answer to your first question is also yes, Java skills are transferable to Scala. That's a double-edged sword. You can make your Scala feel and behave like it's just a syntacticly different version of Java, and apply the same OO design principles as you would in a Java environment. It'll work fine, and your productivity in Scala will quickly become on-par with your productivity in Java. The other answer to your first question is no, Java skills are not helpful (and in some ways detrimental) to using Scala as a functional language. It's a very different mindset, but it's also where some of the bigger gains in productivity are to be found. The temptation to do something the Java way can be hard to overcome and think through a functional solution. I highly recommend taking Martin Odersky's class and really pushing yourself to develop functional skills to complement your OO skills.


Edit: typo and implement java interfaces rather than objects
11 years ago

Rogerio Kioshi wrote:I'd like to know: what kind of things I can do with Scala that I cannot do (or they are very difficult) if I use Java.



Pattern matching. A simple match in Scala can achieve the same functionality as reams of incomprehensible syntax in Java.

To me, a lot of the other differences aren't about something being more difficult to do in Java so much as it's about being more concise in Scala. Because it's concise, you can spend a lot more time reading code and a lot less time scrolling around trying to find code. The differences tie back to making a lot of the syntactic sugar optional. There are also stylistic choices that emphasize not including the sugar (for example, many Java shops consider it a huge violation to omit curly braces around a one-line block, but in Scala that's the norm).

On top of that, there's a vastly better collections library. It uses an inheritance system using traits that allows simple interfaces to bring along rich functionality.

To understand the power of the inheritance system and how it's used by the collections library, compare the Iterator and Iterable interfaces in Java to their Scala counterparts. Implementing the Java Iterator gets you exactly what you implemented: next(), hasNext() and maybe remove(). Implementing the Java Iterable gets you a single function that returns an Iterator. On the other hand, implementing the next() and hasNext() functions on a Scala Iterator gets you a few dozen methods with no further work, and Iterable gets you a few dozen more.


11 years ago

Erik Bakker wrote:
I don't think that Scala needs other specialised preparation than other programming languages. But I don't think there's many people that use Scala as their first programming language yet; for beginners the visibility of Java, Ruby etc. are higher, and I don't think many introductory programming courses use Scala (yet). Not sure how fast that will change



I love Scala but honestly, I think it would be a brutal choice for first programming language.

  • The flexible syntax and optional declarations make it difficult to predict for someone who isn't already comfortable with language syntax.
  • The integration of object-oriented and functional styles leaves beginners unsure of which way to go. One can learn OO first, or learn functional first. Learning both in parallel is asking too much.
  • Image explaining co-variant and contra-variant types to a person who isn't familiar with object inheritance.
  • Many of the harder to understand choices in the libraries are driven by Java compatibility. For someone who doesn't know Java, that means a lot of WTF moments.


  • Heck, the table of contents for Scala in Depth can almost be read as an outline of reasons why it's not a good first language. I'll grant that Chapter 2 has a lot of points that would be good for a first language.
    11 years ago
    Yes, Play needs to be JEE compatible right out of the box. It needs to do that so it can be dropped into a corporate infrastructure alongside a pile of existing servlet-based legacy code. No matter how good Play or Lift or Scalatra or Typesafe Console is, there just aren't a lot of greenfield opportunities. The ability to run on a JVM and integrate well with existing Java is a huge selling point. There needs to be a smooth migration path.
    11 years ago