Exploration Through Example

No.

.

.

.

.

.

Oh, OK.

@ctford asks:

@marick Have you blogged anywhere about with-redefs [a Clojure function used for mocking] and how it relates to mocking private fields in OO? I’d be interested in your thoughts.

@marick My concern is whether by using a test mechanism that prod code can’t exploit, am I reducing some of the design benefits of TDD?

——–

In order to design, the designer must find words (abstractions, if you wish) that give her leverage when thinking about the code.

In order for that leverage to carry over to writing and later changing the code, those words have to appear in it. Most importantly for a language like Clojure, verbs have to be reified as functions.

Testing makes design rigorous by forcing it to be concrete along a different dimension than coding (dynamic rather than static). Tests should therefore have executable (mockable) access to reified verbs.

A programmer using a function may need a conceptual understanding of those verbs, but does not need direct access.

Therefore the reified verbs may be marked private - but only if the tests have a way to evade that. (That is, the need to do the right thing with testing trumps the desire to prevent a future programmer from doing the wrong thing.)

In practice, I’ve found it mildly helpful to add a “testable” access level to public/private. That divides a chunk o’ code into (1) functions of interest to normal users of the code, (2) functions those users don’t need to care about, but that are important for understanding the idea behind the code, and (3) functions that are just a coding convenience.

I’ll be giving a keynote at ACCU 2013 on this topic: “Cheating Decline: Acting now to let you program well for a really long time”.

(Any resemblance to my own looming decrepitude is entirely non-coincidental.)

My premise is, roughly, this:

• We know that age causes cognitive decline. There’s some evidence that it begins well before a typical person’s working life is over.

• Programming, like mathematics, seems to be a field where that cognitive decline hits hard and relatively early. (There are all sorts of caveats around that statement, but let’s leave them for the talk.) Old programmers are thought not able to keep up with young programmers, to be wedded to old solutions to new problems, to be [fill in your stereotype here].

• Nevertheless, some old programmers notably defy this trend. Some are superstars who (unexpectedly) didn’t burn out young. Some weren’t superstars, just good, solid, eminently employable programmers when they were young, who (unexpectedly) turned out to still be good, solid, eminently employable programmers today (once they get past the prejudice).

• What’s special about those who smash the stereotype vs. those who reinforce it?

To answer the last question, I want to reach out to self-identified young programmers. If you believe you know someone who’s a stereotype smasher, I’d like to:

1. … interview you about what’s special about that older programmer (with attention focused on behaviors and habits rather than innate qualities).

2. … interview the older programmer and invite him or her to talk about the same topic.

If you are willing to participate, mail me.

I have Mountain Lion on my new machine. (What a horrible release.) I innocently decided to upgrade my Postgres installation to 9.2.2. I had a lot of trouble getting the Ruby pg gem to build. I found no single source that solved the problem, so I thought I’d post the solution.

The symptom is this spewage:

ERROR:  Error installing pg:
	ERROR: Failed to build gem native extension.

        /Users/marick/.rvm/rubies/ruby-1.9.2-p320/bin/ruby extconf.rb
checking for pg_config... yes
Using config values from /usr/local/bin/pg_config
checking for libpq-fe.h... *** extconf.rb failed ***

Note: if the “checking for pg_config” line fails, you have a different problem. Either you need to set PGDATA correctly, or make sure that the `pg_config` command is in your $PATH. A number of pages out there on the web explain what’s going on.

1. If you look at the `mkmf.log` file, you’ll see that (for some reason) the installer is trying to use `/usr/bin/gcc-4.2`. That doesn’t exist, so:

        sudo ln -s /Developer/usr/bin/gcc /usr/bin/gcc-4.2
   

   Thanks to Stackoverflow user dfrankow for that bit of the solution.

2. That still fails because the program you’re compiling innocently tries to include `<stdio.h>` (etc.) Unlike Unix systems since the beginning of time, there is no `stdio.h` in `/usr/include`. To populate /usr/include you have to start Xcode (version 4.X), go to Preferences, pick the “Downloads” tab, and install the Command Line Tools.

   Thanks to Tim Burks on Twitter for this piece of the puzzle.

I’ll be in Europe definitely between 9 April (Bristol) and 20 April (Kiev) and likely either before or after those dates. I have some ideas for workshops that we might have while I’m there, provided we can scare up someone to do the local arrangements (venue, mainly). I can work on finding participants, though help would be greatly appreciated.

Here are the ideas:

“Shell and Guts” combinations of object-oriented and functional programming

There’s been much talk about a strategy of having functional cores, nuggets, or guts embedded within an object-oriented shell. Here’s a picture from my recent book:

At SCNA, Gary Bernhardt described a different-but-similar approach. (Very neat - incorporating actor-ish communication between shells.)

This workshop would be about exploring the practicalities of such an approach. (Credit to Angela Harms, who proposed a workshop like this to me and Mike Feathers.)

Next steps in unit testing tools

This would bring together tool implementors, power users, and iconoclastic outsiders to make and critique proposals for moving beyond the state-of-the-practice of unit testing tools. Bold proposals might include: use QuickCheck-style generative/random-ish testing instead of or in addition to conventional TDD, or claiming that the next step in TDD is incorporating or replacing the sort of bottom-up tinkering in the interpreter that’s common in (for example) the Lisp tradition.

Community building for language and tool implementors

Although I released my first open-source tool in 1992, I’ve always been lousy at building communities around those tools. Other people have succeeded. This workshop would be a collection of people who’ve succeeded and who’ve failed, sharing and refining tips, tricks, viewpoints, and styles.

Format

Of the various meeting formats I’ve experienced, one of the most productive has been the LAWST format that I learned from Cem Kaner and Brian Lawrence. Some of the LAWST workshops produced concise, group-approved lists of statements that had substantial influence going forward. These three workshops seem like the kind that should produce such statements.

The LAWST format works best if it has a facilitator who has no stake in the topic at hand. (Such facilitators might well follow the style of How to Make Meetings Work or Facilitator’s Guide to Participatory Decision-Making.) I’d hope the local arrangements person could help find such.

If you’re interested in making one of these workshops happen, please contact me.

I’ve been invited to speak at the ACCU conference 9-13 April, 2013. Because I hate long plane trips, I usually only want to go to Europe if I can get something like a total of three weeks of paid work there. That can be a single engagement at one company, typically doing hands-on programming coaching or just plain programming, or it can be several smaller gigs.

Given Functional Programming for the Object-Oriented Programmer, I can also do Clojure or functional programming coaching and training. I have a two day Clojure course on the topic, though it’ll need substantial revision to match the book.

If you think you have possibilities for me, contact me. Thanks!

I’ll be speaking at Software Craftsmanship North America, November 9th or 10th in Chicago. Here is the abstract of my talk:

Primum: logic programming computes values for variables based on relationships between known facts. In the main, introductions to it are either based on logic puzzles (cannibals and boats!) with an at best unclear relationship to the problems we write programs to solve, or on laboriously reimplementing things (arithmetic!) that we can already do perfectly well, thank you very much.

Secundum: generating complex test data is a hard problem, in part because constraints (relationships) amongst bits of the data have to be obeyed. The sadly common result is fragile tests that know too much about the details of their data.

Ergo: I will explain logic programming by showing how it can be used to generate test data from minimal descriptions of what’s needed.

I wanted to learn Clojure’s implementation of logic programming (core.logic). So I wrote up a proof-of-concept of using it for test data generation. I think it turned out rather well, so I took the time to document it. There’s a github repository that includes wiki documentation and tests that are supposed to be explanatory.

It makes involved use of macros (in the sense of having macros that write macros). Those interested in macros might find what I’ve done interesting. That’s not documented, though.

Logic programming will be my talk topic at SCNA.

I’m somewhere between 1/3 and 1/2 of the way through a new book, Functional Programming for the Object-Oriented Programming, based on the tutorial I taught a couple of times last year.

You can find a description and sample chapters at Leanpub.

Mark Needham asked on twitter:

I replied:

He replied:

Since I’m in an explaining sort of mood this week, let me see if I can help.
Read the rest of this entry »

Prompted by Avdi Grimm’s post on underscores in program identifiers, I’ll publicly air my guess about why theBlightOfCamelCaseInfestsOurPrograms when_identifiers_with_underscores_are_obviously_more_readable. (Although Avdi is right that dashes are superior to both.)

As far as I can tell, the popularity of camel case came from Java, which got it from Smalltalk. But where did Smalltalk get it, and why did such smart people go so badly astray?

Flash back to 1979-1981. I was a computer operator for a PDP-10 mainframe at the University of Illinois Coordinated Science Lab. (I still have two pieces of that computer in my basement.) We had a bunch of VT-100 act-alike terminals. But off in a corner, where no one ever used it, we had a single terminal we called “the European terminal”. One interesting thing about the European terminal was that it had no underscore key. Instead, it had a back-arrow key. I have a faint recollection that if you viewed text with underscores on that terminal, it would show up with back arrows instead. (Or was it that the keyboard did have an underscore on it, but when you pressed it, it displayed a back arrow?)

It’s unlikely you’d write←identifiers←with←back←arrows←in←them and, in any case, some programming languages (such as Smalltalk) use back arrow to mean assignment (instead of, as was common before C took off, `:=`).

All of which makes me think—especially since Smalltalk came from Simula, and Simula came from Europe—was there no underscore available to the people who built Smalltalk back in its early days? Was that why they fell back on StudlyCaps?

(I even have a very dim memory of some language—I don’t think it was Smalltalk—where underscore, as well as a back arrow, could be used for assignment.)

Does anyone know?