
Programming Language Checklist - lelf
https://famicol.in/language_checklist.html
======
shadowgovt
When I was younger, I imagined there would come along a true language that
would solve my problems.

It took me a long time (and a lot of banging my head into bad environments) to
realize that language matters a lot less when the IDE is well-configured and
fluent with what I want to do, the toolchain allows for experimentation
without ruining the ability to do large, collaborative work, and both
debugging and profiling are possible. And those are things you can't really
add to a language environment when the language itself (spec and
implementation) is constantly in flux.

Maybe a language will appear one day that renders all those tools obsolete,
but we still evaluate and run code on real machines and it's still written by
human beings so I sincerely doubt it.

~~~
iLemming
> when the language itself (spec and implementation) is constantly in flux.

Common Lisp and Clojure are legendary for their stability. So many times I
have experienced it myself - I would pick up a 5-6 year old Clojure project,
update a bunch of dependencies, and somehow most things work right off the
bat. That trick never worked for me with pretty much any other language - C#,
Java, Python, Ruby, Go, Lua, Javascript - you name it.

Why is that? Probably because Lisp dialects essentially have no syntax. Code
is data and data is code.

~~~
lispm
I thought Common Lisp is stable because the standard is unchanged since its
publication in 1994.

Lisp dialects have a lot of syntax. Every macro implements syntax.

~~~
iLemming
Macros don't get written very often. Some Lispers (e.g.: Clojurists) advocate
against solving problems with macros (if they can be solved with regular
functions). However, at the end of the day, macro or a function - data remains
data. In non-lispy languages syntax often complects meaning and order.

~~~
lispm
> Macros don't get written very often.

It's not how often you write macros. Just write ten macros -> ten syntax
extensions. The Common Lisp implementation I use has around 700 predefined
external macros.

> against solving problems with macros (if they can be solved with regular
> functions).

It's just that macros are for different things and for those are widely used
in Lisp.

------
gdwatson
I’ve loved this list for a long time. It’s a play on the old spam solution
checklist:
[https://craphound.com/spamsolutions.txt](https://craphound.com/spamsolutions.txt)
.

------
everdev
> [ ] Syntax is what makes programming difficult

I'd love to see language design and language development treated as different
disciplines.

Just like developers were the first web designers, developers have been the
first language designers.

Ideally a language designer would only be tasked with how to express complex
ideas in a simple, composable syntax.

Language developers would be tasked with everything else: basically making
those ideas work as efficiently and consistently as possible.

Not to say a language designer and developer can't be the same person, but I
think there might be some benefit to having a linguist (with some
understanding of development) and a developer (with some understanding of
linguistics) team up on a new language.

~~~
nudq
> a linguist (with some understanding of development)

Your wish has been granted: Larry Wall, Perl 6.

~~~
lizmat
Please note that Perl 6 has been renamed to Raku
([https://raku.org](https://raku.org) using the #rakulang tag on social
media).

------
shadowgovt
"The name of your language makes it impossible to find on Google"

\--> [ ] Google has made its own language with a name near to yours and has
stolen all the search results from you

~~~
harikb
I don’t think Google needs to steal a language name. They fuck it up and
create a non-searchable name just as well on their own.

~~~
lmkg
GP may be referencing the Go! programming language, which predates the Go
programming language by several years.

[https://en.wikipedia.org/wiki/Go!_(programming_language)](https://en.wikipedia.org/wiki/Go!_\(programming_language\))

------
ken
Of course, every successful language could be roasted with this, too.

It's a cute post but if there were a simple checklist for creating a
successful language, every language designer would just do that.

~~~
BjoernKW
Bjarne Stroustrup, creator of C++, is often quoted with this statement: "There
are only two kinds of languages: the ones people complain about and the ones
nobody uses."

I suppose, scathing criticism in that respect is the highest form of praise.

~~~
taneq
If you’re not making anybody angry, you’re not doing anything important.

~~~
nulldata
But making people angry doesn't imply that you're doing something important
though.

~~~
taneq
Well yeah, it’s necessary but not sufficient. ;)

------
mhd
> [ ] You have reinvented Javascript but worse

> [ ] You have reinvented PHP but worse

I'm trying to think of languages that would fit that bill. That almost sounds
like a challenge.

~~~
wsc981
Brainfuck [0], Whitespace [1] and INTERCAL [2] come to mind :)

Of course, one could argue none of these are 'serious' programming languages.

\---

[0]:
[https://en.wikipedia.org/wiki/Whitespace_(programming_langua...](https://en.wikipedia.org/wiki/Whitespace_\(programming_language\))

[1]:
[https://en.wikipedia.org/wiki/Brainfuck](https://en.wikipedia.org/wiki/Brainfuck)

[2]:
[https://en.wikipedia.org/wiki/INTERCAL](https://en.wikipedia.org/wiki/INTERCAL)

~~~
baq
> [ ] You have reinvented Brainfuck but non-ironically

:)

------
carapace
FWIW, here's some IMO interesting and maybe even good advice "on language
design":

Frank Atanassow, "Some words of advice on language design"

[http://lambda-the-ultimate.org/node/687#comment-18074](http://lambda-the-
ultimate.org/node/687#comment-18074)

------
zbentley
> Shift-reduce conflicts in parsing seem to be resolved using rand()

Ha!

------
jupp0r
Is there anybody who would argue against:

\- everything is an expression

\- destructuring

\- support for higher order functions

Those seem to be universally loved features that new programming languages are
required to have in order to still be appealing.

~~~
tsimionescu
While I personally agree with you, I know that some people really hate
'everything is an expression', especially when assignment is treated as an
expression. This has been a very controversial addition to Python 3 for
example.

I would also mention that support for higher order functions, in the sense of
functions which take other functions as arguments, is eevn possible in C. I
think a much more important feature that is only recently becoming mainstream
is support for lambdas. Support for HoF without lambdas is relatively
worthless in my opinion.

~~~
fctorial
Loops are not expressions in python.

~~~
tsimionescu
Many things are not expressions in Python. My point was that the community is
hostile to making (some of) them expressions, as was seen with the controversy
over adding := as an assignment expression (so you can do `if x:=y`, for
example).

------
dang
Has there really been only one big thread?
[https://news.ycombinator.com/item?id=6784085](https://news.ycombinator.com/item?id=6784085)

Edit: well, there's also this:
[https://news.ycombinator.com/item?id=7836410](https://news.ycombinator.com/item?id=7836410)

Can anybody track down the year this was written?

~~~
grzm
Looks like it goes back to at least November, 2011:

[https://web.archive.org/web/20111103024132/http://colinm.org...](https://web.archive.org/web/20111103024132/http://colinm.org/language_checklist.html)

~~~
shadowgovt
It's older than that. I won't say how I know, but bits and pieces of this were
tumbling around in the undergrad hivemind of a certain Pittsburgh university
for awhile before 2011. ;)

~~~
nostrademons
I remember seeing it back when I was interested in programming language
design. I lost interest around 2010 (after concluding largely what the
checklist was getting at, that there's no point developing a new programming
language), so that would put it in the 2005-2010 period.

Ironically, most of the languages I've used in the last 5 years (Swift, Rust,
Kotlin) post-date that period, so I was wrong in my conclusion.

------
cies
I got an idea for a language where the code in the file format is some
intermediary language, which you write with an editor plugin that makes it
more human-readable.

The editor plugin (in contrast to existing language plugins) also translates
the error msgs back to the human-readable code.

Just an idea, but I could not get it to fit in the questionaire :)

~~~
cinnamonheart
Have you heard of Unison? If not, it may interest you -- it stores code in a
syntax tree rather than as text directly.

[https://www.unisonweb.org/](https://www.unisonweb.org/)

>Unison is a language in which programs are not text. That is, the source of
truth for a program is not its textual representation as source code, but its
structured representation as an abstract syntax tree.

It has some further goals for doing this which are really exciting to me, such
as content-addressable code, but the starting point is similar to the one you
stated. :)

~~~
cies
Interesting indeed! Thanks for pointing this out.

------
cryptica
>> You appear to believe that: Syntax is what makes programming difficult

This is exactly the problem. People spend so much effort looking for better
syntax that they miss the most important part of programming. It's about
design and structure, the syntax doesn't really matter at all. I don't even
care if it's dynamically typed or statically typed or functional or not. A bad
developer will produce bad code no matter the language is. I've seen this over
and over.

It's not so different from human languages. It doesn't matter what the
language is; if you know it well enough, you can write a great novel with
it... But only if you're a good author to begin with.

A bad author is not going to start learning French because they couldn't write
a successful novel in their native English... Instead, they will work on their
storytelling because they know that they are at fault, not the language.

I've written code in many languages and I can produce good software with any
of them. The language I'm most familiar with is the one which allows me to
work faster, but it has basically no effect on quality of the code.

For example, in the past, I've written Golang code after learning it a couple
of days before for a job interview and the interviewer (a well known developer
and founder of a popular startup at the time) commented that it was one of the
best designed/structured samples he has seen. It took me a long time to write
it because I had to look up stuff all the time but it seems to have had little
effect on the quality of the code.

People have to stop blaming tools and start blaming themselves. It takes over
a decade of intense work (nights and weekends too) of constant self-blaming
and adjustments to become good at coding. That's if you have natural talent
for it. If you're not a natural then you have to be even more patient.

~~~
tluyben2
> the syntax doesn't really matter at all.

Somehow it does though: I find even j/k/apl easier to parse in my head than
Ruby; somehow the ruby syntax gives me a headache. Not sure why that is, as I
wrote a lot of code in it, but I find Python, C#, F#, Haskell or Kotlin far
nicer to read and write. And, even though I understand the semantics and can
write code in Ruby, if I have a choice, I would never touch it again. And
that's only syntax/idioms. I find JS also quite rancid syntactically, but not
as repulsive as Ruby.

And I know other people have this with different (or the same) languages as
well; like someone else said, most people (even on HN) won't even try
languages with a 'weird' syntax, even if they are proven to be more productive
in some cases relevant to them. I know quite a lot of Lisp-y coders (most of
them do Clojure these days) and they don't understand how/why you would ever
use anything else. Most people here (maybe including you) have the inverse of
that. As there are blazingly fast Lisp/Schemes on every platform, why are you
using Go or another syntax than the basic AST? And yet you are and most of us
are. If syntax does not matter, why have any syntax at all?

~~~
skinnymuch
Yeah for sure this is a big thing. I love Ruby’s syntax and if I could, I’d
love to write in it all day if I was being paid the same amount as another
language. Psychology is also at play. JavaScript I agreed can be quite rancid.
But knowing it’s the only language that works in every browser, I internally
whined about it less and now rarely do at all.

~~~
tluyben2
I do not really whine about it (except when people are talking about it as I
do feel it's important to have and hear different opinions) and of course JS
is currently a necessary evil. Thinking about that too much makes no sense and
serves no purpose, but when I step back, I know I just really don't like it.
And then I just get back to coding. With Ruby I have a harder time doing that.
Guess it's taste and 'first experience'; my first Ruby experience was
inheriting a very large, badly written (very hacky) RoR codebase I had to
migrate 2 versions up to the latest RoR. It was pure hell. So it would be a
combination of things that gives me such PTSD for syntax.

------
leshow
This checklist comes across as incredibly ignorant. We push forward with
research into all kinds of things, processors, hardware, mathematics, etc. The
fact that PLT should somehow be exempt is silly. New languages coming out that
do something different are a testing ground for features, some will become
popular, most won't.

Sometimes there is a real advantage to writing real world applications in some
particular language. Maybe you are writing something that needs to be
performant, safe, and low level, so Rust is an attractive option. Maybe you
are writing web front-ends and you see the benefit of a type system like
what's available in Typescript. There are lots of reasons not to just write
everything in C or Java. Don't be sour because we aren't all using the same
language for 50 years; we've made advancements in computer science and that's
reflected in our tools.

~~~
bananabreakfast
Woosh

This is satire of HN, not an actual checklist

~~~
sdegutis
I think GP gets it. This checklist does a great job making several different
valid points, and at the heart of them seems to be the fact that there is no
Perfect Language. Discovering this checklist helped me a ton back when I was
turning down language after language for silly reasons. For example, I'm glad
I gave Rust a chance this past month, despite dismissing it a few years ago.

------
caiocaiocaio
Making a language is fun, and builds your skills. I'd rather work with a
person who has made a bad language than someone who has never made one.

Don't make fun of people for making languages.

~~~
macintux
This checklist is, to my eyes, making fun of people who make fun of languages.

~~~
caiocaiocaio
Well, if that's the case, I can do you one better.

------
nautilus12
Criticism of Typed FP seems to be the main focus of this as most of it's
criticisms seem to be at the top of the list. I think it's partly justified,
typed FP has been cargo culted to the point where I've seen hello world
implementations that definetely were not obvious and required a PhD in
category theory. That said I've seen a ton of python code that took
monumentous effort to get working at runtime, and broke unpredictably in
production too...

------
musicale
dear C, unfortunately you lack: a memory safe compilation mode for gcc and
clang, non-clunky syntax for iterators and abstractions

dear python3, unfortunately you lack: print statement, fast/any type checking,
concurrency, speed

dear java/golang/javascript et al., unfortunately you lack: named parameters,
default parameters, predictable performance

dear nearly everyone except ada/oberon/et al., unfortunately you lack:
sensible numeric types/subtypes and ranges

------
thih9
> You appear to believe that: [ ] Nobody really needs: [ ] concurrency [ ] a
> REPL [ ] debugger support [ ] IDE support [ ] I/O [ ] to interact with code
> not written in your language

This is funny for general purpose languages, but doesn't seem relevant for
specialised languages. I wish the checklist clearly stated that it targets
general purpose languages.

~~~
shadowgovt
I think the joke-inside-the-joke is the assumption that every language seeks
to be a GP language. Which is not true, but sure tends toward truth as time
approaches infinity.

------
mikorym
Is there a formula to follow the checklist? Like some kind of directed graph
in the background?

~~~
cormacrelf
The checklist is a valid, but not very good, brainfuck program, simply execute
it.

------
tracker1
Man, I so need something like this filled out for Blazor, but since it's not
expressly a language, it doesn't quite fit. Been arguing against it for a
while, half the new projects (from other teams) where I work are using it.

~~~
exdsq
My mates a ‘die hard’ C# fan and has been using it (almost exclusively) for
over 15 years. Recently he’s been talking about Blazor a lot, and having
worked on a few web apps myself, I can see its general appeal.

Why don’t you like it? I’ve not read any anti-Blazor opinions.

~~~
tracker1
First off, I'm not really against it in concept... about my only real
complaint is the latency for server actions over the internet is rather
painful (look at devexpress or telerik component demos) and the wasm payload
is around 2.2mb for a hello world app to start.

The component libraries themselves are relatively poor quality and have some
weird JS integrations. There's no good open-source component libraries. Even a
good library that utilizes bootstrap or material-design scripts would be nice.

Once these issues are generally resolved, I'd be more inclined to suggest it,
but I do not want to be the first mover on this one. I've seen way too many X
to browser libraries come and go without gaining any real traction only to die
on the vine so to speak, then you're stuck rewriting or patching an
application that looks and feels ancient.

Even then, one of the larger arguments in favor of Blazor is really, "I can
reuse my C# skills." Even there, you need a lot of Browser application context
knowledge in practice, and you've just created disconnects and more work where
you do need it. That doesn't even get into the mirrored trees directory
structure of .Net MVC that is repeated with Blazor.

If I were to explore something similar, I'd probably favor Yew (rust) which
seems to be around 220k for the todo mvc app.

In summary:

    
    
        * Bulky payload or laggy response
        * Lighter alternatives
        * No network effect
        * Dirty abstractions
        * Messy structure by default
        * Verbose
    

My preference for web applications isn't particularly lightweight, but much
more responsive and imho much better developer velocity with a more consistent
and better functioning application...

    
    
        * React (favoring hooks)
        * Redux / GraphQL
        * Material-UI (jss/css-in-js themes)
        * Fetch API
        * connected-react-router
    
    

I'd also be more inclined to give Vue or Flutter (Dart) a try, both of which
have more maturity in terms of network effect behind them.

------
fctorial
How is this checklist supposed to be used?

~~~
sorz
A: Look this, the perfect programming language I invented is the best.

B: (tick the checklist and sent it back)

------
golemotron
[ ] You appear to have a reason to avoid change.

------
mapcars
[ ] You require the compiler to be present at runtime [ ] You require the
language runtime to be present at compile-time

The guy never heard of Lisp so I wouldn't pay much attention to this anyway.

~~~
gdwatson
I think those were included specifically to poke fun at Lisp. The list isn’t
meant to be taken very seriously.

~~~
hardwaresofton
I also chuckled at the '[ ] "multi-paradigm"' and immediately thought of lisp
since it's one of the only languages that's ever had a reason to lay claim to
that.

If you think about it, lisp is really just the smallest amount of higher-level
PL primordial soup you can give to a programmer.

~~~
dkersten
Almost every language is multi paradigm (it just takes two paradigms after
all, so every imperative OOP language is multi paradigm). All the most popular
languages today have a mix of imperative, functional and OOP. Few languages
(and certainly fewer popular ones) are paradigmically “pure”.

~~~
js8
> every imperative OOP language is multi paradigm

I am not sure how you can count imperative and OOP as two paradigms. OOP is an
extension of imperative paradigm. I would like to see what language you
consider to be OOP but not imperative and not functional.

~~~
jerf
In the spirit of a bit of fun, Erlang can arguably make that claim. The
processes are easy to view as objects, in the sense that I've often thought
that when I read what Alan Kay said about objects, it often seems to be
describing Erlang moreso than Smalltalk. But the language those objects are
implemented in is functional.

(That said, if you read real Erlang code, despite being immutable and
nominally functional, the code often is in practice simply imperative code
where the code author has manually done the SSA rewrite. This is one of my
major criticisms with the language. If you really try to program it
functionally, it's quite a pain compared to Haskell.)

