I have always wanted to design a computer language.
Growing up, I only had access to BASIC of various flavors -- Atari, IBM, and a weird beast of a computer that had 8" floppy drives and a dumb terminal that my Dad brought home from Sperry Univac -- so, when my Dad noticed I had an interest in games programming, he suggested I learn C -- and I found the fantastic "C++ Primer Plus" and fell in love with the ways this new language made programming more practical!
Shortly after that (and this was theme of my first year of college, in particular) I hunted down and explored as many languages as I could. I found Modula-2 on the only Mac in the college computer lab. I was exposed to Parallel Pascal, and I ran into Forth, Lisp, APL, Snobol, Assembler, Ada, and several other languages. In the process, I discovered something interesting: my favorite languages were anything that was as different as C as can be ... and while I came to despise anything that resembles C, mostly because they had stupid conventions that drove me nuts (take Modula-2, for example: ALL CAPS keywords, BEGIN and END blocks, among other irritating issues). It was bad enough that, when I took a 3-year hiatus from college, and returned to find the department had switched from C++ to something called Java, I was nervous ... until I saw it was pretty much like C!
The only exception to this is Python, which, when I first discovered, I breathed a sigh of relief: I no longer have to think about linked lists! Python can get away with departing from C's syntax because Python makes things simpler, and tends to avoid a lot of the superfluous syntax that's as much as a hindrance as it is a help. (In particular, I will never forgive Pascal for requiring a semi-colon after an "else" keyword -- what the heck, how does this help with anything?)
As I look back on this, I realize I had unintentionally absorbed certain principles that have influenced my desires and abilities to learn languages: that syntax is evil, and that the more a language can provide for you (at least in terms of data structures, and to some degree libraries), the better. Over the years, I have also discovered that precedence of operators itself is evil. And over time, I have come to realize that I struggle with learning a language when I am not convinced it has something new to teach me, and don't have an outside force compelling me to learn. (This is why I have been unable to learn Ruby -- I cannot convince myself it's sufficiently different from Python to be interesting to me.)
Now, however, as I have become more familiar with computer languages and environments, I realize that it's probably impossible for me to create a language from scratch, particularly if it isn't substantially different from all the different languages available today!
At the same time, I also recall years ago encountering an interesting question: "If you were on a desert island, with a single computer, a single language, and all the documentation you want, what language would you choose?" The answer given made some sense to me at the time, "I'd choose C, because it would give me performance, and I could always write up my own Lisp system", but over the years, I came to realize the folly of this answer, which could be summarized by Greenspun's Tenth Law: "Any sufficiently complicated program written in C or Fortran will have a buggy, ad-hoc, half-implementation of Common Lisp", along with the corollary "including Common Lisp".
And that's the catch: a language isn't just syntax! It's a compiler. It's an interpreter. It's libraries. It's conventions and idioms and optimizations. It doesn't matter how simple or complex the syntax of any language in general, and Common Lisp in particular, may be: syntax is only one part of the language! You need ways to allocate memory (malloc and garbage collection), juggle the scheduling of functions, reading and writing to disk, and so forth. Even with a language like C, every compiler offers optimizations no other compiler has -- yet every compiler misses optimizations too. In short, any single computer language worth its salt offers so much, it would be a major effort to implement it! What's worse is that Common Lisp is almost just as capable as C for optimization -- you just have to consult the docs, add optional type declarations, and maybe resort to assembly language for the particularly fiddly bits -- but the performance can be eeked out, nonetheless!
So, as much as I would like to create my own language, I have to accept I don't have the time and energy to do so -- and thus, I have to choose among the languages that are available to me instead. And the language I am most attracted to, at this point, is Common Lisp -- it has a weird dynamic of "purity" and "practicality" that appeals to me, and it has a certain flexibility I admire for experimentation -- which means that I have a certain amount of freedom to experiment with language design without having to re-invent an entire language ecosystem!
Yet people for years have been complaining about Common Lisp, how it needs to be "modernized", how parentheses should be eliminated, how it needs up-to-date libraries and tools, and how it is so misunderstood -- everyone thinks it's about "lists" when it's really about "trees", and everybody thinks it's slow, and besides which, "Lisp" is a stupid name, why would anyone want to adopt something that doesn't have a cool name? It would be like saying you drink "Slug Cola".
With those objections in mind, I decided to start a "Treehouse Initiative". Originally, it was intended to be a new language in its own right, but at this point in time, I merely want it to be a layer over something well-established. What's more, however, I have also come to accept that all these objections to Common Lisp are flawed in a major way -- mostly, in that they are matters of opinion. Thus, I have decided that this Treehouse Initiative shouldn't be an effort to "fix" Common Lisp. Instead, it is going to be an effort for me to create a language and environment I like. I will invite other people to join in on the fun, and to create changes they like, too, and to discover and/or create new libraries that would be useful for their projects, as I will for my own. But I'm not going to pretend that this is the "best" way to do things, or the way that Common Lisp (or anything else, for that matter) needs to be "fixed".
Like the attempts to fix Common Lisp that have come before it, I kindof expect this attempt to stagnate and even fail -- in particular, if I get bored with it, or if no one else finds it interesting, it will almost certainly be doomed -- but if enough people take an interest in this approach, it may very well take on a life of its own. It will be fun to see what happens!
What kinds of things do I have in mind for this little initiative? The first, ironically enough, is syntax. The notion that the parentheses just "disappear" has never been true for me -- and this is true as much for C-style languages as it is for anything else -- indeed, if we ever ran out of curly braces, C-style languages will be in trouble! While Python's whitespace syntax helps alleviate the need for braces, I've generally thought that commas get in the way as well, and would appreciate a syntax that doesn't use commas for data structures or separators. Hence, I am in the process of trying to debug the "Sweet Expressions" library, both to fix a bug with comments, and to expand it to include things I appreciate.
The second are libraries. I would like to use Elixir-style actors and pattern matching. I need to explore libraries that try to implement these things. I would also like to figure out how to use the "Cells" library, too, for dataflow management -- which I expect to be helpful when I explore "parameterized dependencies" in computer graphics. And I need to come to terms with GPU programming in Common Lisp. I intend to put some effort into keeping track of and even recommending libraries I like.
The third, I'd like to improve documentation for these libraries, and get into the habit of writing out notes as I explore things. As I have explored some of these libraries, I have struggled to understand how to make use of them, and I figure if I can get good at documenting my discovery process, it will be helpful for other people.
Now, I wanted to have a name for the ideas I want to throw out there -- maybe these kinds of things should be in some sort of forum, so that various topics like these can be discussion points -- but for now, I am just throwing things out on my blog, to see how things will go. Nonetheless, I'd like a name for them -- I like the humble "Request for Comments" used to propose standards for the Internet, named when the original research group had no idea what they were doing, nor whether there were other researchers who were supposed to supervise them somehow -- but it's also a name already in use. Similarly, Python has PEPs -- "Python Enhancement Proposals" -- but I don't particularly want to think of these as "enhancements", in no small part because I want to recognize that what might be an "enhancement" to me might be "detrimental" to someone else, and vice versa -- and I figure that, with a language as flexible as Common Lisp, it shouldn't matter what any one person thinks is an "enhancement" or a "detriment" -- they can all co-exist just fine!
So, I decided I'd call these rambling things "Curious Treehouse Musings", and let people figure out for themselves what works, and what doesn't, be it as it may.
No comments:
Post a Comment