Programming Language Checklist

Colin McMillen, Jason Reed, and Elly Jones wrote this checklist, which they describe as "a tongue-in-cheek guide (?) to help you create a new programming language". The joke is that people invent new programming languages all the time, and most of them are bad and/or unoriginal, and the implicit advice in their "guide" is that people should stop making new languages. We have, of course, ignored that advice, just like everybody else.

The second part of the joke is that nobody really agrees why all the new languages are bad, and the dicsussions about them often become comically unproductive as people offer their pompous opinions. In constructing a caricature of these discussions, the authors also did a good job of enumerating their key points. That gives us a convenient way to summarise some facts about Welly.

The checklist, filled in for Welly

You appear to be advocating a new:
[ ] functional  [X] imperative  [ ] object-oriented  [X] procedural [ ] stack-based
[ ] "multi-paradigm"  [ ] lazy  [X] eager  [X] statically-typed  [ ] dynamically-typed
[ ] pure  [ ] impure  [ ] non-hygienic  [ ] visual  [ ] beginner-friendly
[ ] non-programmer-friendly  [ ] completely incomprehensible
programming language.  Your language will not work.  Here is why it will not work.

You appear to believe that:
[X] Syntax is what makes programming difficult
[X] Garbage collection is free                [ ] Computers have infinite memory
[X] Nobody really needs:
    [X] concurrency  [ ] a REPL  [ ] debugger support  [X] IDE support  [ ] I/O
    [X] to interact with code not written in your language
[ ] The entire world speaks 7-bit ASCII
[ ] Scaling up to large software projects will be easy
[X] Convincing programmers to adopt a new language will be easy
[ ] Convincing programmers to adopt a language-specific IDE will be easy
[ ] Programmers love writing lots of boilerplate
[ ] Specifying behaviors as "undefined" means that programmers won't rely on them
[ ] "Spooky action at a distance" makes programming more fun

Unfortunately, your language (has/lacks):
[X] comprehensible syntax  [*] semicolons  [*] significant whitespace  [*] macros
[X] implicit type conversion  [X] explicit casting  [X] type inference
[ ] goto  [X] exceptions  [X] closures  [X] tail recursion  [X] coroutines
[ ] reflection  [X] subtyping  [ ] multiple inheritance  [X] operator overloading
[X] algebraic datatypes  [X] recursive types  [*] polymorphic types
[X] covariant array typing  [ ] monads  [*] dependent types
[X] infix operators  [ ] nested comments  [X] multi-line strings  [ ] regexes
[X] call-by-value  [ ] call-by-name  [X] call-by-reference  [ ] call-cc

In the above section, I've used "X" to mean "has" rather than "lacks" in every case, to avoid the question of which choice the checklist authors consider to be good! "*" means the answer requires clarification:

  • Semicolons separate statements written on one line.
  • Compilation units are delimited by (some) newlines. Other whitespace is not significant.
  • The module system can be viewed as a hygenic macro language.
  • The language supports compile-time ad-hoc polymorphism, but there is no run-time polymorphism. The module system can be used to instantiate templates at multiple types, but, there is no parametric polymorphism (aka generics).
  • The module system can be used at run-time to instantiate templates, but there are no dependent types.
The following philosophical objections apply:
[ ] Programmers should not need to understand category theory to write "Hello, World!"
[ ] Programmers should not develop RSI from writing "Hello, World!"
[ ] The most significant program written in your language is its own compiler
[X] The most significant program written in your language isn't even its own compiler
[ ] No language spec
[ ] "The implementation is the spec"
   [ ] The implementation is closed-source  [ ] covered by patents  [ ] not owned by you
[ ] Your type system is unsound  [ ] Your language cannot be unambiguously parsed
   [ ] a proof of same is attached
   [ ] invoking this proof crashes the compiler
[ ] The name of your language makes it impossible to find on Google
[ ] Interpreted languages will never be as fast as C
[X] Compiled languages will never be "extensible"
[ ] Writing a compiler that understands English is AI-complete
[X] Your language relies on an optimization which has never been shown possible
[ ] There are less than 100 programmers on Earth smart enough to use your language
[ ] ____________________________ takes exponential time
[ ] ____________________________ is known to be undecidable

Your implementation has the following flaws:
[ ] CPUs do not work that way
[ ] RAM does not work that way
[ ] VMs do not work that way
[X] Compilers do not work that way
[ ] Compilers cannot work that way
[ ] Shift-reduce conflicts in parsing seem to be resolved using rand()
[X] You require the compiler to be present at runtime
[X] You require the language runtime to be present at compile-time
[ ] Your compiler errors are completely inscrutable
[ ] Dangerous behavior is only a warning
[ ] The compiler crashes if you look at it funny
[ ] The VM crashes if you look at it funny
[ ] You don't seem to understand basic optimization techniques
[X] You don't seem to understand basic systems programming
[ ] You don't seem to understand pointers
[ ] You don't seem to understand functions

Additionally, your marketing has the following problems:
[X] Unsupported claims of increased productivity
[X] Unsupported claims of greater "ease of use"
[ ] Obviously rigged benchmarks
   [ ] Graphics, simulation, or crypto benchmarks where your code just calls
       handwritten assembly through your FFI
   [ ] String-processing benchmarks where you just call PCRE
   [ ] Matrix-math benchmarks where you just call BLAS
[X] Noone really believes that your language is faster than:
    [X] assembly  [X] C  [X] FORTRAN  [X] Java  [ ] Ruby  [ ] Prolog
[ ] Rejection of orthodox programming-language theory without justification
[X] Rejection of orthodox systems programming without justification
[ ] Rejection of orthodox algorithmic theory without justification
[ ] Rejection of basic computer science without justification

Taking the wider ecosystem into account, I would like to note that:
[X] Your complex sample code would be one line in: _____________Python____
[ ] We already have an unsafe imperative language
[ ] We already have a safe imperative OO language
[ ] We already have a safe statically-typed eager functional language
[ ] You have reinvented Lisp but worse
[ ] You have reinvented Javascript but worse
[ ] You have reinvented Java but worse
[ ] You have reinvented C++ but worse
[ ] You have reinvented PHP but worse
[ ] You have reinvented PHP better, but that's still no justification
[ ] You have reinvented Brainfuck but non-ironically

In conclusion, this is what I think of you:
[X] You have some interesting ideas, but this won't fly.
[ ] This is a bad language, and you should feel bad for inventing it.
[ ] Programming in this language is an adequate punishment for inventing it.