😉 So this documentation is highly Work In Progress but should be at least readable and understandable for most. Otherwise, you can quickly get lost in all this - trust me. It's quite important to have a centralized base/reference point for the following development.
By now, I've started writing the documentation for the syntax of this language. Also, you have to keep in mind that feature you invent must be possible to implement (especially if you'll be doing this yourself).įor setup, I've created a monorepo on GitHub for this particular project. but to make them into a logical sequence - that's a different story. Sure, you can easily invent some new language constructions etc. I was given this privilege to get to know how hard designing a good (or any for that matter) programming language is. Now, without limitation to just follow the standard for most languages syntax form, I think I created something new, yet really similar to what is being used. Its AST should be not complicated, simple to be later used for easy editor autocompletion, prettifying tools, linters etc. Also, I considered syntax from the side of its implementation. Development in AIM should be easy and shouldn't have too big learning curve. Also keeping in mind performance, reactivity, ease-of-use and logical sequence of language structures. I wanted to target this language to people who develop native, modern and interactive applications. When thinking about this syntax and AIM language as a whole, I've been driven mainly by my personal experience in web development. You may like it or not, but here it goes. As I said in the last post, AIM's syntax is meant to be different compared to any other programming languages, and so it is. It's both the easiest and the hardest part of language design.
So, let's start this project with the syntax idea. This is a continuation of The AIM Project series, so if you haven't read the introductory post, then take a time to do that.
0 kommentar(er)
