One of the things I've been really enjoying about Go is how easy testing is. The pervasive use of interfaces and composition-instead-of-inheritance synergize nicely for testing. But as I've expressed this online on reddit and Hacker News a couple of times, I've found that this does not seem to be a universally-shared opinion. Some have even commented on how hard it is to test in Go.
Since we are all obviously using the same language, the difference must lie in coding behavior. I've internalized a lot of testing methodology over the years, and I find some of the things work even better in Go that most other imperative languages. Let me share one of my core tricks today, which I will call the Environment Object pattern, and why Go makes it incrementally easier to use than other similar (imperative) environments.
There are a number of errors made in putative Monad tutorials in languages other than Haskell. Any implementation of monadic computations should be able to implement the equivalent of the following in Haskell:
minimal :: Bool -> [(Int, String)] minimal b = do x <- if b then [1, 2] else [3, 4] if x `mod` 2 == 0 then do y <- ["a", "b"] return (x, y) else do y <- ["y", "z"] return (x, y)
This should yield the local equivalent of:
Prelude> minimal True [(1,"y"),(1,"z"),(2,"a"),(2,"b")] Prelude> minimal False [(3,"y"),(3,"z"),(4,"a"),(4,"b")]
At the risk of being offensive, you, ahhh... really ought to understand why that's the result too, without too much effort... or you really shouldn't be writing a Monad tutorial. Ahem.
- Many putative monadic computation solutions only work with a "container" that contains zero or one elements, and therefore do not work on lists. >>= is allowed to call its second argument (a -> m b) an arbitrary number of times. It may be once, it may be dozens, it may be none. If you can't do that, you don't have a monadic computation.
- A monadic computation has the ability to examine the intermediate results of the computation, and make decisions, as shown by the if statement. If you can't do that, you don't have a monadic computation.
- In statically-typed languages, the type of the inner value is not fixed at the beginning. It's a -> m b, not a -> m a, which is quite different. Note how x and y are of different types.
- The monadic computation builds up a namespace as it goes along; note we determine x, then somewhat later use it in the return, regardless of which branch we go down, and in both cases, we do not use it right away. Many putative implementations end up with a pipeline, where each stage can use the previous stage's values, but can not refer back to values before that.
If you can translate the above code correctly, and obtain the correct result, I don't guarantee that you have a proper monadic computation, but if you've got a bind or a join function with the right type signatures, and you can do the above, you're probably at least on the right track. This is the approximately minimal example that a putative implementation of a monadic computation ought to be able to do.
Scientists (and, in my experience, especially bioinformaticians) tend to make horrible, awful messes no matter how maintainable you think a language is. (You can hand them Inform 7 and it'll still end up looking like Fortran ate the csh manual and vomited all over an APL keyboard.)
I don't listen to the radio hardly at all anymore. Recently, I was with my wife while she was just idly flipping through, and I was astounded.
The electro/techno stuff was autotuned, but that's less of a surprise.
Autotune, autotune, AUTOTUNE!
Not even subtly, either, but cranked up as far as it will go before the high end simply explodes with noise.
Is there anyone left in the music industry that can carry a tune?
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.
- abtime (godoc): An abstract time library that removes your dependency on the OS time from the time module. I've now run into this problem at work in three forms; unfortunately one of them is in a module I plan on releasing someday and don't want a dependency on this module, but the other two can benefit from a standardized way of dealing with this. I had a semi-complete version of this in my local code base already, but I was inspired to bring it up to public spec by Moonpig.
There's more coming, but they're bigger than these. My supervisor tree library is nearly ready to go, but the requisite blog post explaining the design is still in progress. (It's big.) The library that implements Erlang-style mailboxes, including the ability to cluster together machines and send messages across the cluster the way Erlang does, is still in progress. (I have just barely started the clustering.) My current plan is to lock down and stabilize the system this is being written for in the single-server case, then implement this clustering.
I wouldn't mention it, except that Google does not seem inclined to index these without some form of external link. GitHub permits external indexing of the master branch of projects but I think perhaps their robots.txt forbids the scraping necessary to find unlinked projects. Hopefully this fixes that.
|Past Posts ->|