The foundations
Stacked components
MonkeyScript takes JavaScript gives it a clean environment and standard library, a module system, and implements the ability to serve out web pages and web applications on top of that. From there any sort of web framework you wish to create can be built.
The firm belief is that developing in the other direction — by starting from web-framework and moving to language — or building the language, standard library, extra libraries, and web framework all into the same system — rather than building small parts on top of each other — is the wrong way to go about creating a programming environment.
Complete environment
The other important focus is a clean and usable standard environment for programming. JavaScript has the strong ability to let you MonkeyPatch everything in it, including the standard classes. For that sort of reason JavaScript itself is extremely minimal and omits a huge set of standard string and array manipulation methods because it's possible to patch them in basing them on the standard methods that are included. Unfortunately inside of libraries it's very bad practice to monkeypatch outside things like the standard classes, as doing so pollutes other libraries and can cause things to conflict and potentially break. By that logic there are only two places where monkeypatching the standard classes is acceptable. The standard library / environment that everyone expects to be loaded, and inside of the top-level application itself. Unfortunately doing that inside the application adds pointless extra code, and you can't make use of that stuff inside of libraries. Thus MonkeyScript makes an effort to define any common things you would need to do as part of the standard environment. This part of the project is split off mostly into the Wrench.js subproject so that it can be reused in the browser and in other Server-side JavaScript implementations.
The principles
Ordered weighting and instances
MonkeyScript aim's to provide a cleanly ordered instance based api.
For example, when building a File api most of the time other implementations
(even ruby's, when ruby is even supposed to be an "object oriented language")
stick with a functional approach which is little more than namespacing of file methods
like File.stat(filename);. While this approach does use an "Object", it's not really
following the instance pattern. In MonkeyScript this would be File(filename).stat();
(File() is actually short for new File()) the difference is we first assert
"filename is a file" by creating an instance, then we as for .stat() information from it.
This pattern goes farther than just simple quick things like this. Rather than passing
around paths and going File.exists(path); File.open(path, 'r'); and File.remove(path);
for each thing you want to do on the file you create a single file instance with var f = new File(path);
then from there you f.exists; f.open('r'); and f.remove();, not bothering with the
path you shouldn't be caring about anymore.
APIs take RAII into account, and some spots like the File api even have a Ruby-like block form using anonymous functions that allow the use of block like anonymous functions to express self destroying resources even more reliably than RAII.
Short and sweet
MonkeyScript follows a "code should be short, but not to short" paradigm. Getters and setters should be used where reasonable, and the names of properties and methods should be short, but not so short that important information is lost and things become ambiguous.
This is why String has .uc and .lc getters since .toUpperCase() and .toLowerCase()
are far to long for such a common task, and .ucfirst since str0.toUpperCase() + str.substr(1)
is just plain unreasonable. And why most of the MonkeyScript classes act just like
Error where Class() acts just like new Class() allowing you to omit the new
when you are doing quick things that don't really need the new in them.