FP in Java: alternatives to exception handling

[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 ]

[Ricky Clarkson]

Runtime exceptions are simply not an option, as long as people forget to read specifications, and don't test exhaustively (i.e., forever).

Exceptions themselves are hard to get right - you typically use them for things you expect to go wrong - where's the line between that and using them for flow control?

E.g., look at Integer.parseInt. It is typically used not just to get an int back, but also to tell whether the String had an integer in it. That's exceptions for flow control.

If you do use exceptions for all cases like this, then you'll find that your code looks rather complicated, and unless you disable stack traces in the JVM, it will be more than a little slow.

Another way is to return a container. The container may have a value, or it may not. You give it a function to run if it has a value, and a function to run if it doesn't, and look at the return value.

In Haskell, this is the Maybe type and it works well. In Java, methods are not first-class functions, so it's a bit harder to do, but it's certainly possible.

I'll use [] for generics, because there's no preview button:

Maybe[Integer] parsed=Integers.parseInt("568");
String output=parsed.apply(constant("You fool, that wasn't an int"),new Function[Integer,String]()
{
    public String run(Integer value)
    {
        return "You clever person, "+value+" is an int";
    }
});

With closures, the function will become easier to write: {int x [= "You clever person, "+x+" is an int"}

[again, [ for less-than]

[Jim Yingst]

[Ricky Clarkson]: Runtime exceptions are simply not an option, as long as people forget to read specifications, and don't test exhaustively (i.e., forever).

Right, that's why languages that have only unchecked exceptions have been so unsuccessful. E.g. C#, Ruby... :roll:

It certainly is an option, albeit an unpopular one in much of the Java community. Whether it's an advisable option depends (among other things) on the culture of the company or group you're writing for. There are groups who use testing extensively enough that they can afford to sacrifice some compile-time validation in exchange for improved ease of use. Also I think this style is more suited to rapid development than robust development. Declaring a bunch of checked exceptions on your methods can encourage better error handling (though not necessarily), but it can also slow people down. I think the right answer here depends on what sort of culture you're in. Pho Tek was pretty clear from the start about what sort of style he's using.

I do agree with pretty much everything else you wrote, Ricky. I find the Haskell Maybe to be too cumbersome for my taste when it's expressed in Java. And it's sure as heck not widely known in the community, which can also be a big problem (again, depending what sort of culture you're programming for). I'm hopeful that closures will eventually make it into Java (see Neal Gafter's blog), which would indeed facilitate this greatly. But we've still got huge libraries in the language which aren't written in this style, and a user base unfamiliar with it - so there's going to be considerable inertia. I think this is the sort of thing a new, unencumbered language can pull off much more successfully than Java can.

[Ricky]: I'll use [] for generics, because there's no preview button:

For what it's worth, you can edit your post after the fact using the button. Not quite the same as a preview, but it works.
[ December 08, 2006: Message edited by: Jim Yingst ]

[Tony Morris]

Trimming a post with a quote almost always fails (for me at least), so referring to "I find the Haskell Maybe to be too cumbersome for my taste when it's expressed in Java".

First, we must understand that we are simply defining functions with partial evaluation. That is:
∃x. f(x) is undefined
or another way of writing this is:
�(∀x. f(x) is defined)
For those unfamiliar with first-order logic, ∃ means "there exists", ∀ means "for all" and � is logical negation.

So this can be interpreted as:
"There exists some x such that f(x) is undefined"
or
"For all x, f(x) is defined" is not a true statement.

This applies even to your void write(byte b) methods that declare to throw IOExceptions or whatever we do for those cases that appear (but don't actually) to disprove that the only time a Java programmer *ever* throws an exception or returns null is for evaluation of a partial function - always and ever and great, now we agree (If you don't, then I apologise for not proving it, but please assume it is so).

Then, writing Maybe in Java, while very cumbersome, is at least only required once. Given this, I don't understand why it is otherwise cumbersome? Using it on the client side of the API is definitely not cumbersome, so suppose the core API introduced a Maybe type, I don't see the problem - apart from the fact that Java programmers might have to clue up a bit, which would kill market and the corporation's profit and yaddy yaddy ya and so we have to maintain "dumbification of the masses" (yes yes I'm crazy and whacko and all that - let's get on with it).

Are you saying that we would have to rewrite Maybe over and over? If so, I agree, expressing any algebraic data type in Java absolutely sucks. Maybe is one of the simplest and it is far too many lines of code for my liking. But I don't see it as the case that we would have to keep writing it over and over - only once. Given that the problem of partial function evaluation has been around for so long (the circular exception debate right?) and that the Maybe solution is definitely superior (this may not be obvious yet), I don't see why anyone would not invest the small amount of effort to understand it, then have a significant advantage over "the other guy".

As a result, my answer to the original post is simple. First, understand what it really is that you are doing i.e. the formalities - partial function evaluation. Second, consider your options: checked exceptions, unchecked exceptions, null, continuation passing, Maybe algebraic data type. Weigh them all up;
* checked and unchecked each have their own disadvantages - I think you can see that
* returning null causes some large percentage of software bugs meaning that you don't get to go home on time
* continuation passing will never work while the stack grows linearly to the each continuation - it is also verbose and cumbersome to use (in Java that is).
* Maybe algebraic data type has none of the problems above, but requires some investment of effort in a) understanding what it is you are doing (this is immediately obvious if you have used Haskell for example) b) the investment in effort of actually writing it (you can have mine if you like)

Given that you at least have a small amount of initiative (why did you even ask this question?), and it is probably safe to assume you have more than a small amount, I think the answer is now clear - invest effort and reap a benefit.

Let me know if you want to take it further and we'll start using proper programming languages
[ December 08, 2006: Message edited by: Tony Morris ]

[Garrett Rowe]

[Jim:]Though that's the "standard" idea about exceptions, [...] the idea here is to avoid them entirely, if possible, and that means that runtime exceptions are preferred for situations where others would use checked exceptions.

You're right on, I thought about that as I was writing my response, but then I just thought maybe I was taking the post too literally and dismissed the thought. Upon further inspection, I must agree with your interpretation.

On a different note, Ricky, I've been playing around with your functionalpeas classes for about a week now. I've had a pretty good time of it. It (currently) has a lot less bloat and is therefore a little easier for a functional beginner like myself than some of the other functional API's for Java.

[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.
[ December 08, 2006: Message edited by: Jim Yingst ]

[Tony Morris]

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.

Why would the client side need to create anonymous classes all the time? I agree, continuation passing is not feasible. Consider the following pseudo-code:

Maybe<Y> m = f(x)
if(isJust(m)) {
  Y y = fromJust(m)
  ... do stuff with y
} else {
  ... function evaluation failed
}

You might be referring to what Ricky seems to prefer (I claim erroneously). Revisting Maybe in Java You will note the method:
public abstract <Q> Q maybe(JustC<Q, T> jc, NothingC<Q> nc)

This is exactly emulation of continuation passing. It will fail in a stack-based language i.e. Java. Not only because of the verbosity that you mention (and I agree with).

Nevertheless, I do not propose this solution at all[1], for the reasons that you mention and more. It is a shame that the pseudo-code above cannot be rewritten as if it were pattern matching, but this is Java after all - nice and verbose (sarcasm ). I do propose however, that the additional verbosity (additional over other languages, not alternative solutions - it is actually less verbose in that case) is superior given the premise of Java itself.

You might even argue that the pseudo-code is a try/catch with different keywords on a compile-time checked exception. The problem is, function evaluation is only known to be partial forall x, but it might be known for "some x". This is called "altering the universe of discourse".

e.g. the code Integer.parseInt(s) will not succeed for all s, but if we restrict the universe of discourse of s; let's say, with an if statement:
if(s.equals("1") || s.equals("2")){Integer.parseInt(s);} we know for sure that this function is defined. It is these cases that the "unchecked" side of the exception debate selectively observe to argue their case. Of course, it is only part of a bigger picture and so their opponents simply select their preferred view of that bigger picture, hence the debate is circular. "Cognitive Dissonance" is was called back when I was studying Psychology - many many years ago.

[1] but I do have it available in a "more complete" Maybe, simply to cater for those on what I believe is the incorrect side of an argument - one that Ricky and I have had before and have not agreed.

[Tony Morris]

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 ]

Hi Jim,
While I understand your point, this particular issue has nothing at all to do with FP. If anything, it has more to do with Java. Partial function evaluation has been a problem since the inception of Java and will continue to do so. Functional programmers don't have to worry about such fundamental concepts (actually, this doesn't hold for all FP languages). Referring to the solutions provided by other languages only provides a reference to a superior solution if indeed that is the case as it is here.

I believe that by not referring to a superior solution, the responder is doing the original poster a disservice. Otherwise, for this particular case, you'll only get the "same ol' stuff about exceptions" i.e. "you should use checked", "no wait! you should use unchecked!", etc. etc.

I think this is a mug's game that I certainly don't wish to participate in, but if a poster has the initiative to ask a question that is specific to a problem that has so much hype around it, I see no reasonable option other than to refer to the correct answer. It just so happens in this case, that a few FP languages offer a perfect answer to this question.

There are also some subtle implications underlying it all:
a) why does it take ~100 lines of code to write "data Maybe a = Just a | Nothing" in Java - a simple algebraic data type?
b) this problem has been around for so long and been so prominent - it *must* be solved - partial function evaluation causes so many problems i.e.
T t = f(x); method(t); where f(x) may be undefined.
Just what is the correct solution? Why are there two camps holding opposing views while those who use expressive algebraic data types get on with writing software?

While functional programming offers an answer to 99.9% of the problems expressed on any Java forum, I am certainly not proposing we do that, but I do think someone who takes the effort to post to a forum to solve (what I believe) is a real problem (as opposed to "please do my homework"), I think they are entitled to a complete and importantly, a correct answer - not an emotionally charged answer that is based on disinformation - there is just too much of it out there.

[Jim Yingst]

[Tony]: I believe that by not referring to a superior solution, the responder is doing the original poster a disservice.

And you are welcome to refer them to such a solution. But not to take over the thread discussing the matter with a bunch of people other than the original poster. This is a pattern I've seen repeat too many times here. I don't know whether the original poster leaves because they got the answer they needed, or because they got swamped in a bunch of discussion they didn't understand, or some other reason. But one way or another, the original poster vanishes, and I have a strong suspicion it's because of the second possibility I just listed.
[ December 09, 2006: Message edited by: Jim Yingst ]

[Ricky Clarkson]

Jim said: "Posters ignoring this request may find some of their followup posts simply deleted."

I'm fairly new to this site, but if I found that my posts had been deleted I would probably stop using it - deleted posts are a waste of time for the poster. Make it easier for you to move, or 'fold' a post that you consider off-topic, rather than deleting it.

Jim said: "Right, that's why languages that have only unchecked exceptions have been so unsuccessful. E.g. C#, Ruby..."

And languages without garbage collection have been so unsuccessful, like C.

I should have qualified 'not an option' with 'not an option in Java', but I thought that was implied from the context (javaranch).

Jim said: "There are groups who use testing extensively enough that they can afford to sacrifice some compile-time validation in exchange for improved ease of use"

Checked exceptions could, with a stretch of the imagination, be implemented in a dynamically typed language. You could be required, when calling a method that throws an exception, to provide an exception handler, and get a runtime error if you don't. I don't know of any compelling reasons to do this, rather than use Maybe, though.

Jim said: "I find the Haskell Maybe to be too cumbersome for my taste when it's expressed in Java. And it's sure as heck not widely known in the community, which can also be a big problem"

I know what you mean about being cumbersome - however, show some code that you wrote using Maybe in Java, and we'll see if we can make it seem less cumbersome. Function composition could help.

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.

Garrett said: "On a different note, Ricky, I've been playing around with your functionalpeas classes for about a week now. I've had a pretty good time of it. It (currently) has a lot less bloat and is therefore a little easier for a functional beginner like myself than some of the other functional API's for Java."

Interesting. I write that as a beginner in FP myself, which might be why it's easy for you to use. My current working copy needs committing sometime. I'll be adding Sequences (immutable linked lists) and a replacement for the Maybe implementation (currently called Maybe2). If you have any RFEs let me know. Google Code gives me no download/check out statistics, as far as I know, so I don't know how many people are using it. 1 is news to me.

Jim said: "Creating new anonymous classes all the time just seems annoyingly bulky"

Yes. Function composition can help, or it can make the code worse. I'd like to see an IDE that makes an anonymous class appear as a closure. IntelliJ have no plans to do that, but find it interesting. Apparently a plugin can do it, but I have no licence for IDEA at the moment, and the plugin has no visible details online.

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.

[Tony Morris]

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.

Computer Science was once a spe******ation of Mathematics. It is unfortunate that it is no longer this way. In fact, we wouldn't be having a discussion about such a fundamental concept if it were. We'd be getting on with communication at a higher level and doing some cool stuff. Many believe that "you aren't a programmer if you do not know the mathematical foundations of computer programming" - while I won't comment on my take on this, you can at least see there is a very plausible point being made. First-order logic is generally taught or at least "skimmed over" in most tertiary courses that I have seen i.e. back when I was lecturing. First-order logic is also very applicable in every day life - it is surprising to watch someone use a primitive form of logic to attempt to "resolve what appears to be a contradiction based on gut instinct", only to make a crucial mistake because they don't have the required formalities to overcome it. Anyway, I wasn't speaking in any other language than "the language of computer programmers". I would accept that "Java" and "computer programming" are two different things and so I would then accept that I am off-topic.

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.

Again, I am speaking in the language of computer programmers. I don't mean anything but what I said, because English is not type-safe, I attempt to eliminate my projected world view in what I am saying for fear of misinterpretation. Yes, the two terms are likely to be interpreted as equivalent, but the former is a mistake. I apologise if I made that mistake.

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.

If we take a basic premise that I believe. Java users in general, are quite low in terms of spatial cognitive ability. i.e. below the average layperson. Then we plot a standard deviation curve against people who go above this average, but cannot see beyond Java (Blub Paradox?). For example, the very fact that the original poster spotted a problem and decided to pursue feedback from others about it, suggests that this person goes above this average. I also believe that say, my girlfriend, a midwife, could understand the Maybe concept in just a few seconds. In fact, it took about 2 hours to explain the 19 rules of inference of first-order logic to her (without quantifiers), so what now? . I am only suggesting the use of Maybe would require someone to go above "below the average layperson" - where Java programmers currently stand - which is not much at all. In fact, this is exactly where Jim might suggest that our discussion has scared away the original poster, where my response would be "oh well, I must have misjudged and that person actually falls below where I'd assumed" - being an optimist does have a cost.

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.

Definitely not. It's just a pain every time you wish to write an algebraic data type. I wouldn't want to get any more complicated, but since Maybe has been written and solves such a huge set of problems with nil cost (besides a requirement for increased spatial cognition to initially internalise), why the hell don't we (users of Java) use it?!

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.

Well this is the point that I claim you have over-simplified ever since you proposed it on IRC. Instead of going over our argument, I will note the following: In order to solve a problem that I claim exists, you have had to resort to imperative code (an optimisation that a decent compiler should make) in order to make that problem at least appear to go away. I promise you, withour further explanation, that it hasn't gone away at all. Continuation passing definitely fails in Java, or you have discovered something that a whole lot of people are trying to solve (as their thesis for example) - you should at least agree with this statement. If it is the latter, I strongly urge you to publish a paper, but I have to admit, I am erring on the former based on the evidence that I have seen.

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.

You would get a failure since the recursive type is useless. In fact, you could isolate all failures to this specific type in an entire program. There is a proposal in GHC to make fromJust a bit more meaningful when noobs call it on a Nothing, but being the purists that the community is, they have decided instead to educate those noobs so as not to make such a fundamental mistake. Scaring away the original poster or having them on-board as an initiated computer programmer if you will May the strongest survive! I'd prefer to educate the noobs who go on and on about checked and unchecked exceptions, but it may require them to grasp the fundamentals of what it is they are doing - computer programming, isn't it?

[Ricky Clarkson]

Tony said: Computer Science was once a spe******ation of mathematics.

I'm not sure why there appears to be censorship there - are you censoring your own anti-American spellings?

That computer science relies on mathematics is a given. That driving a car relies on mechanics is a given. That understanding mechanics is required in order to drive a car is not a given. As computer science has moved through the ages, it *appears* to rely less on mathematics. That's not to say that it *actually* relies less on mathematics.

Mathematics is poorly taught, arguably more poorly than computer science. Given that computer science is taught for between 3 and 5 years typically, in the UK, and mathematics is taught for between 11 and 13 years, it seems that it is poorly taught, based on the mathematical abilities of normal adults, compared to the programming abilities of normal adults (of those who have studied Computer Science).

In short, mathematics is inaccessible, and making mathematics a prerequisite makes a subject inaccessible.

I am careful not to say that mathematical concepts cannot be used. It is, however, usually a good idea to explain the concept, and *then* introduce more formal notation for it, rather than the other way around.

If I started off explaining what rot13 was by showing an implementation in Haskell, I wouldn't get anywhere with most (non-programmer) people, unless they were in the same room as me, in which case they'd be polite enough to humour me.

If I started off by telling a (probably inaccurate) story about Julius Caesar needing to send secret messages, my audience would be larger.

In fact, if I started off with an implementation in Haskell, I would almost certainly be *trying* to eliminate a section of my audience. I feel that using Greek notation prior to defining it here is such an attempt. Perhaps I misjudge your reasons, but I'm sure you can understand my reasoning.

In short, bring the audience with you, rather than confronting them.

Tony said: "Anyway, I wasn't speaking in any other language than "the language of computer programmers""

I have been programming since 1986, and I have not yet found a case for Greek symbols. There is no global language of computer programmers, possibly with the exception of English. Wikipedia puts first-order logic into the category of mathematics, not computer science.

Tony said, with reference to 'partial function': "Again, I am speaking in the language of computer programmers."

Again, it appears not. Wikipedia puts partial function into the category of mathematics. I confirm my understanding of your original statement now, having realised that 'partial function' is a defined term, and having read about it.

Tony said: "Java users in general, are quite low in terms of spatial cognitive ability. i.e. below the average layperson."

I can understand how you might draw this conclusion. I explained the Maybe type to a Java programmer who I know socially, and while he appeared to understand it superficially, he seemed to believe that it would not scale to his needs. He had no idea why, just an intrinsic closed-mindedness. I didn't worry about this; he still has not even met generics. If I had to work with him, I'd train him up. For him, Java is the new Delphi is the new COBOL..

I could get one of my girlfriends to understand it, and she would not have the closed-mindedness - the idea that it wouldn't work in practice, without the reasoning. I could take that to mean that she is more intelligent than him. In fact, when they spoke to each other, he leant over and put his elbow in an ashtray, which doesn't bode well!

It is worthwhile not to confuse closed-mindedness and idiocy.

Tony said: "In fact, this is exactly where Jim might suggest that our discussion has scared away the original poster"

Take a look at my original post, have a look at the choice of words, and note that Jim left that one in the original thread (and copied it here).

Tony said: "why the hell don't we (users of Java) use it [Maybe]?"

For the simple reason that we don't know about it. The usual documentation is in terms of functional programming. You can argue that everyone should learn functional programming, but if Maybe can be expressed without the dependency on the terms of functional programming, and of course subsidised by some names that people know, such as Joshua Bloch, then the users of Maybe in Java would increase.

There is also the problem that while people who argue in favour of the status quo tend to agree with each other, the progressives tend to argue with each other more, which makes it hard for those in the centre to follow.

Tony said: "Continuation passing definitely fails in Java"

You understand my implementation, as far as I know. It works. Something has to translate between the recursive code and the iterative code. If that is me, that doesn't stop continuation passing from being used. The behaviour and semantics are still the same - the difference is the code.

I may be wrong here, I possibly don't fully understand the term CPS. The following from wikipedia may be relevant:

"Continuation passing style can be used to implement continuations in a functional language that does not feature first-class continuations but does have first-class functions. Without first-class functions, techniques such as trampolining of thunk closures can be used; in this case, it is possible to convert tail calls into gotos in a loop, eliminating even the need for TCO."

Tony said: "There is a proposal in GHC to make fromJust a bit more meaningful when noobs call it on a Nothing, but being the purists that the community is, they have decided instead to educate those noobs so as not to make such a fundamental mistake."

Interesting. I wonder what the implications would be if fromJust didn't exist, and wasn't implementable - that is, if a 'Maybe a' gave no way of obtaining 'a', only ways of running functions on the 'a' and getting a 'Maybe b' back.

Tony said: "I'd prefer to educate the noobs who go on and on about checked and unchecked exceptions"

Then make your explanations accessible, and don't call them noobs. I didn't know about Maybe 12 months ago, and I wasn't a noob then. I did realise that there was a problem though.

[Jim Yingst]

[Tony]: Computer Science was once a spe******ation of mathematics.

[Ricky]: I'm not sure why there appears to be censorship there - are you censoring your own anti-American spellings?

Oh, wow. Looks like, as part of recent spam-prevention measures, someone added "cialis" to a naughty-word filter. Which obviously didn't have the desired effect here - "specialisation" became "spe******ation". Oops. I'm out the door now, but will look into finding a better solution later.