Flutterby™! : Sun on Java 2003-02-10 22:02:19+00

Sun on Java

2003-02-10 22:02:19+00 by Dan Lyke 8 comments

I've seen a couple of links to the Sun Microsystems: The Java Problem memo. Rafe says "if Java doesn't run well on Solaris, Solaris has big problems", and Borklog notes "Even Sun isn't fond of Java". I think they both miss the real conclusion of the memo, part of which compares Python with Java: The U.C.S.D. P-system failed for valid reasons, and notions of intellectual software purity and misguided visions of software engineering pale against the reality that what we need are more expressive languages, not more restrictive ones.

I come to this after helping a couple of teenagers with programming homework last night. They're taking a C++ class, but in reality the book so far is using C data structures with C++ streams for file access. These kids are totally lost, partially because they've been asked to assume that "magic happens" in one set of accessors while twiddling bits in other structures. The stdio.h interface would be far more logical for them, but someone has decided that they need to be learning C++, even when that means several extra lines of code cluttering up the page as they try to understand what a for(;;) loop does.

Java is failing not because of how it's written, but because how it's designed. C# and the .NET CLR will do better because Microsoft understands that they're not building a one-size-fits-all language, they're making Visual Basic with C++ like syntax; something for a specific application.

Somewhere or another, in the past week or so, I ran across a link to a PDF version of The UNIX-Haters Handbook. I can't find it now, of course.

Anyway, I dumped that sucker to dead tree last week, and finally got time this weekend to sit down and read it, which was good for a few laughs.

It seems like reading the C++ chapter would do you a world of good; it might help the kids, too.

Lemme know if you can't find the PDF and I'll see if I can dig up the link -- it has to be in some browser history somewhere...

The Java Problem mentions alot of symptoms without jumping on the obvious: the hardware is not catching up with the software. Microsoft rides the wave by developing software just beyond the current hardware and not rereleasing until the hardware catches up. Java has always been slow and always will be slow because they keep expanding the core too much. Maybe Sun needs to force the Java team to use older machines...

There's another red flag in that memo that people seem to skip over: The Java team has slipped into prioritizing new features over stability. That's a formula for a slow decline and lingering death. Without investing in stability (bug fixes and refactoring), the code base gets harder and harder to work within. Gradually, the skills and knowledged needed to work in the code base instead of on the codebase get dispersed and lost. I've heard this pattern called "Milking the Cash Cow."

I personally am glad Dan sees a certain pointlessness in teaching C++ early on, because I hate being the only person with a particular cranky opinion. (I'm not going to extrapolate to any general feeling about C++ - I find it a useless language, but I don't necessarily assume Dan does from his comments.) The problem with C++ as a teaching language is that it hides information at a time when the information most urgently needs to be transparent. Black boxes are only useful once you understand what they do well enough, and trust them well enough, that you don't need to look at the gears inside to verify that they're really there.

That said, I believe in the concept of a one-size-fits-all language. Well, a two-sizes-fit-all model, perhaps; one interpreted language and one compiled one. I agree that Perl has definite limitations, for example, but they all have to do with code size and critical mass; Perl is simply not equipped to deal with anything very large. For that I use C. Both are very open-ended as languages go. That's the point.

I have a boss - a gent who has literally spent his life in IT and who should know better - who hates Perl because he says there are always too many ways to do anything, that it gives you more than enough rope to hang yourself. To me this is like complaining that your car is useful both for short hauling AND long road trips.

(I also don't understand people who don't think you can write structured code in Perl. Sure you can, and a good programmer does; it's just that there's a lot of bad code in the world. Point is, enforcement/rigidity built into a language is NOT the answer for bad code. Better-trained programmers are the answer.)

I have the same complaint, but I look at it differently. Trying to use Perl feels like borrowing some off-roader's customized jeep. Sure, it can drive on any road from the highway to the side of a cliff, but how do you get it out of the driveway? Why are there three gearshifts? What's a "locker" and when do you use it? When would I need to turn the air compressor on? This switch that controls the electric radiator fan - is that instead of or in addition to the normal fan? Will the engine overheat if I don't turn it on? Why are there switches to turn off individual brake cylinders and am I going to crash if I don't use them at the right time? Does the normal brake pedal still work?

Now of course if you *are* an experienced off-roader none of this is particularly mysterious, and a truck with all those features would probably be a lot of fun to play with.

The problem I have with Perl is that it forces you to be pragmatic. If you want to get anything done, you have to simply do whatever works and stop worrying about how it works, whether the approach you stumbled across (or the source code snippet you dug up) is the most appropriate one for your situation, and what sort of problems might arise in the future as a result of this particular design choice. The options are so plentiful, the design decisions so mysterious, and the lore so widely distributed that there's no way to absorb enough of it to arrive at a real understanding.You just have to wing it.

So I don't think Perl so much makes it impossible to write structured code, as it encourages you to kludge systems together with duct tape and baling wire. You can write bad code in any language, but with Perl the distance from the beginning to the point where you can actually tell the difference between good and bad code is almost prohibitive. So I think there is a cultural selecting factor there, where people who care a lot about writing good code will tend to avoid Perl, while people who care a lot about getting the system running and getting on to the next problem will tend to like it just fine.

Mars, it's funny that you come at Perl from the "too many features" perspective. I got sucked in by doing little things, large search-and-replace operations, stuff like that, and it was only as I found myself building more complex operations that I realized there was a real language under that "slightly more than grep" command line tool.

As I write more and more software, I'm getting more and more to the "I want my language to let me be pragmatic fast" view of things. There are situations where multiple interfaces on inherited objects and all of the overhead associated with that are appropriate, and it always feels really good to put together a nice OO design, but for the most part I've found that I get paid for answering the "how easy does this language make it for me to glue lots of disparate code together and ship quickly?" question.

Templatized C++ with the huge algorithms library doesn't do that. Wading through huge class hierarchies doesn't do that. Encapsulating an int so that I can call by reference rather than value because the language assumes one thing over another doesn't do that. Fighting a garbage collector that does the wrong thing definitely doesn't do that.

I like bits of C++, I think case is for places where vtables aren't available, and I like the control over inline functions. The Java

solution to multiple inheritance is handy, but the available classes take way too much glue-code to do anything useful with, and steep hierarchies mean that early design decisions can have big consequences further down the road (Not to mention "slow" and "the only truly portable Java

app is a core dump"). C# suffers from the "garbage collector doing the wrong thing" problem, but if you just look at it as a VisualBasic

with familiar syntax and do all the important bits in C or C++ it's tolerable.

And Todd, you might point out to the chap who says that Perl

"gives you more than enough rope to hang yourself" that I heard this complaint leveled at C by the Pascal and Modula folks all through the late '80s. C won that war because it gives you the rope, Perl

improves on C because every imaginable configuration of gallows is available from CPAN, and there are lots of friendly people who've figured out how to tie really efficient knots.

Something's telling me I need to work that last paragraph into something quotable in 3 lines of .sig file, but it's just not coming.

At this point, I only really know Perl, it fits what I do via web and shell on Linux with text and SQL servers perfectly. Life would not be possible without it. - And yes. my perl code makes people's head hurt. Lots of duct tape. But Dan nicely points out that for one off and short runs, the ability for a toolset to do the job quickly and with the least amount of fuss is important.

And. my '84/86 Bronco.. Dash has a big starter button WITHOUT a tranny interlock (so I can crank over the 351w while in gear and the pegal floored..handy when it stalls from going vertical fast) has a custom built automatic and a slapshifter that LOVES manual shifting including forced downshifts (great way to brake going down a hill) and there are toggles for each of two electric fans, an alternator cutoff, and an 'alternator maxed out' (useful for welding, jumping someone off.), front and real lockers.. and if I very got into rock climbing there would be a manual brake for each wheel.

And I cheat with perl as well, I have files I include in a lot of my perl code with a lot of personal functions for time and date manipulations, input validation and URL cleanup, database manipulation.. that would drive you nuts as well unless you took them apart first and got familiar with their quirks. What seems to be the MS-Issue is that you can't take the black boxes apart and see why they work (or don't). Oh well..