Joined: 20 Jun 2006
|Posted: Tue Jul 11, 2006 10:43 pm Post subject: Scripting Language Philosophy
|In the midst of the MiniD identity crisis, I've been mulling over features and implementations and syntax and stuff, when I realized that I was getting too low-level too early. I decided to step back, and really think about where I really wanted to go with this.
(this forum is ending up as my development blog..)
The Purpose of a Scripting Language (and the interaction between native and script code)
It seems really obvious, doesn't it? You use a scripting language when you want your program to be scriptable, i.e. for add-in tools or user macros or the like. But making a program scriptable isn't just like boom, and it's done. Making a program scriptable means that it has to be designed a certain way. Things have to be modularized so that they can be accessed using the (usually) simple and restricted script interface.
In addition, decisions have to be made as to what will be handled by the native code and what will be handled by script. This is a common scenario in things like game engines, where it's important to have high performance and power, but at the same time, make it easily extensible by people who are, many times, not really programmers. So the parts which absolutely need the speed are put in native code; the rest is scripted. Apparently (I've never worked on one ) many large-scale, big-budget games use scripting extensively, even if the game is not meant to be extensible with user-made additions. Some companies claim that their codebase is almost half native and half script.
So scripting is something of a design philosophy in and of itself. Scripting should make it easier for beginner programmers to help program parts of a program, but should still be powerful and efficient enough to please the real programmers.
Orthogonality is important in any programming language. I don't know about a lot of you, but one of the main reasons I left C++ was purely aesthetic - it just looks terrible. And it's not a minor problem. I routinely look at C++ code and can't figure out what it's trying to say, simply because there are so many conflicting, unrelated syntaxes all mixed together. D, C#, and Java, on the other hand, look far nicer and are far easier to scan. This is, in large part, to a very small change: the use of the dot operator to access any kind of member, be it a module member, a value type (struct) member, a reference member - whatever. It's always dot. A small change, but it does wonders for increasing readability and orthogonality.
Lua (from which I derive a lot of inspiration) achieves orthogonality by focusing the entire language around a few simple, but powerful, constructs - namely, tables (AAs) and functions. In Lua, you can simulate modules, classes, complex data structures, and multithreading. Lua is conceptually orthogonal - it takes the stance that a single, powerful construct can take the place of several other, more specific constructs. By learning one simple construct, the same ideas can be applied to a wide range of problems. The syntax of Lua is also orthogonal, but the language as a whole really shines in its design.
So orthogonality - both conceptually and syntactically - are important concepts in a language. Elimininating strange corner cases, syntax that exposes implementation details (like '.' vs '->'), and excess complexity are key. Simple, reusable ideas are the best, and being able to use them intuitively is also important.
OK. So I'm going to be thinking of some kind of "core mechanic" for the language. Objects, like Smalltalk? Tables, like Lua? A mix, or something completely new?