Where's the conversation?

One of the things that bugs me about web logs is your inability to find out who's read and commented on something you've posted.  I know that there may be various mechanisms out there for accomplishing this, but there doesn't seem to be any standardized way to do it.  We have a pretty good public thread/conversation system already; it's called NNTP.  I like the way that people put a little more time (at least some people do) into their weblog postings -- reducing the conversational nature seems to have had a good effect on the writing; each becomes more like a little essay.

I just wish there was a way to track it all, something standard, something easy...

10:58:10 AM    

Typesafe Enums.

JavaWorld is running another series on enums; yes, this issue has been covered to death in the press over the years.  Here's my take -- enums in Java are a pain in the ass to do.  Why don't we just take a quick look at what's out there, and what works?

The best model I've seen is what Delphi/Pascal do.  You can declare enumerations with contants.  They are typesafe.  Then, importantly, you can declare sets of them.  Something like this:

myEnum = (meFirst, meSecond, meThird);

myEnumSet = set of myEnum;

Handling sets of enums (and set operations) is something that happens all the time.  It's something that Pascal got completely right, way back when, and hasn't been done right in any of the major languages since.  Please, for the love of god, put proper enums and sets in the language.  They'll get used all the time, and the resulting code is wonderfully readable. 

Sometimes I miss Delphi!

10:52:53 AM    

Library Changes != Upgrade Cycle

Manageability #66 is bugging me. I'm sorry, but changes to the Java library don't count as upgrades, in my book. Where are the improvements to the JVM for multiple language support? Where is bettering the language? Does Sun think they've got it all perfect? Not a chance!

The science deserves better than Java. It's good, but we are not there yet.
5:53:00 PM    

If backing by a large, cash-rich, aggressive, technically savvy company with a vision is the necessary component for success, then why has Linux succeeded so well, and OS/2 failed so badly? I won't dispute the fact that having that definitely helps, but that's only one component to the story. He's right about the vendor-neutrality, but I think as time goes on we'll see a consolidation in vendors in the Java space and an expansion of vendors in the CLI space as both Mono and Portable.NET achieve some measure of success in the commercial marketplace, so ultimately that'll be a wash. In the end, it comes down to one thing: which platform is your boss, the guy with the checkbook, wanting to back today? [The Mountain of Worthless Information]

I think there are intense technical reasons why Java (and its VM) is in danger of losing, here...NET is designed from the first to support multiple languages.  You can say that it can be done with Java, and it can, but .NET is evolving pretty rapidly at this point...there are people working on functional languages and other more esoteric stuff for .NET.  This is important because the primary reason these environments have failed is the lack of widespread library support. 

That is arguably no longer true -- there are some pretty massive libraries available for LISP, OCaml and so forth at this point, but they're hard to find, hard to integrate together.  With .NET everything can use everything else.  That's important beyond belief.  It's what's left Java leapfrog ahead so quickly -- a clean binary standard that lets things play together, within reason.

.NET is poised to move ahead.

Will anybody ever produce a different programming environment for .NET?  I suppose Borland will build something, but we may not see very many others.  We'll see language plugins, I guess.

12:45:54 AM    

Hacking to...

In the spirit of Mr. Glass -- Sasha's AirdrawnDagger, which if you're into a little intelligent electronic music, is the first truly interesting new thing I've heard in a long time.  And maybe that's just because I'm kind of unplugged from it all.

There's too much to choose from out there in the world.  Too many ways to approach a problem, and it gets confusing at times.  Really, the only thing we can do is pick one (even at random), start the ball rolling, and see what develops.

It's a lot more complicated to do code than it was 10 years ago.  Some things are easier, and some things are harder.  We're doing things today, by ourselves, that a team of a hundred people wouldn't have attempted a decade ago.  Trying to see your way through everything, while you're still at the beginning, is becoming a lost cause, and is a progressively more lost art.

Take heart, though -- even the best (and that isn't me) need to refine what they do. Insight comes as you work.  Just start.  It'll happen for you. 

12:36:21 AM    

Normalized Formats.

The old pattern of "convert Y to normalized format, then convert to X" is something we've all used, and used many times.  The thing is, trying to construct a single normalized form for many object (or knowledge) models just isn't very easy, and often you end up with something that's unwieldy.

I've been playing with multiple normalized models...the idea is to create progressions of models -- evolutions of structure that approach normalization but do not necessarily fully normalize information from multiple domains.  You normalize to the intersections between the models instead.

Why do this? If you're trying to construct information relays -- things that can take arbitrary information and move it around -- then you want something like this.  Sometimes, in a given domain, there are radically different approaches to the basic problems (this is from my day job).  When you're dealing with that, you don't want to lock yourself into (or have to maintain) that single normalization.

2:14:38 PM    

Instability.

Dammit.  When I choose the 133mHz FSB freq, my system becomes unstable...crashes periodically.  Can't have that.  Substandard memory?  I've got all the latest drivers and so forth...there's something wrong.

12:00:10 PM    

Distributing Prevayler-like Commands.

I built something like Prevayler about a year ago, except that it maintains distributed knowledge stores.  It's kicking around statement edits, basically.  I can have a bunch of tuplespaces locate each other through JINI...they are able to relay commands to each other when other processes do things (like write or remove statements).  The commands are kept in a buffer.  The trick is, how do you guarantee that each instance executes the same commands in the same order?

The answer is what I called a time ordering protocol, but I'm sure other people have named it something else.  Basically I try to get my peers to agree on the current time, but I really don't care if they do -- they just have to be reasonably close to each other.  Each peer has its own unique id.  I sort the commands/operations by time first, and originating peer id second.

Presto -- completely sorted lists of commands, around my entire set of peers.  What happens if I receive a command that needs to be sorted earlier than the latest one I have?  I pop off the commands, one by one, inserting them into my wait list, undoing them, until I can insert the command I've received.  I can do that because my do method keeps enough information to undo if necessary.  I then sort the list of commands I have waiting and execute them all.

Works pretty well.  Yes, the checkpointing and all that seems to work.

I think that something like Prevayler and what I implemented back then are OK, but they don't really scale all that well.  What happens when you need to have 20 or 40 GB of information?  Can't keep that in memory, but you still need to get the job done.  At that point you're writing a compressed paging store, assigning object ids as your commands are executed, and pushing things out of memory and onto disk when you need to.

Still, you need a lot of data before you get to that point.

11:25:03 PM    

Promises aren't Enough : AOP Leasing.

I was reading over the documentation for the E language yesterday.  I'm impressed by the thought that's gone into it, and the careful scrutiny that's been applied to the security problem it primarily wants to solve.  As I think about it, though, I'm not sure that the promise feature is adequate to the task. 

The promise basically says, yes, I am doing this send for you, and there will be a result ready for you at some point in the future.  You can check at that time.  I don't think that's good enough for systems where the receiver of the send has to do resource intensive work.

I prefer something like the JINI leasing model, applied to function call requests.  If A wants B to do something, he asks B to start doing it.  B returns a lease for the request (or just the answer, if it can be delivered really quickly).  A is required to maintain interest in the request.  Once B has finished, it sends a message to A with the result.  A can either maintain its interest, or cancel the request if it is no longer needed.

It sounds like a complex model, but it can really work well if you are implementing a server.  You know that when you're servicing a request, the client who wanted it is still wanting it.  The client has a way of canceling a request, which means more server time to do the things that really matter.

The protocol outlined above is a prime candidate for implementation via aspects, too...the JINI libraries supply some of this kind of functionality automatically.  It's a good thing.

11:42:41 PM    

K is CISC.

Carlos opines that K is perhaps a RISC language.  I'd disagree!  Let's review what the basic languages give us.  C gives us variables, for loops, and you can make your own functions and have function pointers.  That's pretty much it (ok, yes, I am simplifying).  Let's say you wanto do something like K's grade operator. Sure, you can write your own implementation; K is, of course, written in C itself.  The point here is that you shouldn't have to.

I think that the function set available in K falls squarely in the CISC camp.  Look at the power that its primitives deliver -- they are considerably more sophisticated than the average 3GL...

11:35:27 PM    

Aspect Diagrams.

Somebody (not me) should get off their butt and produce an evolution of UML that will allow aspect-based systems to be effectively diagrammed.  It should be fairly straightforward to come up with a visual notation that shows the assembly of a system...this need not be substantially different from what we're used to seeing in other assembly systems.  And hey -- with any luck -- the visual system can create recipes for assembly that are executed automatically by an AOP runtime.  Even better, having some kind of standard for attaching aspects/advice to objects would mean that a variety of frameworks could be used, each with its own performance characteristics, and we'd all be able to switch from one to the other.

9:52:51 PM    

Aspects: Invocations are first class objects.

Some of the more advanced programming languages let us have functions as first class objects, and some even do continuations.  Aspects (through toolkits like JAC) let us get at a call before it happens, possibly modifying what's going on in it, and performing pre- and post-activities.  I wonder what a language that directly supported invocations as first class objects would look like.  You'd be able to work with them, pass them around, trigger them once, again...adjusting parameters as you go.

Current aspect-oriented programming systems just don't seem to feel right for this stuff, yet.  The dynamic nature of JAC is clearly the way to go...being able to splice complex creations together at runtime is at the heart of any modern system.  Compile-time flexibilty (a la AspectJ) just isn't good enough for enterprise class systems.

I want something that's going to give me the clean syntax of an AspectJ, but the runtime flexibility of JAC...I think that runtime flexibility should be in the language. 

Which brings up another point.

Minimalist languages are stupid.  Let's see -- I can have a very small language where I have to code everything, or a bigger language where many of the complicated things are done right for me.  I'll go with the more complex language any time.  It just doesn't take all that long to learn them!  Learning libraries is much more complex than learning languages.

4:55:17 PM    

Out of the Air.

Hmm.  The plane was old, man.  I am just not used to it.  Old airplane, high wing, different airport, tiny runway, unfamiliar procedures, radio that didn't work as well as I'm used to.  Add all that together...I just don't know about training there.  I think that I'd rather just spend the extra $25 an hour and do what I've been used to doing -- much newer plane, easier navigation...you name it.  It's too bad flying has to be so expensive...

I'm glad I tried it, though.  Got up in the air again.  The one thing that's good about the older planes is that they just trim out really nicely...very smooth controls, usually.  The newer Warrior III that I usually fly seems to have significant static friction that you have to overcome while you're flying.  You can't really fly it with your fingertips, like you can some other planes.

4:36:27 PM    

In the Air.

If the weather's good tomorrow I'll be out on my first lesson in quite some time.  I haven't been able to fly in a while (it's a really expensive hobby!).  We'll see how things go with the new instructor tomorrow -- if I like what I see then I can switch and not have to drive for an hour to get there!  This airfield is much closer.  I might get to do a longer flight on Sunday too...

2:10:36 AM    

Radio in Motion.

I've moved my Radio setup to the new computer I built.  Let's hope this goes thorugh to the blog! I don't think I like doing as much on my laptop as I used to.  It's just too slow now (but it was a speed demon when I bought it).

10:43:42 PM    

Giving Up.

I've learned that I suck at giving up. Long after I should, long after the point of diminishing returns, I'll continue to bang my head against the wall, trying to make things work. It's a flaw.
8:16:43 PM    

New Toy.

I decided to drop a little cash and pick up a new computer yesterday. Bought a nice Soyo MB, 1 GB mem, 100 GB HD, etc. It's amazing what a $1000 will buy these days. Stuck my favorite Java environments on the new box and man, do they ever fly. I don't think all that much about hardware on a daily basis -- it just doesn't really matter to me. I'll be rethinking that for my work computers now. I can't believe how much faster TJ runs, and Eclipse starts up.

It's a little tough looking at how ugly Java applications are when they start up on the XP box. The JGoodies programs run and look very nice, but the Java control panel and other apps looks incredibly ugly. Yuck. Talk about lack of integration with the system look and feel.

I'm still recovering from being sick and it's impacted my ability to get work done. The new box should be very pleasant to work with so I'm looking forward to doing a little "test development" on it. All I know is I've never seen my TJ run so fast. Maybe the UI designer will actually be usable now!

I've read through the JAC papers and I really like how the system comes together. They need to spend a little time extracting the core of the JAC system and packaging it separately. Of course, I can do that myself, but a better division of functionality out of the box would be very nice.

I'm struggling to understand exactly how JAC's distributed model works at the moment. What happens when it scales up? What protocols are being used to resolve distributed conflicts? Can a subset of information be replicated between servers? Can aspects really solve this problem?
2:31:10 PM