Haskell proponents often argue that the outermost shell of your program is littered with statefulness (for Haskell users in the room, think Monads), but most of those outermost parts will fairly quickly start calling completely pure, side-effect-free, functions. Thus, the inner core of the app is all pure functional, and the outer bits aren't.
A common example is a window manager in haskell. All the internal stuff calculates where windows are supposed to appear (a non-trivial calculation), and is all stateless, but the actual 'array' of windows on display is obviously stateful. It pretty much has to be. Unfortunately for functional programming, almost every real world example has a bunch of state, but not all real world examples have non- trivial stateless calculations at their core. The basic rule for immutables I use is: If I can imagine a way to pull it off that isn't completely ridiculous, I'll go for it, but I won't spend more than about a minute or 2. Immutability is great, but it's not a silver bullet. Sometimes you have to get creative. For example, the concept of a list that you can dynamically add stuff to (think ArrayList) seems like a clear case of mutable state that you can't build up with immutables. Except that you can: Define lists as a parent list plus the new element at the end, and define an 'empty list' singleton. Voila. The .add() operation now returns new ImmutableList(this, newElement);. This is in fact the standard list model used by a great many languages, though for traditional reasons, new lists are built up of a head element and a tail list, instead of a head list and a tail element, and prefixing is the O(1) operation, instead of suffixing. I'm not sure if I can give you any quick hints on how to think of such structures. It would be nice to have a website or a book filled with such exercises: Here's scenario X. Come up with a way to build up its data structure so that it is all, or almost all, immutable. I don't know of any such site or book, though. Another thing that might help is really grokking for/list comprehensions. Scala has them, by the way. So does python. They look like: [x in someListGeneratingExpression, y in someListGeneratingExpression2 ; z = x^2 + y ; if z > 25 && x > 0] and the idea is a more readable combo of mapping (z=x^2+y), flattening (we're combining the two input lists), and filtering (the if). The above is pseudocode, most list comprehension supporting languages come up with something a little more concise, usually by just eliminating the semicolons. There's a surprising amount of stuff you can elegantly express as comprehensions. Much easier, in general, than trying to come up with a good chain of flatten/map/flatMap/filter/zip On Aug 29, 11:09 pm, "Peter Becker" <[EMAIL PROTECTED]> wrote: > Scott, > > the FP fans will hate me for it, but I personally still believe OOD > and FP don't mix well at all. You can easily model something like > objects in a functional programming language, but since they are > always immutables they tend to clash with the design strategies used > in OOD. > > My dream language would have two separate type systems: components and > value types. The latter being immutable and with value-identity > (http://blog.peterbecker.de/2008/05/java-should-have-value-types.html), > the former being designed for dynamic, mutable approaches -- which for > me means having properties and events (but the events themselves > should be value types). This way you get the nice world of FP-style > purity for values (and thus calculations) while maintaining a higher > level view that is closer to OOD, which I believe to be closer to the > way domain experts model see their domains. By restricting > communication between components to value types you also solve a lot > of the potential pitfalls involved in threading/parallel computing (I > would even consider to drop the notion of a standard method call in > favour of a pure event-based communication model). > > Most FP languages (including the OO ones) don't let you model things > this way. I believe Scala would let you, but it's not enforced, which > I think is a bit of an issue -- it could turn out to be a little bit > like Perl in being a write-only language. But only time will tell. > > Just my 2c, > Peter > > > > On Sat, Aug 30, 2008 at 6:39 AM, Scoot <[EMAIL PROTECTED]> wrote: > > > Apologies if this is somewhat off topic, but I think (hope) the posse > > audience have some useful insights on this. > > > I'm trying to get my head into functional thinking. I'm sold on the > > principles of immutability and all the attendant advantages; I've > > looked at examples in various languages (erlang, haskell, scala) and > > admired the elegant simplicity of recursion. > > > What I'm struggling with is how to model real-world domains using > > these principles. Someone (Dijkstra?) once jested stacks were > > invented solely to demonstrate Abstract Data Types; it kind of feels > > like the Fibonacci series is the functional programming equivalent. > > > What I'm missing are examples from real world domains; like customers > > holding accounts or purchasing products. I want to think about these > > as stateful entities; e.g. the account moving from in credit to > > overdrawn and back. > > > So: how does one "think" about these things functionally? > > > I know in scala I can represent them as stateful objects but that's > > sidestepping the issue; how do I think about state - and persistence - > > functionally? Any thoughts/pointers gratefully accepted. > > > tia, > > Scott. > > -- > What happened to Schroedinger's cat? My invisible saddled white dragon ate it. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
