Blog post on programming language design principles gains traction
A 2024 essay on multiline strings, file paths, and keywords sparks debate over language design best practices.
What to know
- The essay argues that early design decisions in programming languages—such as multiline string handling and keyword syntax—are difficult to change without breaking backwards compatibility, making upfront choices critical.
- Readers debate the merits of trailing commas, with some defending them as ergonomic and others expressing strong opposition to the syntax.
- The thread explores alternative visual markers for keywords: the author proposes sigils for backwards compatibility, while commenters counter with historical examples like Algol's boldface keywords or Haskell's backslash syntax.
The dispute Whether trailing commas improve ergonomics or corrupt syntax meaning, and whether sigils, boldface, or historical alternatives better solve the keyword extensibility problem. · positions read across 21 posts and comments
Trailing commas are a valuable quality-of-life feature that simplifies code reorganization and addition/removal of items.
-
“Why? It's an incredibly basic quality of life feature.”
Kronopath · Lobsters ↗
Trailing commas are aesthetically wrong and corrupt the meaning of the comma syntax.
-
“Powerful visceral disgust at allowing trailing commas.”
composite_higgs · Lobsters ↗
Sigils to distinguish keywords are technically sound but harm code readability and aesthetics.
-
“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.”
zem · Lobsters ↗
Historical alternatives like Algol's boldface keywords or Haskell's backslash syntax offer better solutions than sigils.
-
“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.”
doug-moen · Lobsters ↗
Blog author Programming language designer/writer
How it unfolded 7 developments, newest first · click a bar or a number to jump postscomments
-
7
Commenter cites Haskell precedent for multiline string handling
A reader points to Haskell's existing approach to multiline strings using backslash delimiters, offering a simpler historical example of the problem the post addresses.
-
You will be disgusted by how we use `;` in programming languages.
2 more of the top 3 · 7 posts in this stretch
-
I went the 2nd path in zukte, and I'm still happy with the result. Separating the namespace of language keywords & features from user-defined variables makes it clearer (especially to new coders) what's happening. You get used to the sigils the same way you got used to them in basic and perl. ``` if @player.wizard then print "There's a wizard…
-
> but I kind of wonder how much actual value it provides Boldface in Algol 60 and 68 allows the languages to be sure that a keyword is not part of an identifier. In Algol, you can insert spaces anywhere in an identifier and it is treated the same. So, “print operand” and “printoperand” are the same name, and they don’t contain the keywords…
-
-
6
Post also shared on Hacker News with lower engagement
The same essay is posted to Hacker News and receives 2 points with only 1 comment, indicating narrower audience interest on that platform.
-
The OP wishes to syntactically distinguish keywords from identifiers, so that you can add new keywords in a backward compatible way, without invalidating existing code. The OP suggests using sigils to distinguish keywords, but the Algol standards propose to mark this syntactic distinction by representing keywords in bold face. And bold face looks…
-
-
5
Discussion shifts to alternative keyword marking: boldface
A commenter proposes using Unicode boldface characters for keywords—a visual distinction from the 1960s Algol standard—as a more aesthetic alternative to sigils. A follow-up questions the practical barriers to entering and displaying such characters cross-platform.
“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.”
— doug-moen -
> 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?
2 more of the top 3 · 5 posts in this stretch
-
> 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:](https://docs.lix.systems/manual/lix/stable/language/values.html#type-string) > This…
-
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…
-
-
4
Commenter raises readability concerns about keyword sigils
A reader acknowledges the technical merit of using sigils to distinguish keywords but argues that from a human perspective, sigils would make code harder to read.
“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.”
— zem -
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.
1 more of the top 2 · 2 posts in this stretch
-
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…
-
-
3
Readers debate trailing comma syntax
Discussion splits sharply on the trailing comma feature. Some defend it as a quality-of-life feature that simplifies code reorganization, while others express visceral opposition to the syntax.
“Powerful visceral disgust at allowing trailing commas.”
— composite_higgs -
Why? It’s an incredibly basic quality of life feature.
2 more of the top 3 · 5 posts in this stretch
-
why? im a huge fan and use it all over the place, it just makes adding, reorganizing, and removing items more encapsulated
-
You might also like: [Let's Stop Copying C](https://eev.ee/blog/2016/12/01/lets-stop-copying-c/) Zig has a good take on [multi-line string literals](
-
-
2
Commenters propose additions and debate keyword syntax
Early discussion frames the post as 'mostly a good list' and introduces counterarguments. A commenter suggests adding sum types and criticizes the optional braces syntax in C-like languages. The author's proposal to add sigils to keywords draws immediate pushback from readers who worry about readability.
“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.”
— icefox -
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…
-
-
1
Post shared on Lobsters community
The essay is posted to Lobsters and receives 25 points with 15 comments, reaching moderately high visibility on the platform.
“Indented multiline strings are just a thing that you can put a few extra hours of effort into fixing early, before it becomes a problem for your users and then you can't change without backwards compatibility issues.”
— Blog author, Essay author · source -
background
Author publishes essay on programming language design principles — A blog post outlines ground rules for new programming languages, addressing multiline strings, file paths, file extensions, trailing commas, and keyword syntax. The author argues that decisions made early in language design—such as how to handle indented multiline strings—are difficult to change later without breaking backwards compatibility.
What people are saying 7 voices from 1 site · best of 21 · verbatim
- What method of entering Unicode mathematical boldface characters is practical cross-platform and outside an IDE?
- Do the solutions cited for multiline strings (Dhall, Nix/Lix) actually handle indentation well, or do they have their own drawbacks?
- Yesterday
-
Early Fortran (late 1950's) ignored spaces, except in string literals. The language was specified before it was implemented, and I'm sure this sounded like a great idea at the time. On the one hand, you were using 80 column punch cards to input Fortran programs, and leaving out spaces allowed you to get more code onto a card. On the other hand…
- Sep 22
-
Hm, this looks fairly different to me... Besides indentation, the other main perk of the `\\` syntax is that every character (sans newlines) appears literally, i.e., you can copy-paste *any* text file into your codebase, tell your editor to prefix each line with `\\`, and indent it to whatever level you want. This property isn't upheld by any…
-
Yup. Don't begin your design by purposefully pissing off 99.9% of your future users. Related:
-
Haskell has actually had something not dissimilar for a very long time (it was already in Haskell98 and I'm too lazy to go back further): ``` foo = "hello!\n\ \this is a multiline \ \string" ``` which is equivalent to `foo = "hello!\nthis is a multiline string"`. The need to add manual `\n` is a bit finicky but it's very simple. You can indent…
-
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.
-
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.
-
You're right. Go whole hog and treat them as whitespace, like Clojure & EDN. So comfortable to not worry about misplacing them.