Hi JamesJ, Yeah, I feel the same way. I've been trying to be fairly pragmatic with my use of immutability/mutability... however, many of the objects that I write (especially the bigger ones) tend to be mutable.
Like in my game, my inventory management has to be mutable, I think just for performance reasons. This game is going to let you have a lot of items, and of different types. You're going to be getting items every time you kill crap. We also need a way to generate ids for the items generated by drops, or items that are crafted, and so on. Maybe I could create a key generator that is functional, but it was a lot easier to auto- increment a long and also persist that auto-incrementer when they save the game ;) I guess I struggle because sometimes I love simple solutions to simple problems, and sometimes mutable solutions are really nice and simple. Sometimes I think functional ideas may just seem like acrobatics because I am not a skilled functional programmer... but I have to admit, I love the functional solution that jumps out at me and is much simpler than the imperative one. So my code ends up being a mix of mutable OO with lots of functional thrown in. For example, the inventory repository is like a full blown database, and all of the methods were so easy to write. It's extremely rich to interact with it because of all the awesome higher order functions on collections. I'll keep playing it by ear. I'll try to be more functional so I can learn, but I guess I'll continue to be pragmatic as well. I guess that's the beauty with Scala... you can do that and it works. On Apr 29, 4:13 pm, 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]. > For more options, visit this group > athttp://groups.google.com/group/javaposse?hl=en. -- 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.
