I'm fairly new to Scala too. I'm not convinced on the everything mutable (or everything functional) bandwagon yet either. I have done quite a bit of real-time embedded programming in the past and understand the difficulties of multiple threads. I see that for some classes of problems, immutability is an awesome tool for lowering cognitive load. But, why does a tool that is good at solving one issue have to be used for everything? Wouldn't it be better to just design you app to take advantage of appropriate approaches in appropriate locations?
I have seen examples where coders are doing coding acrobatics just to make something immutable, I would have just used mutability inside of a well defined bound to accomplish the work and just made sure that my external interface was immutable. Same thing about functional, if you write a piece of code as a loop or as a recursive function, and it is part of an internal implementation, then I go with the one that shows my intent more clearly. I'm not a big fan of writing a loop as tail recursion just so I can say it's functional, unless it actually looks better in the end. I think the most important part is to make it clear what is immutable and not in you design and be careful. One other observation. Thinking that just because you make stuff immutable that you don't have to think about threading concerns is a mistake. You still have to think about it, it is just a different puzzle. (probable a much preferable one though.) I like immutability, but don't like applying it everywhere indiscriminately. Along the same lines. Collections, have a similar issue. Java and Scala have a very protective collection library that hides the nodes and stuff. Which I like most of the time. This makes it simple/safer for most situations, but can be a big drag when you are trying to maximize performance. (Example from way back: in some OS code in C, they use a trick where you put the node structure the first in a larger structure that needs to be stored in a list, then when you wanted to perform list operations, the node pointer was the structure pointer. Super fast, but super dangerous.) In Java, if I did profiling, and knew I needed better performance, then I would go back and change away from the default collection library to something a bit more dangerous but more performant. Sometimes you just got to get you hands dirty. One more interesting note: Back in the day, In our embedded real-time environment (C++) we recognized the difficulty most coders have using raw thread synchronization correctly. So we build a framework to help people be able to reason about what was happening and increase their accuracy and productivity. It worked really well (and still does), and surprise, surprise, it closely resembles what we call Actors today. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
