In my Haskell Implementors 2012 talk Haskell Platform: Field Report and Future Goals (slides, video), I called for an expansion of the content of the platform to bring it up to par with what other programming language platforms provide. Here is a partial list of package topics that are commonly in other language platforms that are missing from ours:
- Crypto — hashing, mac, ssl, uuid, common cyphers (aes, des, etc…)
- Data Formatting — csv, json, base64, yaml, mme, xml, parsing, generation
- Database — dbm, *sql, sqllite
- Encoding — base64, quotedprintable
- Image Processing — rendering, compositing
- Math — statistics
- Media — audio formats, image formats, video formats, id3, media containers
- Network Services — amqp, curl, memcached, sessions
- OS Services — logging, file utils
- Programming — benchmarking, test framework
- Text — html, diff
- UI — curses, gui framework(s)
To get started on that mountain, I’ve put together the start of a straw man for what we might get into the 2013.2.0.0 release: Package Staging. It is a list of about 20 or so packages (or package needs where I’m not sure which package to suggest) that I think we should tackle first.
My aim here is to be ambitious. The platform has proven itself to be a useful part of the Haskell ecology. By expanding its coverage we can make Haskell more viable for a broader audience beyond the Haskell community itself.
To get this done we’ll need tremendous efforts on the part of package maintainers. But we also need the support of all of you, the Haskell community: We can achieve this ambitious goal if we focus on producing a well engineered, practical, stable platform so that people can simply choose Haskell because it is the best tool for their programming work.
I believe the time is right, and we can come together and, in the immortal words of the Power Rangers: “Let’s do this!”
We’ve had our electric car, a Mitsubishi i-MiEV, since the end of December. It took a few weeks for us to get the 240v charging set-up, new utility rates in place, and to get used to driving it. By the end of January, we had settled into using it as our main transportation. I measured our usage in February, and this is what I found:
We drove the i-MiEV, in the 30 day period from Jan 29th, through Feb 27th:
- 1,278 miles, or 42.6 miles / day average
- used 318.4 kWh (*)
- spent $39.21 for that electricity
- spent just 3.07¢ per mile
Our previous primary vehicle was a 2001 Prius. We get about 40 mpg in that car, so the same month in that car would have consumed 32 gallons of gas. At the average local gas price in Feburary, $4.07/gal, it would have cost $130.20 to fuel the Prius for the same use. That works out to 10.19¢ per mile, and…
a savings of $90.99 for the month!
(*) The astute will notice that this works out to 4 mile / kWh, which is about middle of various measures I’ve seen for the car. To be fair: We sometimes “charged-up” in the middle of the day at free charging stations in Palo Alto. On the other hand, we also love the “pre-warming” feature, and spent some electricity warming the car on those cold mornings.
Update 3/5: I was able to get our external charging usage data. In February we used an additional 23.3 kWh of charge. Which brings our car efficiency down to 3.74 mile / kWh. However, that includes the energy we used pre-warming the passenger compartment before we unplugged in the morning, which is significant, but unquantified.
Johan Tibell and I have been working on a Haskell serialization API recently, and he wrote an excellent post outlining the general issues one runs into again and again. This is a follow up that adds another.
Please read Designing a Serialization API first
How many ways can the Haskell types map
In some serialization, there is really on one useful way to map the basic Haskell types. For example, Bool‘s True and False clearly map to and from JSON’s true and false. Any other conversion, while conceivable, probably isn’t realistic. On the other hand, there is no standard way for Int to map onto a stream of bytes. Even within a given protocol, and Int may be serailized different ways at different points in the data stream.
This influences the design of the serialization type classes: Aeson’s toJSON type class can be parameterised by type, because Int, Bool, String, and Text are all going always serialize the same.
On the other hand, Binary’s Put monad allows, at some extra programmer work, the ability to serialize a Int various different ways. via putWord8, putWord16le, putWord16be, etc…
Turns out, Binary also provides the Binary type class, parameterised on type, must like Aeson’s ToJSON and FromJSON type classes. However, it isn’t used as much for serialization to known protocols for precisely the reason that you don’t have enough control over how the basic Haskell types are represented.
tl;dr: Unless you are writing programs that address over 2G bytes of data at once, install the 32-bit version of the upcoming Haskell Platform.
Given that I had both, it seemed like a good idea to benchmark them somehow, and give people some guidance as to which to install. I choose Johan Tibell’s unordered-containers package, as it has a nice benchmark built with criterion that tests both it, and the common
IntMap data types. (And also because he was sitting at the desk next to me at work today, so I could pester him with questions!)
The results were a little surprising: The 64-bit version ran between 0% and 139% slower on most benchmarks, averaging 27% slower. For a small few, it ran a little bit faster (0% to 15%, average 8%). Details and discussion after the break.
I used to think it was best to support the Democrats, as a functional counter to the Republicans. (Basically penance for the one time I failed to vote… and Regan became President.) But I’m older and crankier now, and don’t have the patience for the Democrats: They speak nicer sentiments, but are hardly the forces of change we need.
I’m looking for a political homestead: A group that cares about people over corporations. A group that speaks in facts in truths, and acts mature. No spouting ideologies, but enough fire to call a spade a spade. A group that encompasses all aspects it takes to govern a nation, not concerned with just one set of social issues, or a particular economic solution. A group with a platform I can get behind.
Anyone know such a party? A website? Non-Profit? A journal? Weekly meetings of concerned citizens? A writer? Is anyone organizing a reformation of American politics?
Or do I need to start planning to emigrate to some other country (suggestions welcome)?
I admit that I’m addicted to code-golf. Sometimes I feel like a little coding for fun, but I’m not in the mood to get into any of my more involved projects. At these times, a short code-golf puzzle can be just the ticket. Most code-golf entries are often very convoluted and hard to read. But in Haskell, I often find that even distilled to minimal character count, the code still expresses the meaning clearly. Sometimes it even leads me to a deeper appreciation of the code.
On his Sententia blog, Chris Smith argues that Haskell’s niche is “hard problems”. While I agree with many of things he finds are great about Haskell, I don’t really agree with the premise that “different programming languages are good at different things”, at least universally.
There are certainly domain specific languages, languages that have made syntactic and semantic trade-offs to support one particular domain very well.
awk comes to mind as a good example. Sure, it’s Turing complete, but it is really only well suited to line-oriented text processing.
But a large class of languages are general purpose, and as such, I don’t think make them particularly good at one thing over another. For example, I think any distinction between what Python is good at vs. Java vs. Ruby vs. PHP vs. C++ vs. Haskell is just bound to be forced, and 99% a matter of taste.
Now, it is certainly true that the set of libraries available, and the execution environments often are highly skewed to one domain or another. For example, I still find myself coding in PHP for small dynamic web sites. Not because the language is particularly suited to it (in fact I find it downright painful), nor the libraries particularly good, but because it is right there integrated into Apache and “just works” out of the box.
Once you are over the hump of getting a language workable in a particular environment, then I think for most “full-featured” programming systems (languages and their commonly available libraries), I think one would find that none of them is more or less particularly suited to any given domain.
All that being said, I find Chris Smith’s main points about Haskell spot on, and I love his slogan: “Haskell is for solving hard problems.” But, I’d go further, assuming I can get it running in whatever execution environment I need, “Haskell is for solving most problems.”
Someone I met at BayHac e-mailed me asking for some help with state. He was generating an HTML page and wanted to be able to number all the figures consecutively across the whole page. I ended up writing a little tutorial code for him on threading state, both directly and with the State monad, and thought I’d share it here.