Originally posted by Jim Yingst:
[Tony]: Given this, I don't understand why it is otherwise cumbersome? Using it on the client side of the API is definitely not cumbersome,
I was referring to the client side, just as Ricky had in his last post. Creating new anonymous classes all the time just seems annoyingly bulky (looking at the code) for what would become a routine operation. Not impossibly bulky of course, and we certainly do it in "mainstream" Java for other things (esp. Runnables and event handlers). But like I said, it's a matter of taste. If Java gets a compact closure syntax, then this style could be much more to my liking.
Brining this back to the original poster's intent, I suspect that someone who currently prefers unchecked to checked exceptions is unlikely to be very enthusiatic at the prospect of replacing those icky catch blocks with anonymous classes. I could be wrong though. As we're now verging at the "taking over the thread" brink (or perhaps past it), I'm not inclined to comment further on FP in this thread, unless the original poster expresses an interest.
Originally posted by Jim Yingst:
This thread has been split off from Judicious use of exceptions. It seems there's been recurring interest in these forums in discussing aspects of Functional Programming (FP) and how it may be applied within Java. That's great, I think it's good to spread new ideas, and FP seems to have a lot to offer. However it also seems that most times this comes up, we immediately get a lot of discussion from advanced users that tends to drown out the original topic. Often the original poster is never heard from again. Not everyone is necessarily willing or able to pursue the significant paradigm shift that FP represents. Remember most programmers need to collaborate with other programmers e.g. at work, and often it's just not practical to expect everyone to drop everything and embrace FP paradigms. So, I think that often our posters are not well-served by FP discussions which parasitize existing threads. Let people use the methods they know and are comfortable with - or that their co-workers will allow - if they want. And let them discuss these methods without having their thread hijacked by an alternate approach that may not be feasible for them.
Now that I've split this off into a separate thread, I find it's more work to do this than I thought. In the future I don't plan to do this every time an FP discussion starts taking over a thread. I would encourage posters: if you see a thread that you feel the urge to respond to with a discussion of the merits of FP, please post a short comment with a link to where people can go for more information. That may be this thread, or some other new thread. Yes, you can still start your own threads about aspects of FP. But please don't try to keep following up in the original thread. Posters ignoring this request may find some of their followup posts simply deleted.
OK, for the first few posts below may still have some confusing references to the previous thread, but hopefully this will be clear enough. Onward...
[ December 08, 2006: Message edited by: Jim Yingst ]
Originally posted by Ricky Clarkson:
Tony: I'm interested in what you have to say, as you know, but please use words instead of Greek letters. I don't think we're mathematicians here, in general. I appreciate that you interpreted it, but I don't see how the Greek helps.
Tony said: "the only time a Java programmer *ever* throws an exception or returns null is for evaluation of a partial function"
Are 'partial evaluation of a function' and 'evaluation of a partial function' equivalent? If you speak in plain English, I think you mean 'functions which cannot guarantee a simple result' or similar.
Tony said: "Java programmers might have to clue up a bit"
Not all the APIs introduced in Java are intended for the amateur programmer. Consider the newish concurrency stuff. It's possible to have Maybe in use without having to retrain people. A utility method can be provided to convert a Maybe into a non-null value, with some exception if it fails. That would probably facilitate working with people who don't understand Maybe, with the slight advantage that you can easily find those places by looking for usage of that method.
Tony said: "Maybe is one of the simplest and it is far too many lines of code for my liking."
In Haskell, Maybe is a one-liner. That makes it a statement, it equates to a sentence in English. "Maybe fish is either Nothing, or Just a fish".
In Java, it's a bit longer - you get an interface plus static factories to express it. That's not a problem though - it doesn't invalidate the use of Maybe in Java.
Tony said: "continuation passing will never work while the stack grows linearly to the each continuation"
Continuation passing works fine as long as it isn't unbounded. E.g., in my Sequence type (type=interface+static utility class), foldl doesn't use unbounded stack space - I make the compromise and use iteration. I'll change this if/when Java gets tail-recursion elimination. Because the hand-elimination doesn't have any observable effects outside the method, I'm happy with that.
Tony wrote some code showing an if..else with a Maybe:
What would happen if you called asJust on a Nothing? I don't think this helps - if we could rely on programmers always to follow a rule we wouldn't even be discussing this.