A Strongly Named Language f
Taking the Objective C/Smalltalk method naming convention a couple of steps further. I sort of like this.
Ceejbot
A document of my midlife crisis.
Posts I like
-
GUYS CAN WE TALK ABOUT THIS PICTURE OF KLOKOV PLEASE
-
-
The Shadow - Edmund Blair Leighton
Search results for 'programming'
The Cost of Features f
How code bases grow over time. Builds to an analogy calculated to appeal to me:
It’s not a car for everyone, but it’s spectacular in its niche.
How To Make Your Open Source Project Really Awesome f
Specifically written for the Clojure community, but these points apply generally:
If you plan on releasing a library as open source, please make sure it has
- Clear dependency/installation instructions
- At least one brief documentation guide
- A change log and tags in the repo
- Some information about supported language/runtime/tool versions and project maturity
- A mailing list where users can ask questions and help each other
The mailing list seems more appropriate to very large or complex projects, but documentation is always a good idea. I like to see automated testing reports right there at the top of the README, too. It’s a huge confidence builder.
"What's going on" f
[T]here are cultural and technical sources of performance issues [in scripting/dynamic languages], and they are related. In his talk, Alex criticizes the naïveté of both tools and programmers. He bemoans the lack of sophistication in tools that make implicit hash addiction and allocation problems unavoidable, but he also complains about the commonality of poorly performing idioms in scripting language code. The tools, or in some cases lack of tools, encourage these poorly performing idioms in this code.
There is a change coming in the languages we use for common tasks. The tradeoffs we made when we all chose dynamic languages a decade ago (perl, python, ruby, etc) are starting to irk us because they’re not longer tradeoffs we have to make. The next generation of languages (Go is the topic of the linked-to post, but I suspect Rust will be on the list) is allowing us the rapid development without the performance tradeoffs.
Building the Adobe Photoshop 1.0 source f
An amazing exercise in software archaeology, as the writer digs up the compilers and libraries needed to turn the Object Pascal source into working software.
A blast from the past for me: MPW! I still change the shortcuts of every editor I use into a replica of MPW, because it was the best. (And only BBEdit truly preserves its search-n-replace goodness.)
Why Do Computers Stop and What Can Be Done About It? f
Earlier this week I was lucky enough to see Joe Armstrong talk about the principles behind Erlang. During the talk he mentioned one of my favourite technical reports—Why do Computers stop? by Jim Gray for Tandem Computers.
[…] For a little more analysis and a summary, I’d recommend reading @mononcqc’s excellent summary, especially to those who want to skip straight to the good bits of the report.
Source: programmingisterrible
The game of distributed systems programming f
Stashing this link here, because I am once again thinking about this blog post and how I can advance my own understanding of the problem space. Uh. Erk.
Everything fails all the time f
My current reading is this post on distributed systems & the CAP theorem.
Literate Jenks natural breaks and how the idea of code is lost f
On writing a fresh implementation of an algorithm when the original description is locked by copyright and unavailable. Most available implementations are translations of an old Fortran implementation, and they lose something as they go.
Clojurescript: up and running f
My current reading.
Greg Wilson on “What we actually know about software development and why we believe it’s true.” via programming is terrible
Talk: Advancing Distributed Systems, by Eric Brewer f
He begins with a useful history lesson, putting the development of distributed systems into perspective from two distinct views—databases and operating systems—showing NoSQL and SQL have a longer history than most imagine. He also offers some promising directions in which they can learn from each other.
A fascinating lecture on computer science, built upon his experience teaching a combined internals course on operating system & relational databases. I was lucky enough to catch Eric’s keynote live, streamed from the RICON conference (thanks Basho et al).
Source: programmingisterrible
keep-alive-agent f
This destroyed sockets bug kept coworker Danny & I occupied through the start of the week. This simple keep-alive agent is our workaround for it. If you happen to need a socket-reusing agent for node.js, it might prove useful to you.
Developer diary: Error handling
As you know, I hate boilerplate. It’s what enrages me about Java. Anything that a compiler/language/whatever can predict and generate automatically should be predicted, out of the way of the programmer. (This is why Java IDEs enrage me even more.) The node.js world has some particularly voluminous boilerplate in the error handling that typically opens every async callback. Javascript doesn’t provide any language features to help with this and the community is resistant to standardizing on any third-party modules.
My Sooper Dooper Sekrit Projekt has a lot of it and it’s starting to annoy me. I am going to adopt a new pattern to help.
Here’s an example of the problem. Look at the blocks of error handling in putTogetherSomeData():
Now imagine many functions with the same pattern repeated over and over: every call to couch.get() must be followed by nearly identical error handling code. This boilerplate is a problem for several reasons. It’s a surface for bugs; the error handling is required for application safety, but nothing demands its presence. It clutters the source and makes it harder to read and see what’s going on. As with all boilerplate, spotting minor differences in the error handling from case to case can be difficult. It adds to programmer cognitive load.
Here we’ve introduced some improvements.
We start by wrapping the db get functions. The wrapper functions take three parameters: the input originally required by the getters, a success callback, and a failure/error callback. The wrapper functions include all their own error handling. They look at err and status codes and call their error handlers instead of their success callbacks when appropriate.
This allows putTogetherSomeData() to flow better. It first defines the error handler function that it uses to clean up after one of its operations fails. Then it calls the wrapper functions. The success functions don’t bother with any predictable error handling at all, because they simply aren’t called in conditions that count as pure errors.
The error handler is similar to an exception handler, in that you can define it at the level where it makes most sense to handle the error. Lower levels can just toss it on up. But unlike exceptions and err params, you have to define that function somewhere; you can’t just forget to write the error handling.
Weaknesses: One hand-written wrapper per call. Doesn’t help functions that throw exceptions.
Advantages: If you’re like me, you’ve already wrapped many of your third-party db driver calls to do things like log.
Here we’ve auto-wrapped predictable functions.
Weaknesses: Not every function will be auto-wrappable, because the application might have different needs on different invocations of a third-party call. Not enough data is making it back to the error handler. That callback extraction code is iself boilerplate that needs to be refactored out. I like the assertions, though!
Other approaches to the problem
Promises. See q, a popular implementation of promises.
![theprofoundprogrammer:
[text: “who the fuck indents with spaces, you should be jettisoned into space”, photograph of the deep reaches of space, where no man has gone before]
[HD Version]](http://25.media.tumblr.com/tumblr_m8bo537gJS1rzupqxo1_500.jpg)
[text: “who the fuck indents with spaces, you should be jettisoned into space”, photograph of the deep reaches of space, where no man has gone before]
Source: theprofoundprogrammer
-
Find me on
hJZTQMSP