It is never too late to make that change you wish to see
This post on the PLT discussion list reminded me of me. There was a point where my interest in programming languages was more about what you could do with a language, without much of an emphasis on the why you would want to do such a thing. While you can do a lot of interesting things in different languages, there is often more value when there is reason, or vision, of why you would do those things. From my perspective, most languages have, at one time or another had some guiding vision or force behind them.
Eiffel has Bertrand Meyer saying “Everything is an object, and be static about it” and C++ has Bjarne Stroustrup saying “Keep it fast, keep it generic”, Scheme “Programming languages should be designed not by piling feature …”. Ruby has Yukihiro Matsumoto saying “It makes sense to me, if you don’t like it, see you later!”. Consequently there are a lot of really “neat” things you can do in Ruby, but it is not always obvious to me why you might want to do those things (I’m excluding the obvious ones so give me a break on those). Mats knows, and if you don’t “get it” oh well! The vision, or reason, extends all the way from the macrocosm of the entire language to the microcosm of its individual features.
Programming language features are there for a reason. While I will always find individual features interesting in terms of what you can do, one of my goals as a programmer is to always study with enough discipline to understand why such features exist.
As a programmer it is your duty to understand those features before utilizing them. Matthias’ reply to this post provides an excellent example of the conciseness and clarity that are the fruits of such discipline.
Last year some of my friends and I both attended and presented at Barcamp Milwaukee. When you have a bunch of people coming together to discuss things about which they are really passionate, well, you can’t beat it. It was a lot of fun, I met a lot of wonderful people, and even made some new friends. You can watch a video about that event here.
I just heard the news that BarCamp Madison #2 is getting lined up. Here are the details:
The Home Page
The Google Group
DrScheme provides a very versatile keybinding system. Out of the box you get bindings that make it very easy to navigate and even refactor your code. One keybinding, insert-lambda-template, works by surrounding the selected code with a lambda function. By default, insert-lambda-template uses the lowercase lambda symbol λ rather than the word lambda. As DrScheme encodes its files in utf-8 it has got no problems with this (in fact DrScheme has shortcuts for inserting most other Greek characters), but if you use other tools to edit or process your source code you may find that they (quite disappointingly) choke on it. For that reason, I wanted to modify the keybinding so that it would use the world lambda rather than the symbol. There are two ways to go about doing this.
The first involves modifying the source code of DrScheme itself. This sounds harder than it is as it doesn’t even involve downloading the source code. When you install DrScheme, it includes a number of source files used to customize itself. If you wanted, you could look up this keybinding, change it, and re-run the setup program. I don’t like this approach, though, since it forces the user to re-build part of the program. That leaves us with the second alternative, a custom keybinding.
A custom keybinding is easy to implement and add. To write it, I copied the definition of insert-lambda-template and changed the lambda symbol to the word lambda. Next, I went through DrScheme’s Edit->Keybindings menu to select Add User-defined Keybinding. That is all it takes.
My keybinding file can be downloaded here.
Be good once, be an angel once; it is the smallest moments that change lives.
DrSync is a plugin that saves your files on frame deactivation and reverts them on frame activation. This tool is of particular interest to folks who run external programs like version control or build related tools on files which they are editing inside of DrScheme.
Continue reading “DrSync: Automatically synchronize file changes in DrScheme v370 and above”
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!
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!
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?
Perhaps it was a result of anxiety.
The OLPC project’s vision is to “provide children around the world with new opportunities to explore, experiment and express themselves.” To help further their goal, the OLPC folks gave us the opportunity to purchase one laptop for ourselves while at the same time purchasing one for a child. Over the past month I’ve read, talked, and blogged about the XO, played and tinkered on the XO, programmed, hacked, and surfed the web on the XO. It has been a lot of fun, but more importantly, it has changed how I think.
OLPC is pitched as a learning project, but it is so much more than that. When you learn, you change; you make opinions and get ideas and live your life differently. It is a personal growth project. You will collaborate, exchange ideas, and make decisions. You will develop your own philosophy, hear others, and be a better person for it. Whatever path you take on this journey will lead you to the same destination: knowledge.
If you weren’t able to, didn’t want to, or maybe even didn’t know about the XO before today, it is not too late to spend some time getting to know more about both the OLPC project and the wonderful little machine that is part of it. If you are interested, please read on.
Continue reading “Grants OLPC XO Mind-Share Experiment”