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.

Martin Fowler:

Kent Beck came up with his four rules of simple design while he was developing ExtremeProgramming in the late 1990’s. I express them like this.

• Passes the tests
• Reveals intention
• No duplication
• Fewest elements

Loup:

Object Oriented Programming died several times already. This time might be the last.

Nevan King:

In iOS 8, this code doesn’t just fail, it fails silently. You will get no error or warning, you won’t ever get a location update and you won’t understand why. Your app will never even ask for permission to use location.

I just got bitten by this while updating an app. This post goes through what is needed to fix it.

Michael Johnston:

You cannot build a 60fps scrolling list view with DOM.

The Flipboard team have gone to great lengths to get the performance they want from the browser.

Everything is rendered to canvas elements. They’ve created their own representation of elements which they pool aggressively to avoid GC hits.

This is another place where React’s virtual DOM comes into its own. Flipboard use React to render to canvas elements. They’ve wrapped this up into react-canvas.

This is an extreme approach but the app feels slick because of it.

Bob Nystrom:

When they create 4089 libraries for doing asynchronous programming, they’re trying to cope at the library level with a problem that the language foisted onto them.

Each of those function expressions closes over all of its surrounding context. That moves parameters like iceCream and caramel off the callstack and onto the heap. When the outer function returns and the callstack is trashed, it’s cool. That data is still floating around the heap.

The problem is you have to manually reify every damn one of these steps. There’s actually a name for this transformation: continuation-passing style. It was invented by language hackers in the 70s as an intermediate representation to use in the guts of their compilers. It’s a really bizarro way to represent code that happens to make some compiler optimizations easier to do.

No one ever for a second thought that a programmer would write actual code like that. And then Node came along and all of the sudden here we are pretending to be compiler back-ends. Where did we go wrong?

Red and Green callbacks:

It’s actually worse, every Javascript programmer who has a concurrent problem to solve must invent their own concurrency model. The problem is that they don’t know that this is what they are doing. Every time a Javascript programmer writes a line of code that says “on this do that” they are actually inventing a new concurrency model, and they haven’t a clue how the code will interleave when it executes.

What’s even more difficult to understand is errors. Errors in multi-threaded callback code with shared memory is something that would give me an extremely large headache.

The in-language mixing of synchronous and asynchronous calls makes code hard to reason about. The language-side simplicity of Ruby or Java’s concurrency model is something I have taken for granted.

Michael Feathers:

I strongly believe that there is a law of conservation of complexity in software. When we break up big things into small pieces we invariably push the complexity to their interaction.

Adam Wiggins:

Make it real

Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don’t say you did something, provide a URL that proves it.

Plenty more great stuff in there.

Mike Caulfield:

Wiki is a relentless consensus engine. That’s useful.

But here’s the thing. You want the consensus engine, eventually. But you don’t want it at first.

It’s funny, I was looking over this keynote last night, and I saw this line and realized — this is the simplest explanation of federated wiki.

James Clear:

In my opinion, this is the greatest success “hack” there is. If you live in an environment that nudges you toward the right decision and if you surround yourself with people who make your new behavior seem normal, then you’ll find success is almost an afterthought.

Systems are better than goals.

Tom Stuart:

Monads are in danger of becoming a bit of a joke: for every person who raves about them, there’s another person asking what in the world they are, and a third person writing a confusing tutorial about them. With their technical-sounding name and forbidding reputation, monads can seem like a complex, abstract idea that’s only relevant to mathematicians and Haskell programmers.

Forget all that! In this pragmatic article we’ll roll up our sleeves and get stuck into refactoring some awkward Ruby code, using the good parts of monads to tackle the problems we encounter along the way. We’ll see how the straightforward design pattern underlying monads can help us to make our code simpler, clearer and more reusable by uncovering its hidden structure, and we’ll end up with a shared understanding of what monads actually are and why people won’t shut up about them.

The accompanying video is short, snappy, and to the point.