Sorry, but I found http://lunduke-sdk.com/index.php?title=The_Lunduke_Language disappointing. It's pretty much Integer BASIC plus subroutine parameters, with about thirty years of programming language innovation waiting to be recapitulated. Say I wanted to write an RSS reader that sorts items by date and/or title. How would I store a collection of feeds, each of which is a collection of items, when the only data structure is a map of key/value strings? How would I write a sort that uses a comparator parameter to learn what order two items should appear in? If the list is huge, how do I re-sort gradually without freezing the UI? If some feeds are RSS and others scrape Twitter or something, how do I dispatch to whichever implementation of getMoreMessages is appropriate for each feed? I can't remember the last time I had to write an entire application without being able to do all of these things and more (reflection? plugins? mocks for testing?) nearly effortlessly, and I doubt many people will be willing to do without them.

There are, certainly, many new features that can be added to the language itself. What exists now is powerful enough to build some pretty robust applications, but more flexibility and power in a language is always good! One of the (many) reasons this is becoming an open source project... we, as a community, can decide what new language features are most vital and add as needed.

I've thought about this before, and I'm betting that a large portion of the developers on HN have too. For me it always comes back to the fact that any new language, framework, or SDK on top of an old one simply fragments the industry even more. When 10 developers come up with 10 different abstractions of 3 frameworks, you get the exact opposite of what you are trying to accomplish.

If you want everyone to use the same framework, then my advice - though somewhat impractical - is to use it, advocate for it, and contribute to the community.

This approach really does away with those issues. At any point a developer can utilize any language or framework they like. The top level language and framework translates to any supported language and framework.

In fact, this reduces fragmentation considerably. (And there is already a community utilizing the pre-cursor to this language.)

It's hard to think that the answer to all of our platforms and languages is yet another platform and language.

Java set out to solve a very similar problem (write once, run everywhere) and the issues it ran into didn't involve the language itself but the platform specific framework/libraries.

Furthermore, let's remember that a developer can build C code on virtually all major operating systems using various compilers without being encumbered by licensing issues.

Therein is the fundamental difference. This isn't "write once, run everywhere". Nor is it a new platform. It is a method for bringing one code base to many platforms.