Rethinking Programming Languages
My thinking around a new programming language for the last two years has been to find a way to make a living creating development tools that I was passionate about. A few weeks ago, I met a fellow iPhone developer and during our chats, I mentioned my passion of dreaming up and working on programming languages and development tools. Our discussion turned to the theoretical idea of, “what if you could create programs by just connecting the dots?”
Initially I raised my skepticism towards the idea; it has failed so many times, and I just didn’t think any real programmers would actually want to use a system like that.
…
But I realized something. My goal of creating a programming language to make a living made me focus on practicality, not innovation. It narrowed my sights onto what was familiar, and was a constant tendency to steer towards the normal axioms and arguments that existing languages have defined. Is it static typing or dynamic? Is it purely functional? Is it object-oriented? Multiple inheritance? Prototype based?
The thing is I have a great daytime job, and I don’t need to focus on what I feel would make a great business. Instead, I should have been dreaming about what might allow me to actually create a unique language that might offer some innovation.
I remember back to a discussion at Evening at Adler that took place. The question was what their vision of the future was for development tools.
Wolf fielded the question first (at roughly 58 minutes in), and stated that Objective-C was a dead end unless they could remove pointers. Wil Shipley then retorted that new languages come by with the goal of getting rid of pointers, and then C [based languages] still win out. His conclusion is that the miracle language isn’t coming.
A little later in, Eric Peyton added the observation that every language that gets rid of pointers eventually adds an extension that allows interaction with C or pointers, and he rightly concludes that is the moment you know that the language did not fulfill the original requirement needed to live without C or pointers.
Originally this comment irked me, as an employee of REAL Software and naively believing that REALbasic was a great compromise; I always felt it to be a great power to be able to call directly into OS libraries. But the real reason for doing that wasn’t because I really wanted to call into system libraries from REALbasic; It was to fill in a gap that the framework didn’t provide, or a 3rd party didn’t provide. REALbasic was not a pretty language to interact with the system.
So I believe my development efforts will be devoted towards a new system. Inevitably I think each new language can be described as “like X, Y, and Z.” Hopefully my blend will be something interesting, unique, and useful.
1 year ago