Simon Marlow:

Haskell isn’t a common choice for large production systems like Sigma, and in this post, we’ll explain some of the thinking that led to that decision. We also wanted to share the experiences and lessons we learned along the way. We made several improvements to GHC (the Haskell compiler) and fed them back upstream, and we were able to achieve better performance from Haskell compared with the previous implementation.

Agile Tortoise:

Terminology for iOS is based on WordNet, a great semantic lexical reference. We do not offer a full Mac app for Terminology, but have prepared a dictionary using this same great data for use in the built-in OS X Dictionary app.

Brian Marick:

So, interesting: an enormous amount of effort is spent on apps that convert map/vector-structured data into map/vector-structured data.

However, because of the mindshare dominance of object-oriented programming that came because of Java - “Smalltalk for the masses” - it’s hard for most people to think of an approach other than a pipeline of structured data -> objects -> structured data. The tools and frameworks and languages push you toward that. So: a programming model tailored to objects with serious lifetimes has been used for data that lasts only for one HTTP request.

Dave Copeland:

We’ve given up on “fat models, skinny controllers” as a design style for our Rails apps—in fact we abandoned it before we started. Instead, we factor our code into special-purpose classes, commonly called service objects. We’ve thrashed on exactly how these classes should be written, so this post is going to outline what I think is the most successful way to create a service object.

Some good advice for building service objects in Rails.

Michael Snoyman:

As of today Front Row uses Haskell for anything that needs to run on a server machine that is more complex than a 20 line ruby script. This includes most web services, cron-driven mailers, command-line support tools, applications for processing and validating content created by our teachers and more. We’ve been using Haskell actively in production since 2014.

An experience report on using Haskell in production.

Tony Morris:

In this talk, I will explain to you how list folds work using an explanation that is very easy to understand, but most importantly, without sacrificing accuracy.

I particularly like the constructor replacement analogy for foldr.

Elisabeth Hendrickson:

I prefer:

• Recovery over Perfection
• Predictability over Commitment
• Safety Nets over Change Control
• Collaboration over Handoffs

Ultimately all these statements are about creating responsive systems.

When we design processes that attempt to corral reality into a neat little box, we set ourselves up for failure. Such systems are brittle. We may feel in control, but it’s an illusion. The real world is not constrained by our imagined boundaries. There are surprises just around the corner.

Dijkstra:

I have told this story to different audiences. Programmers as a rule are delighted by it and managers, invariably, get more and more annoyed as the story progresses; true mathematicians, however, fail to see the point.

Ron Garret:

The Lisp model is that programming is a more general kind of interaction with a machine. The act of describing what you want the machine to do is interleaved with the machine actually doing what you have described, observing the results, and then changing the description of what you want the machine to do based on those observations. There is no bright line where a program is finished and becomes an artifact unto itself.

RDX:

Having deployed a variety of Ruby apps (Rails and non-Rails) over the course of many years, here are some lessons I’ve learned to keep things afloat.

Yehuda Katz:

• In Rust, as in garbage collected languages, you never explicitly free memory
• In Rust, unlike in garbage collected languages, you never explicitly close or release resources like files, sockets and locks
• Rust achieves both of these features without runtime costs (garbage collection or reference counting), and without sacrificing safety.

This post contains a nice summary of Rust’s ownership model.

Dorian Taylor:

If 90% of every­thing is crap, the obvious strategy should be to produce as much crap as you can afford, because the other 10% will be spectacular.

Scott Wlaschin:

But now we have something much more abstract, a set of generalized requirements that can apply to all sorts of things:

• You start with a bunch of things, and some way of combining them two at a time.
• Rule 1 (Closure): The result of combining two things is always another one of the things.
• Rule 2 (Associativity): When combining more than two things, which pairwise combination you do first doesn’t matter.
• Rule 3 (Identity element): There is a special thing called “zero” such that when you combine any thing with “zero” you get the original thing back.

With these rules in place, we can come back to the definition of a monoid. A “monoid” is just a system that obeys all three rules. Simple!

…

To sum up, a monoid is basically a way to describe an aggregation pattern – we have a list of things, we have some way of combining them, and we get a single aggregated object back at the end.

The first of three posts that give a simple definition of what monoids are and the benefits they provide.

The more Google pushes the sophistication of its web development tooling, the more we all benefit.

Paul Ford:

I erased most of my TODO list since I really only need to stay alive and listen to people and everything else is a lie.