Tony Morris

I agree regarding the "swallowed exception", but not to the fact that there is nothing wrong with using the null assignment version (I'd opt for your "messy" version and concede that I'm using a "messy" language).

Regarding your Java 7 version, it is called the Loan Pattern in Java version 42 http://scala.sygneca.com/patterns/loan

Why *are* you still using such an obsolete (messy?) language anyway? How is Haskell hacking going?

Originally posted by Campbell Ritchie:
. . . and for FileWriters, try thispublic void writeToFile(String fileName) { FileWriter myFW = null; BufferedWriter myBW = null; try { try //Yes, try inside try { myFW = new FileWriter(fileName); myBW = new BufferedWriter(myFW); myBW.writeThisThatAndTheOther(); . . . //etc etc. }//end inner try finally { if(myFW != null) myFW.close(); if(myBW != null) myBW.close(); }//end finally }//end outer try catch(IOException ioe) { ioe.printStackTrace(); . . . //other exception handling }//end catch }//end write to file

Every time you assign a local to null think, "there is always a better way". Answering the original poster is a little difficult without more detail on the intention, but if it for opening and closing resources, the above code can be improved by embedding try/finally blocks in try/catch blocks. There is never a need to assign to null and the above code is quite dangerous and could lead to a resource leak. Here is pseudo-code for the original poster:

try { final Resource r = open(); // let us assume may throw IOException try { use(r); } finally { close(r); } } catch(IOException e) { // can't get resource }
If you have multiple resources:

try { final Resource r = open(); try { use(r); final Resource s = open(); try { use(s); } finally { close(s); } } finally { close(r); } } catch(IOException e) { // can't get resource }

Note: You may be puking at the verbosity of the corrected code at this point, but please do not shoot the messenger. I didn't write this language. Heck, I do not even encourage its use for anything practical.
[ May 18, 2007: Message edited by: Tony Morris ]

Originally posted by James Clarke:
Well Tony its strange that in the 'real world' so many large organisations have choosen Java even though "thousands of lines of Java can only do very little".
James

I don't find it strange at all, rather, entirely able to be explained without contradiction whatsoever. But I'll leave that for now

You must remember, I once worked with Java, even on the Java implementation itself. I understand the religion better than many of its fanatics - this too, is capable of being explained.

All these posts seem to have missed the point by a long shot. Joel is referring to what is also called the Blub Paradox (Paul Graham). Java is a language designed specifically for novices. It requires very little skill and mental discipline to produce thousands of lines of Java source code that does relatively little - despite masquerading (to other novies) to the contrary.

Joel (as is PG) is alluding to the fact that once you learn more powerful programming paradigms, namely loose functional programming (Lisp, Python, et. al.), that this becomes clear - but not before then (as in the case of previous posts). Further, once you learn pure functional programming (Haskell, Clean, Epigram), you have taken yet another large(r) leap again and you can see clearly how weak other languages are (a leap that Paul Graham is yet to take given his writings).

Of course, this realisation brings about accusations of elitism, arrogance and what have you, but this is the "real world" that I am describing (your term remember? ) - not some fanciful, wishfully thought up, convenient delusional state.

It has been common knowledge for many years and thankfully is becoming more and more common. The sooner the better - and so as an industry, we can *finally* get on with writing decent software.

Joel does talk a bit of crap though - and to his credit, he's acknowledged it (citation?)

Originally posted by Mr. C Lamont Gilbert:
AFAIK, only literals are interned. I was not aware that constants would be interned automatically.

public final static String STRING = new String("Something");

I don't think that is interned!?

No, it won't, but it is not a constant. Yes, all constants are interned. It is important to point out that in previous posts, the term 'compiler' refers to javac and not the runtime compiler, which may well (and often does) make the optimisations that are being asked about. It does this by reasoning that the type is 'immutable' (has only referentially transparent operations). In the case of String, the reasoning is shortcut by the simple fact that String is a compiler primitive.

http://java.sun.com/javase/6/docs/api/java/lang/Runnable.html

Originally posted by Jesper Young:
Well Tony, you wouldn't even have to think very hard to implement it in Java, because you can just copy and paste the source code from the website you linked to!

Nice one
I have written in Java before (using destructive update on an array), but I also have it written in Scala (which is callable from Java) using pure function calls (the Scala compiler tail call eliminates). I have also written it in C# and Haskell. LCS-based delta (and therefore, ED) is a problem that I happen to be very familiar with

Sure it's easy:

boolean isSimilar(String s1, s2) { return levenshteinDistance(s1, s2) < myThreshold; } int levenshteinDistance(String s1, String s2) { ... // have fun ... // I sure as hell wouldn't want to be doing it in Java :) }

Levenshtein Distance
[ February 09, 2007: Message edited by: Tony Morris ]

Originally posted by Ulf Dittmer:


How does it make a difference whether Java or Flash are used?

Time to failure is diminished?

You might be interested in learning about the (classic computer science) Edit Distance problem. This problem describes the difference between two universes of discourse where each is a monomorphic list with elements bounded by the equality relation.

e.g. in Haskell/Type Theory
Eq a => [a] -> [a]

Rough equivalent in Java:
Given interface EqualityRelation<A>{boolean isEqual(A a1, A a2);}
the method has a signature of:
<A extends EqualityRelation<A>> ed(List<A> xs, List<A> ys)
// not java.util.List of course

An image is exactly this (a list) and the description of your problem is exactly that of the edit distance problem, though, there might be algorithms that specialise further in your area that I am ignoring.

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?

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.

Sorry my mistake.

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.