Gold in vault, target
Steel door closed, locked, key thrown away;
Thief laughs "There's no wall!"
Data stream flows, filling
Lake overflows; disaster!
Man trusts fellow Man,
fellow Man undeserving.
Script code injected.
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
Now love's checksum fails
Small time differences,
like the blink of a blink, yet,
timing attacks still work.
Chick digs my profile,
sends regards in attachment.
Virus, still no love.
That plaintext password?
Easy, but when the press hears...
thought too hard to bear.
Address sign-up forms,
Security mindset sees
a way to spam foes.
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.
|Past Posts ->|