Re: [xml-dev] DOM's javascript roots (was Re: [xml-dev] Have JDOM / XOM / etc. failed?)

[Robin Berjon <robin.berjon@expway.fr>]

On Mar 31, 2006, at 22:58, Elliotte Harold wrote:
> Robin Berjon wrote:
>> But now I'm writing in my platform's default encoding. That might  
>> have been tolerable in the 80s when the folks who came up with  
>> this ridiculous API were sharpening their text-munging fu on  
>> ASCII, but those benighted days are thankfully over, in no little  
>> part thanks to XML's arrival.
>
> You're right. In reality I'd write something like this:
>
> Writer out = new OutputStreamWriter(new FileOutputStream 
> ("file.txt"), "UTF-8");
>
> It's still one line, though a longish one. Perhaps I'd even break  
> it into two lines. But I'd have to do similar things in Perl or  
> Python if I wanted to handle character sets sensibly there too.

Right, so when first asked the question you bring up a given class,  
then upon being reminded that that solution isn't portable you bring  
in two other classes that also write stuff out, plus an extra  
interface for good measure. And you still haven't included either the  
local code to handle the exception, or the change to your method's  
signature if you're not handling it (with the various implications  
that has). I'll remind you that all we're doing here is trying to put  
some characters into a file.

As I said I'm not getting into language bashing, my original question  
remains: you bring someone up with the notion that they need to know  
all of the above to even hope to get writing to a text file right, do  
you really expect them to pause a second and think "hang on, this DOM  
thing could be easier"? If that were the case wouldn't they all be  
storming Santa Clara to get some decent interfaces out of the JDK?

> The real difference is that Java assumes you want to do the right  
> thing with full error handling, appropriate character set support,  
> and more by default. It's a language designed for professional  
> applications that cross the t's and dot the i's.

Again, not my point, but if that were true picking the right encoding  
for a file would be easier, not harder, than not doing it. I get to  
see a lot of Java-produced XML here, and I wouldn't even want to  
start to count the number of times it stops working if you throw the  
producer in a "weird character" (as it is most often reported).

> Perl et al. assume you want to write quick and dirty throwaway  
> hacks. It's a difference in focus. Of course, you can write  
> professional apps in Perl or quick and dirty hacks in Java, but you  
> work against the language when you do that. Pick the language  
> that's appropriate to your task.

No, the assumptions are different. Java assumes that the dude who  
wrote the interface knew what he was doing, which in the face of  
experience is completely laughable. Of course, the reverse is  
laughable as well but at least they have a sense of both pragmatism  
and humour :)

Note however that this notion of "designer is right" tends to be more  
acutely wrong when confronted with open systems such as XML or RDF,  
unless you try to bound things going the XML Schema route (which  
tends to fail as well).

>>   open my $fileHandle, ">:utf-8", "filename.txt" or die "Error  
>> opening file: $!";
>
> Perfect example. The entire app shuts down because you couldn't  
> open one file. I can make a Java program shut down in one line too,  
> but it's not the natural thing to do in an end user facing  
> application or a reliable library.

The above does not shut down the app, it just throws a runtime  
exception. It is the idiomatic equivalent to the somewhat less  
idiomatic:

import java.io.*;
//...
try {
   Writer out = new OutputStreamWriter(new FileOutputStream 
("file.txt"), "UTF-8");
}
catch (IOException ioe) {
   throw new RuntimeException("Error opening file: " + ioe.getMessage 
());
}

except that by its simplicity it tends to be more inviting to do the  
right thing.

-- 
Robin Berjon
    Senior Research Scientist
    Expway, http://expway.com/