JetBrains MPS, and thoughts on the next big language

1) Games are very much going to determine the outcome of the "next gen language". Game programming is arguably the majority of all graphical interactive coding today. Not only is this borne out by the statistics from the App Stores, which shows that games are more than 2x larger than any other category of product:

but also, when you look at all the dashboard companies popping up, the gamification of business products is well under way, and what was a stodgy dull statistical program is now singing and dancing. Get into your brand new car, and dashboard does a song and dance. I don't care where you turn, customers are suckers for flashing lights and motion, and if your language can't draw well, it is going to be a hard sell. A language doesn't have to full-tilt into 3D complexity, but if you can't drastically simplify the pain of laying out screens in the quirky and frustrating HTML/CSS abomination, why did you bother making your tool in the first place? This by the way is why i consider terminal-based languages like LISP and FORTH to be near useless in this era. There is ample evidence that drawing needs to be integrated into the language.

2) This is why MPS is non-starter for me; I don't see a drawing system. The majority of all my code in every graphical interactive product i have made has been related to drawing. From a word-count perspective, drawing consumes an awful lot of program code. Numbers are easy. They have a value. Period. But a piece of text, it has a font list, a size, optional bold and italic, justification, indenting, stroke color, background color, and on and on. So naturally text is going to dominate the code. If you are building a billing system, generating a nice looking PDF bill for the customer, is a ton of work to drawing nicely, with pagination that works well. I spent decades in word processing/desktop publishing/graphic design product space, and there is just a lot of tricky stuff relating to languages. And don't get me started on the complexities of making your product read well in Asian languages. That was my specialty. 

And since it isn't just about drawing, but interacting, that is why HTML/CSS/JS is such a nightmare, and why there are so many frameworks, because the designers of the web did a rather poor job at anticipating interactivity, and their approach of laying out pages not with function calls but with a textual description basically calls forth a very complex framework system to compensate for this mistake. complex domain specific languages aren't a computable readable model; imagine if the web had an internal model that was not textual, that would have made it so much easier to build interactive graphics. A next gen language to succeed will at least need to allow people to not have to wrestle with webkit, which has a nasty habit of scrambling your layout when a tiny error is made. 

Apple has done a lot of work in their storyboard system in XCODE to make laying out things easier, although it is still evolving and i wouldn't call it settled. I don't know the android studio well, i imagine it has tools for this as well. But i would like to see a cross-platform layout system that makes it easy for a single code base to nicely fit into whatever device you are on. Making layouts fluid should be part of the language, and anyone who thinks they can just live on top of HTML/CSS they are doomed IMHO.

3) As for correctness by construction, there is ample evidence that completely untyped languages that can mutate the type of a variable accidentally from number to string, are very dangerous. The mistake of imitating ActionScript2's overloading of the + operator to mean both addition and string concatenation has caused countless errors in JS. If they had used PHP's & operator, or some other punctuation, millions of man-hours would have been saved. TypeScript and other transpilers/preprocessors are clearly a great win because JS by itself is a minefield. A successful next gen language will eliminate a lot of errors. Eve was very much inspired by SQL, which is a very declarative style of language, with little instruction given as to how do it; you just tell it what to do. However, it isn't that easy to recast a chess program into that style. there is a lot of sequential processing to do, so some compromise has to be reached, where you eliminate as many sequence related errors as you can at compile time by letting the compiler do more work, but still retaining the ability to specify the proper sequence for things to be done in, unambiguously of course else you have obscured the product, which is counter-productive. I believe that sequence related errors constitute half of all debugging time, so eliminating mistakes of sequence should yield a 2x improvement. 

4) there are many additional syntactical features one can add to a language, like runtime physical units, that allow the product do more integrity checking and catch subtle errors quickly. The Wirth family of languages emphasized compile time checks, and Modula-2 for example had overflow, underflow, range, array bounds, nil pointers, undefined variables, checks all of which could be disabled. In my Discus product, we leave the checks on until we ship the product, and it shrinks by 30% because the overhead of checking is substantial. Nowadays, with computers idle 98% of the time, one can argue that leaving the checks on in production products is now feasible, and probably a good idea. All that Microsoft C code, with no runtime checks, is a security hazard, and Microsoft has been endlessly patching their Windows monstrosity for decades now with no end in sight. When you pass an array to a Modula-2 function, the array bounds are sent in a hidden parameter, which allows the called function to not go over the limit. This doesn't exist in C, which means that any large C program is forever doomed to be unreliable. I cannot understand why the executives chose such flabby languages to standardize on. Surely they must have known early that the cost of all these tiny errors in the sum total represented a maintenance nightmare. Java has plenty of problems of its own, and don't get me started on the flaws of OOP.  Thank goodness few of the next gen projects even consider building atop OOP paradigms.