Tag: Programming

How do you find the perfect programming language?

For many years I sought “the perfect programming language”. Traveling aim-fully from language to language, I found that there are a number of aspects to enjoy when it comes to a particular programming language, but I never found one that was “just right”.
During that journey, I started out as a slave to syntax. I had to “like” the syntax. Even when I found a syntax I liked, I would find that the language would be too narrowly-focused. Most general-purpose languages force you to shoe-horn your solution to a problem into how the language creator wants you to solve it. Most programmers hate being forced to do anything; especially how to think.
Eventually I realized that there is no “perfect programming language”. Perhaps, though, there is a language that is “good enough”.
A lot of folks love the programming language Lisp. It provides all of the core language features you could ever need. On top of that, it lets you tailor the syntax to your pleasure.
From what I know about Lisp, it is “good enough”, and in the world programming languages, that is probably just about the best compliment you could give any language.

On Python and Lisp

The last time I spoke to a friend of mine who knows both Scheme and Common Lisp (among many other programming languages), his current language of choice was Python. More or less, he said that it just “feels right” (I need to pick his brain more on this).
Is Lisp the future of Python? Do Lispers gravitate towards Python? I’m not sure yet, but this paper aims to shed some light on both of those questions.

When Code Really is Art

For all of the programmers who lament the fact that code is not recognized as art, there is Piet.
Joking aside, once you get up to speed on stack based programming, this looks like a fun interpreter project. I am supposing that there are some very interesting opportunities on how to literally make your code “more beautiful”!
Addendum: 09/08/08
Here is a hello world program with a thorough walk-through and explanation of how it works.
Addendum: 12/28/08
Possible projects:

  • An interpreter
  • A picture editor
  • A graphical representation of the interpreter
  • A Scheme to Piet compiler; trained to generate “pretty pictures”

Disciplined Thought: A Programmer's Friend

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.

Nonstandard Interpretation with Scheme

In response to this excellent blog post by Dave Herman, Jay McCarthy pointed the reader to this interesting paper about creating a language construct that allows you to modularly redefine how your code (that you may or may not have written) gets evaluated (in other words, nonstandard interpretation).
Nonstandard interpretation

is a powerful and useful construct that supports such tasks as tracing, security logging, sandboxing, error checking, profiling, code instrumentation and metering, run-time code patching, and resource monitoring.

Obviously, these things aren’t new features. You can probably already perform nonstandard interpretation using your language of choice.
The interesting thing about this approach is that rather than performing compile time environment or code manipulation, a new language feature is applied to perform the non standard interpretation at runtime.
While both will get you to the place that you want to go; only the latter offers you an opportunity to build a conceptual framework for understand how you reached your destination. Neat!

BarCamp in Wisconsin

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