Functional programming versus patterns

I haven't worked with a functional programming language since college, where LISP was big; I haven't touched Ruby or the C# 3.0 preview as of yet. Today I learned a couple of fascinating things about them: functional programs inherently support concurrent execution (Hejlsberg articulates this); and -- more of a "wow!" for me -- functional languages don't need no stinking design patterns:

In a functional language one does not need design patterns because the language is likely so high level, you end up programming in concepts that eliminate design patterns all together. Once such pattern is an Adapter pattern (how is it different from Facade again? Sounds like somebody needed to fill more pages to satisfy their contract). It is eliminated once a language supports a technique called currying.

I admit appreciating the dig at the pretentious and unreadable Gang of Four. But the important point is this: although we software engineers think of them as these happy helpful things, the very utility of design patterns reflects the inherent impedance between (imperative) programming and the software solutions we want to build. There is tremendous conceptual baggage involved in implementing a working system, and much of that baggage is necessitated by our implementation paradigms.

Now, whether or not this doesn't have to be the case, and functional programming's poop doesn't smell, as coffeemug at defmacro.org is implying, I don't know.

Niners

Dahlia made nine-months yesterday. I have to see her pictures from months ago to believe how much her look has changed already. She continues to be very curious and ambitious, and happy happy happy. Do not get into her line of sight, for she will pummel you with baby smiles until you melt.



We've been making more of an effort to read books with Dahlia, which is harder with the second child. She really enjoys classics like Huggy Buggy Shapes and Baby Boo!, even between nibbles on the book edges. I also get her up to the piano whenever I think of it, and she immediately lays down some chords; we'll see if this interest in the keyboard lasts, but it's seeming she's a natural lover of music.



I often threaten, in the morning, to take Dahlia to work with me, because she's such a cute little squirt ball -- couldn't I just set her on my desk next to the plant? Alas, she would tire of that. And she would try to eat the plant's dirt. But yesterday I did have the whole family up to the new office. My company's just relocated to a big building with glass elevators looking out on an impressive atrium. Elias loved it, noting the large air ducts (he loves to talk about large air ducts), then wanted to ride the elevators all day. Dilly just hung on Amy's front, taking all the sites in and forcing my coworkers to do that melt-until-you-smile-back thing.

Having a baby with you is like having a very powerful weapon, one which cuts through all grumpy-adult seriousness. Such a weapon is dangerous, though, because it has no "off" switch, and must soon be removed from places of employment before all production ceases and starvation begins to set in. I seem to recall that this type of civil-degeneration-due-to-babies was explored in an old Star Trek episode, no?

Link shuffle

I'm updating my humble links section:

Adding: The0phrastus, a software engineer-by-day and SF writer-by-love, apparently, who reads the snot out of Aristotle and paints nice pictures, such as a stylized nude of war-winning Athena, for fun.

Adding: Artchive, an archive of high-quality scans of fine art, such as breathtaking details of Mona Lisa.

Adding: Acid Free Paper, the thoughtful posts of an Objectivist fiction writer.

Dropping: Rough Type, because although Carr is justly and intelligently critical of the fall of civilization as manifest by far too many collectivist, anti-intellectual web-biz heads, there is good reason so many consider his blog to be a firehose of hatred. (Which reminds me of a funny comic-strip frame I saw years ago, about Jean-Paul Sartre at Christmastime: "Just look at this toy elf -- it's so hateful.")

Dropping: Charles Krauthammer, because not only have I realized he's not the somewhat-principled (ouch) defender of civilization I once thought (he's just one more rationalizer of neoconservative nonsense), but today he's even suggesting that a massive energy tax would somehow be an instance of "the essence of capitalism." Smoking something, he is. PrairiePundit supplies links to all the daily analyses of war I could want anyway.

Moving: The Intellectual Activist, from my Philosophy link-section to the Politics link-section. Although this has nothing directly to do with Tracinski's recent (though some say hardly surprising) bomb that philosophy doesn't really do anything, I am working on what I want to say about that.

Etymology search

Want some hints about the etymology of a word, and somehow you've misplaced your 145-pound Oxford English Dictionary? Etymonline might be a good place to start. (Found via The0phrastus.)

Is CCDD part of TDD?

Does test-driven development (TDD) entail what I'd like to call client-code driven development (CCDD)? Sells contrasted them in 2004, while admitting that what he called "client-driven development" (confusingly, since it more readily labels something else) may just be a degenerate case of TDD. Yesterday, Box noted what a good thing Sells's approach is. I agree.

Although CCDD -- which, in ad hoc form, must be just about as old as programming itself -- doesn't seem to be referenced explicitly in some common overviews of TDD, I find that in practice TDD entails CCDD.

In TDD, the software engineer follows this recipe for success:

1) write test A for a requirement
2) run test A, see it fail
3) implement production code
4) run test A, see it pass
5) go to 1, proceeding to test B

This appears simpliciter to define a fail-safe process for writing code. But if this is all you've got, as soon as you start, big questions arise about how to proceed that this recipe does not address. The rub is that step #1 assumes a test of something specific -- but what? Oftentimes, for me, the target production code is some method, but how was it chosen? The tests for method Foo() may drive the implementation of Foo(), but they cannot drive the need for Foo().

A wider scope is needed to choose which Foo() and which Bar() to create when and where. In a sense, one can stay true to the TDD dogma and say that higher-level tests -- ultimately, the user tests for stories and requirements -- have the necessary scope to drive all narrower decisions. My point is that, in practice, the meat of this process entails writing, over and over again, client-code calls to code that doesn't exist yet -- which forks a sub-process for the software engineer: these tendered client-code calls are the proximate causes of dependent units of code, whose implementations will be driven by their own tests.

In effect, tests will drive an implementation, which itself often "drives" the need for more code and thus more tests. CCDD is an intrinsic part of TDD.

Why people write?

Quote of the day (meaning, the day that I found it):

Virtually every useful tutorial in the world was written by a moron-turned-expert.

Best Pleo video yet

Yet another article on the forthcoming baby dinosaur robot, this one has a good five-minute video without any monologue, just an example round of playing with a Pleo: waking him up, poking at him playfully, inducing him to peer over the edge of a table, then picking him up until he goes back to sleep. The user in the video is the inventor. The three-page article is interesting too, giving background on the Idahoan inventor, who use to be a mime before creating the consumer-sensation Furby (which looks almost as annoying as those singing-and-dancing snowmen advertised during the holidays) and earning himself $10 million.

To be released in March at $250, the Pleo seems an unlikely purchase for us, but it sure is tempting. I'm just fascinated by the fact that we are at the cusp of the age of robots, and this will go down as one of the first mass-market attempts at a life-like robot. But then I am not sure if I want the kids to be around a robot pet just yet. Would it be fun for more than a week, then become a very expensive toy mistake? At the other extreme, would Elias get so emotionally attached to it that he'd cry when it breaks? What if he breaks it himself, will he be devastated? And is it just wrong to love a robot -- or is it good to develop a sense of both what a robot is and isn't? And isn't having pets and toys which need gentle care while they are alive/functioning a good part of life? Et cetera.

For my own part, I want to know more about the AI ware to get a good idea of how complex and therefore interesting this thing really is. Sounds like it is programmable to some extent (or maybe you can't write scripts, as you can for Lego bots, you can just set the Pleo's personality parameters), but there's not much it can physically do besides sleep, purr, wiggle, walk, and respond to pokes and pets. Hmm, sounds like a cat, minus the barf and litterbox ... that's starting to sound like a pretty good investment. Maybe this should be the marketing line: It's cheaper than a year of cat food.

UPDATE: Bill Gates compares, in five pages, the robotics industry today to the software industry of 30 years ago. Carr takes a quick glance.

Gates confirms something for me: the biggest challenges in robotics are software problems. But I'm skeptical of his suggestion that robotics is especially in need of multi-threaded software. His example of a robot too busy adjusting its drive motor to notice an imminent cliff is silly -- even Office bloatware is rarely that unresponsive -- and his praise for Microsoft's "concurrency and coordination runtime" just sounds like an ad to me. (Microsoft is obviously playing catch-up in robotics to other software giants ... like Lego.) If we've learned anything in software, it's that task switching on a Von Neuman architecture is a really, really good way to achieve virtual simultaneity. Moderately complex multithreaded programs are not just "difficult" to write, they're just shy of impossible for humans to get bug-free.

Montessori method turns 100

Here's a picture of opening day of the Casa dei Bambini (home of the children), Rome, Italy, January 6th, 1907. More info here.

Snodgrass for president

My post title may be juveline, but it gives some sense of how impressed I am with two articles on our war situation by Colonel Tom Snodgrass (found via PrairiePundit).

The first article begins with a quote of Clausewitz -- so you know where this is going. What follows is dispassionate analysis of the steps the West would have to take to win in Iraq and the wider Global War on Terrorism (GWOT). His identification of the cardinal errors of both the Left (we can't win!) and the Right (we are winning!) during Vietnam obviously applies just as well today.

Not to claim this summarizes the article, I can't resist quoting this pearl: "political negotiation has a Crusader's chance in Mecca of succeeding."

The second article gives a sketch of how US leaders became epistemologically resistant to the concept of victory after WW2, most notably in 1961, and we are still in that dark valley -- thus our current operations are fundamentally police actions premised on socio-political fantasy, and destined to fail. The critical issue raised in this essay is whether or not a modern democracy can sustain and win a war. I think: obviously it can, if it wants to -- but we will not want to without a lot more of this type of thinking.

McCoffee blues

New Year's Resolution-time being prime time to review dietary choices, we made the mistake this weekend of imbibing the "nutritional" information for our favorite Starbucks drinks. It is hardly surprising that most of the drinks are sugar- and fat-bombs, but the bright side is that this demotivation dovetails nicely with another resolution: to spend less money.

The only good news for fans is that, as of Wednesday, Starbucks in Portland will have no trans fats in their foods -- though I don't know if that includes the all-evil "whip" which crowns the best* Starbucks drinks.

* "Best" is used in a purely relativistic sense here, since Starbucks is incapable of making an actual latte or cappucino -- or even, some would say, a good cup of coffee. But luckily, for any of those treats, Portland is Mecca. You have not lived until you've had a Stumptown cappucino in the downtown shop that is so cool, you have to be unemployed and in a band to get in.