Philosophy

This page aims to be a overview over the philosophy on which promiseland is built.

promiseland includes javascript

its very important to me that promiseland users dont have to learn a new language.
if you just write plain javascript it will compile to a pure javascript module that can be loaded with amd and commonjs loaders. the generated code should also be obeying the javascript standard as far as possible.

limitations

• by inluding javascript i mean javascript strict mode. a "use strict" is added in front of a closure function that surrounds the hole module. if you dont know what strict mode is please consider 2 things: 1st dont ge scared, its basically javascript without the with statement (which you hopefully dont use anyway), 2nd pls google it, my experience with strict mode was that it is surprisingly easy to understand, and i am confident you will have the same experience.
• additional keywords. there is a small set of additional keywords introduced in promiseland. for example "require". i am trying to keep the list of additional keywords as small as convenience allows. if you compare promiseland with c++, its worthy to point out that c++ is generally considered to be backwards compatible to c, however you can no longer have a variable called class. same applies to promiseland. you can no longer have a variable called require.

concentrate on your program logic

i wanted to create a programming language which enables me to focus purely on the program logic.
you still have to be aware of if a operation is synchronous or asynchronous but the concern is minimized to the level of awareness you have to have about a variable containing a value or not or something being a function or not.
furthermore with writing promiseland code you dont have to focus on weather your code runs on the server or the client.
and i want to make it possible to add a load / save engine that can be used with your program classes in a seeming manner.
pay attention to what matters!

Modules

promiselands units of code are modules. a module loader is mostly mandatory. i consider to make modules useable without a module loader, as long as the special promiseland features are not used, but for regular app development a module loader is mandatory.

points worth mentioning:

• requiring other modules is considered to be a asynchronous call. since during compilation time there is no way to determine weather you use a amd loader or a commonjs loader, there is no way around treating require as asynchronous
• return on module scope defines the module.

Goals / what aims promiseland to be?

a way out of callback hell

the most imporant motivation for creating promiseland was to offer a way to write synchronous looking code that can execute asynchron.

frame switches made easy

if you are using javascript on the client and the server or on two servers that talk to each other, or you are using worker threads in browsers, you are always confronted with the same problem: communicate from one frame (of execution) to another.
this communication is allways asynchronous and most of the time you will create a more or less custom way for each frame switch you have to do. maybe you like to use rest stores, or you create a message queue or you implement a way to execute functions remotely. promiseland aims to solve this problem pragmatically and with a "once and for all" mentality. you have to implement a way to send string data from one frame to the other. thats it, all the rest will be taken care of by promiseland.
integrating the frame switch concept into the programming language

• is easy, since we have already a concept for asynchronous functions
• offers more possiblities for programming. the synced objects are the most advanced use of this possibilites so far. but who knows what we (programmers and users) will come up with in future.

generate fast code

by offering the possibility to generate low level javascript out of high level syntax additions, the programming experience gets more convenient. but can you be sure your code will be the fastest implementation?
the performance is a key factor in all design decisions.
the language additions are split in speedcritical parts which will be as fast as possible, and speed uncritical parts.
one example for this is the require statement. its possible to implement a faster require but you would not have the level of convenience that promiseland offers. and since require is a statement you usually only use a limited time, speed was not key to its desing.
a example of a speed critical implementation are typesafe classes. since the members of typesafe classes are known at all time it is possible to implement typesafe classes as arrays. arrays offer twice the speed compared to objects which makes the use of typesafe classes as fast as possible.

minimize unnecessary type work

while fully backwards compatible to javascript, some typework you have to do in javascript can be minimized in promiseland.
examples for this are:

• string continuation on line breaks.
  you safe the ""
• optional function keyword.

but also the class keyword in its simple form is just a way to create a constructor and a prototype without typing it all out.
promiseland will keep up this philosophy as long as no backwards compatibility is broken.