Visualizing Lisp without parentheses

Michael Weber had the inspiration to imagine how might one visualize Lisp without parentheses in his mwe-color-box.el extension to Emacs.

Below is a screenshot from Michael’s page. More of Michael’s Emacs Hackery is available here.

[[http://www.wisdomandwonder.com/wordpress/wp-content/uploads/2008/02/color-box.thumbnail.png]]

Why you might want to learn FORTH

You may or may have not heard about the programming language Forth, but if you have heard about it, you are very likely to have heard about it from some very happy, passionate Forth developers!

The best advocacy/introduction/tutorial I’ve ever read about Forth is located in the beginning of source code for this Forth interpreter!

After reading this, it is hard not to get excited about the programming language Forth.

GTK-server

GTK-server is another way to write portable GUIs with your favorite programming language.

The GTK-server is a free, open-source project, which offers a stream-oriented interface to the GTK libraries, enabling access to graphical user interfaces for shellscripts and interpreted programming languages using either GTK 1.x or 2.x.

Low Exposure: librep

Have you ever heard of librep?

librep is a dialect of Lisp, designed to be used both as an extension language for applications, and for use as a general programming language. It was originally written to be mostly-compatible with Emacs Lisp, but has subsequently diverged markedly. Its aim is to combine the best features of Scheme and Common Lisp and provide an environment that is comfortable for implementing both small and large scale systems. It tries to be a “pragmatic” programming language.

Low Exposure: IronScheme

Have you ever heard of IronScheme?

IronScheme [aims] to be a R6RS compliant Scheme implementation based on the Microsoft DLR.

These aren’t just nebulous goals either, they’ve actually got the interpreter up and running!
With so much development going on around the DLR right now; I’m going to pay extra special attention to when the *next* Lang.NET symposium is going to happen. It looks like a lot of fun!
Addendum: 24/10/08
ANN: IronScheme 1.0 beta 1

Using Scheme's Eval in Sandbox

One of the most tantalizing features that folks hear about Scheme is the eval function. While in reality, when it comes to meta-programming most modern Scheme distributions have evolved other mechanisms to do so, eval is still a big draw. The biggest shock most folks have when it comes to Scheme, though, is that you can only evaluate expressions in the top level environment. If eval holds your interest long enough, for perhaps any number of different different reasons, you will eventually reach the point where you want to do use it to evaluate code that you didn’t write (my inspiration came in the form of the Dolphin Smalltalk tutorial task where you write network chat clients that can send code to each other for execution). Whatever *your* inspiration was, though, you will also reach the point where you realize that you don’t necessarily want arbitrary code to be executed in the environment in which you are running your program; you don’t want folks sending (exit) for example, that can be pretty irritating. One way to work around this issue to to evaluate your code in a sandbox.
Here are three ways to do it with PLT Scheme: DynamicEvalCustomNamespace, DynamicUntrustedEval, and Sandboxed Evaluation.
Addendum 04/22/08:
Here is a link directly to the Schematics PLT package which provides “a library of useful procedures on namespaces”.

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!