Older blog entries for garym (starting at number 68)

3 Jun 2003 (updated 3 Jun 2003 at 21:18 UTC) »
Oh, this is Nice ...

Seriously. I've been searching all my computing life for a decent programming language, and I've been through a lot of them in my travels up since WATFOR and PL/C. Many come close, and those close-fits today form the core of my toolbox; there's been a lot of very nearly almost close-fits and some of them painfully not quite there -- in that latter list I include Ruby -- but because of my annoyingly unavoidable real-world constraints, my toolbox really consists of, in order of decending frequency and increasing power, bash-shell scripts, PHP, Perl, Java and C

Now before the language bigots jump up all indignant like, hear me out. This is, in decreasing order of importantce, what I cannot do without and what disqualifies even wonderful and enlightened programming idioms like Ruby, Haskel and Prolog:

  • free-software 3rd party components -- because I'm just one guy out in the woods and I can't afford to re-invent every low-level protocol or general purpose widget. As much as I would love to author every line of code (just like the good old days of the Z80!) it's just not viable in my market. I have to be re-using components shared by other developers, as much as feasibly possible.

  • Easy, easy package management. Again, I just don't have time to fiddle with manually picking up and tucking into right spots all the little components and dependencies most non-trivial code requires. This drives me bonkers in the Xerces-based XML jar files of Java where the least little version conflict throws the whole thing into a tumble, and CPAN, well CPAN is the single most influential factor in my staying with Perl, the language I love to hate. If Ruby had CPAN, and if Ruby's CPAN had even half the breadth of the Perl archive, I'd be there. As it is, count me with the camel.

  • OOD. Real OOD, not the kinda-sorta joke of OOP in PHP4 or the goddamn the torpedoes let it rip OOPishness of C++ (which has almost zip CPANerisms) but the reasonable sort of mental-scaffolding OOP. And not canned-mediocrity of VBasic either, it has to be seasoned and practical and, well, yes, I'm not the accountant mindset type so it has to have that Eiffel/Pascal notion of "the programmer is not always right" checksumming that saves me from myself. I want to program concepts, not chipsets.

Anyway, back to the point, what should happen today, which is an otherwise yet-another-dismal-no-prospects day of sifting sand in the exhausted stream of the down-the-tubes IT market, and what pops up in the radar but something called Nice. I haven't been there yet, but right off the bat, I can see evidence of those immortal words of Bucky Fuller ...

"You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete."

The Nice programming sytem, whether it is or not, claims to be a step in this direction, not trying to usurp my toolbox, just extending it, building on what I have (at least in the Java department) but doing so in a direction that's, well, very probably better ...

Nice is a new object-oriented programming language based on Java. It incorporates features from functional programming, and puts into practice state-of-the-art results from academic research. Among the advanced features: parametric types, anonymous functions, multi-methods, tuples, optional parameters to methods, design by contract, detection of many errors during compilation (in particular, concerning casts and null references). This results in more expressivity, modularity, and type safety.

Nice plays nice with java libraries, so it fits my first two criteria at least as well as Java does (which still ain't no CPAN, but it's no proprietarily padlocked C++ either) while simultaneously extending Java into the directions it should have gone way back what, 5 years ago?

Anyway, I haven't tried it yet, and I'm not sure where I might use it, but if it plays nice with the JVM that's at least an opportunity to test it out, and if it perchance also plays nice with gjc then it may actually win another convert here in Sauble Beach.

And maybe it's a idea worth stealing for Ruby too -- I wonder ... what's the chances of a Ruby-wrapper that would transparently adapt anything you could get in CPAN?

This is funny, just came in over the mail reader:

From: <news@ineedhits.com>
Subject: Yahoo! Has Acquired Inktomi

   Hi Gary Lawrence Murphy, As an ineedhits.com member we strive
   to keep you up to date with the latest Search Engine news, and
   Industry developments. Below is some recent and very exciting
   news about Yahoo! and Inktomi.

 ======================== LATEST NEWS IN THE PRESS ========================

  Yahoo! Has Acquired Inktomi --------------------------
  On the 19th March YAHOO!Inc. announced completion of its
  acquisition for Inktomi. Inktomi is now a Wholly-Owned
March 19th!!!! Oh, yeah, that's latest news alright! I probably heard about this deal within the hour over either Google news or Feedster, and the old "Wait until we're ready to print" ... well, I guess mailing lists just don't cut it anymore.

I'm not a fonts person. I appreciate nice typography, and I understand the science of legibility in principle, but the actual choosing of one font over the other and placing it all on a page strikes me as a shade short of voodoo, like the people who actually have a use for all 64 of the hues in the Crayola box.

Today I fixed my X11 fonts; after installing the Mandrake 9.1, my XFree86 became highly unstable (I use the notorious i810 driver) so I had to switch to the XFree.org binary, and while that solved my stability problems 100%, I was left with an issue of fonts because the XFree i810 server apparently doesn't like fonts on unix:/-1, and that's the config for the Mandrake font server.

Anyway, care about font servers about as much as I care about watering the plants in my office, which is to say that I recognize when either is dead, and today, in a fit of expediency, I inserted the replacement FontPath lines from the fs/config and suddenly the web was a typographic cacaphony, and such clarity!

All except one place, Kode-Fu. A peek at his CSS showed Georgia as the main font that was rending like the liner notes on a sex-pistols CD, and that left me with that nagging question born of my typographic ignorance, "Is that what Georgia is supposed to look like?"

Well, to make a long story short, no. It's not. Georgia should be a very nice book-like roman-ish font. How do I know? Well, Google found me a reference page where I can check all my standard fonts, only now I have another font problem: Georgia on the Linux Web Fonts Page looks just fine ...

Now more than ever, we need edge-network computing. Yesterday the UTwente mirror for the Mandrake 9.1 release shut off access to the ISO images:

    Our server was suffering real bad under this and we had to block
    downloads of mandrake.

    We are really sorry for this :(

    Derk-Jan Hartman

This was most sad since UTwente is one of the very few mirrors properly configured to serve ISO images as binary content, and that's a requirement for trying to save Derk-Jan's servers by distributing the download using our Open Content Network download page.

Shamefull self promotion? Not really, not intentionally. There's no ads on that page and only one link back to our site, it's lean and to the point, existing only to set up the OCN for these downloads. With the current crush on Mandrake 9.1, and considering I'm one of the converts who believe this is one of the most complete and accessible Linux distros ever, I just want to get the release out the door without ticking off kind mirror managers like Derk-Jan, and if you ask me, OCN's 'WebRAID' is just the way to do it.

I don't know, maybe this is the new face of the IT business, but riddle me this: if Operations requires a custom-built closed-source clean-room implementation of an FTP client because "not invented here" is the company religion, do you suppose they are just trying to drive up costs so the department doesn't outsource? I've been sent on a lot of hoop-jumps in my day, but this one, where the client app is used by one or two users for all of 10 days, well, it takes the top honours.

22 Mar 2003 (updated 22 Mar 2003 at 18:53 UTC) »

Now here's a little-known fact that's going to sting a lot more people: Did you know that, as of 1.4.1_02, Sun now bundles Xalan into the rt.jar? If you did, or even if you didn't, did you know that classes placed in the classpath will not override this, so if you need to get around the brokenness of the Xalan release they chose (for example, in the lib/sql connection pools) you have to hunt up how to tweak the Endorsed Standards Classes Deployment and even then you need to know that the default given in the Sun pages is different from what the Sun Linux package uses (the real one is $JAVA_HOME/jre/lib/endorsed;) and once you get past that, also be aware the launch script for Tomcat4 _overrides_ the default with a null path unless you hack it in.

Put all this together and if you ask me, Sun has shot itself in the foot again over Java.

Why on earth take an unfinished jar like the old 1.x Xalan and burn it into the core fabric of Java? Having done so, what then is the logic of making the work-around so obtuse? Maybe I should follow the community development meeting notes more closely because it seems someone's smoking something during those sessions.

I'm probably just in a crabby mood because this secret tantric circle has cost me the loss of a full day's wages hunting down just how it could be that no matter what I did, I could not avoid the ClassLoader error on line 474 of DefaultConnectionPool even though my sources had no such line, even after I'd locate'd and deleted every one of the two dozen copies of the Xalan jars on my machine. I expect I'll lose yet a few more hours when it comes time to convince my already java-nervous client that I need to inject a hack of a jar into their core dirs or the JAVA_EMBEDDED_DIR into the very core script of their production systems tomcat environment ...

I'm normally not a fan of technical jargon, but in the case of Technical Debt I'm ready to make an exception:

we can never completely resist externally imposed schedule pressure to "just get it working so we can [ship|deploy] it." Good to at least explicitly record such things, to provide a stick with which to whack management later ("See all this debt you incurred? Now we have to pay it off...")

Technical Debt. Word-sound-power at it's finest.

If you haven't tried it already, check out Google Quotes, the new experiment on Google Labs where each hit will also show quotes from inbound links ... kind of like Google with a side order of Technorati.

1 Mar 2003 (updated 1 Mar 2003 at 14:47 UTC) »

Scripting News' Dave Winer says Neither Microsoft or Google, or Pyra or UserLand are open source companies. You'll find that the excitement in software is often this way. The open source implementations can come later, but people at the leading edge generally need to keep the source to themselves. No matter, if everything is working correctly, users still get choice, and have the ultimate power over what's created.

Say what? Dave Winer is saying that innovation requires closed source? Or is he saying only closed source can produce exciting software? (Does RMS and the FSF have any thoughts on this claim? How about the claim that "user's still get choice and have ultimate power"?

Are Advogadorians going to sit back and let that go by without challenge? Are we all simply working on open source implementations that copy the innovative commercial software what's gone before? (I know I'm not, but what about the rest of you?)

Argument by anecdote is bad enough, but to make an assertion like this one, based on just 4 exceptional examples out of a whole world of possibilities... and yet Winer gets the Harvard post? The world is a funny place.

On a tip from JOHO, here's Tim Oren's point by point comparison of Bayesian Nets and Latent Semantics used in spam filters. Latent Semantics was a new one to me, but considering the number of IP patent weights around its neck, that's not surprising. The good news is Tim's undecided on which of the two methods is more effective.

59 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!