Motive
The more complex programs I wrote the harder I realized that I am not fluent the way I would like to be. No matter how focused I was, how much I knew about the language, there was always either a cryptic syntax, missing feature just for my safety, or some kind of legacy design. Eventually I realized I was at the point I cannot any longer happily dive into new project because I could foresee all the struggle with this or that language. And how much fun is rewriting for the n-th time the same helper functions, because I did some web developing and now I have switched to statistics? Programming is no longer a joy for me — a passionate programmer — as it used to be!
You want something done, do it yourself — I had to design my own language.
Enlightenment
I read several books about compiler design, in theory I could just start writing a compiler, but the truth was — I had no idea how to start. I could write anything, but I didn’t know what. Even such simple examples (simple now) like the one given in classic Wirth’s “Algorithms + Data Structures = Programs” were pure magic for me — how it was conceived? Where was it going? The pile of compilers books on my bookshelf was getting bigger, the list of features I wanted to have was longer and longer, but I didn’t make any real progress. Until Coursera happened — thanks to “Compilers” course by Prof. Alex Aiken (I cannot praise this course enough, enroll now) and his COOL language the spell was broken and I finally connected the dots.
At last I had the will and the skill (well…).
Strategy
At first I rewrote entire COOL framework and compiler from Java to C#. But there was a catch — I couldn’t find any good lexer/parser suite for C#. It slowed me down, but not stopped for sure — I wrote my own suite. From this point I started changing working COOL compiler into working Skila translator — and this work continues as you read these words.
Since I cannot devote myself solely to Skila development I go with minimal plan — instead of writing pure compiler, I decided to write translator first. Here are the steps I envision:
- adding new features and writing translator to PHP at the same time (in progress),
- add translation to Javascript,
- replace PHP translator with real machine code compiler.
All this should be done with as little philosophy as possible (see: break
in Scala). Same goes with cheap compatibility (see: C# arrays).
Goal
I hope the only time you find an obstacle in Skila is when you are about to write an incorrect program — besides that Skila should offer you nothing else but helpful, common-sense, features. You have the idea, you write it down in readable English, work done. The flow of the human mind is more important to me than toasting the CPU. I would like to have a language that could be used safely after 14 hours of non-stop work — there should be no room for stupid mistakes, and all the risky features should be available only if asked explicitly.
I don’t have a blueprint in my hand, what I do is scavenging. I took C# as the base language and removed all the parts that annoyed me while adding the ones I took from the other languages. And I let Skila evolve…
better just translate your language to one language called haxe(see haxe.org).
This haxe already translates to lot of mainsteam languages -PHP,Java,JavaScript,Flash,neko etc ; new ports of Objective C and C# are in progress.
@zaxebo1, thank you for your comment. I am fully aware of the existence of Haxe (the link to its website sits on this blog from the very beginning). Do you mean by “translate your language” using Haxe as Skila backend? In such case I am not sure if I would use my own language :-). Too many layers (every translation stage requires time), I would have to spend some time to learn Haxe first. Such move would also undermine my goal — dropping translators and making true compiler. And I am also afraid that adding yet another chain to entire translation sequence would make it more fragile.
Writing backend so far does not take majority of my time. Conceptual thinking and writing semantic analysis are the most time consuming processes. So I am not saying firm “no”, but I don’t see too many advantages — i.e. such move wouldn’t save my time. But since I can add any translator I want, it might be Haxe, who knows. First things first though — I have to make Skila usable and make it available to others.
I did not meant haxe as backend of skila.
I meant that implementing skila in haxe language itself. This will mean that: from a single code of skila (written in haxe), we can have:
[1] skila interpreter itself can run on .NET(as haxe source code can compile to .NET),
[2] skila interpreter itself can run on jvm (as haxe source code of skila itself can compile to JVM too)
[3] skila interpreter itself can run on python (as haxe source code of skila itself can compile to python3 too)
[4] skila interpreter itself can run very fast on native (as haxe source code of skila itself can compile to C++ too)
@zaxebo1, very tempting I admit, thank you for that reminder. So far, I made several approaches to Haxe, yet I am still bouncing of the simple fact it is written in ML and I am not fluent in this language. Either I finish my own backend, or I made a breakthrough and I sink in and will use Haxe as an engine. Haxe could be really beneficial to my efforts, that’s for sure. Btw. I hope you don’t mind I fixed the way you spelled “Skila”.