BerlinBrown, I apologize in advance; I must be chairman of Haskell hate or something.
On Jun 26, 2009, at 3:51 PM, BerlinBrown wrote: > One small issue I see with Lisp languages over something like Haskell > where side effects are greatly minimized. I tend to write code in > this style: This is a nit, but I wouldn't say Haskell minimizes side effects so much as it makes them explicit. After all, if I write a program in Clojure and you write one in Haskell and they both do the same thing the same way, the Haskell one necessarily has just as many side effects as the Clojure one. For any lame extra-side-effecting version I can come up with, there can be a Haskell one that does it the same way. It'll just be easier to do it messily in anything besides Haskell. > ----- > (when-let [seco-files (.getMergeFilesPrimary *main-global-state*)] > (merge-memory-handler-primary prim-files)) > > Or something similar, you don't have to understand what is going on > with my logic, but if you notice 'seco-files' may return or may return > something else. Also, getMergeFilesPrimary may throw an exception. > > If I remember, some languages like Haskell give you a little bit more > power to detect what will go wrong. Haskell does, but it's not all roses. This blog post talks about there being 8 different ways to handle errors: http://www.randomhacks.net/articles/2007/03/10/haskell-8-ways-to-report-errors The most popular being the error function, Maybe, Either and ErrorT. Of course these are not composable with each other, which leads to great fun when trying to integrate libraries that use different methods. Most of them make the exceptional situations a part of the type of the whole function though, which I think is what you're talking about, right? > How do you deal with with this in Clojure? What is your coding style > to prevent this. I guess I could write every function such that it > returns a value, but I normally don't. The core idea behind FP is that every function returns a meaningful value (and purity is just that it is always the same value for the same input). The parts of your program that are not like that are inherently stateful and therefore will resist FP techniques; those parts are likely to feel like a poor fit with the rest of Clojure (but maybe a great fit for Java). This is no different than having large static void functions in generically named objects in Java being a poor fit for OOP. Both are sometimes necessary, but minimizing them is usually advantageous. For Clojure, I think it's probably wise to follow Haskell's program structure: write as much of your program as you can in a pure functional way and make this the core of your API. Isolate your stateful code elsewhere and make sure to use your PF API from it in a sane way. Haskell enforces this. It isn't always possible (or useful) but I'd rather have the ambiguity in my Clojure code than the intense, often verbose or incomprehensible machinery that Haskell foists on you. If instead you want to be more explicit, there is a monad library in Clojure Contrib you can use to make your side effects more explicit and safer. An advantage to moving the stateful code somewhere else is that it makes more sense to handle I/O errors in functions that mainly do the I/O and hand it off to PF libraries. There's always going to be a tradeoff; Java is more explicit than many other languages but everybody hates checked exceptions. I think FP and OOP are really two sides of the same coin; after all, functions don't work without data and objects don't work without methods. Sometimes one is a better fit than the other. Like Martin Luther said, mankind is like a drunkard whom after falling off on side of the horse is liable to get back on and fall off the other side. All the best, — Daniel Lyons --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
