Journal of my investigation into the development of a new programming language
Guiding Principle - Clarity
Can there be emergent
guiding principles? As I play with these ideas, I'm finding myself reacting to this feature or that one of one language or another, looking at that reaction, and trying to analyze what drives it.
So at some level, the primary basis for all of my decisions here is visceral. But what makes me react the way I do? I think there are genuine, consistent principles underlying my reactions, and I think I can discover them. Thus: emergent, guiding principles.
One thing I see in the examples I'm coming up with is brevity. In Adjectives
, shorter code fragments were a compelling argument in favor of the addition. But brevity can make code harder to understand - I'm thinking here of Perl's regex features. And when it makes code harder to understand, I don't like it. So brevity isn't primary.
Well, then, how about clarity? Expression of intent? Yeah. How many ways are there to say this? Language is about communication. With people. Lots of programmers seem to think that programming
language is about communicating with the computer, that as long as it works - or as long as it compiles - it's fine. I don't. I don't want the burden of unnecessary work of figuring out what I or some other programmer meant six month or six years - or six hours - ago. I don't want the added risk of introducing new bugs because I didn't understand what it was doing in the first place, or because I was confused about how to describe my changes.
A well-written program is easy to read; you look at it and know what it does. And if it's broken, or if it needs modification, you know how to go about changing it. So, naturally, a great programming language makes it easy to write programs that are easy to read.
So, clarity, or the facilitation of clarity, seems to be my first guiding principle. Stay tuned.