Static and Dynamic in Programming Languages

References to static and dynamic programming language features often come up on discussion boards; and are often made in an inconsistent if not confusing manner. It seems that dynamic and static refer both to name binding and type checking. I wanted a clarification; the following is my take on what I learned based on reading a TSPL along with Wikipedia articles on Name binding and Type systems.
Name binding refers to the abstraction provided by programming languages by which we associate a “name” in the code with an “object” in the execution environment. In statically bound languages, the binding can not change, so it can be made before the program runs. In dynamically bound languages, the binding can change or in other words is not yet known, so it can not be made before the program is executed.
Type checking refers the process by which the language runtime applies its type rules. In statically typed languages, this process occurs before the program is executed. In dynamically typed languages, this process occurs while the program is executed.
The fun thing to do now, of course, is to determine how name binding and type checking occur in your current language of choice, and then figure why they do so in that manner!

Sometimes the first 80 percent is "good enough"

There is a joke among programmers: when the project manager asks how complete is the project, and you’ve finally reached the “%80 complete” mark, you tell him the good news because now you all know how long it will take to finish the 2nd %80 of the project! Sometimes this is just how efforts evolve; and it its not just limited to work efforts.
For the past month of so I’ve been practicing a beautiful song called “Over the Hills and Far away” (aka OTHAFA) by Led Zeppelin.
It has been a challenge for me. The practice-duration/song-duration ratio of OTHAFA’s has been a high. Learning it has almost been like work project: you get an idea of what needs to happen, start digging in, and eventually figure out what *really* needs to happen!
Ultimately, it took me about a month or so to learn all of the parts of the song (aka the first %80), and based on what I can see it will take another month to be able play it well enough to perform it (aka the second %80). Don’t get me the wrong, the first %80 means I play the parts correctly and it sounds nice. There are just all of the details that really take it from sounding “good” to “great”. It has been frustrating, though; as I started studying the 2nd %80 my progress slowed and it was a little bit disheartening. I soldiered on, but man…
Talking to my guitar teacher about it really helped me put things in perspective. He explained that the goal of learning the song was to learn all of the guitar playing techniques in OTHAFA that I would end up using in %80 of all of the other songs that I would end up learning. In other words, he had a clearly defined pedagogical approach to my course of study, mastering the 2nd %80 was more like a bonus, or an optional goal that I could pursue if I so desired. Wow, I had no idea; I felt a lot better after hearing that.
My take away from all of this is what when it comes to learning, it is really up to you to decide whether or not *now* is the right time to pursue that 2nd %80 of whatever you are learning. Perhaps even more important is using enough discretion to determine whether or not you are actually moving into that 2nd %80, or you are simply moving outside your comfort zone because *that* can feel even more difficult that the latter!
Whatever the case, keep on learning, whatever you can, and have fun doing it!

Bubba Zanetti on "the it factor" in programming

When it comes to identifying “the it factor” in programmers, everyone has an opinion. Paul Graham attributes it to good taste. Bertrand Meyer attributes it to doing things with class. Neither of them, though, of even come close to revealing the truth of it as Bubba Zanetti, the preeminent philosopher of the wasteland, did when he identified style as “the it factor” in programming.
His seminal contribution to answering this age-old question came to him in a fit of inspiration following a conversation he had with another programmer. In reply to said programmer, who had just explained that he would never learn Lisp solely for the fact that he hates parentheses, Bubba Zanetti suggested that:

You just don’t have the style, do you, chicken shit?

Bubba Zanetti clad in helmet on his bike
Addendum: When questioned as to why many of today’s programmers lack the so-called “it factor”, Bubba Zanetti suggested that:

Perhaps it was a result of anxiety.

Want to chat about Scheme?

Email discussion lists and comp.lang.scheme are an excellent to start.
Another option is #scheme on IRC at Freenode; there is nothing like speaking to another human being about Scheme.
When you talk with folks; you learn faster and have a lot more fun. When you are really digging into a concept, the kind soul who answers your question at just the right moment can make the difference between learning the concept now, or in a few days. Not to say that learning is a race; it is just so much fun that I think everyone loves to learn the next thing!
An aside; I’ve found that my mastery of topics, and in particular the lack thereof, is revealed much more quickly to me when I open my mouth! I won’t miss a chance to do so!

14 Ways to Write a Spelling Corrector

Peter Norvig posted this article explaining how implement an “industrial-strength spell corrector like Google’s” in only 21 lines of Python!
This article is a pretty fun read, especially for folks looking for fun problems to solve in their programming language of choice (or hopefully in the new language that they are currently learning). Be sure to check out the implementations that folks provided in other languages.