The desire to create a new language has come from my own experiences in programming in a framework I’ve built, Motorcycle.js and the language TypeScript. Motorcycle is very similar to the more popular project Cycle.js. In my current place of employment we are building a rather large and complex application and we have felt the language barriers of ECMAScript and TypeScript much more than we have the programming patterns we have come to use.
This is, currently, a very informal and non-exhaustive list of things I wish a single programming language would have. This language would likely to be very opinionated, and geared towards functional and reactive web applications. In many ways, but not all, I’d like to see a language designed around the programming patterns of Cycle and Motorcycle.
I hope to develop this language in the future, unless someone else beats me to it! Following this is a bunch of points, given a rough order in what I think to be most “required” of my perfect language.
Like many other programming languages a ML-inspired syntax that emphasizes readability should be used. Similar to Python and Haskell, whitespace should be used to designate blocks instead of { } or other similar constructs. Infix operators should not be user-definable as their use can lead to a decrease in readability and require an understanding of the operator e.g. f >>> g does not read as well as compose f g.
Though this document does not attempt to specify that of a standard library, it should also strive to be extremely readable. It should prefer naming patterns that are easily understandable and not necessarily the shortest amount of keystrokes.
This language should be functional by design, and many of the following sections are inspired by purely functional languages. Adhering to very strict purely functional patterns is very powerful, but not always the best or fastest (in time and performance) solution to a given problem. It should be possible to use a subset of object-oriented programming patterns. In particular, this subset of object-oriented programming should encourage, preferably enforce, composition over inheritance.
There should be absolutely need to distinguish variable declarations as immutable, but in rare cases where absolutely required, it should be possible to explicitly mark a variable as mutable. Mutability is largely seen a footgun in programming but in a Language like ECMAScript using immutable data structures requires importing external libraries that vary greatly in API, performance and size.
This language uses powerful and descriptive static typing akin to a Hindley-Milner type system. The type system should allow defining typeclasses which can be extended and used as type constraints to functions. The type system should have a succinct and readable way for using higher-order types and type constraints. Preferably, it'd be possible to avoid generally scary terms such as "Monad" or at least offer better material for learning about them.
Like many functional programming languages, this language should also make use of currying to allow for simple function composition and partial application.
ES2015 introduced a language specification for statically analysable import and export statements. This language should make use of ES2015 module syntax, at the very least compile to ES2015 module syntax, to provide seamless interoperability between ECMAScript. This will allow for a large about of the standard library to be “compiled away” if the code is never used via bundling tools that are ES2015 module aware such as Webpack 2.x and Rollup. Hopefully this would avoid the need to introduce a new package management or build system for this language, as NPM and javascript bundlers would solve both of these problems.
Unlike some other functional programming languages that use laziness by default for evaluation of expressions, because this language aims to be capable of being transpiled to eager languages such as ECMAScript, it will use other lazy data structures, such as Streams, where possible and makes sense.
In a language like ECMAScript value equality is only used for primitive values like numbers and strings, but for objects it uses reference equality. This language should make use of value equality everywhere it is possible and makes sense to avoid footguns. Using ECMAScript { a: 1, b: 2 } === { a: 1, b: 2 } would evaluate as false, but this language should make the proper comparisons necessary to ensure an expression of similar construct would evaluate to true.