Anyone remember the C++ ACE library? That bundle of joy predated both actors and the SEDA acronym, yet looks eerily familiar. Seems that some ideas just have to bide their time.
http://www.cs.wustl.edu/~schmidt/ACE.html I believe they're still promoting the strength of their corba ORB :) Scala is first and foremost a pragmatic language, use what works! Having said that, you're better off starting with immutability then breaking it when you have good reason, instead of going the other direction. Once I seriously got into Scala I found that I rapidly came to recognise a var as an indicator that I should pay extra attention, because something significant was about to happen. On 29 April 2010 21:13, JamesJ <[email protected]> wrote: > 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]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- Kevin Wright mail/google talk: [email protected] wave: [email protected] skype: kev.lee.wright twitter: @thecoda -- 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.
