Darren New wrote:
> Invisible wrote:
>> Well, perhaps you're right. All I know is that we started ending up 
>> with lots of "Java" programs which only actually work with the M$ JVM.
> 
> I've seen very few Java programs that work correctly on multiple Java 
> interpreters, myself. I think I have 3 JVMs installed at work (under 
> Linux) to support the three different java-based libraries I'm using 
> from different parts of my program.
> 
> If you want your Java portable, don't use proprietary libraries. It's 
> pretty easy.

In fairness, it would probably help if the AWT hadn't been designed by 
an escaped monkey...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
> In fairness, it would probably help if the AWT hadn't been designed by 
> an escaped monkey...

Heck - in early versions of Java (i.e., Netscape 4 timeframe), they 
didn't even have Hashtable working right.

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message

> Invisible wrote:
>> In fairness, it would probably help if the AWT hadn't been designed by 
>> an escaped monkey...
> 
> Heck - in early versions of Java (i.e., Netscape 4 timeframe), they 
> didn't even have Hashtable working right.
> 

That's an implementation bug. Invisible is talking about AWT *design*, 
which can't be just "fixed on the next release".

Post a reply to this message

Nicolas Alvarez wrote:
> That's an implementation bug. Invisible is talking about AWT *design*, 
> which can't be just "fixed on the next release".

Yes. He was changing the topic, and I was still on the original topic. 
:-) Just saying, AWT wasn't the worst of it. Java had all kinds of evil 
brokenness, and still does.

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message

Darren New wrote:
> Nicolas Alvarez wrote:
>> That's an implementation bug. Invisible is talking about AWT *design*, 
>> which can't be just "fixed on the next release".
> 
> Yes. He was changing the topic, and I was still on the original topic. 
> :-) Just saying, AWT wasn't the worst of it. Java had all kinds of evil 
> brokenness, and still does.

So does .Net have a less horribly broken library design then?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Darren New wrote:
> > Nicolas Alvarez wrote:
> >> That's an implementation bug. Invisible is talking about AWT *design*,
> >> which can't be just "fixed on the next release".
> >
> > Yes. He was changing the topic, and I was still on the original topic.
> > :-) Just saying, AWT wasn't the worst of it. Java had all kinds of evil
> > brokenness, and still does.
>
> So does .Net have a less horribly broken library design then?

probably and sadly yes.  Because it was made to run on a single OS from a single
company.  Many choices and tradeoffs are easier to make as is making it work
nice with the underlying architecture.  of course, it's less broken but much
more evil than Java. ;)

Post a reply to this message

> Darren New wrote:
>> Nicolas Alvarez wrote:
>>> That's an implementation bug. Invisible is talking about AWT 
>>> *design*, which can't be just "fixed on the next release".
>>
>> Yes. He was changing the topic, and I was still on the original topic. 
>> :-) Just saying, AWT wasn't the worst of it. Java had all kinds of 
>> evil brokenness, and still does.
> 
> So does .Net have a less horribly broken library design then?
> 

AFAIK, The library for making windows and stuff is less broken than Java 
AWT, *because* it's too Windows-oriented. Since they didn't bother with 
any crossplatformness, the API is simpler...

Post a reply to this message

nemesis wrote:
> probably and sadly yes.  Because it was made to run on a single OS from a single
> company.  Many choices and tradeoffs are easier to make as is making it work
> nice with the underlying architecture.

Other than some of the low-level windowing stuff, what do you see in the 
.NET libraries that would be difficult to implement on (say) Linux?

The only bits I've seen that are actually Windows-specific were the bits 
that were either accessing directly the win32 stuff (like turning off 
particular windows message pump messages), which you don't need to do. 
Or stuff that Linux doesn't support anyway, like distributed 
transactions. (E.g., AFAIK, you can't write code in Linux to rename 
three files from A,B,C to D,E,F in such a way that nobody ever sees D 
without seeing F, and a powerfailure after you rename A and before you 
rename C undoes the renames you've done so far.)

The stuff you'd expect to be portable (web stuff, file stuff, threads, 
data structures, code generation, library management, temp files, etc) 
are all quite portable.  Just off the top of my head, I'd say maybe 10% 
of the library routines, tops, have an API or functionality that makes 
them hard to port, and maybe 1% have an API or functionality that makes 
them hard to port to an OS that actually supports that kind of 
functionality.

Of course, it's *difficult* to port the windowing stuff, but that 
doesn't mean it's inherently non-portable. Only that it's complex. It's 
difficult to make X programs run under Windows, too, without writing an 
X server.

What classes do you think are unportable?

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message

Invisible wrote:
> So does .Net have a less horribly broken library design then?

I would say it does, actually, yes.

Now, granted, it's very *complex*, because it has a lot in it. And some 
of the design decisions aren't obvious unless you actually read the 20 
or 30 pages of "this is why we did it this way" documentation.

For example, most of the classes say "static class methods are not 
thread-safe, but instance methods are."  Huh?  Why would you do such a 
thing?  But the rationale is actually quite reasonable, and it's obvious 
the designers had spent some time thinking it through.

The same with the organization of complex callbacks/events, where you 
have a pre-change callback, a post-change callback, and throwing errors 
results in different behaviors at different points in the process. 
Complex, but when you go looking for "how do I do this..." you go "Oh, 
they already made that work right."

The regexp matcher, for example, is also way complex compared to what 
I'm normally used to. But it lets you match on one call multiple 
subexpressions, find out where they matched, and so on. In that case, 
there's really no "simpler" version, and the documentation is mildly 
obtuse, but playing around with it a little and looking at the result 
set in the debugger made it clear.

It also helps that there are things like events (linked lists of 
callback pointers) and properties (automatically-named getter/setter pairs).

There are, of course, still warts, many caused by the static typing. For 
example, the return type from the regular expression matcher is several 
inter-related classes all referencing each other. Confusing, until you 
actually read all the docs. Not more confusing than, say, trying to 
understand C socket programming based on the man pages, tho.

There are also warts caused by interfacing to systems (like SQL) with 
different data models (like, there's an "int?" type, which allows for 
integers or NULL, but the IDE doesn't generate code to use that, instead 
requiring things like resultset.column[2].isnull()).

The encryption stuff is kind of funky, as half of it is still using the 
Windows library things, so like the encryption stuff only works if 
you're running web pages under IIS, because it's using IIS's encryption 
library.

I haven't had to deal with reflection, introspection, or code 
generation, nor with all sorts of dynamic loading/programming/etc.

But overall, it's surprisingly clean.

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message

>> So does .Net have a less horribly broken library design then?
> 
> I would say it does, actually, yes.
> 
> Now, granted, it's very *complex*, because it has a lot in it.
> 
> But overall, it's surprisingly clean.

Java has a long list of brokeness. The language itself is horridly 
broken, but the standard libraries are insane...

It's been a while since I actually used Java. But IIRC, the Object class 
has a surprisingly vast collection of methods. The base class for AWT 
widgets is *huge*. And there are multiple methods which apparently do 
the same thing... except... they don't... but it's not documented... Hmm.

Other fun things include the frequency with which they deprecate massive 
sections of the API and provide new ones. (IIRC, originally we did 
stream-type stuff with stream wrappers. And then they added "readers" 
and "writers" and deprecated all the old interfaces.)

Basically, if you run the same program on several different JVMs, you 
get wildly different behaviour, because nobody is sure exactly what all 
the GUI-related method calls are actually *meant* to do...

I really hope .Net has managed to avoid all that...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message