These are a series of essays dedicated to chronicling my somewhat meandering, idiosyncratic, unpredictable, and even fanciful research into computer languages, and what it takes to develop a truly good new one.
I have recently become fascinated by the relationship between human languages (in my case, English) and computer machine languages.
How does English become machine language, as in computer programs?
Besides wikipedia, which has articles by now on all sorts of computer science subjects, my other two recent sources of inspiration are Paul Graham and Charles Moore. I've been burning up the links originating from:
How does one come up with a computer language (ie, something that is at least sort of English) that is truly powerful? And power seems to come down to two things, if I understand these experts:
One - is it powerful as an excellent consumer of machine resources?
Two - is it powerful as an abstracter of a programmer's ideas?
Are One & Two in conflict? Do they have to be in conflict? I'm finding this stuff really fascinating to explore right now.
The Genesis of this interest grew out of a computer architecture I have been designing over the past several years. Once I started trying to develop a higher level language for it, well ...
At this point in this introduction, I think it is worth mentioning what this set of essays (which for brevity, I will sometimes refer to as a blog) is not :
It is not an exposition of my computer architecture, the Flexible System Architecture, otherwise known as the FSA. Most everything I have to say about it is on the homepage of www.genapro.com and its associated links. For various reasons that work has been moved to a back burner. I will unavoidably have to refer to it from time to time, but this blog is about languages.
It is not a course in computer science. For one thing, I don't have a degree in computer science, so who am I to write about it? I hope it may ultimately spark some conversation with those who do, but many of them may not get through the early stuff, which is going to be very elementary. When I cover a subject, I like to start at the very bottom. I should say that I am largely self-taught in this area. On the plus side, I know this is the best way to learn something, but on the negative side, it tends to leave definite holes in one's mastery - hopefully not fatal ones! One result of these holes is that sometimes I make up my own jargon that is not industry standard. A rose by any other name, right? Actually, wikipedia has helped to curb this tendency of mine, but from time to time I just know that someone with a CS Doctorate reading these essays would stop and say, "Huh?"
It is not supposed to be mind-numbingly technical. No higher math, a minimum of arcane code samples, just mostly prose. I've already written the first four entries following this intro, and I have to admit I'm not keeping this promise as well as I would like when it comes to code samples. I will try to do better as I get into more abstract concepts.
Finally, I can't predict where it is all heading. Oh, I have a general outline for the first few essays, but, eventually my writing is going to catch up with my experimentation. At that point I can't, I don't want to predict where things will go. In other words, I am not only self-taught, I am also self-teaching.