I’ve evaluated many pieces of technology now. Tons. And I think there’s some consistent trends to the stuff that I like. And the ones I don’t like, as much. Here’s some, and why:
#1A) Good: HTTP. Fantastic standard. Simple, powerful, extensible (headers!). I think that the World Wide Web is as good as we know it because of HTTP (not HTML, which I think is neither good nor bad. It just ‘is’.)
#1B) Bad: WebDAV. Turns this good fantastic standard into a confusing mess. I *love* the idea of PROPFIND. It’s a really great idea. But not, I think, in this standard. Why couldn’t there just be a nice simple way of getting directory listings, along with locking, and maybe some very very very simple concepts of file ownership? Instead there’s all this crazy crap, and no thing for ‘and here’s how you can extend it!’ The end result – we still use every other available protocol (FTP, SMB, AFP, et al) for file transport. How lame. I had to *SNIFF* the wire to figure out all of the hidden pieces in the various reference specifications and client specifications. What a mess.
#2A) ‘Good’ is not really the word I will use for this, but ‘adequate’ is: POP3. Yes, it’s annoying, but you can build a POP3 client or server pretty easily, and the entire Internet ran on that architecture for a very long time. Now being augmented heavily by, and perhaps supplanted by, IMAP4, but I’ve written POP clients and IMAP clients and even if you do a subset – POP is just so much easier. If they had extended POP3 instead, they could’ve made a better IMAP…
#2B) Bad: IMAPv4. It’s for many (me too!) a necessary evil – but there’s so much latitude in the implementation, it’s ridiculous. “You can use any separator character you’d like! Dots? Sure! Slashes? Why not!” That just costs more code. Why not just say that it’s way X not Y and if you don’t like it, screw off. And UIDValidity – christ! If you’re writing an IMAP client, you think, ‘Hey, I almost got it! Almost done!’ and then you realize you don’t cover UIDValidity changes. FUCK. Why not just insist it never happen? And leave the implementation to the servers? Same reason as before – it says in the standard, “Some email servers may not have any storage to store UID values…” When my friend Bryan and I read that, we both at the same time said, in mock sympathy, “Awwwwwwwwwwww!” Were I writing that spec, I’d say, Fuck ’em! Figure something out! MD5 the headers or something, I don’t care, but the UID _DOESN’T_ change.
#3A) Good: DNS. Impressively powerful standard for turning names into addresses. Completely decentralized. When extended, it can be used as an IP database, in some places (DNS RBL’s, etc). All this so that you can say ‘www.yahoo.com’ and get a nice answer.
#3B) Bad: DNS. Multiple ugly flaws in the specification. I’m with DJB on this one. Why specify the whole secondary protocol? There were plenty of them at the time, it’s unnecessary. Why require 2 DNS servers for a 2nd level domain? That’s unnecessary specification. And why not force referrals down to the client, instead of making them be performed on the server? E.g. the Recursion mode – bad idea. CNAME’s – totally unnecessary, should be at the Server’s discression. The second-to-last one feels like hindsight to me, but I think the other objections are valid.
#4A) Good: Nothing. Well, maybe, /etc/passwd. It doesn’t do anything, but it never breaks. And when it does break, you can vi it (for me, I ‘joe’ it) or pico it and fix it. So nice. And for 99.9% of the world, definitely enough.
#4B) Bad: LDAP – Here’s another one where you can just do whatever the hell you want. Actually authenticating People is almost secondary to this massive behemoth (sp?). It again allows you to do just about anything. You can define a person with 4 assistants, each of whom has 2 subassistants, and that you have 4 postal addresses. But what attributes are required in order to actually authenticate people? Who cares! How do you attach to the Directory? Eh, you decide! But if you want to define a PenisSize attribute, yes, you can have that. How useful. This is sadly one of the times where MS can just sit down and define their own implementation and swing the standard their way, and it actually helps.
#5A) Good: IPv4, TCP/IP, UDP/IP, etc. Again, there’s a reason why the internet runs on it. IP is a dirt simple and ugly way of chucking packets from hither to yon, and TCP is a very elegant way to put some nicer controls on top of that so you can get your packets in an orderly fashion. Multiple routing protocols allows for nice evolution, survival of the fittest and all (note – no routing protocol specified in the standard!), and we have neat evolutionary extensions such as NAT (or PAT in Cisco parlance).
#5B) Bad: IPv6. The entire whole wide huge internet is built on IPv4, but we need a whole new protocol for the next generation. No migrations for us! Sigh. And how many bytes is an address now? That’s ridiculous. 40 bytes of header it looks like? I don’t like that. A TCP frame is probably 2 Megabytes once you’ve put it on this monstrousity. Feh.
#6) Good: SMTP. It has its faults, but SMTP is simple and clean and makes a lot of sense. You could easily do something better, having 20/20 hindsight, but it’s very good considering how old it is.
#7) Good: XML. Verbose, yes, misused often, yes, no binary support, yes, BUT, it’s a great way of representing arbitrarily complex data. Great for interchange – and that’s what it’s designed for. Tons of people use it for wrong things, and that’s stupid. But for being used for what it’s actually for, it fits the bill nicely. I even like extensions like Namespaces and such (though I have a few nits to pick with that one).
#8A) Good: REST. One URI, one resource. GET it, PUT it, DELETE it. POST to it if you need to.
#8B) Bad: SOAP. One URI, everything goes through that, look at the data to figure out what’s going on, represent all kinds of crazy crap in the data, way too much definition of what’s going on in there. Yuck.
#9) Adequate: Apache. It’s a decent webserver, performs pretty well, can do just about anything, but it’s big and bulky. But anything that’s faster is rarely worth the effort. So I give Apache an ‘adequate’.
#10) Good: PHP. As a language purist, PHP will make you want to vomit. But what I like about it is that it’s so blue-collar, working class, get-it-done language. Yes, there’s no namespace support, and no naming scheme, but you can get a hell of a lot done in a few lines of code, and if you’re not psycho, you’ll be able to read that code later on. And it runs fast. Security has been a historical concern for it, but they keep getting better and better with that – but let’s be honest, there have been several worms using PHP vulnerabilities. Yuck. But some of that might be the Popularity issue – it’s so popular, so write worms for it…
There are more – but they’re not interesting. Ethernet is good. Wifi is adequate (the WEP/WPA/whatever crap makes it not Good). Windows and Linux and Mac OS X are either adequate or inadequate depending on who you have administering them. There’s no more of ’em I can think of.
There, a sufficiently punditey-looking post. Enjoy.