Programming

I've pushed two repos to GitHub with Go code: gomempool (godoc): A []byte pool manager for Go. It's less generic than the Pool implementation that is working its way into Go tip, but also therefore understands more about []bytes, and is much simpler than the I-don't-even-know-what magic is in that implementation. It also tracks stats, which I've hooked up to my monitoring so I can see the usefulness of the pool in my real running code.

Gold in vault, target Steel door closed, locked, key thrown away; Thief laughs "There's no wall!" Data stream flows, filling Lake overflows; disaster! Arbitrary code Man trusts fellow Man, fellow Man undeserving. Script code injected. Novice celebrates, Output easy, just append strings! Master needs new novice. Dark secrets made, shared Tells foe the password is lost... Rubber hose finds it. "Love", Alice tells Bob In anger, Eve flips one bit

One of my objections to Erlang is that despite paying the price of being a functional language, it often fails to reap the advantages. An example of this is in testability; nominally, a purely functional bit of code ought to be easier to test than the imperative equivalent, because it is just a matter of setting up your parameters and checking the results, with no IO or state in between.

Erlang doesn't make this impossible, but it's less convenient than the brochure promises. The core of your application is generally locked up in the various gen_* handlers. These handlers have very stereotyped ways of being called, which include the full state of the thing being tested. I find this very tedious to test, for two reasons: 1. Every test assertion must define some sort of "complete state" for the handler, which is probably full of real-world concerns in it. In particular if it has further messages it is going to send, those are often relatively hard-coded somehow... an inconvenient-to-mock Mnesia entry, an atom-registered process name, etc. (Erlang programs end up having a surprising amount of global state like that.) 2. If you want to test some sort of sequence of events, you are responsible for threading through the code, or manually invoking the proper gen_* start up functions, or something. It's possible to refactor your way out of this mess, but in practice it's a lot of work for the reward. So many of the tools you could use in other languages aren't available.

Go, in theory, ought to be harder to test than Erlang, being an imperative programming language. In practice, I'm finding it much easier, and I'm doing a lot more testing in it.

A couple of months back, I analyzed whether I wanted to propose switching to Go for work. I've still technically got the blog post with the results of that analysis in the pipeline (though who knows when I'll get it up), but there's a part of it that keeps coming up online, and I want to get this bit out faster. It's about whether Go has "sum types".

Learn You a Haskell for Great Good! (A Beginner's Guide) by Miran Lipovača, published by No Starch Press (2011). No Starch was kind enough to send me an advance copy for review.

Haskell books for "real programmers" are still thin on the ground, being limited at the moment to Real World Haskell (2008) and possibly Programming in Haskell (2007). As its introduction states, this book is aimed at existing programmers who are currently fluent in something like Java, C++, or Python, and would like to learn Haskell.

I put my take on the traditional discussion of why you should consider learning Haskell in another blog post, so we can get on with the review here.

The hardest thing about learning Haskell with no previous functional experience is bootstrapping the strong foundation that you've long since taken for granted in your imperative language. If you don't have this strong grasp of the fundamentals, then every line of code is an invitation to get stuck on some subtle issue, and you'll never have the fluency that great work requires until you have that foundation.

This book is the best way I know to obtain the Haskell foundation you need for fluency.

No Starch Press asked me to write a review of the new Haskell book, Learn You a Haskell for Great Good!. I started to write a section about myself and my view of Haskell for context, and realized that it really needed to be its own post as it grew to a length where it was self-indulgent to make it part of the review. But it fits as its own post nicely.

Markdown.

BBCode.

Uncountably many Wiki markups, all different.

reStructuredText.

Textile.

Pottymouth.

Who knows what I'm missing.

Please stop.

In many modern languages, encoding errors are the number one cause of security flaws in software.

This is going to be long because if you don't have a deep understanding about what is going on, you too will write encoding-based security flaws. Given the widespread state of ignorance about this situation, including a large number of people who don't even believe there is a problem, I do not believe I can make this much shorter.

But before I can discuss any sort of solution, what exactly is the problem? Let us start with a parable.

I've loosely defined the value function (link) to only compare two "things", without further specifying what "things" it can take, because some things we put in there (like CloseToFamily) are fundamentally non-numeric properties. But some people have their own specializations of this value function. One that almost nobody will admit to using, but a lot of people live by, is the Money value function. This function takes just one argument and returns a single concrete number with the unit "Dollars" (or relevant local currency).

When I was a child, I wanted to be like Spock. For those few who do not know whom I mean, Spock was the science officer on the star ship Enterprise in the famous 1960's sci-fi television show Star Trek. His claim to fame was being half-human and half-Vulcan. Vulcans were an alien race who are so naturally violent that they felt themselves forced to renounce their emotions and turn to a life of pure logic, lest they extinguish themselves in endless war. A common misconception is that Vulcans have no emotions; they do, but they rigidly suppress them.

Spock's major character arc involved a conflict between his "human side" and his "Vulcan side", between "emotions" and "logic". During the television series, he had chosen to attempt being pure Vulcan/logical, but he met with less success than he would have liked. Something never made clear was whether this was purely a personal issue or if perhaps being only half-Vulcan made it somehow biologically more difficult to live with the Vulcan philosophies and disciplines. (Most likely even the writers themselves were conflicted over their interpretation of this.)

Spock's initial choice reflects a common view of emotions, that they are intrinsically opposed to logic, unpredictable and uncontrollable, that you are forced to choose either the cold, cruel world of logic, or the squishy, utterly irrational world of emotion and feeling, but that ne'er the twain shall meet. This is view can be seen in our most ancient literature, where the fiery passions of somebody's loins are routinely contrasted with their cold, austere logical mind.

What absolute garbage!