If you are a java user and don’t want to read it all, the take-away lesson is simple: You should be using java.text.Collator which is better than Collections.sort(list, String.CASE_INSENSITIVE_ORDER) which is better than just calling toLowerCase() on everything.

To explain why string comparison is so much more nuanced, we’ll visit three interesting locales, each throwing a unique wrench in the works.

Example 1: The Eszett character

In german, a certain ligature for two consecutive s characters has been used so much for so long it’s considered its own unique character. The Eszett or Scharfes s: ß. It shows up all over the place in german, for example in the word street, which is straße in german. The Eszett is somewhat unique in that it has no capital form. Words don’t start with double s so there has never been a reason to capitalize it. Instead, if you ask a german to write street in all caps, they’d write STRASSE.

Uhoh. That’s not a reversible operation! The lowercase form of STRASSE is strasse, and even knowing that the locale is german, you can’t just guess that double-s ALWAYS becomes the ß character. You’d need a dictionary. Arguably you’re better off doing that conversion than not doing it if you know its german (more likely), but it won’t be a sure thing. Nevertheless, trying to check if straße and STRASSE are two equal strings under case insensitive comparison should return true, and not false, but while that’s in the cards, using .toLowerCase() as a proxy for case insensitive comparison is never going to get us that.

Java actually gets this right, sort of. trying to uppercase straße will in fact produce STRASSE even when just using .toUpperCase(), you don’t have to specify Locale.GERMANY. You can experiment by using \u00DF which is the (lowercase) Eszett. There is such a thing as a capital Eszett in unicode, which nobody in germany uses and is clearly a silly idea: You don’t hack a living, breathing language to get around i18n problems. If that’s feasible we might as well tell the world to stop whining and only use english when using machines.

Here’s the problem: String.CASE_INSENSITIVE_ORDER does not in fact return ’0′ (indicating equality) when comparing straße and STRASSE, even though every single language that uses the ß (german. That’s it!) says those two are case-insensitive equal. Nevertheless, that does not excuse the brokenness of the ‘toLowerCase() is an alternative for case insensitive comparison’ meme.

NB: My thanks go to dpark who spotted a problem in an earlier version of this post where I erroneously reported java did in fact use the invented uppercase variant.

Example 2: The turkish dotless/dotted i, and the somewhat famous PHP breaks on turkish computers problem

The ß vs. SS issue indicates that toLowerCase() isn’t a valid replacement for case insensitive comparison, but it gets worse. You can’t, in fact, say anything whatsoever about casing, or case insensitive equality, without knowing the locale you’re operating in. In turkish there’s not one ‘i’ but two: The dotted i and the dotless i. Where this gets crazy is the capital forms of those. The capital form of ‘i’ is a dotted capital I, and the capital form of dotless ‘i’ is our normal, familiar capital I, which doesn’t have a dot in it. This even messes with kerning (fi is a common kerning where the tip of the curvey top of the f is joined with the i’s dot. That’s not appropriate in turkish, where that dot is important). This means “i” and “I” are not equal in case-insensitive comparison in the Turkish locale. toLowerCase() comparison gets this wrong, of course. toLowerCase(new Locale("TR")) would actually get this right. String.CASE_INSENSITIVE_ORDER gets this wrong, because you can’t give it a locale. For natural language comparison (and why are you upper/ lowering strings in the first place, if not because youre doing natural language comparison?), tLC(), tUC(), String.CASE_INSENSITIVE_ORDER – are all inherently broken. Java gets this a little right and offers Locale-based variants of tLC() and tUC(), as I hinted at earlier.

That PHP we always like to bash on? One of the things PHP does (or perhaps did, I don’t keep up with it) wrong for the longest of times was that it would completely lose its marbles if the system’s locale was set to turkish. It would just fail to work. PHP identifiers are defined as case insensitive, and PHP implemented this by toLowerCase()ing everything, using the platform default encoding. This turns “FILE” into “fıle” which is not equal to “file”, and thus running most PHP code on a machine configured with turkish locale breaks, if the PHP is in english. This is a famous example of the universally lamented “it works for me” attitude. So, yes, making this mistake has dire consequences.

Example 3: Ascii hacks

To make matters worse still, lets think about why one would want to do a case insensitive comparison in the first place. Presumably because there’s some user input of some sort that needs to be compared, and you don’t want to bother the user with case sensitivity. However, if thats the aim, “case insensitive” is entirely the wrong idea. There are a bajillion systems around that can’t deal with unicode. For example, if many ‘name’ forms don’t even accept a dash in your last name, how many do you think accept a “ü” in it? And yet plenty of german folks are called “Müller”. The ‘fix’ these poor saps have used for years and years is to write the canonical ascii alternative for their funky character. ß becomes ss, ü because ue, etcetera. I’m betting that if you intend for “JOE” and “joe” to be equal, then you should consider “müller” and “mueller” equal too.

Whats really needed is a human inputted string comparator. Optimally speaking such a tool will first canonicalize each string, turning for example dotless i of any capitalization into a dotted lowercase i, turns ß into ss, ü into ue, etcetera, and only then compare the strings. I’m not even sure this can be done properly without knowing a locale, but you could do a lot better than String.CASE_INSENSITIVE_ORDER that way, and far better still versus comparing the .toLowerCase() versions of any two given strings. Java does in fact have something for this: java.text.Collator. This indeed does more or less what I just described, and it is in fact what one ought to be using. If I were you, I’d make a pmd plugin right now that checks for usage of locale-less tLC and tUC, as well as String.CASE_INSENSITIVE_ORDER, and flag them all as warnings.

Bonus Example: Lower case. Upper case. And Title case??

Astute folks may have observed that Character.toTitleCase() exists in the java standard library.

What’s that you ask? Well, in some languages, there are single characters that look like 2 characters. For example the ‘dz’. That’s one character in some languages. This is very similar to the germans who have enshrined the much used ß ligature into a unique character. However, unlike the ß which has pretty much lost all resemblance to the original character, and which can never appear at the beginning of a word, these characters are mostly just a kerned version of the original, and CAN appear at the beginning of the word. In unicode speak these are called digraphs. These have 3 and not 2 capitalization forms: all lowercase, all uppercase, and the first part of the digraph uppercased, the second part lowercased. This is what you’d use when you want a word with just the first letter capitalized, and you use the all-caps version only if you need an all-caps rendering of the word (i.e. rarely). This obscure little factoid actually was useful for me when writing lombok: The method that turns “foo” into “getFoo” will use toTitleCase() and not toUpperCase().

And there ends our trip round the world. I hope you enjoyed it. Though now you know: That feeling of despair when someone mentions i18n? You’re entirely correct in feeling it. It’s a pain in the tusch!

Het is algemeen bekend dat een (meerderheids)coalitie erg moeilijk gaat worden na de volgende verkiezingen, maar terwijl ik vandaar zat te denken aan hoe een minderheidscoalitie er dan uit moet zien kwam ik tot de conclusie dat zelfs een minderheids coalitie vrijwel onmogelijk is! Ik loop door wat opties. Ik houdt me hier aan de polls van De Hond met wat gezond verstand erbij (to wit: Gekeken naar de crash van het CDA in de Gemeenteraads verkiezingen gaat die zeker niet beter uitkomen in de polls dan hun nu al magere positie, PvdA is een beetje een wildcard door de recente gebeurtenissen, en Wilders is ook wel een wildcard want is moeilijk te pollen: Velen zullen niet durven uitkomen dat ze Wilders stemmen, maar anderen ‘stemden’ tot nu toe bij de polls voor Wilders meer als buikgevoel/tegenstem en gaan dat niet daadwerkelijk doen na bezinning).

Peilingsdata is hier beschikbaar: http://www.peil.nl/?2891

Meerderheidscoalities.

MegaRechts: VVD, CDA, PVV, TON.

Deze mix kan in feite wel door een deur. De grootste vraag voor een leek zou kunnen zijn: Wil de CDA dit wel? Maar die hebben uiteindelijk toch vrij duidelijk getoond dat ze geen grote problemen zien om samen met Wilders te regeren. Dat VVD, TON, en PVV goed samen kunnen werken lijkt me duidelijk. Het probleem is echter dat ik niet verwacht dat dit setje de 76 zetels haalt; in de polls staat deze groep op 71. Het CDA en TON gaan hier zeker niet een hoger nummer van maken, dus zou Wilders + VVD 5 zetels meer moeten krijgen dan in de polls. Dat lijkt me een brug te ver.

MegaRechts2: VVD, CDA, PVV, CU (en TON).

Deze mix zal de 76 wel halen, maar het CU en de PVV gaat niet echt samen. Verder is het CU in een soortement van machtsstrijd verzonken met de CDA om de christelijke stem, en zal het CU ook wel weten dat ze door de kiezers uitgekotst gaan worden als zij het mogelijk maken dat de zwaar op verlies staande CDA en Wilders aan de macht gaan komen. Half nederland kan die coalitie niet uitstaan, en de andere helft gelooft er zo hard in dat die stemmen allemaal naar PVV en CDA gaan volgende electie. Ik verwacht dus dat de CU gewoon gaat bedanken voor dit idee.

Paars+: Groen Links, PvdA, D66, VVD.

Deze mix haalt de 76 misschien niet en dan zou de CU er ook nog bij moeten. Ik zie niet helemaal hoe Groen Links en de VVD in een coalitie moeten gaan komen. Verder smakt dit toch redelijk naar Paars, waar ik totaal geen probleem mee had, maar zal na fortuijn’s crusade tegen Paars toch een wrange nasmaak aan zitten.

MegaLinks: SP, Groen Links, PvdA, D66

Dit gaat de 76 niet halen. Zal dus de CU bij moeten, en uberhaupt heb je dan wel een grote verliezer (PvdA) en een hele grote verliezer (SP) in de coalitie. Ook is de overlap in standpunten van bijvoorbeeld SP en PvdA niet zo groot, en als de CU er ook nog bij moet dan zie ik dit ook niet gebeuren.

Centrum: CDA, D66, VVD, PvdA

Niet helemaal ondenkbaar, maar wel raar dat de huidige regering (CDA+PvdA) die zo ontiegelijk afgestraft gaat worden opnieuw gaat regeren. Ik zou dan verwachten dat D66 en VVD het voortouw gaan nemen en dat Pechtold of Rutten de MP gaat leveren. Ook vind ik persoonlijk dat de standpunten van het CDA en D66 eigenlijk niet echt samen kan, maar desondanks wordt VVD+CDA+D66 hier en daar ge-opperd (maar haalt het niet) dus als dat kan waarom dit niet? Als duidelijk wordt dat minderheids coalities niet gaan werken (zie onder) dan zal dit toch meerdere malen genoemd worden als oplossing, verwacht ik. Maar wil de CDA, die toch redelijk anti-liberaal is, in een coalitie met D66 EN VVD (is CDA/D66/VVD ooit gebeurd vroeger?), zeker aangezien Rutte en/of Pechtold, om de smaak van een herhaling van balkenende IV weg te halen, de MP gaat worden?

Minderheidscoalities.

De minderheidscoalities hebben het probleem dat ze altijd een extra partij mee moeten krijgen, en dus kunnen ze niet te controversieel zijn. Dat is het probleem, kijk maar:

MegaRechts: VVD, PVV, CDA (, TON).

Als minderheidscoalitie gaat dit nooit werken; ik verwacht dat de rest van de kamer het gewoon niet zal toestaan en op alles principieel nee stemt. Tussen Wilders en het CDA is er meer dan genoeg politieke reden om je zo op te stellen en ik verwacht minimaal dat D66, SP, Groen Links, PvdD en D66 dit ook zullen doen. Dan zal de druk op de CU en de SGP zo groot zijn dat ze zelf ook niet over willen komen als lamme schapen die achter deze controversiele coalitie lopen en dat gaat dus niet werken. Hetzelfde geldt voor een andere minderheidscoalitie met Wilders er in. Het lijkt me duidelijk dat als Wilders wil regeren het alleen kan in de vorm van een meerderheidscoalitie, en zoals boven getoond wordt dat lastig.

Paars: PvdA, VVD, D66.

Ik denk dat vooral D66 graag wil regeren, desnoods in een minderheidscoalitie, maar of de PvdA die nu toch al in recovery mode is geraakt dit aandurft vraag ik me af. Het is ook puur Paars dus verwacht ik dat er veel backwash zal zijn (met stemmen die veelal naar Wilders zullen gaan, ook) niet zozeer omdat zo’n kabinet rare dingen gaat doen maar omdat het volk nou eenmaal denkt dat Paars zuigt. Als de PvdA top denkt zoals ik gaan ze hier nooit aan beginnen. Desondanks is deze combo de meest denkbare momenteel, denk ik.

Links: PvdA, D66, Groen Links.

Een minderheidscoalitie hoeft geen 76 zetels te halen, maar iets in die buurt is wel handig natuurlijk, en dit setje haalt maar de 56. Dat betekent ten eerste dat het een schaarse representatie wordt voor de ministersposten, en ten tweede dat ze bijvoorbeeld aan het overtuigen van de SP niet genoeg hebben en dat wordt dus erg zwaar regeren. Desondanks kan het wel; op liberaal gebied is er geen enkel probleem en komen ze makkelijk aan 76 stemmen voor. Op economisch probleem zullen ze of SP+CU of CDA mee moeten krijgen, want ik verwacht niet dat deze coalitie met ideeën op economisch vlak komt waar de VVD op voor gaat stemmen. (Ik ga er even vanuit dat de CDA zich recalcitrant en onwerkbaar op gaat stellen, omdat die partij momenteel nogal in de war ligt). Met de grote winst voor ‘rechts’ wilders denk ik ook dat een grote groep nederlanders zeer luidkeels gaat protesteren tegen dit idee wat er voor gaat zorgen dat het onmogelijk wordt gemaakt voor deze coalitie om de extra stemmen te krijgen en gaat het dus niet werken.

I know the sales pitch for the Apple iPad to be a third device, but I think that’s just shortsighted. What would your average family really need to do that the iPad cannot do? Play intricate games? Well, don’t discount the iPad’s hardware, but evenso the usual solution to that is to buy a games console and not a PC. Program? Well, yeah, but that is by itself not going to convince an average family to keep a PC around unless they’re already into programming. Work long hours? Not sure if a family really needs to consider that, but one can argue the keyboard dock will do the trick. Sure, it sucks for posture, but if many of my friends slave away for many hours behind a notebook and don’t bother to invest in a docking station, clearly that’s not a big concern.

Computers are complicated. Really, really, really complicated. Mac OS X is really no exception to this; it is perhaps the lesser evil amongst the 3 major OSes, but my parents, for example, still can’t make heads or tails of it. An iPhone, though, that’s easy. Even for technophobes and digital illiterates. I foresee the iPad being used as a replacement PC. it’s far more convenient, it’s cheaper, and if the reviews are to be believed, browsing the web (95% of what family computers need to do, these days) is actually nicer on it.

But therein lies a problem. Game consoles are already closed NDA-protected fiefdoms, and the iPad is no different.

Without exaggerating, can you explain succintly why this is so bad?

No problem. It boils down to two very simple problems:

• You can’t just get the SDK. You need a mac, you need $99, and you need to be 18 years old to sign that NDA. I don’t know about you folks, but I made my first tentative steps into the world of programming when I was less than half that age.

• There’s no nice learning environment. Something like The LOGO programming language isn’t available in the SDK. That’s not the direct problem – the direct problem is that it isn’t possible to remedy this in a way that doesn’t involve getting some facetime with Mr. Jobs and convincing him it’s necessary. You can’t make LOGO for the iPad; appstore programs can’t run other programs. You can’t make LOGO for another platform either – only the official SDK can produce a distributable that can be loaded onto an iPhone / iPad / iPod.

Shortsighted?

I’d say its a bit short-sighted to not presume the iPad could be such a success, and/or not considering that a lot of excellent programmers got started just tinkering about. I certainly didn’t just say one day: I know! I’ll become a programmer! – that’s not generally how it goes. I can also imagine an awesome development environment to draw creative talent all around the world into the world of programming – something graphics and ‘oooh!’ factor heavy, with modules that can be represented as little puzzle blocks, that you can easily stick together by making gestures, for example doing the zoom gesture to investigate the source. Sadly, you can’t build such a fantastic idea, because you’d run afoul of the needlessly strict rules for app store apps.

Addendums

Technically you can attempt to introduce programming via websites. Mozilla Bespin shows that there’s some merit to this idea, but reading out the camera in HTML5 is very far off indeed. Programming is also one of these things where internet latency can be a real issue. Nevertheless, bespin is a very cool project, and I hope it may perhaps fill this gap.

I agree to the maxim, but I never really liked the solution. Helper methods are awkward; where do you put them in the source file? They should obviously ‘go with’ the method they are a helper for, but in many code houses (including for example google), you’re supposed to sort your methods in a specific order, so you’d have to prefix all your helper names with the original method name. Thus, something like:

 public void enormousMethod() {
     enormousMethod_doStep1();
     enormousMethod_doStep2();
 }

 private void enormousMethod_doStep1() {
     ...
 }

 private void enormousMethod_doStep2() {
     ...
 }

Doable, but annoying. The more serious problem is that you have to pass in variables for all state from the main method that you need, and you have to return everything that you mutate or produce in the helper method. If you mutate/produce more than 1 result, then you need to return a tuple of some sort, which is unwieldy. You also have to refactor, which IDEs can help you with, but only to an extent.

I’ve found a solution which I think is superior. We’re going to use a little known java feature: Scope blocks – you can just start a block in java, anywhere. All variables declared inside the block are no longer valid when the scope ends, just like when you use them as the block associated with a while, if, or for construct. Thus, we can have ‘methods in methods’ so to speak:

public void enormousMethod() {
    /* Explanation of what step 1 is for */ {
        ...
    }

    /* Explanation of what step 2 is for */ {
        ...
    }
}

It’s not a panacea; sometimes a helper method is the better choice. For example, you cannot just break out of a scope block, whereas with a helper method, you can (You return from the method). However, you nicely separate your behemoth method into mostly self-contained blocks that can have their own local variable names, and you have absolutely no problem sharing state in between them where that makes sense. Thus, they can all increase a counter for example.

Another more drastic trick you can do in java is to create a method local class, with state stored in that method local’s fields. If in another language you would have used an actual method-in-a-method, then that’s the nearest simile java has to offer. It’s a bit unwieldy in syntax, but in rare cases it ends up being the cleanest solution.

Earlier, someone contributed XFN support for it. And, for lombok, we’ve recently received patches for netbeans and JDK7 support. The current lombok ‘hailbunny’ beta is out with netbeans support thanks to these patches (Jan Lahoda: You rock!). You can download the beta here.

Could be a coincidence, but this is the first time that the make it open source and people send you patches theory is starting to work out, and as a developer, that kind of feedback is just awesome.

So, if you are a user of an open source project and you find a bug or think of a nice feature, implement it, send a patch, and odds are you’ll get the eternal gratitude of the developer, and you’ll likely see your patch integrated into the main release.

Patches rock!

Notes from his presentation at devoxx, 17:40-18:40 Central European Time, November 19th, 2009.

Section 1: Problems and Solutions

(why jigsaw, what is it trying to solve? Subtext: What is it trying to solve that OSGi can’t?)

jigsaw exists because they want to have modules-all-the-way-down. OSGi depends on java classes, but how can you then modularize the core java classes like java.util.List or even java.lang.String with OSGi? So, the module system needs to be done in the JVM core. OSGi comes with baggage such as lifecycle management that isn’t needed for slicing rt.jar into modules.

Secondly, jar files are a fine distro tool, but a crappy runtime tool, so a new package processing system is required. If everyone versions, then we can go back to the model of installing ‘jars’ (whatever they will be) into the system, without running into version conflicts anymore. By changing the format between running and distro, java can verify at install time, do some ahead-of-time compilation, and store JIT profiles straight into the local module base for future executions of the JVM. This is not something OSGi does (or even should do). Also, class files are great for distribution, but they aren’t that great for efficient loading. The java core libraries are what they are. They can’t be changed now. And yet, e.g. java.io.FileInputStream has a method to get a java.nio.FileChannel. If java.io and java.nio are to be different packages, and you don’t want io to be dependent on nio, then what?

Even worse, some non-util packages contribute a class or two to java.util. OSGi is very much anti split packages. If java were to be designed from scratch with modularization in mind, that might be okay, but java wasn’t. Thus, split packages, in-package optional dependencies are all fairly complicated requirements that are needed for slicing rt.jar into modules.

Big point he keeps making: He looked at OSGi to slice rt.jar, decided it just wasn’t going to work, so came up with a new module system that is mostly not intersecting with OSGi’s bailiwick. And then he decided that, as java code itself will have to have the capability of stating that it doesn’t, for example, need swing, or nio, or corba (heh), it makes sense to allow other people to make modules in this as well. Hence, jigsaw.

Section 2: Jigsaw – technical details

Part A: Grouping

A module system needs to group classes and other resources in a single module.

jigsaw solution: module-info.java file, at the top of the relevant source tree (so at ~/module.info if your class is at ~/com/foo/Whatever.class)

Flipside of coin: Need ability to state dependency, better than import foo;

example:

module com.foo {
    requires org.bar.lib;
    requires edu.baz.util;
}

and with versions:

module com.foo @ 1.0.0 {
    requires org.bar.lib @ 2.1-alpha;
    requires edu.baz.util @ 5.2_11;
}

Version syntax is now chosen to be non-descriptive at all. Anything goes. Just like apt-get. Awareness of the need to then look up versioning scheme per module, and there WILL be syntaxes like 2.(1+). Preferable to OSGi forced versioning system. Tokenizes on a limited number of characters (dots and dashes, pretty much), and each subsequence can be matched against with wildcards. It seems to work well for debian, and for rpm (their their algo is slightly different), hence confidence this will be fine, and should make for much easier adoption amongst existing projects, such as Oracle v1.9.12.0.0.0.0.0.0.0.0.0.2 (red: I’m channeling Joe here, not Mark)

As there is to be interop between e.g. rpm and debian, anything more rigid will also not translate very well (e.g. a complex wildcard just couldn’t be translated to a deb file!) requires by default flows through to dependents. So if A requires B, and C requires B, then C has access to A’s stuff. Get around via requires private.

You can also get around this FROM A:

module com.foo.secret {
    permits com.foo.lib;
}

means that only com.foo.lib can requires it, and can’t export it (forced to say private, or compiler error).

Optional dependencies: requires optional

Of course, your code will need to deal with the ClassNotFoundErrors and such that could result.

virtual modules: Like apt-get’s virtual java package. It’s a bit like a module interface concept, though it’s just a name, there’s no structure in a virtual module. So:

module com.foo.lib {
}

module com.foo.lib.impl.phone {
    provides com.foo.lib;
}

If another module then wants com.foo.lib, it’ll get com.foo.lib.impl.phone.

Part B: Interop with other packaging systems, and module distribution.

You can for example create a debian package (For apt-get, so you can install on ubuntu, debian, etc):

jpkg - m classes deb com.foo.app com.foo.lib

creates a .deb file for apt-get from the modules com.foo.app and com.foo.lib. All dependencies are reflected into the debian package, so if com.foo.app requires foo.bar.baz, this is reflected in the apt file’s Requires block.

For windows, with no such package manager, or in any java-centric environment, or even on phones with a stripped-down linux without rpm or apt-get, you just stick with java’s own. There will be a platform independent transfer format (basically v2.0 of jar files. Won’t be zip on the inside, will be opaque so the format can be revved by sun over time, but it’s mostly the same concept). It will have a new file extension.

Part C: Slicing the JDK.

Here’s a chart of dependencies per package in java core library:

Here’s what base is dependent on in JDK6 (so, almost everything):

Here’s what it looks like now in an experimental JDK7. with base dependent on very little, and nearly acyclic:

And even simpler with optional deps removed (this photo you should be able to read):

JIGSAW BINARIES will go live in a few minutes after this talk!

http://openjdk.java.net/projects/jigsaw

http://dl.openjdk.java.net/jigsaw

only binaries for unbuntu jaunty, but you can always build from source (that’s just because Mark is an ubuntu user). It’s all very raw, but it includes the packaging tools, as well as support for module-info.java and the like.

Part D: OSGi interop.

(Not mentioned in main presentation, but someone asked).

Status unknown, but it’s something they’ll look at. Realization that compatibility is rather difficult due to different requirements, such as split-packages. Realization that having 2 competing module formats, forcing lib devvers to make 2 versions. Something Mark is looking at is extending jigsaw libraries to just wrap around an OSGi library. That way, you can choose to just make an OSGi library and ship that.

NB: There’s a BOF coming up on this at 20:00 Central European about the Modular Java Platform and Jigsaw with Mark, so this isn’t the last word.

NB2: Slicing rt.jar is well on its way, but not quite done yet. Still dependencies exist that will be eliminated before JDK7 RC. Also, so far, no measurable performance benefits (yet). However, new installed-module stuff (ahead-of-time implementation, second version of class file format optimized for reading, jit profiles) aren’t live yet, and should bring significant performance benefits.

The theory then goes: Even if the odds that the earth is actually doomed unless we make some drastic changes is very low – then the above table should make it obvious that anything above 0% is more than enough reason to get drastic and do get started right now. After all, multiplying the odds will always get you to -infinity if the world decides to keep going as we are.

This argument is often touted by crackpots. See Exhibit A. That’s okay – it takes all sorts to make a world. However, I get personally miffed when otherwise very smart people fall for this logical fallacy. I get even more miffed when they somehow proudly proclaim how they repurposed Pascal’s Wager. Pascal’s Wager is itself a fairly obvious fallacy. Normally, smart people are supposed to be able to add two and two together. Maybe that M. Night Shyamalan movie was on the something and tree hugging makes your brains fall out of your ears. I don’t know what it is.

Thus, a public service for all those who experience temporary bouts of idiocy when it comes to the environment. It happens to all of us, don’t feel bad.

I’ll fix that table for you, should make it obvious why you should stop talking about Pascal already:

If you think that particular doom scenario is preposterous, I will posit that earth being utterly doomed when we don’t fix up the environment is similarly preposterous. There are also lots and lots of other doom scenarios: A killer virus, aliens, global thermonuclear war, a world-wide revolt due to male overpopulation and religious fanaticism due to continued poverty, corruption, and civil war in the third world – pick your poison. You’ll find plenty of theories about how the earth could end if we aren’t careful.

So, we should fix all of that right?

Right. Except earth is a place of finite resource. Human creativity is still a finite resource. We can’t focus on all of that equally. We have to make choices.

And this is where I, and other sane and right thinking individuals like Bjorn Lomborg – who is one of the few true environmentalists I know of, stand: The only way to get out of this dilemma is to create win-win scenarios. Running around like a headless chicken screaming bloody murder about the environment, using cockamamie theories like the Environmentalist’s Pascal’s Wager, the more we’re going to really risk ending up doomed. There are so many things we could do that would actually save the environment, and be a net positive effect on mankind economically and scientifically, but virtually none of it gets done. Instead we spend all our time lobbying for people to become just as treehugger crazy and for utterly ineffective corn ethanol. D’oh.

There’s also a long-standing tradition in certain more fanatical environmentalist groups to be completely unreasonable, and make downright retarded decisions. Every hip american buying a Prius is one fine example: Considering the trade-in value is so worthless that most of them hit the scrapyards inside of 15 years (those batteries just don’t last all that long), you should probably just buy a Hummer. Mother Earth would be more grateful. Inane FUD spreading of nuclear power plants is another one: It’s a very tough choice, but France has been doing just fine with it so far. If the french can make nuclear safe enough, then what the heck is everybody whining about? We should at least take it a bit more seriously.

Apple is being torched almost daily for not being green enough. This is the company that make the notebook computer as the only computer you own popular. The amount of power and material saved is enormous. Green peace and company should grovel at Steve Jobs’ knees and thank him for the good he’s done. Of every soul I meet that proclaims they are an environmentalist, 99% of them are short sighted bags of hot air. It annoys me so.

The latest fine example of environmentalists being absolute idiots is 2 google searches generate 7 grams of co2.

Riiiight – and driving to the library and spending 5 hours looking it up there is much better for the environment. How short-sighted can you get? Google, and the internet in general, is the best most scalable thing that has ever happened to the environment.

I’m not a global warming denialist. I strongly feel that we, as mankind, ought to be doing more. I just get annoyed when otherwise smart people turn into blithering idiots, is all. Please, for the sake of this planet – use some common sense. I thank you.

An accelerometer is a device that lets an object know which way up it is. That’s just what the RIM corporation itself seems to need, for it is clear that with the release of this dog they don’t know their tits from their tibias.

And his isn’t the only brutal review of the storm around. It seems to be universally panned to the point of hate.

It’s RIM’s attempt to build an iPhone. It even includes one actual honest attempt to innovate: Its touchscreen clicks down physically like apple’s new macbook trackpads. They screwed it up royally, but that’s sort of the point: These dinosaurs of the old age tend to run themselves full tilt into a wall when faced with revolutionary competitors. When you’re the market leader, you don’t make a product that is way more immature than the new competition. Everyone that values stability and patience, the one market you get for free, goes running to your competitor. What could possibly possess RIM to screw up so gigantically?

Palm self destructed spectacularly when it faced some marginal competition, but the handheld device market isn’t the only industry that has kindly committed seppuku to let the new blood run rampant. Microsoft is finally getting some actual pushback on many fronts and in response they hand over the keys to the kingdom to Steve ‘chairsbane monkeydance’ the marketer. A marketer? Microsoft? Bill Gates would turn in his grave… is what we would have said if he wasn’t the guy that made that happen. Is self-destructing microsoft part of his new humanitarian efforts? Microsoft’s recent OS release, utterly ignorant of a new world filled with notebooks, netbooks, and mobile phones, all of which want slick kernels that know how to conserve power, is such a fantastic dud that it defies comprehension. That took 7 years?

Piracy became a somewhat serious problem when it became easy and pedestrian. Before napster, a dedicated individual could pay 5 bucks a month for newsgroup access and download -whatever- he could possibly want as fast as his pipe can carry it. But you need some serious technical knowhow. Napster and its children, and even bittorrent, via sites like the pirate bay, make fast transfer easy for everybody. -THAT- scares the pants off of the RIAA and the MPAA. How do they respond? By making the piracy easier than the real thing by charging prohibitive prices for legal online downloads, getting stuck in a new format war, and adding unskippable piracy warnings in front of every movie. The only way I can make sense of this move is if the MPAA is kindly downing the family size bottle of sleeping pills in order to make way for a new digital distribution age.

How about the car industry? “Bailout”. Nuff said. The sheer insanity of the leaders of the big three in the US has already been covered far better in numerous other places.

What in the world possesses these companies to self destruct so quickly when faced with something they do not understand?

One thing I do know: Without the convenient propensity of the big hulking elephants in the industry to shoot themselves in the face, the world wouldn’t be moving forward nearly as quickly. Thank you, dinosaurs. Thank you very much.

Herein lies at least some vindication for Sun’s ‘backwards compatibility trumps everything’ mode of thought regarding java releases. You must be backwards compatible.

What intrigues me some is that this python3k release could have been done so much nicer, and it wouldn’t have been too difficult:

Start with a ‘version’ indicator in the source. Something like ‘python 3′ right at the top of the file (it would be legal nowhere else, to avoid having to declare a real new keyword). This then gives the interpreter the opportunity to parse the file differently, depending on version. Lack of version indicator means its assumed to be python 2.6 (the last pre-3 release).

Now, some py3k changes may not be easily solvable even if the interpreter knows what the code was written for. But the simple stuff, such as py3k ‘range’ being the same as py2k’s ‘xrange’, and py3k no longer having an xrange function at all, could easily be handled by a backwards compatible py3k interpreter. With some effort I bet you could build a py3k that is 100% backwards compatible in this fashion. Python is a dynamic language with duck typing, which makes this proposal quite a bit easier compared to a language that uses nominal typing, such as java. So why hasn’t python taken this option?

I have no idea.

That’s not all she wrote though: I am still waiting for a language that offers infinite smooth upgrade ability for its own language, its own core libraries, and for any third party library that chooses to offer it. I’ve tried to work this out and its not exactly simple to build such a programming language, but it can be done: Each library that wants to offer backwards compatibility can break its API and offer adapters that essentially build a ‘view’ that acts like the older API. This way code expecting the old API can work with code that expected the newer API without breaking it. A few languages / loaders offer the ability to load whatever version a program expected, but those tools simply don’t work if one module of a program expects v2, and the other expects v3. That’s why you need views, so that the actual library itself can always be at the latest version. Also should be great for security updates: You now never need to update multiple versions. Just update the latest version and make sure the adapters work well.

Maybe Seth Godin is slipping a little, but Seth Godin’s simple missive: Make a customer happy when he calls. Otherwise, do not answer the phone! – is very much true.

Before I called, I was mildly annoyed that philips hardware can’t work with philips hardware. After I called, I was seething mad at their boundless idiocy.

After half an hour getting the runaround, the conclusion was that the Philips TV and the Philips satellite receiver aren’t compatible. It was my fault for not realizing it, according to Philips, because ‘STB’ stands for Set Top Box, and not Satellite Box. This was a fairly basic mistake so they wouldn’t try to fix it by e.g. sending me a Philips Universal Remote Control. When I pointed out that their own technical support staff are just as clueless as I am (given the runaround I’ll describe below the fold), and that their standards seemed to be set just slightly too high, the service rep got angry with me. Specifically, she was quite perturbed about me not accepting her apologies. That just bewilders me. I thought it was a tech support number, not a “We’ll listen to your whines and agree with you, for 10ct a minute” service number. Why would her personal apology that their hardware sucks help?

How come I, a techno geek, knows more about marketing than a supposed world leader in this sort of thing?

Well, congratulations, Philips. That’s the last time I’ll ever buy from you.

The runaround was even worse:

First guy I got wants to know my personal details (I told him to go screw himself, but nicely, considering that I had a simple question and I was paying to call them), then wants to know how the satellite box was connected to the TV. At this point I bit back a colourful statement regarding his brain size, and instead just said “I’m talking about the remote control!”. He put me on hold, it took too long, so I hung up instead and redialed in a hope to get a more clueful operator.

The next operator at least got the basic gist and gave me a different number for their universal remote control division. I told him it wasn’t a universal remote, but he was certain they’d fix it for me.

I then dialed the other number and got a very clueful person on the line. He actually insulted the other number’s staff, apologizing profusely for sending me on a wild goose chase. He double checked the TV’s model number and then assured me that my remote isn’t programmable and if it doesn’t work right away it never will. He then gave me a last hail mary and gave me the way their universal remotes are configured: Press the STB button continuously until your satellite box turns off. Let go right away – it’s now set. That didn’t work.

Armed with this knowledge, I dialed the main number again to ask for a reasonable solution. I then made the mistake of mentioning that the satellite box was bought slightly too long ago for me to return it, at which point the tone of the conversation turned icy and the above story was foisted on me.