Random Stuff

Curiosity was framed, Ignorance killed the cat.

[orclev-blog]

Why it's likely Windows 8 will suck

Microsoft is to OSes what Star Trek is to Movies?

Edit: I've had a lot of comments claiming I missed the 2000 and NT releases. I specifically excluded those from my list as they were targeted at business and professional users and not widely distributed to the general public. I've bolded the original statement to draw more attention to it.

So I've noticed a trend in Microsofts OS releases. The trend is very similar to that classic geek rule that every other Star Trek movie sucks. What I have seen is that, starting from about Windows 3.1x, every other Windows release has sucked (I'm also discounting the server and business releases). So, lets review:

Windows 3.1x (1992) - Good

Windows 95 (1995) - Mixed bag, at the beginning it sucked

Windows 98 (1998) - Good

Windows ME (2000) - Sucked (hard)

Windows XP (2001) - Good

Windows Vista (2006) - Sucked although not as hard as ME

Windows 7 (2009) - Good

Windows 8 (2012?) - ???

So, it seems fairly obvious that every other release of Windows has in fact sucked, but why has it sucked?

How did we end up in this situation?

To understand why Windows follows this pattern you've first got to understand what Windows brings to the market. Linux obviously brings customizability (for better or worse), and Mac OS brings a simple, consistent, managed experience for a price. But what does Windows bring? The answer unfortunately for Microsoft is, a large software catalog, and a largely average desktop experience. Windows 7 although a "good" OS, is ground breaking, exciting, or otherwise remarkable in exactly no way. Windows 7 is the bare minimum for a decent desktop experience (as judged by today's standards).

The only reason people continue to throw money at Microsoft is that they've got a huge momentum in terms of software. To that end, it's absolutely vital to Microsoft's continued success that any new releases of Windows must on the whole be backwards compatible with software written for previous versions of Windows. For Microsoft, a release of Windows that would only run new software specifically written for that OS would be a complete non-starter. The situation is even worse when you consider hardware.

So, what's Microsoft to do when they want to fix something deep in the guts of WIndows that will require a change to for instance part of their hardware API? If they make the change and roll it out in the next version of Windows it will break all the drivers written for the old API and people will be angry that their hardware doesn't work anymore (because even though some manufacturers will release updated drivers, not everyone will). If they don't change the interface the capabilities of the OS will continue to grow old and outdated and Windows will increasingly be overshadowed by the capabilities of the other OSes. Microsoft ends up stuck between a choice between keeping up with the latest developments in computers but pissing off their customers, or becoming increasingly obsolete and losing customers to the other OSes.

To further add to Microsoft's woes their development process isn't exactly the fastest one on the block and they tend to take much longer between releases than their competition. In other words they're always racing to catch up with the latest features of the competition, and when they do manage to score a coup their victory is short lived. Add to that the relative loss in revenue due to the infrequent releases and things look grim.

What's with all the suck?

All the "good" Windows releases can be considered the most up to date version of WIndows available at the time, they typically represent a fairly significant architectural change from the last "good" Windows release. The sucky WIndows releases on the other hand represent half way points in between the good releases, they typically incorporate pieces of both the old and new good releases. Because of the hybrid nature of these releases two things are common with them. First, a lot of hardware either flat out doesn't work, or else it's flaky and tends to cause BSODs or otherwise fail in strange and arcane ways. Secondly a lot of software will likewise fail in some fashion or other and in general will have a lot of problems. We've gone through this cycle enough times now that the pattern should be obvious. Windows ME was panned because the hardware compatability was poor and the software was flaky. Windows Vista was panned because the hardware compatability was poor and the software was flaky. Who wants to take bets that Windows 8 will be panned because the hardware compatability is poor and the software is flaky?

Why every other WIndows release sucks... on purpose!

For Microsoft however none of this matters, it's actually smart strategy. Some of you are probably scratching your head and wondering how releasing a crap product everyone will hate is a smart strategy. Well, it's simple, by releasing a pariah release of WIndows every other time Microsoft accomplishes three things. First they give the hardware vendors time to update drivers. Who cares if no hardware works on the sucky Windows releases just as long as it runs fine on the good ones. Secondly and similarly it gives software developers time to adjust to the new frameworks and interfaces and iron all the bugs out of their software. Once again, who cares if your app is flaky in the sucky WIndows version, so long as it actually is stable and works in the good ones. Lastly, and most importantly for Microsoft, they can release parts of their unfinished good version of WIndows as a stop gap measure to not only bring in some much needed revenue, but also to demonstrate that they're keeping up with, and in some cases surpassing the competition in terms of features.

Sure people will be a little angry at Microsoft for selling them a broken version of WIndows, what is in essence an Alpha or Beta release, but in the long run it doesn't matter because nobody really remembers the bad versions, and it makes them all the more excited for the good ones. The way it usually pans out is, you either install the old good version and completely ignore the new bad one in which case if you're buying new hardware you need to purchase an extra copy of the old version of Windows (Microsoft wins), or you get the new bad version and suffer through it chomping at the bit the entire time to purchase and upgrade to the new good version (Microsoft wins).

My prediction

So, based on the history we've seen, I'm making two predictions:

Windows 8 is going to suck.

We'll see Windows 9 (or whatever they're going to call it) released sometime in the next 3 years and it will fix nearly every problem in Windows 8.

[orclev-blog]

On readability

This post is a reply to another blog post which is itself a response to comments on a previous post by the same person. If you haven't read it yet, you should check out the above link.

Done? OK, so, if you haven't spotted what's wrong with that post I'll break it down and provide some examples here.

First, lets do an Apples to Oranges comparison like he did in that article.

Here's a trie implementation in Haskell:

And now here's a TST implementation in Python:

Wow. Stand back from the monitor and squint at them :)

OK, enough of being a dick. So much like the William's article what I've done here is compared a basic trie implementation with a ternary search tree. Technically they're both trie's, one's just a bit more complicated than another. Ultimately it's a performance optimization, or at least it attempts to be, and like nearly every performance optimization it hurts readability to a certain extent.

Now, here's a fairer comparison, this is my Haskell trie versus the original python trie, first the python:

and now the Haskell version again:

So, as I had commented previously on William's blog, you can write readable and unreadable code in just about any language out there. Some languages make it harder on you, some make it easier, but if you're determined and/or lazy enough, it's possible in just about anything. It also has a lot to do with what you're familiar with. I can just about guarantee that for the people coming from a OO and procedural background those foldr, liftM, and F.toList references in my code are what's going to trip you up. However, for someone from a functional background they make perfect sense and the code is highly readable. Unfortunately the opposite problem hardly ever crops up so it's nearly impossible to do a fair comparison as most people start out with procedural and OO code, and then move into functional.

What I can say, is that I can explain foldr in one sentence in a way that should make it understandable to just about everyone.

foldr takes a function, some kind of collection type object, and a starting value, and then iterates through the collection object applying the supplied function to sum up a single result.

One of the interesting properties of foldr (and any of the fold family of functions) is that even though it produces "a single result" nothing prevents that result from actually being another different kind of collection, so folds can be used to convert from one type of container to another, which is exactly what those F.toList calls are doing (they convert the trie into a list of suffixes).

But I digress, back to the topic of readability.

So, part of judging the "readability" of a piece of code requires that you actually be familiar with the general features of a language (the basic syntax) as well as the design patterns used in the code (the term design patterns is used loosly here). Now, due to the nature of programming languages, you can often read a language who's syntax you know nothing about, if you know the syntax of a similar language, much as someone who knows Spanish for instance can for the most part muddle through reading French. However, just because someone who knows Spanish can mostly understand French, that doesn't mean that French is more "readable" than say German, English, or Japanese. Likewise just because being familiar with a similarly styled OO language like Java or VB.Net will probably allow you to muddle through most of the above Python doesn't automatically make Python more readable.

In William's post, he cites a few key factors that he believes are keys to the readability of python. The first of those is the use of significant whitespace, specifically indenting. Ironically enough, Haskell also uses significant whitespace, possibly even the exact same formatting rules, although I'd have to check the python docs to be sure. Personally I wouldn't say significant whitespace improves readability, although it does strongly encourage some kind of standard indenting policy which can help.

The second factor he mentions is that python is concise. It is indeed fairly concise, but I wouldn't say significantly more than Haskell is.

The third factor mentioned is that python uses keywords and not "symbols". This one is largely argueable, after all, "=", "@", ".", "__" and ":" are all symbols and with the exception of "@" used quite heavily in python. ":" in particular is sprinkled all over the code as is the "." operator. It is true that Haskell has a tendency to introduce new operators to support the myriad combinator libraries available, including a few that are rather integral to the base language such as Monad. However, in Haskell an operator is just a binary function, so really not that different from any other function, it doesn't matter if it's called "bind" or ">>=", it's the same function. There's also an argument to be made that operators improve readability, otherwise we'd have long ago abandoned infix notation in math and use RPN everywhere, yet no one is scrambling to abandon "1 + 1 * 2" in favor of "* 1 2 + 1". Further the ability to use any function infix in Haskell can also improve readbility as in:

"example" `notElem` ["This", "is", "an", "example"]

It's also worth pointing out that, aside from the arrows (->), the list constructor (:), the concatination operator (++), and the type signatures which are mostly optional, the Haskell code in his article doesn't really have "symbols" in it, certainly not significantly more than the Python code.