Friday, February 11, 2011

When is Lambda not a Lambda, Part 2: Replacing the Stubs

In the Ruby programming language, there is a construct called "lambda". In answer to the second part of the apprentice's question, it is called lambda because the developers wanted to give it an air of authenticity, by identifying the construct with the computational theory of lambda calculus.  The Ruby developers weren't the first to do this, and won't be the last, and are following in a tradition among computer scientists of borrowing popular labels from one another.

Not that I know enough about the internals to tell whether or not they are justified in their use of the term lambda. What I do know is this: that anonymity has nothing meaningful to do with the computational theory, nor anything really meaningful to add in practice. 

What makes lambda special, at least in Ruby, is not that it doesn't have a name. In fact, it does have an identity, otherwise Ruby couldn't pass references to a lambda around as function arguments. Ruby just hides whatever internal identity it maintains for a lambda from the user. Nor does it stop the user from assigning a lambda to a name. Anonymity is completely and utterly irrelevant to the purpose and utility of a lamba. 

Where anonymity really comes into play is in the concept of a block, which in Ruby is a syntactic sugar for what other languages might call an inline function.  

What makes lambda special is that the enclosing scope is bound to the lexical environment in which it is defined, and that it maintains a calling structure from which the "return" keyword will properly exit. This differentiates lambda from a method which has a scope defined by the object to which it is bound; and from a Proc, which doesn't impose a deeper return nesting... acting as it does as a reference to the otherwise anonymous { block } syntax. Oh, and lambda has the argument signature more strictly checked.

Apparently the implementation is all based off of the kernel Proc class. So Ruby's lambda isn't really much like its functional counterparts; like the "java" in "javascript", the name "lambda" is used more for affect than effect.  This is further highlighted by the name pollution, Y combinator gymnastics, and stack overflow surprises one gets into when attempting to use it recursively...  

On a side note, one has to give credit for the Ruby community for adding more functional language constructs. The reference implementation of Ruby 1.9 supports tail call optimization as an option. 

When is Lambda not a Lambda, Part 1: Conversational Mocks

One of the apprentices at the office asks
What is this thing called Lambda, and why is it called Lambda?
I'm trying to formulate a concise answer, when one of the more brilliant young developers in the office blurts out
Lambda is just a way to make an anonymous function.
My explanation thus cut short, sticks in my throat. His quip is pleasantly succinct and sufficient to move a pre-teen on to more productive work. I'm sure I came off as ignorant and overly complicated by comparison.

Except that his explanation, succinct though it was, is entirely and utterly


not to mention misleading. Now, the kids didn't really need an explanation, and they got the sort of glossed-over, abstract re-labelling that passes for an explanation without actually being one. Like saying that what makes something a circle is that it is round. It was a mock and a stub, a convenient pretense of understanding that allowed them to conversationally move on without getting bogged down by reality.

Not that he isn't capable of insightful explanations.  We're working in Ruby here.  He knows better. 

Thursday, February 10, 2011

Curious Misunderstandings and Other Faux Pas

Among this week's curiosities there stand out a few weirdnesses.  Like the slamming of doors by a 46 year old woman and being left to chill with my own thoughts for the rest of the night.  Or to have a seemingly professional prospect throw a hissy fit at not being rung up in a couple of weeks, saying he doesn't want to work with me after all.


The prospect-turned-insulted-date was weird enough. It was more disquieting to have someone close throw a tantrum for having to take her own dog to a potty break for the first time in days. That'll teach me for letting them take me for granted, all right!

Some people will get the wrong impression about you simply because they lack the empathy themselves to see things from your point of view. But it helps no one to be too agreeable too often. 

Why, Again

I've felt recently that I'm picking up new skills; still questioning the pace at which I pick them up, and why it seems frustratingly slower than those around me. I'm a loner, to be sure, not by conscious choice but apparently by the side-effects of internal preferences and tendencies as yet beyond my ken. Not that I feel alone in this... there are many who appear to be alone and just don't see it.

I have trouble following in conversation, in being where everyone else is being, doing what everyone else is doing. It is as if, if someone else is already there, squatting and tearing up the soil, I need to be elsewhere. Not sure why that is, or from whence it stems, but yeah, it has been with me since I was a little kid.

One aspect of this tendency to take a side-long view of social interaction, is that I'm constantly asking "Why"?  And the more focused I get on a single skill area, the more strongly that question pervades my thinking -- why is this a worthwhile technology, why will it be useful to struggle with what seems to be the gratuitous constraints it imposes, why am I focused again on technology when it is the social interaction that is most obviously my own stumbling block, and why is it that I am not profiting sufficiently personally or professionally from either my skills or relationships ?

But the most important question "why" seems to be pointed at everyone else... my peers... why are you doing what you are doing?  Sean Hannity reminded me of this on his radio show. As I flipped on the drive home, I caught the tail end of a conversation about him confronting a businessman over taking stimulus money. He remarked that as a former construction worker, it would have violated his sense of ethics to build an abortion clinic building even if it was well funded.  To me, it isn't whether or not a customer is "being made happy," it is whether what we are pursuing should be done at all. 

Saturday, February 5, 2011

Iron Filings

Iron by iron is sharpened, And a man sharpens the face of his friend.
A minor incident this week reminded me of this proverb. Actually, a lot of incidents do. As a metal blank is turned into a usable tool, it must first be shaped, then smoothed, and finally polished. Likewise, older tools can be refurbished by first welding, then re-grinding and polishing. In the process a lot of little bits of metal castings are generated, the stuff that was useful at some moment in time but now goes completely against the grain of the refurbishment.

My hope is to be able to find a path that makes me feel that I'm not constantly leaving great big piles of "me castings" around on the floor.

The other day, I cut some code for a Rails report. Relatively simple stuff. But there were a few problems. First, I was fatigued. Second, I was programming alone. These contributed to the actual root causes, the "me castings" for this week:

  • Short-cutting tests is just a way to lull yourself into a false sense of security. Run them the way they are supposed to be run, completely, from top to bottom, and pay attention to the details of what the results are saying. Make sure you run tests fully before attempting to commit changes. 
  • When you have a failing test, don't commit. Or if you do commit, make it clear to everyone involved that you have failing tests, and ask for help; or offer to commit to a branch; or stash the changes and move on momentarily until you can get help. 
  •  Line-wise and paragraph-wise Cut and Paste is a recipe for error injection. It is just dangerous, period. I used to code by cut-and-paste often in 4GL languages due to the repetitiveness of the apps' boilerplate approach to development. I foolishly thought I could use it and find a way to not inject errors. The lesson, in retrospect, is that there is no way to separate cut-and-paste errors from cut-and-paste. Copying lines and paragraphs is especially evil because my brain tends to be looking for and see the similarity, and auto-correct for the differences, but those corrections may never make it to my fingers.  Besides, the approach to Rails used here is most definitely not a boilerplate approach: the app may be copied to start, but everything after that is treated as one-of crafting. This was the most grievous "me casting" of the week.
  • Cutting into other's code requires special mindfulness. Doing it with cutting-and-pasting is completely wrong. Doing cutting-and-pasting while tired is a crime. At one point, I saw what looked exactly like a three-line function I just wrote,  so I cut.  It wasn't my function, and had I run Rake properly I would have seen that it was not. Fortunately, we had git. Make sure you communicate if you have an elusive sense of uncertainty, but especially if you feel completely confident. 
I'm tempted to force git to warn me had I not run Rake before committing, or obfuscate the line-oriented cutting commands in Vim, but these are mere technical crutches. The reality of the examples of practice that I'm seeing, is that it forces you to be mindful of your surroundings, of your code, of your peers.

Being mindful enough of the affect of your actions, and communicating often and early with those in your circle, is critically important. At least, if you want to stay in the circle. It has been many years since I've been in a group of developers that really functioned as a team. It is profoundly disturbing to see how much less proficient I can be compared to some of the younger developers, and as difficult to consciously spot and let go of poor habits. But I am trying.