Updated version of the tongue-in-cheek Programming Language Checklist

Programming Language Checklist 2024.txt

 Programming Language Checklist
by Colin McMillen, Jason Reed, and Elly Fong-Jones, 2011-10-10
updated by BoppreH, 2024-01-24

You appear to be advocating a new:
[ ] functional  [ ] imperative  [ ] object-oriented  [ ] stack-based  [ ] concurrent
[ ] interpreted  [ ] compiled  [ ] JIT  [ ] cloud  [ ] AI  [ ] beginner-friendly
[ ] academic-friendly  [ ] visual  [ ] sharable  [ ] esoteric
[ ] memory safe  [ ] memory unsafe  [ ] provable  [ ] Turing-incomplete
[ ] statically-typed  [ ] dynamically-typed  [ ] completely incomprehensible
programming language. Your language will not work, and here's why:

You appear to believe that:
[ ] Syntax is what makes programming difficult
[ ] Performance is:
    [ ] not relevant anymore  [ ] worth any and all sacrifices
    [ ] independent from language design
[ ] AI-generated code is generally correct  [ ] and won't create legal issues
[ ] A Turing-complete type system is a benefit
[ ] Developers don't make mistakes and guessing intent is a good strategy
[ ] Nobody really needs:
    [ ] concurrency  [ ] a REPL  [ ] debugger support  [ ] IDE support  [ ] I/O
    [ ] determinism  [ ] compile-time analysis  [ ] joy in their lives
    [ ] to interact with code not written in your language
[ ] Scaling up to large software projects will be easy
[ ] 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
[ ] The primary objective of a programming language is writing compilers

Unfortunately, your language (has/lacks):
[ ] comprehensible syntax  [ ] significant whitespace  [ ] macros  [ ] memory safety
[ ] pattern matching/destructuring  [ ] string templates  [ ] assignment expressions
[ ] infix operators  [ ] nested comments  [ ] multi-line strings  [ ] regexes
[ ] pipelining  [ ] variable shadowing  [ ] emoji names  [ ] immutable data structures
[ ] implicit type conversion  [ ] explicit casting  [ ] type inference
[ ] async  [ ] exceptions  [ ] ergonomic error values  [ ] closures  [  ] objects
[ ] reflection  [ ] multiple inheritance  [ ] operator overloading  [ ] coroutines
[ ] goto  [ ] comefrom, but unironically  [ ] DSL's  [ ] effect system
[ ] algebraic datatypes  [ ] recursive types  [ ] polymorphic types
[ ] covariant array typing  [ ] monads  [ ] dependent types  [ ] tail recursion

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
[ ] The most significant program written in your language isn't even its own compiler
[ ] Your language encourages insecure and fragile programs
    [ ] and even your examples fail in common edge cases
[ ] 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 is
    [ ] impossible to find on Google
    [ ] impossible to pronounce
    [ ] a curse word in _________
[ ] Interpreted languages will never be as fast as C
[ ] Backwards compatibility and versioning is more important than you think
[ ] Your language assumes the existence of a sufficiently smart compiler
[ ] ____________________________ takes exponential time
[ ] ____________________________ is known to be undecidable

Your implementation has the following flaws:
[ ] Hardware does not work that way
[ ] Compilers do not work that way
[ ] You require the compiler to be present at runtime
[ ] You require the language runtime to be present at compile-time
[ ] Your compiler errors are completely inscrutable
[ ] Basic features have been "on the roadmap" for a year
[ ] Your README looks AI-generated
[ ] Dangerous behavior is only a warning
[ ] Dangerous behavior is not even a warning
[ ] The compiler crashes if you look at it funny
[ ] The LLM it uses can be jailbroken
[ ] You don't seem to understand basic optimization techniques
[ ] You don't seem to understand basic systems programming
[ ] You don't seem to understand pointers
[ ] You don't seem to understand functions
[ ] You don't seem to like your fellow programmers very much

You seem to be targeting the market for:
[ ] systems programming  [ ] scripting  [ ] shells  [ ] web  [ ] games
[ ] batch jobs  [ ] app making  [ ] teaching programming
[ ] appeasing ops/security officers  [ ] freaking out ops/security officers
[ ] code golfing  [ ] parody languages  [ ] writing type-theory papers
[ ] creating AI  [ ] *mumble* blockchain *mumble*  [ ] other forms of raising VC money
but I'm afraid the market is:
[ ] already saturated with frankly better options
[ ] unwilling to adopt solutions from small companies
[ ] unwilling to adopt solutions from individual part-time developers
[ ] busy with more important problems
[ ] too smart to fall for your ploy

Additionally, your marketing has the following problems:
[ ] Complete lack of code examples
[ ] Unsupported claims of increased productivity
[ ] Unsupported claims of greater "ease of use"
[ ] Obviously rigged benchmarks where the bulk of work is done:
    [ ] in handwritten assembly
    [ ] by libraries in other languages, that you call through your FFI
[ ] You're exclusively benchmarking toy functions for:
   [ ] addition  [ ] Fibonacci  [ ] FizzBuzz  [ ] JSON parsing  [ ] serving HTTP
[ ] Noone really believes that your language is faster than:
    [ ] assembly  [ ] C  [ ] Rust  [ ] Go  [ ] Javascript  [ ] Python
[ ] Rejection of orthodox programming-language theory without justification
[ ] Rejection of orthodox systems programming without justification
[ ] Rejection of orthodox algorithmic theory without justification
[ ] Rejection of basic computer science without justification
[ ] Rejection of engineering ethics without justification

My security officer asked me to point out that:
[ ] Your builds are:
    [ ] not reproducible  [ ] unsigned  [ ] triggering our anti-virus
    [ ] hosted on a forum  [ ] in a sanctioned country
[ ] It relies on external servers  [ ] and runs code from them  [ ] at runtime
[ ] Your deserialization feature is indistinguishable from a reverse shell
[ ] Your package manager:
    [ ] has trivial security holes
    [ ] lacks decent user authentication
    [ ] hasn't learned the lessons from left-pad et al

Compared to similar efforts, I would like to note that:
[ ] Your complex sample code would be one line in: _______________________
[ ] We already have many "better C" languages
[ ] We already have many safe system languages
[ ] We already have many easy-to-learn languages
[ ] We already have many web languages, for frontend, backend, and both-ends.
[ ] We already have many "look at this cool type system!" languages
[ ] You have reinvented Lisp but worse
[ ] You have reinvented Haxe but worse
[ ] You have reinvented Crystal but worse
[ ] You have reinvented Zig but worse
[ ] You have reinvented Javascript but worse
[ ] You have reinvented Javascript better, but that's still no justification
[ ] You have reinvented IntercalScript but non-ironically

In conclusion, this is what I think of you:
[ ] 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.
[ ] I don't want to be in your shoes when the cloud bill comes.

noone is too smart to fall for my ploys