Design your programming languages right (2024)

icefox | 8 hours ago

Mostly a good list! I'd personally add sum types to it. And maybe "don't do the C thing of allowing {} to be elided after if/for/while", which is a cute syntactic hack that has never, ever earned its keep.

Itʼs more my personal opinion, but I dislike bare keywords. I think keywords should come with a sigil to clearly denote them as a keyword and allow extending the language with more keywords without breaking old code that used them as identifiers.

Certainly a bold take, but I don't think I'd want to write:

$fn sum(values: &[i32]) -> i32 {
  $let $mut accm = 0;
  $for item $in values {
    accm += item;
  }
  $return item;
}

I'd much rather write the inverse:

fn sum($values: &[i32]) -> i32 {
  let mut $accm = 0;
  for $item in $values {
    $accm += $item;
  }
  return $item;
}

But IMO neither is necessary, it's better to make clear versions and expectations about breaking changes to the language. The syntax changes are things that can be caught and (usually?) fixed by a machine. If you make it so that extending the syntax can't break it, it just means that you'll break things in far more subtle semantic ways instead.

danso | 6 hours ago

You might also like: Let's Stop Copying C

Zig has a good take on multi-line string literals.

apropos | an hour ago

Indented multiline strings

While I'm glad to see "hey, you want multiline strings to be on the same indentation level as the rest of your program" mentioned, I don't actually think the mentioned languages do this particularly well.

From the Lix documentation:

This kind of string literal intelligently strips indentation from the start of each line. To be precise, it strips from each line a number of spaces equal to the minimal indentation of the string as a whole (disregarding the indentation of empty lines).

Since ${ and '' have special meaning in indented strings, you need a way to quote them. $ can be escaped by prefixing it with '' (that is, two single quotes), i.e., ''$. '' can be escaped by prefixing it with ', i.e., '''. Linefeed, carriage-return and tab characters can be written as ''\n, ''\r, ''\t, and ''\ escapes any other character.

Indented strings support string interpolation using ${ } the same way regular strings do. $${ is interpreted literally in indented strings as well, so the $ character must be escaped if it is to be followed by an interpolation.

That's a very complicated heuristic! And while this is vaguely standard, it's different-enough across languages that I always have to double-check, particularly around the indentation stripping. Raw strings in this style suffer also, as they have to come up with a delimiter pair which does not occur in the raw string itself (i.e. Rust's r###"..."###).

What I prefer instead are Zig-style raw/multiline strings. They're line-prefixed, like comments, which solves the issue of escaping characters and matching syntax pairs (all characters except \n are entered literally, \n corresponds to a newline followed by \\), and they're explicit about how much whitespace precedes each line rather than relying on heuristics, and they also accomplish "multiline strings should be on the same indentation level as code". This is what it'd look like if Nix had them:

stdenv.mkDerivation {
  ...
  postInstall =
    \\mkdir $out/bin $out/etc
    \\cp foo $out/bin
    \\echo "Hello World" > $out/etc/foo.conf
    \\${
    \\  if enableBar then 
    \\    "cp bar $out/bin" 
    \\  else 
    \\    ""
    \\}
    ;
  ...
}

Pretty cute design, IMO. Very pragmatic.

zem | 3 hours ago

I am sympathetic to the pure technical reason to add sigils to keywords, but from a human point of view they would make reading the code a lot more unpleasant.

doug-moen | 2 hours ago

Algol 60 and Algol 68 had boldface keywords, which look great. In the 1960's, there were no affordable hi res graphics displays and no affordable hi res graphics printers, so nobody implemented the language that way AFAIK.

Now we have cheap hi res graphics, and the Unicode standard has upper and lower case latin letters in boldface. So there's not much of a barrier to using boldface keywords today.

5d22b | an hour ago

the Unicode standard has upper and lower case latin letters in boldface. So there's not much of a barrier to using boldface keywords today.

What method of entering Unicode mathematical boldface characters do you use that you consider "not much of a barrier"?

Furthermore, is this method available cross-platform? Is it available without an IDE?

abeyer | an hour ago

Isn't this more just a flavor of syntax highlighting... aka a display and typesetting convention?

Or do you actually propose this as a syntactic rule? And to what end? I guess it namespaces keywords and identifiers separately... which in theory is nice, but I kind of wonder how much actual value it provides.

composite_higgs | 7 hours ago

Powerful visceral disgust at allowing trailing commas.

Kronopath | 6 hours ago

Why? It’s an incredibly basic quality of life feature.

daveliepmann | 5 hours ago

You're right. Go whole hog and treat them as whitespace, like Clojure & EDN. So comfortable to not worry about misplacing them.

composite_higgs | 2 hours ago

Indeed, I am thinking of s-expressions. In general, I think syntax beyond s-expressions is pointless. True lisp curmudgeon here. I actually find the idea of treating them as whitespace almost as aesthetically offensive. I just don't see the point of ambiguous or free syntactic constructs, although in the case of whitespace the alternative may be worse. I think the thing about whitespace is that all whitespace means the same thing from a syntactic point of view, whereas a comma has a much more specific meaning.

As I noted below, this is all a bit silly and I'm being melodramatic, but its something I really hate. I mean the fact that this is valid closure is ridiculous: (list a, b c, d).

adam_d_ruppe | 6 hours ago

why? im a huge fan and use it all over the place, it just makes adding, reorganizing, and removing items more encapsulated

composite_higgs | 2 hours ago

Its a wart on top of a wart, in my opinion, and absurd. A comma means "more follows" and I find the idea of corrupting its meaning out of laziness truly difficult to accept. Obviously in the grand scheme of things its nothing and I'm being melodramatic, but it really, really rubs me the wrong way.