Why Driverless Cars are No Solution

This is a good start.

To it one can add that driverless cars will mainly act to increase the capacity of freeways (by enabling cars to safely tailgate each other at freeway speeds). When it comes to congested surface streets in major employment and commercial centers, cars simply can’t move that fast. There’s too many intersections and other hazards to contend with.

Street capacity is already maxed out (or nearly so) in those areas. Making it possible for the freeway system to dump significantly more traffic on those streets will simply make congestion get worse until gridlock develops and the queues waiting to enter the congested area back up onto the freeways and congest them, too.

Self-driving technology does nothing to change the essential fact of personal transportation: that it doesn’t scale. Cars work well only when there are relatively few of them.

Regarding the Paris Attacks

One simple sentence basically sums it all up:

The West is less morally superior than it pretends to be.

If you’re flying off the handle about that statement being a justification for what just happened, then you didn’t actually read what I just wrote. Go back and re-read the sentence. It’s actually very nuanced and sums up a lot in a few words.

For openers, it actually states that the West is in fact morally superior to ISIS. The wording is goes “…less morally superior than it pretends to be.” It does not go “…not morally superior,” “…morally equivalent to,” or “…morally inferior.”

It’s just that the actual level of moral superiority is significantly lower than the professed one.

For example, there is no rejection on either side over the principle of engaging in actions which cause civilian deaths. Drone strikes have been accomplishing the latter for decades. And doing so routinely; they’re remarkably imprecise. How can they be otherwise, given how they are conducted remotely? If all one is going on is a fleeting image from above of a fairly distant group of people, you’re going to be misjudging the nature of those people fairly often.

Sure, ISIS deliberately sets out to cause civilian deaths whereas in the drone strikes they happen incidentally as part of efforts targeted at combatants. But dead is dead, so rhetoric like “we value life and they don’t” is, well, B.S.

And the West, despite those somewhat higher standards, is the party that is far more heavily armed, and thus far more likely to inflict actual civilian death. Terrorism has killed far fewer civilians in recent decades than the war in Iraq did, for example.

Mind you, I’m very glad I live where I do and not someplace controlled by ISIS (or by the Kingdom of Saudi Arabia, which is just about as bad). But please, spare me the “we’re good, period and they’re evil, period” rhetoric.

Time for Another “Javascript Sucks” Post

For no other reason than it’s been a while since my last one. Oh, I’ve just been bitten by some sucky Javascript today, but that’s hardly new: it happens most days.

That’s because there’s an awful lot of sucky Javascript code out there. Which is the case because Javascript is a difficult language to program well in. Which in turn is the case because both the core language and its object model basically suck.

I mean, how much more sucky a design decision can there be than making all variables by default global unless explicitly made local? This is precisely the opposite of what any sane design would do. Thanks to this misfeature, all the Javascript coder need to is absentmindedly leave off a var or two and presto, there’s a bug waiting to strike. And Javascript’s parallelized and callback-based nature means the bug probably won’t be immediately obvious, so it will make it through testing and into production where it can bite users.

And then there’s the Javascript object model. It’s not necessarily deficient, it’s just bizarre. Well, bizarre to anyone used to the classical inheritance model (which means virtually any other object-oriented language out there); Javascript uses prototypal inheritance. It’s a bit of gratuitous difference that just makes Javascript needlessly strange and thus more difficult to learn and understand for the vast majority of programmers. Why? Just why?

That Javascript makes failure easy and success difficult can be illustrated by how it’s not that hard to run into bad (i.e. flaky and unreliable) Javascript on Google pages. I mean, if one of the largest and wealthiest corporations on the planet, one famous for hiring the best and brightest, one that writes browsers as well as web pages, can’t successfully implement a toolkit to tame Javascript’s bias towards failure outcomes, that’s about as damning an indictment as one can make against Javascript.

Finally, it’s instructive that those who designed the Google Web Toolkit chose to (alas, ineffectively) fight Javascript’s brokenness by writing a tool to enable developers to avoid programming in Javascript entirely.

Javascript code would be bad enough if most of it only had all of the above factors working against it, but wait, there’s more.

First, client-side Javascript has to be cross-browser portable, and there’s lots of gratuitous little differences between the execution environments on different browsers (or even differing versions of the same browser).

Second, many kinds of client-side code, in particular AJAX code, are difficult to write well. Such code must cope well with all sorts of network conditions without adversely impacting human-machine interactivity.

The latter would be difficult to do even with a sanely-designed programming language and execution environment. In Javascript, it’s often close to impossible.

It’s one reason why the answer to the question of how best to do something in client-side Javascript is a simple don’t.

Don’t do it. Not if you can do it in static HTML somehow. It might in some theoretical sense be better to have more interactivity, but in practice a less theoretically-elegant solution that works and works reliability in a wide variety of situations will come out ahead.

Sleazy Recruiter Earns a Poison-Pen Response

Normally I don’t send harshly-worded responses to recruiter spam, but this guy just begged for it. He’s been spamming me over and over again. He’s from an insurance agency, of course.

Holy hell, are you ever one clueless sleazy dirtbag of a recruiter.

Can’t you understand plain English?? To wit, the disclaimer that appears with my online résumé:

This résumé is being posted strictly for the purpose of soliciting responses related to employment opportunities in the field of software development. In particular, neither insurance sales [emhasis added] nor systems administration are software development.

I would not work for your company even if it were the last employer on Earth.

Moreover, I am going to tell all of my friends to avoid purchasing insurance from your firm.

Hello David ,
My name is Ron Ellwanger with Colonial and I have tried reaching out to you in the past but we have not been able to connect. I am still interested in speaking with you about the benefit consultant and account manager positions in your area. (we may be able to talk about management as well depending on openings)
We are rapidly growing with the business 2 business market especially with the recent changes in health care reform. We are helping more people than ever before.
If you are still looking for a position, I would like for us to set up a time to chat over the phone.
If interested, please send me an email and we will set up a time to chat.
Ron Ellwanger
Colonial Benefits