$1 million for mormon cricket control in Utah – is that the species of cricket or a game played by the brits?

I mean seriously, that’s so fundamentally uninformed that I can’t even mock it.  A million dollars is a bargain for statewide pest control that costs hundreds of millions of dollars in structural and crop damage annually.  He’s old enough that, statistically speaking, he should have seen every living thing at least twice by now (including brontosaurus); one is tempted to remind him of that crawly sandwich he had with Joseph Smith.

“I have no idea what they’re even talking about, so surely I’m qualified to think it’s pork!  Who needs locust control anyway?”

Asshat.

Of course, anyone with half a clue will remember three things:

1. He was not being instructed by an authority figure that adware was in the victim’s best interest
2. His goal was making money
3. He had months, including time away from the authority figure, in which to think it over

The dirtbag goes on to talk about how difficult it was to ignore a challenging occupation when one doesn’t have many other options.  Thing is, I could be making tons of money as a pirate, or writing malware, and I manage to get through my day without doing it.  I’m also willing to bet that Drew Peters wasn’t actually looking for other jobs at the time.

“It’s even harder if the bad starts out small and slowly gets bigger.”

Horseshit.  The second you do something bad, you object, and if they try to force you, you walk away.  That’s why when I found out my old boss Russell was triple- or more billing his clients in my name, I told him that he stopped tomorrow, or I walked.  Did I get fired?  Sure, but I told the client what happened, so so did Russell, and I ended up getting the job back with a different boss and a much larger hourly billable.

Oh, and I had my honesty and decency intact.

Go to hell, Matt Knox.  It’s not that hard to not write malware.  It’s just hard for people like you.  I hope that eventually you find yourself the victim of the things you’ve done to others; you’ve almost certainly caused far more damage than you’ll ever understand, during a time where it was extremely easy to get other work.

Disgusting.

Pity the Boise police show so little interest in corporate illegal behavior – I’ve already reported three of these to them, and they don’t even open reports.

Unsurprisingly, this has ended my being a Best Buy customer permanently.  They were, previously, taking in about $1500 per month from me.  Wonder if it was worth it.

Unsolicited commercial email, and fraud to boot.  Pretty much the definition of SPAM, isn’t it?  So why isn’t anyone going after them like they are for the other spammers?  Aren’t there vast sums of money involved?

I’ve lost more packages in the year since I’ve moved here than in the rest of my life put together, and the ones I do get are usually in piss poor condition.  It’s a wonder they pass quality control.

On the mailing list, people are actively trying to bring Erlang up to snuff with regards to web standards.  One of the more unfortunate choices being discussed is JSON as a data notation.  JSON, unfortunately, does not actually map to Erlang in a useful way.  Joe Armstrong has gone as far as to suggest BIFs, which are decidedly unrealistic as well as unnecessary.  My goal is to create a JSON handling library.  However, the mailing list is beginning to put momentum behind an alternative proposal which is currently presented in BIF form.

This post explains why my approach is different.  Many of the issues herein are discussed by the tabled EEP (EEP 18, “JSON BIFs” by Rickard O’Keefe), but some are not, and some of these issues are accepted when I believe they should not be.  It is my position that EEP 18 is unacceptably dangerous.  I will explain why.

This paper assumes you are familiar with Erlang and with fundamental containers (the list, the array and the key/value map).  It is very helpful, but not required, to be familiar with JSON, or JavaScript or any ECMA derived language such as ActionScript.

Premise

There’s a movement starting to use Erlang for web work.  There are several stumbling blocks to that end.  Among them are a simple primary webserver, a simple primary unicode system and a simple primary JSON manager.

The webserver problem is mostly solved: there’s the httpd module, there’s yaws, there’s mochiweb, there’s the currently unavailable work at Tobbe’s Red Hot Erlang Blog, there’s even Joe’s HTTPD tutorial.  YAWS and MochiWeb in particular get a lot of action these days.  The situation isn’t amazingly straightforward, but it’s fairly straightforward; we’re in “Good Enough” territory.  (I’m building another webserver that behaves like factor’s drop-and-go server, based on Joe’s tutorial, but that’s not for here.)

The unicode problem, however, as well as the JSON problem, are not solved.  Unfortunately, whereas the Erlang community has had the foresight to deal with complex problems in modules first then to move them to syntax later, this process seems to be failing with both JSON and Unicode.  It can be argued that some of the choices made in each process are dangerous.  This community will, by and on the whole, remember the re: module, which is being replaced now with a partially incompatible successor that takes account of limitations and problems in the prior attempt, as well as moves to a stronger RE dialect.  It is important that this ability be retained for JSON and Unicode, both of which are subtly strikingly difficult problems, and both of which are unlikely to be Gotten Right™ on their respective first attempts.

The Principle of Least Surprise

One of the most important parts of writing libraries is to not write nasty shocks into place for users.  In transcoding libraries, there is one rule that defines least surprise more powerfully than any other: round-trip translations must not lose data.  No configuration of EEP 18 can achieve this.  Indeed, it is my position that a one to one translation of JSON to Erlang terms cannot exist, and that any attempt to present a not-1:1 translation as a translation is unacceptable, in that people will expect j2e(e2j(X)) == X, and that cannot be true.  This is especially important given that the suggestion that these translations become BIFs seems to be being taken seriously; foo_to_bar(X) bifs are currently never lossy, and this would create a worrying change in the meaning of several basic naming practices.

It is of critical importance, in my opinion, that we do not provide libraries which fail round-trip conversion in either direction.  At this time, EEP 18 attempts to satisfy this clause with creation-time configurability; I will explain my stance that this is inadequate below.

Why Translation is Unclear

There are, in fact, quite a few problems that prevent 1:1 translation.  We’ll go over them one by one.

1. The notations offer different fundamental containers
   1. Erlang offers dense sequence (“tuple”, {}) and singly linked list (“list”, []) containers.  The erlang standard library offers other containers; I discuss later in this document why I’m not using them.
   2. JSON offers dense sequence (“array”, []) and key-value map (“object”, {}) containers.  That’s it.
2. The notations offer different fundamental datatypes
   1. JSON has a fundamental string type; erlang doesn’t.
   2. Erlang has atoms; JSON doesn’t.
   3. JSON has booleans and “null”; Erlang doesn’t.  For transcoding, pretending they’re atoms creates ambiguity, and is therefore unacceptable.
   4. JSON has explicit support for unicode characters in strings.  Erlang doesn’t have strings at all, but rather lists of characters (in the way that C has arrays of characters).  Those lists are context and usage defined; C++ programmers may think of this as parallel to array strings vs std::string.  Erlang currently has no concept of Unicode (though that’s another issue I’m working on as divergent from the current mailing list / EEP approach.)
   5. JSON and Erlang have very different lists of quoted terms for strings.
      1. Erlang supports embedded octal with shortening, and a bunch of semi-defunct control characters like form feed ("\f") and escape ("\e").
      2. JSON supports 16-bit Unicode character embedding.
      3. Problematically, JSON does not define whether that embedding is UTF16, UCS2 or something else.  Most software implementations assume UTF16.  This document will carefully avoid the issue, which is a serious defect in this document, and a serious defect in JSON.
   6. Erlang terms are byte-available, meaning Erlang programmers may be aware of endianness; JSON objects are not.  This suggests that the handling library needs to either make a choice about internal endianness, or needs to provide control to the user.
3. The notation for similar containers is dissimilar
4. Similar notations are similar, not identical
5. Dangerous string ambiguities

Working from http://sc.tri-bit.com/outgoing/scjson%20parser%20halp.html

Let me be forward: I cannot stand the various Objective C books I’ve tried.  They all want to teach me to be a programmer.  I’m already there.  I just want a book like Stroustrup.  The PragProg book is awful: the first several chapters are about Mac development tools, like I give a damn.  Everything’s through interface wizards.  It’s nauseating.

Jeff heard mein painz0rz, and turned me on to From C++ to Objective-C.  It isn’t perfect: it’s not super comprehensive, and it’s translated from a different native language (French), which leaves a few passages cumbersome.  However, as one can tell from reading the intro, the author of the document, much like me, found little to love in the state of Objective C documentation, and wanted to write something for people who were already well established.

Kudos to Pierre Chatelier for writing the book that Apple and Alan Kay could not.

There’s this host.  I’m not going to name them, because it isn’t clear to me whether it’s ethical to do so.  Four times in the last year, I’ve caught their engineers telling customers who are shared with my employer complete horseshit.  They’ve blamed their servers being compromised on our application without a lick of evidence (which turned out to be their own fault after basic inspection), they’ve made absurd claims about our policies, and now they’re making claims that we don’t support MS Exchange, which is of course completely false.

What’s worse, when their engineers get caught being completely full of crap, the company’s response is to isolate those engineers from explaining the claims they made, and instead they’ve been going to my company’s CEO, trying to get me in trouble for telling our shared client to be careful about the advice received from their engineers, despite knowing perfectly well that the advice being handed out by their engineers (particularly during commercially motivated server takeover) was dangerously incorrect.

So I’m not really sure what to do.  Do I go public with the names and claims of the individuals involved?  Do I just choke on the rage and be silent?  I tried going to their bosses; their bosses’ response was to try to get me fired from my own job.

How do my readers suggest that I handle such an improbably unethical hosting company?

Ha!  The problem is, the iPhone has an autocorrecting keyboard which corrects if you don’t tell it not to (the obnoxious kind like Outlook has), and it makes completely asinine replacements (its becomes it’s, as if the word its doesn’t exist).  This is bad enough if you just speak above the level of an eighth grader, but it makes using unix shells and writing code genuinely impossible.

Classic apple zealot response from IRC: “don’t be stupid, just teach the iPhone every word you want to use when programming.”  Like they don’t even think before they answer.

Apple: why can’t I turn this off?  It’d be simple enough: there’s bound to be some function somwhere get_best_replacement(char* current), which signals no reasonable match (as you get for, say, ‘zzzzz’) by way of an empty string, or something similar.  That’s the hack point.  Add if (customer_isnt_retarded()) { return “”; } else { previous_logic(); } and it’s fixed.

Seriously, who locks people into an autocorrecting keyboard?  Ugh.  This ruins the iPhone for any kind of technical use.  What a mess.

If you hate this too, vote this up on digg and reddit, so that an Apple employee will see it.