Wednesday, January 22, 2014

readme.txt

PLUS is a programming language in development. The mission of PLUS is to be an enjoyable, teachable, and literate way to get things done quickly and effectively. Once it achieves that mission, it will change names to "Grog".

Let me clarify that mission statement.

* Enjoyable: Programmer comfort comes first in every respect.  I look at this primarily from the maintenance perspective, because we always spend more time maintaining than creating. I don't seek specifically to minimize the number of keystrokes in any given form. Rather, code should be comfortable to read six days or weeks or months after it's written, and it should be comfortable to make a change.

* Teachable: The language shall have a shallow learning curve so that people new either to programming or to PLUS can apply each new concept as they learn it, without having to deal with incantations that only make sense after you've learned a bunch of other stuff. As much as possible, each concept should make sense in isolation.

* Literate: The concept of literate programming has been around for decades. The general idea is that the same source code file generates both the executable program and one or more forms of attractive documentation.

* Get things done: This means that PLUS will add bindings to existing libraries where it makes sense, and it shall grow into new domains of application as it becomes possible to do so.

* Quickly: I'm concerned with programmer time, not CPU time. Although I have some notions about how I want to arrange things for optimization, it's too soon to worry about that, and premature optimization is not a good idea.

* Effectively: This is about support for the programmer (or programming team) as the program grows. This is why we have type inference, static type safety, and a module system.

Secretly, development of PLUS also serves as a way to dig into the consequences of decisions and trade-offs in general-purpose languages.

PLUS is still in its infancy. There is a working compiler/interpreter, but many ideas are yet to be implemented. PLUS needs to grow and change in response to the feedback of real use. Language design represents a balance of many interacting decisions, and it's far too early to think I have good answers to most of them. On the other hand, the current build of PLUS is Turing-complete and usable for a variety of things.

One way to follow the development of the PLUS language is to read the test cases and, eventually, standard libraries. As PLUS is still very young, I do expect to make some incompatible changes from time to time.

============
Here are some areas where PLUS currently needs to grow:

The type system, in three parts:
    1. (tagged) union types.
    2. type classes.
    3. objects.

Module resolution. This merits a separate discussion.

Embedded domain-specific languages (e.g. regular expressions, SQL, and maybe XML).

2 comments: