Good Singletons

Singletons - we’re better off without them

I was first introduced to the singleton pattern as an alternative to global variables (”global variables are bad, use a singleton instead”). But this is one instance where singletons emphatically should not be used. Replacing a global variable with a singleton is just a lazy way of avoiding global variables without avoiding any of the problems inherent in global variables.

He goes onto list the reasons not to use singletons this way which include (in my order of importance): difficult to test, inhibits code reuse, breaking modularity, inadvertent changes occur between accesses and multiple references.

A singleton is responsible for both its behaviour and for ensuring that only one instance of it exists. In other words, it is responsible for two unconnected activities. This should usually be avoided and the unconnected activities should be implemented in different classes.

Good Models - My Super-Turtle is Better than Yours

• Standards and Pseudo Standards from Celebrating OWL interoperability and spec quality. Can a standard be based on a pseudo standard? Another posting also points to "An Investigation into the Feasibility of the Semantic Web" about the feasibility of integration using ontolgies.


• Beyond Belief 2006 Session 5 includes Paul Davies (asks why the universe should even be understandable to human beings, why he's no longer a Platonist and levitating super-turtles) and Session 9 on why religion may have a place.


• Agile Atheism "I am not agile because I don't believe in the agile religion and I don't accept its dogma. I like the engineering and planning practices that agile teams use - in the same way that I like people who do nice things (even when they do it because of fear of divine retribution). The difference is I don't want to be constrained by dogma into only doing those sensible things which are prescribed by agile. In the same way I don't like being prevented from doing sensible social things because of religious beliefs."


• Jane's Rule for Loading Dishwashers "Compare this to test-driven development. There may be a little more effort when writing code, because you are writing programmer-tests to drive writing that code. It's an "unnatural" process, like sorting silverware into sub-bins when loading the dishwasher. But the true benefit comes later in the project (possibly just minutes or hours later), when you can rely on those programmer-tests to make refactoring safer. And since you fixed bugs during TDD, you have much less work fixing bugs later when it comes time to ship your product."


• How can I get financial market information updated automatically to my spreadsheets?


• 10 most intelligent / least intelligent dogs My dog is apparently the stupidest breed with regards to obedience. I'm not sure I'd call obedience a sign of intelligence (the complete opposite really).

Strong Typing without the Typing

Functions, Types, Function Types, and Type Inference "One of the most important things to recognize about Haskell's type system is that it's based on type inference. What that means is that in general, you don't need to provide type declarations. Based on how you use a value, the compiler can usually figure out what type it is. The net effect is that in many Haskell programs, you don't write any type declarations, but your program is still carefully type-checked."

"If we look at that type, and think about what the factorial function actually does, there's a problem. That type isn't correct, because factorial is only defined for integers, and if we pass it a non-integer value as a parameter, it will never terminate! But Haskell can't figure that out for itself - all it knows is that we do three things with the parameter to our function: we compare it to zero, we subtract from it, and we multiply by it. So Haskell's most general type for that is a general numeric type. So since we'd like to prevent anyone from mis-calling factorial by passing it a fraction..."

Currently I'm enjoying the print version "The Haskell Road to Logic, Math and Programming" (links to the PDF version). I haven't appreciated the writing style used in this math textbook this much since, "Introduction to Graph Theory". I'm still waiting for Haskell to reach 0.1% popularity.

Simplicity, Good Design and Refactoring

Questions for Paul Graham - Simplicity and beauty in art, science and programming "Perhaps we're at a point where art and science and programming diverge. Science (often) aims at finding the simplicity behind the apparent complexity of the universe. Engineering usually aims at efficient solutions, excluding the extraneous which introduces cost and more paths to failure. Art doesn't always aim at simplicity. It just as frequently tries to expose the complexity of what looked simple. Thus, perhaps the union of art, science and engineering maintained by Paul's essay isn't fundamental, although there are certainly historical periods in which they align."

Video of interview of Paul Graham and original article Taste for Makers.

Mocking the Inspector

TDD Anti-Patterns "The Mockery - Sometimes mocking can be good, and handy. But sometimes developers can lose themselves and in their effort to mock out what isn’t being tested. In this case, a unit test contains so many mocks, stubs, and/or fakes that the system under test isn’t even being tested at all, instead data returned from mocks is what is being tested."

"The Inspector - A unit test that violates encapsulation in an effort to achieve 100% code coverage, but knows so much about what is going on in the object that any attempt to refactor will break the existing test and require any change to be reflected in the unit test."

Languages - Open vs Closed World

What did Javascript have that Java did not? "Languages based on static inheritance and typing are good for building complex silo (i.e. closed world) based applications. However, a global scale Architecture of Participation requires more dynamic structures like that found in prototype based inheritance and dynamic typing. In such a massively open world, the distinction between metadata, configuration and instances is simply impossible to pin down into well defined classes and configuration files."

"Javascript by its design is fundamentally messy, however that is its advantage over Java. The path to any sanity may just be what Google has shown, when building silo apps, hide the messy details under a clean well defined Java facade. Never forget though, that these facades are abstractions that leak. Always afford your applications the ability to escape into the Web and Javascript when necessary."

Bruce Tate has recently had a new article published, "Crossing borders: Delayed binding": "The more you dig into type and binding strategies, the more you find that waiting until run time to bind to an invocation or type fundamentally changes the programming process, opening a whole new world of possibilities. True, you find less safety. But you also find less repetition, more power, and more flexibility with fewer lines of code."

The Fifth Element

Outcomes over Features - the fifth agile value? "An agile project – in fact any project – should focus on a set of outcomes. How we get there is less important than actually getting there. A CIO or business sponsor wants to solve a specific problem, by a specific date, and has an idea of how much money they are prepared to spend achieving that. By driving out a comprehensive list of stories, estimating them, and then rolling it all up into a Big Release Plan, you run the risk of focusing attention on the features (stories) and defining Success as the delivery of all these stories. This is exacerbated when the release plan is shown to people who weren’t part of the original exercise. They see the release plan and naturally assume that it is the primary “output” of the process.

In the manner of the Agile Manifesto, whilst there is value in delivering a list of features, I value achieving the outcomes of the project higher. This feels complementary to the other four agile manifesto values."

Via, Valuing Outcomes over Features.

Robert Glass

Author Interview: Robert Glass "If you had to sum up today's state of the art from the perspective of someone who experienced software development in the sixties, seventies, and eighties, what would you say are our best and worst traits.

Bob:Best traits? The depth and quality of available tools. The Agile belief in people over process. The Open Source focus on fun over duty.

Worst traits? The "us vs. them" mentality which causes today's programmers to see themselves as a separate and competing breed from yesterday's programmers. The tendency to reinvent wheels. The belief in Agile processes as being good for all problems. The hyped belief in Open Source as the best of all possible ways of building software."

Developer.* has some of his work, "Software Maintenance is a Solution, Not a Problem", "Success/Failure Criteria: Some Surprises", and "The Many Flavors of Testing".

The Common Misunderstanding of Design Patterns

A little while ago, I responded to Andrae talking about how patterns were just language defects. As I pointed out, "Design patterns are not reliant on OO, Java, C++ or any particular language or programming paradigm." and as an example the singleton pattern disappears when you use Spring et al.

Similarly, a much more popular blogging group are talking about the same thing with "Ralph Johnson on design patterns" and one of the author's of "Design Patterns" response, "Design patterns and language design".

Mark Dominus writes,

"If you're a language designer, and a "pattern" comes to your attention, then you have a great opportunity. The programmers using your language have a recurring problem. They have to implement the same solution to it, over and over. Clearly, this is a good place to try to expend some design effort; perhaps you can trade off a little simplicity for some functionality and fix the language so that the problem is a problem no longer.

Getting rid of one recurring design problem might create new ones. But if the new problems are operating at a higher level of abstraction, you may have a win. Getting rid of the need for "subroutine call" pattern in assembly language opened up all sorts of new problems: when and how do I do recursion? When and how do I do coroutines?"

And Ralph Johnson,

"No matter how complicated your language will be, there will always be things that are not in the language. These things will have to be patterns. So, we can eliminate one set of patterns by moving them into the language, but then we'll just have to focus on other patterns. We don't know what patterns will be important 50 years from now, but it is a safe bet that programmers will still be using patterns of some sort."

So this goes to the heart of what good design is. Putting in double dispatch or multiple inheritance is not necessarily an overall win in language design whereas something like closures may be. But like most things, especially related to design, proficient users are usually too close to the problem to make the right call.

Ten Times

What's the Secret Sauce in Ruby on Rails? links to Crossing borders: What's the secret sauce in Ruby on Rails? "Debates about Rails in the Java community have been intense and show no sign of dying down any time soon. Rails proponents boast of incredible productivity, with some claims of 10 to 1 over Java development. As a Java programmer, your knee-jerk response is to dismiss any wild productivity claims because you've likely heard them before and been disappointed. Java advocates increasingly insist that Ruby on Rails is a toy that can't scale, produces bad code, and won't work beyond the simplest applications. But as Rails praise keeps popping up -- often from credible sources -- a more prudent course might be to understand what Rails does well and to bring those ideas back to the Java platform. In this article, I'll explore the core features -- the secret sauce -- that are the essence of Rails's great productivity."

If Ruby is up to 10 times more productive that makes it about as productive as Python, Tcl and Perl, see "An Empirical Comparison of Seven Programming Languages".

Protected is Evil

I thought I'd blogged about this before but apparently not.

So I'm a fan of both Alan Holub's articles about "Getters and Setters being Evil" and "Why extends is evil". These articles reminded me of an early book by Peter Coad called, "Java Design: Building Better Apps and Applets" which introduced this idea of composition over inheritance. Certainly a predecessor to the whole IoC bandwagon.

In fact, re-reading Holub's article it's interesting in the summary he writes: "As much as 80 percent of your code should be written entirely in terms of interfaces, not concrete base classes. The Gang of Four Design Patterns book, in fact, is largely about how to replace implementation inheritance with interface inheritance."

Likewise, Arthur Riel's, "Object-Oriented Design Heuristics" doesn't ban inheritance but offers the few cases where it is should be used.

Tony Morris (a fellow mouse) has written, "Why extends is not evil". Where he talks about interface inheritance and makes a pretty good point: "The only keyword that is exclusively associated with concrete inheritance is the protected keyword. The use of this keyword should be avoided indiscriminately."

Ontological Programming

Semantic Integration "Basically semantic integration seems to involve using RDF/OWL to define mappings between XML vocabularies.

Recently I've been involved in co-ordinating a number of large scale data migrations to help integrate several systems. This inevitably involved exploring the business models in the affected applications to define a mapping layer to allow the data to be cleanly migrated. Also inevitably this mapping ends up being expressed as a bunch of (hairy!) procedural code. It would have been nice to have been able to express that mapping in a more declarative way, if no other reason than it's easier to understand and debug possible problems. An example of not being able to see the wood for the trees."

There are many way to declaratively map different schemas - SQL, OO and XML all have their own tools. The value that RDF has is that you can program to a single ontology and map all of these different data sources to it.

With RDF there's not only the ability to map between XML vocabularies but to program to an ontology rather than a schema. In this case, the problem goes from MxN to M+N (or even just M).

One of the articles that highlights this issue is The Impedance Imperative Tuples + Objects + Infosets =Too Much Stuff!.