Newlandese is intended to be a next generation language. It development and use will depend upon several factors. Of course the use itself depends upon the development.
A language is really only as good as its editor. So I will write an editor in order even to being to process of developing the language. In fact, I will try to begin with a language editor-interpreter.
This language is part of the entire Newland project, thus the name, NEWLANDESE. All letters in the name are capitalized for correct use, just as all keywords in the language are. Any plugins designed for the program are capitalized like this: Mypluginname. This is true even for documentation and promotional purposes. The idea is to enforce strict standards for everything, not because computers like consistent syntax, but because we humans need it in order to collaborate.
NEWLANDESE is designed to be a collaborative language. If it succeeds, all the work contributed by all the programmers should be usable and understandable by other programmers. In fact, most languages today have enough following to become extremely useful and effective. The problem is that it is difficult for beginners or even experts to understand each other's code and make use of it. In effect, most languages are drowning in too much support, without enough clarity.
NEWLANDESE plugins will produce objects that are often accessible in programs. NEWLANDESE will endeavor to produce a way in which an end user can find the original programmer who created any given plugin. For example, a window that displays images with animation may have been built upon several plugins. Unless the programmer disables the feature, right-clicking on the object or the program will produce an option to see which plugins came from where.
Documentation is required in the language, and space is provided. Warnings will be produced by the editor when code is undocumented. Documentation includes space for attribution. In this way, the programming community will be encouraged to collaborate and build respect and reputation. In fact, the entire language itself could become a form of online social networking.
This language is intended to be used to produce educational software for Newland University. That project will produce a vast array of objects for use by other programmers. These objects will be formally included into the language using the proper naming schemes. Eventually, the language should be extremely robust, much like C# with its auto-completion, which gives easy access to most of Windows key features.
In other words, this language does not have to be popular in order to become extremely useful. It only needs to be well documented, well designed, and highly organized.
Implementation: In the end, this is a giant issue. Everyone wants to know which language to use so that their program will run on everything. This normally is the bain of small languages. NEWLANDESE will at first sacrifice efficiency in order to win this battle. It will run as a layer on top of other languages, such as javascript. Then, implementations can be made for any language or system. Once an implementation is made upon another language like javascript, NEWLANDESE will run on anything javascript runs on.
Clarity: Code should be clear to experienced programmers, including those who did not write the code.
Strict: Rules should be enforced, so that both the original coder and future readers of code can understand it. This strict application of rules should lead to the smallest number of different ways to perform tasks, facilitating fast uptake of information about how to complete each task using the Internet to look for code examples.
All letters in user identifiers are lower case. Non alphabet characters cannot be used in class, function, or variable names. This is to make it easier to remember the correct names of objects.
All reserved keywords are all caps. This way they are clearly distinguished from user code, and new keywords can always be added to the language. Libraries such as support for media or 3D rendering can be given keywords that refer to a version. That way multiple versions can be supported, such as 3D_STEVE_OPENGL.
All plugins capitalize the first letter of publicly accessible objects. This way, a user knows automatically whether any given object is their own code, a plugin, or a keyword.
Every object and variable must have a description. These descriptions are always preceded by ~ Multiline descriptions are allowed.
Functions:
Objects contain 6 sections:
Object name
Immutable parameters
These parameters will be copied and the new copy belongs to this new object.
Mutable parameters
These parameters are passed by reference, so that any changes persist on exit from this object.
Variable definitions
All variables must be defined before use.
Constructor
Destructor
Methods
Methods are also Functions.
Return section
Return
Return provides a collection of objects. If there is only 1, then variable = function name gets the result. Multiple results are possible:
RETURN 6
RETURN_mycolor "I like purple"
RETURN_mycolor ff00ff
returnvalue = myfunctionname()
mynumber = returnvalue_mycolor
Basic variable types:
STRING
INT
DOUBLE
POINT
RECTANGLE
IMAGE
COLOR
PEN
BRUSH
WINDOW
CONTROL
SQL
URL
FILE
STREAM
MICROPHONE
CAMERA
VIDEOCAMERA
SOUND
VIDEO
PLAYER
Future variable types can use a single word or an extension with an _. For example, CONTROL_CHECKBOX. The underscore is used in order to allow easy display of code on websites, so that readers are not confused by periods.
Other keywords:
PUBLIC
PRIVATE
MOM – refers to the parent of a nested object, giving access to all local variables
MOM_MOM – allows access to higher layers
IF ELSE – standard meaning
DO WHILE – standard
SWITCH
EACH IT– EACH myarray {IT is the element – perform code in the block}
ENUM - standard
Example code:
OBJECTNAME: myfunction
IMMUTABLE PARAMETERS: STRING myname, INT myage
MUTABLE PARAMETERS: INT myfutureage
CONSTRUCTOR: myfutureage += 10
RETURN_STRING: "My name is " + myname + ". I am " + myage " years old."
RETURN_STRING_myfutureage: "My future age will be " + myfutureage
The editor would allow:
O: myfunction
IP: STRING myname, INT myage
MP: INT myfutureage
C: myfutureage += 10
R_STRING: "My name is " + myname + ". I am " + myage " years old."
R_STRING: myfutureage: "My future age will be " + myfutureage
The language requires an editor, which should automatically handle the language. It should provide auto-completion, error-checking, format-checking, etc.