A given abstraction can be helpful in one situation and harmful in another. Often, we use abstractions out of habit without thinking critically about their benefit. Sometimes, an abstraction is harmful because it distances us from other features of the language, as I wrote in Abstractions.
Here, I give an example of such an abstraction, which happens to be very common in the domain of parsing, but which comes up in many other places. I also begin refactoring the code to use a more helpful abstraction.
Continue reading "An abstraction gone wrong"
Abstraction allows us to wrap up complication into a simpler form. We can take a set of things, with all of their nuances and details of combination, wrap it all up and call it new thing.
But, abstractions can sometimes get in our way. If they're not designed properly, they may not go together in convenient ways, or they may distance us from other useful parts of the language.
Continue reading "Abstractions"
Recently, I needed to document firewall rules for a cluster of machines. The document needed to spell out rules by machine, but that meant that connections between machines were described in two places: the machine requesting the connection, and the one servicing it.
Context-based programming gave me an easy to describe a connection in a single place, but generate a document that connection in two places.
I can also use the same source file to generate the firewall rules themselves.
Continue reading "Context-based programming is DRY"
There's a style of programming that I stumbled across a while
ago. I don't remember hearing about it anywhere else before, so I
thought I'd write about it here.
I call it "context-based programming." Code is expressed using
terms that are defined by a context, and the user can control the
context and how the terms are defined.
Here's a simple example:
Continue reading "Context-based programming"
What happens if you apply a technique from stock-analysis to software projects?
Continue reading "Stock-analysis applied to software projects"