Monday, January 19, 2004

Protocols Plugin. I've begun organizing some of my source code with Sten-Erik Bergner's Protocols Plugin for Eclipse.  What it does is provide a decent and clean way to organize the members of a Java class.  You declare section names and give it a sort order.  Then, in the Java Browsing perspective (not the Java perspective), you can drag and drop from the member types window into the list of member categories ("protocols"). The plugin organizes your source code as you go. What you end up with are pretty nice looking source files that have all members that correspond to a given category ("accessing", "creation", "event handling", or whatever) all bunched together, in sorted order.  When you're working with your code, you can click on any Protocol in the Protocols view and have your list of members filtered to include only members of that category.  When you're working with larger classes or more mature systems, this is a godsend.  You can quickly zero in on public stuff, property handlers, and whatever else you want. You can make up your own protocol names...I wrote a paper a while back that describes a series of method classifications.  I've made some protocol names that correspond to those.  3:03:43 PM

	Sunday, November 09, 2003

The Relentless March Of Stupid Technology. Here in the DC area there's a story getting some buzz: Glitches Prompt GOP Suit Over Fairfax Tabulations. The GOP is absolutely right to protest this vote; it's not about anything other than the validity of the process. The machines in question are the WinVote model, from Advanced Voting Systems. Just listen to their pitch: The functionality linchpin of the WINvoteTM system is its wireless LAN (IEEE 802.11b) system - called the Wireless Information Network (WIN) -- that enables the user to communicate remotely with the major components of the voting system. Does anybody else see a problem with enabling wireless communications to voting machines? This is just f'ing stupid, beyond belief. Encryption can help ameliorate the situation, but what I see is the possibility of ne'er-do-wells attempting to disrupt elections with laptops. All they have to do is hang around the building within a few hundred feet, and they can screw with the election machines to their heart's content. Who wrote the IP stack on the machines in question? We can't tell from the web site, which means in all probability it isn't open source. That means we have no idea what stack is running in there and what its vulnerabilities are. Even encrypted stacks can be vulnerable to certain kinds of attacks. Voting companies have been pretty underfunded. Why are we trusting our democracy to these stupid machines? The only function of a computer in the democratic process should be to help print a legible vote. Count me, as a computer guy, concerned. 12:05:24 AM

Fixing Patents. Great reading here...the FTC is releasing findings about the patent system. Reading this, it's just common sense to do so, and everything in here squares with what I've experienced. 12:00:40 AM

	Tuesday, November 04, 2003

On the 1.5 Java Language Extensions. I was reading the (old) chat at the Javasoft site.  It's got some insight from the developers...here are a few comments... On Generics: Nice addition to the language, but for the love of God why aren't primitive types included?  After all this time, I still cannot make an efficient map of integers to doubles, or any other primitive type combination.  What's missing is a generic-type capable implementation of a BTree...this will lead to some serious compaction in atomic data storage... Typesafe Enums: Nice to have, like'em, but Delphi did it better 47 million years ago.  Bit mask sets were perfect for tons of different things, and they're still perfect today.  A tiny little bit of syntactic sugar is all that's necessary to make them work.  Why should I incur hundreds of bytes of overhead to store a set of enums?  It makes no sense.  And if you want to treat them like real objects, the compiler can autobox into a typesafe enum object.  Just keep the representation in the field structures as compact as possible.  Remember, there might be several millions sets.  One of the most important uses for enums are flag sets, which just aren't going to be efficient in the proposed scheme.  JFarre: What about supporting "references to references"? I know it's one of the hardest things to learn in C, but it allows us to almost do magic... Neal Gafter: This is sometimes called "hooks", and I do miss this ability in the Java language. The closest thing we have is java.lang.Ref. We haven't considered adding anything like pointers-to-pointers in the Java language. You don't need pointers to pointers.  You need a functional type, which can be used to do pretty much the same thing, with much more flexibility.  A proper functional type doesn't need an "object" to call a method on -- you can just call a "thing", which can be atomic, a method call, a function call, or a composition of the above, and it returns a result of that type.  Of course, you can throw exceptions and they are declared in the functional type's signature. With the generic system you can create containers full of functional objects, and the possibilities are quite endless.  Functional type compatibility should be automatic with the compiler -- if the call signatures are compatible, it can be used... This is, in my opinion, the single biggest missing thing in Java.  If we had proper functional types, our code would be so much simpler, and we'd all be doing cool higher-order functional programming.   3:59:42 PM

	Monday, November 03, 2003

Sandboxing Outlook's HTML Display. One of the perfidious things out there on the web right now are the nicely formatted "scam" emails that purport to be from places like PayPal.  Sometimes it can be pretty hard to distinguish these from the real thing -- the problem is that the HTML displays inside of common programs, like Outlook, don't show you where they're getting their information from.  The email program cracks the email apart, extracts the HTML content, then hands it to a browser component for display. What we need to do is have the email program pass the domain of the reply-to or message-source field to the browser component, which is then instructed to not display anything that is not from that domain.  HTTP requests for that content in that component will not be sourced from anywhere but the indicated domain.  What's more, if any part of the page tries to hit something outside that domain, the entire message will not display. This will pretty much eliminate HTML-formatted spam email.  It won't work because the pages can't access anything other than the server that sent the email.  Forge that, and your email doesn't display. Note that we can extend this concept to include regular email as well.  If the email contains a web address that comes from anywhere other than the domain that sent the address, we can elect to not display it.  Of course, this messes up having one friend send a link to another...so it's not particularly workable as is. 1:21:29 PM

	Thursday, October 23, 2003

Spam Throttle. I've written on this before, but it's worth repeating: My feeling is that the internet as a whole is going to evolve towards a trusted/untrusted scenario.  Big vendors like AOL and MSN will be "in the club", so to speak -- their mail systems will "trust" each other, and accept email at full speed. Other systems, particularly those connecting for the first time, will be untrusted.  Those systems will be severly limited in the number of emails that will be accepted.  A Bayesian filter can be applied to the email coming in from any new connection.  The filter doesn't stop the email; rather, it builds an approximation of how much spam is coming in over that particular connection.  The odd false positive isn't going to hurt, that way. As the system gains trust, which can happen only by having time elapse and by having a low spam percentage, trust will gradually accrue, and email traffic will be permitted to have progressively higher volumes. The beauty of this situation is that you still accept email from just about anywhere, but you don't _trust_ that source, until that source proves itself. It doesn't take very much to implement a solution like this.  Any organization that failed to implement it or have a strong anti-spam policy would find itself being on a lot of untrusted lists, and unable to send very much email.  Simply being a transfer point for spam will also get you untrusted, which means that you'll have to pay attention. 5:38:59 PM

	Sunday, October 12, 2003

Eliminating NullPointerExceptions. Every reference in Java is either null, or valid.  In the development stage of many applications, and even during production phase, we can still see a lot of null pointer exceptions being thrown.  This is usually due to failure to check a return value from a function call. The null result is often returned from a function to indicate "I couldn't", or "that object was not available".  It is very common to want to return this result, and exceptions shouldn't be used to signify it.  We don't want to incur the overhead of generating an exception. It would be interesting to be able to mark a method as "returns null", in the same manner that we can throw an exception.  The compiler can then check to see if the value returned is checked for null, before being used.  If the value is returned from the function, that function must be marked the same way, forcing callers of it to check, or declare to throw. Yes, we can always put the null value into a class, and there are more convolutions of this principle that could get at that... It is an interesting idea, nonetheless.  Extending it further, we can note that we might declare multiple return paths for any function, and the calling of that function becomes like a switch statement, where the type of the result directs the path of execution, much like a type-inferring language like Haskell or ML. And maybe that is what I really want.  For now, though -- enforced null checks! 4:01:23 PM

	Friday, October 10, 2003

Anders Hejlsberg is Wrong, Part II. And this time it's not me saying it.  James Gosling is saying it.  Excellent.  Bottom line is, it's fun and fast to ignore exceptions or catch them in some pointless top-level loop.  That's fabulous for, I don't know, applications that don't matter?  Now you're writing an app that has to stay up.  This is what most of us are doing now, in the Java world.  It has to stay up for months, or years.  Do you think your top-level exception loop is going to be able to handle the multiple strategies that are necessary to deal with failure in that environment?  You're going to activate retry-logic at the top level? And what the heck is the top-level in any modern Java app anyway?  It doesn't exist. Java helps you build robust code.  That is now, and has always been, its most important feature.  It does a better job of this than any other commonly used language.  We have a couple of a million lines of Java code in our app, and it's pretty damn bulletproof.  Trying to get to that level of reliability in C could take decades.  And no, we are not crappy programmers.  If you think you could do it in less time, you think you're smarter than a lot of very smart people out there who have been writing system-level stuff in C for longer than you have been alive.  Here's a clue: You're not.  You need the help; you just don't know it yet. 2:49:51 PM

At Play in Piccolo. Something unexpected...(this likes a fast machine). 1:54:35 AM