(,-o.c(((O) The Goals

One does not simply write a new programming language. There needs to be a good reason for it, and not only a good reason, but also a good answer for how it is supposed to be better. That’s the short version. In truth, a good language needs to be designed to fulfill some goals in a way that appeases the person who is going to be using it. The goals are what shape the paradigms the language will have.
What are the goals of this language?

1) Must have correct memory management.
Working with C++, I get tired of having to do manual memory management. Using JavaScript, I get annoyed with making sure I don’t have cyclic loops of reference. I don’t want a garbage collector. Things need to die when they are expected to die, not before and not after.
2) Must gracefully handle errors.
Mistakes – and therefore errors – are inevitable. Part of eliminating errors is by not having the option for “null”. Another part is internal: making sure that the interpreter implements a friendly version of the language specification (such as returning default values on failure rather than crashing) and providing helpful error and warning messages.
3) The language interpreter must be embeddable.
That means that I can put the language interpreter into another program and have it compile all of its necessary features alongside that program. Furthermore, it must be easy to integrate with another language.
4) The language must be extensible.
A language that cannot be extended is limited by its shell (no pun intended). In order for this language to gain more features and hook into other languages without modifying the core engine, there needs to be some mechanisms for extension in the engine as well as rules for extension within the language itself.
5) The syntax must be simple.
Creation of programs could be so much faster if we could focus more on designing the program than on syntax.
6) The syntax must be easy to read.
“Code is for the programmer”, as the Python philosophy states. There is no sense in creating a language that requires code that cannot be maintained next month, next year, or whenever someone comes along to maintain.
Simplicity does not mean “readable”, but readability is still necessary for code correction.
7) The syntax must be familiar.
The less you have to reorient your mind to working in a language, the easier it is to create with it. Admittedly, any drastic change in language paradigms is going to result in changes in syntax that are unfamiliar, but hopefully with simplicity, the detrimental effects of such changes are reduced to having a negligible impact on one’s performance writing code.
This goes hand-in-hand with the goal that the syntax must be readable, but it is definitely not the same.
8) The syntax must be easy to write.
In order to ensure code is easy to write and maintain, it must not require a complicated character set. For example, APL fails this test miserably.

9) The language interpreter must allow for a REPL.
To receive immediate feedback and testing ideas, it’s very nice – and in many cases expected – to have a REPL.

Not on the list is “the language must be powerful”. That comes along with “The language must be extensible” as adding extensions will add capabilities. Besides that, “powerful” is a relative term, which could arguably be used in reference to syntax as well.

All in all, there can be more goals for this language, but when it comes to a conflict of interest, these will take precedence.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s