Good design lies in the eye of the beholder. Right?
This is the third in a series of articles on building a programming language called Wee and its tooling. Wee is an educational prgramming tool for beginners, bridging the gap between (visual) learning tools like Scratch, and professional environments like Java, Python, or C. You can learn more about my motivations on my old blog.
Since the last installment, I've smashed my head against the proverbial wall, trying to come up with a sensible initial design for Wee, the language. The design is currently a living and breathing artifact that will hopefully change for the better based on your input. I've thus decided to store it in a Google Doc that everyone can comment on.
You can find an embedding of the latest version of the design below. You can directly comment on the Google Doc.Each section covers one aspect of the language and includes a list of open problems. Some sections are not done yet. I hope to fill those in over the coming days and weeks.
The three biggest areas that need flushing out are error handling, memory management, and whether to include reference types. The latter is tied to memory management, as it would require a garbage collector (unless I want to expose novices to manual memory management, which I don't). The current design only has value types, which have a life-time corresponding to the scope they've been designed in. See the section "Rephrasing stack and heap values (value types and reference types) as a life-time and shareability issue" for a discussion of the pros and cons of reference types.
As for error handling, I think I will go the Rust way, and exploit Wee's tagged unions.
Again, I would be very grateful for feedback in form of comments on the Google Doc. Please keep the design goals as laid out in the document in mind.
Next up
I'll keep iterating the design a bit longer until it feels mostly well-rounded. After that, I will start implementing the language in TypeScript and document how I do that. I'll try to have all pieces working form the beginning, including the compiler, VM/interpreter, and debugger. I'll post-pone editor integration until a later date.
As always, I'm happy to hear from you on Twitter and appreciate corrections to my terrible writing in form of a pull request. If you are interested in helping out with Wee, or want to give feedback that does not fit into a tweet storm, you can reach me via email.