Tag: philosophy

The energy to become productive in a language

I’m not doing programming for it’s own sake, but because I’m trying to get my real work done and that involves writing code. I have neither the inclination nor the luxury of time to really delve down and spend three or six months learning a complex language in the hope that I’ll be more productive

— Janne
In the past I have said the same thing myself. This seems to be the status quo for the industry. I don’t feel that way anymore, though. It was the result of a feeling and not a rational thought process. Once you think about it, it doesn’t really make much sense.
If we don’t learn anything more than what we already know, then how will we ever get any more productive?
(via this comment)

A culture of problems

It seems like my culture has expended a great amount of effort in teaching the individual how to identify and report on the sad state of affairs which he is in, but has not taken the next logical step by teaching him how to move beyond that state. He is a man who knows how to identify problems , with no chance of solving them. This is a cruel punishment that has created a culture full of problems seemingly without solutions.

How many kinds of Schemers are there?

Since the beginning of my study of Scheme I have tried to understand the community. What I have found is that if one had to define a single trait by which you could make a classification it would come down to whether or not they wanted more than what R5RS defines, or not. A few days ago in this thread on comp.lang.scheme, a poster elaborated on this: 


1. People who prefer R5RS, and think it should not have been extended.
(Felix Winkelmann, maintainer of Chicken)
2. People who like R5RS, dislike R6RS, but think a better standard for
Scheme is possible (Will Clinger, maintainer of Larceny)
3. People who use R6RS as their primary language (Aziz Ghoulum,
maintainer of Ikarus)
4. People who use a particular Scheme implementation (myself, using
PLT)

As he pointed out, that is a non-exhaustive list. A question for the reader:

“What is missing?”

Is Unicode in the code taboo?

MzScheme supports UTF-8 encoded files. Combine that with DrScheme, which makes it pretty easy to type in Unicode symbols, and somewhat suddenly, and surprisingly, you have the opportunity to work with symbols in your code beyond the standard 95 character ASCII set that we all know and love. What are the implications to you as a programmer?
The simplest implication is that you now have the ability to work with 100,000+ characters. In case you felt limited by the inability to use the characters of your native tongue like Tamil or perhaps Braille, you are restricted no more. Scientific programmers may enjoy using Greek letters; and who of us wouldn’t like to use the letter π to represent Pi? For Schemers, perhaps you would use → rather than ->.
The common theme among these atypical examples is that they facilitate communication. Without getting into the deep theories and concepts behind the value of communication and how the limitations of a language affect it; I would share a quote relevant to us as programmers regarding how we communicate to each other with our code:

Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.

— Donald Knuth
It seems like Unicode might facilitate that communication, but Unicode in code today is not at all common. Why might that be?
The usual suspects are that our tooling (IDEs and text-processing tools) doesn’t support Unicode well. Perhaps that is the case, but I am had pressed to believe that if people thought it had any value they wouldn’t simply add support to their tooling for Unicode. Fonts seem to be the biggest practical issue; lack of a supporting font usually results in an ugly box in place of the character. In the end I suspect that the worst culprit here is simply that Unicode in the code is a taboo: people simply won’t give it a try until a thought leader or two sheds light on the power to facilitate communication that Unicode brings.
Until then, you will have to be happy with Emacs and DrScheme.

Scheme and the Philosophy Behind Perl 6

Contrast Larry Wall‘s take on the “soon to be released” Perl 6 today [in 2008]:

Don’t design everything you will need in the next 100 years, but design the ability to create things we will need in 20 or 100 years. The heart of the Perl 6 effort is the extensibility we have built into the parser and introduced language changes as non-destructively as possible.

(via Computerworld)

with that of [R3RS] Scheme in 1986:

Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.

(via R3RS, referenced in R5RS)

In other words, language implementers ought to accept that they aren’t going to “get it right” on the first try, and they should leave the language extensible for additions.

Are you as excited about Perl 6 as I am! 🙂

It is what you know that you don't know that matters most

The idea that “It is what you know that you don’t know that matters most” has been coming up a lot lately. Here is one fellow’s take on it via this post:

I have the the distinction of being the “programming languages guru” here at Dobbs Code Talk. So what does this mean to me? It means that after many years of programming and studying language design, I am reasonably aware about what it is that I don’t know about programming languages. Contrast this to something like helicopter mechanics, for which the only meaningful thing I can say is that I know nothing about it.
It is perhaps a dubious achievement to be knowledgable about the limits of your understanding, but at the same time I don’t really think you can do any better.

Agreed.