7 ms·

Choosing a language based on its syntax?

40 points by todsacerdoti 8mo ago

chrsw 8mo ago
Language syntax is like the weather. When it's good (or when you're acclimated to it, I guess) you don't notice it. When the weather is perfect you don't even feel like the atmosphere even exists. When a language is so ingrained in your mental models, you don't even notice syntax, you just see semantics.
- ivanjermakov 8mo ago
  True to any design in general.
- gingerBill 8mo ago
  In the follow up article, I wrote something like this in the conclusion: > Designing a language is more than just getting the syntax right, and denotation semantics are a lot more important in most ways, but that does not mean syntax does not matter. When you get syntax right, people won’t even know you’ve done anything at all. But when you’ve got it wrong (and have actually tried using the language), they will complain instantly. Follow-up Article: https://www.gingerbill.org/article/2026/02/21/does-syntax-matter/ https://www.gingerbill.org/article/2026/02/21/does-syntax-ma...
IshKebab 8mo ago
A lot of programming is taste, and syntax gives you a very quick judgement about how good the language designer's taste is. How familiar they are with what we know about which syntax works well, and so on. For example if you're designing a language in 2026 that uses `type name` instead of `name: type`... that is highly suspicious. Also syntax is the interface through which you interact with the language, so bad syntax is going to be something annoying you have to deal with constantly. Sure you'll be able to write good programs in a language with bad syntax choices, but it's going to be less fun. > Odin’s rules, which are very similar to Python’s, are to ignore newline-based “semicolons” within brackets (( ) and [ ], and { } used as an expression or record block). Honestly I always thought that was a bit crap in Python and I'm surprised anyone thought this was a sensible thing to copy. Really, just use semicolons. As soon as an "easy" rule becomes even vaguely difficult to remember it's better to bin it and just require explicitness, because overall that is easier.
- gingerBill 8mo ago
  Did you even read the article, even the heading of that section? You know there is a huge majority that do not want semicolons whatsoever, so saying people should just suck it up is actually a determent to the adoption of the language because of people's general tastes.
imglorp 8mo ago
As Ken Iverson noted in "Notation as a Tool of Thought"[1], yeah the syntax absolutely matters. The same program might resonate and make sense in one language but be incomprehensible if translated 1:1 in another. Computer languages are for humans to understand and communicate. 1. https://www.eecg.utoronto.ca/~jzhu/csc326/readings/iverson.pdf https://www.eecg.utoronto.ca/~jzhu/csc326/readings/iverson.p...
- d-us-vb 8mo ago
  Iverson's point is more regarding semantics than syntax, though. The only mention of syntax suggests its better for it to be simple (presumably so that the semantics are closer to the surface). Every programming language is a notation for describing computation; notation is a catch all for all three levels: orthography, syntax, and semantics. APL is interesting because it not only uses an unconventional syntax, but also an unconventional orthography (obligate usage of special symbols), and its semantics are different as well from most languages (array programming). Iverson's point is that APL as a notation is valuable for making the structure of certain computations obvious, and that this point generalizes across programming languages. GingerBill's article is making a narrower claim: that semantics are what determines a good notation usually, not syntax.
  - imglorp 8mo ago
    > Iverson's point is that APL as a notation is valuable for making the structure of certain computations obvious, Yes, very much so, where as usual, there are local maxima where each notation excels at representing some problems nicely and is awkward for others.
majorchord 8mo ago
Syntax is what keeps me away from Rust. I have tried many times to get into it over the years but I just don't want to look at the syntax. Even after learning all about it, I just can't get over it. I'm glad other people do fine with it but it's just not for me. For this reason (coming from C++) I wished Swift were more popular because that syntax is much more familiar/friendly to me, while also having better memory safety and quality of life improvements that I like.
- tialaramex 8mo ago
  Do you have some examples of what you couldn't get along with? I know this is a lot to ask, but to me while I do write Rust and I don't write C++ or Swift in volume (only small examples) the syntax just doesn't feel that different really. If you do like Swift you might want to just bite the bullet and embrace the Apple ecosystem. That would be my recommendation I think.
- rrgok 8mo ago
  This resonate so much to my relationship with Rust. Also with Go. I'm having hard time learning Rust's advacend concepts because of its syntax. Strangely enough I find Lisp's parentheses much more attractive.
- g947o 8mo ago
  Swift's syntax may look nice, but as soon as you run into "The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions" you'll forget all of that. Hint: they are related.
  - O-stevns 8mo ago
    It didn't have to be like that though... It hasn't always been this bad. Personally I think they've been ruining Swift since version 4. It's particularly terrible in SwiftUI context nowadays but you can also make it chuck on something as simple as a .map(...)
- rtfeldman 8mo ago
shortercode 8mo ago
A languages syntax and its error messages are its user interface. Yes you can have a good tool that you don’t enjoy looking at. You can also have a good tool that’s frustrating to learn because its user interface isn’t clear and doesn’t do what you expect. Can I not hope for something that does what I need, is easy to use, and looks good? I dislike the “you can change the syntax” argument because that just doesn’t happen. Closest thing is a new language that compiles to another.
nice_byte 8mo ago
I have really just one wish when it comes to syntax: no syntactically significant whitespace. Space, newline, tab, etc. should ALL map to the same exact token. In practice this also means semicolons or something like them are needed as well, to separate expressions/statements. I dislike langs that try to insert semicolons for you, but at least it's better than the alternative. the way python treats whitespace is a huge design mistake that has probably wasted like a century (if not more) worth of time across all users, on something really trivial.
- JamesTRexx 8mo ago
  That's one of the things I like about C, the independence in how one can write code. I was able to develop my own style thanks to that, visualising the structure of the code to distinguish the different parts of statements and make it more clear (at least to myself). (edited several times to try to correct changes in formatting for an example here, but it's just screwed up :-/ )
  - liveoneggs 8mo ago
    https://www.perlmonks.org/?node_id=45213 https://www.perlmonks.org/?node_id=45213
- zzo38computer 8mo ago
  I agree, that I do not like automatic semicolon insertion (in my opinion it is one of the worst features of JavaScript, and possibly the really worst one), and I think it is a good idea that you should use semicolons or whatever to separate expressions and statements (except for a programming language where it is already unambiguous (e.g. because you are required to have brackets around them instead), in which case it is unnecessary). However, spaces, line breaks, tabs, page breaks, etc are not normally tokens (and should not be tokens), but will separate tokens. However, that is not the only issue with the syntax, although it is a significant one.
  - nice_byte 8mo ago
    Yeah I misused the term "token". What I really meant is that they should just be token separator and nothing more (i.e. once we encounter whitespace it means the current token has ended)
wduquette 8mo ago
Semantics are where the rubber meets the road, certainly; but syntax determines how readable the code is for someone meeting it the first time. Contrast an Algol-descendant like C, Pascal, Java, or even Python with a pure functional language like Haskell. In the former, control structure names are reserved words and control structures have a distinct syntax. In the latter, if you see `foo` in the body of a function definition you have no idea if it's a simple computation or some sophisticated and complex control structure just from what it looks like. The former provides more clues, which makes it easier to decipher at a glance. (Not knocking Haskell, here; it's an interesting language. But it's absolutely more challenging to read.) To put it another way, syntax is the notation you use to think. Consider standard math notation. I could define my own idiosyncratic notation for standard algebra and calculus, and there might even be a worthwhile reason for me to do that. But newcomers are going to find it much harder to engage with my work.
- IshKebab 8mo ago
  I absolutely agree about Haskell (and also OCaml). They both suffer from "word soup" due to their designers incorrectly thinking that removing "unnecessary" punctuation is a good idea, and Haskell especially suffers from "ooo this function could be an operator too!".
- zahlman 8mo ago
  > Contrast an Algol-descendant like C, Pascal, Java, or even Python with a pure functional language like Haskell. In the former, control structure names are reserved words and control structures have a distinct syntax. In the latter, if you see `foo` in the body of a function definition you have no idea if it's a simple computation or some sophisticated and complex control structure just from what it looks like. The former provides more clues, which makes it easier to decipher at a glance. (Not knocking Haskell, here; it's an interesting language. But it's absolutely more challenging to read.) For what it's worth, Python has been moving away from this, taking advantage of a new parser that can implement "soft keywords" like 3.10's "match" statement (which I'm pretty sure was the first application). Believe it or not, the motivation for this is to avoid reverse compatibility breaks. Infamously, making `async` a keyword broke TensorFlow, which was using it as an identifier name in some places (https://stackoverflow.com/questions/51337939 https://stackoverflow.com/questions/51337939). In my own language design, there's a metaprogramming facility that lets you define new keywords and associated control structures, but all keywords are chosen from a specific reserved "namespace" to avoid conflicts with identifiers.
hackyhacky 8mo ago
An article about diversity of language syntax that somehow only deals with C-adjacent curly-brace languages (and,tbf, Odin). This is a blinkered viewpoint. If you want to talk about syntax, at least mention the Haskell family (Elm, Idris, F*, etc), Smalltalk, and the king of syntax (less) languages, LISP (and Scheme), which teach us that syntax is a data structure.
- gingerBill 8mo ago
  The article does no such thing and just focused on declaration syntaxes and semicolons. I can class literally any language into the three categories for declaring variables. * Haskells are name-focused languages. * Smalltalk is a name-focused language. * LISPs are qualifier-focused languages. I think you might have a blinkered viewpoint in how you have interpreted the article.
  - hackyhacky 8mo ago
    > * Haskells are name-focused languages. * Smalltalk is a name-focused language. * LISPs are qualifier-focused languages. First, I reject the idea that all languages can be classified according to this metric. The fact that you think that they can reveals how little experience you have with different languages. Second, your proposed classification of these languages, even by the naive standards of the article, is wrong. You've proved my point.
    - gingerBill 8mo ago
      First, tell me languages which have named value declarations which don't fit into that category. I'd love for my hypothesis to be proven wrong. Second, how are they wrong? You haven't proved any point as you were extremely vague.
      - hackyhacky 8mo ago
        You're missing the point. Your categories are irrelevant. It's like if I announced proudly "All cars can be divided three categories: those with rear lights angled up, those with rear lights angled down, and those with rear lights straight." True but useless. But if you're going to categorize, your categorization is wrong. Just because a language puts a qualifier first in no way means that it is qualifier focused.
WorldMaker 8mo ago
The syntax of a language is the poetry form, it defines things like meter, scansion, rhyming scheme. Of course people are going to have strong aesthetic opinions on it, just as there are centuries of arguments in poetry over what form is best. You can make great programs in any language, just like you make beautiful poetry in almost every form. (Leaving an almost there for people that dislike Limericks, I suppose.) Language choice is one of the (sometimes too few) creative choices we can make in any project. > Another option is to do something like automatic semicolon insertion (ASI) based on a set of rules. Unfortunately, a lot of people’s first experience with this kind of approach is JavaScript and its really poor implementation of it, which means people usually just write semicolons regardless to remove the possible mistakes. Though the joke is that the largest ASI-related mistakes in JavaScript aren't solved by adding more semicolons, it's the places that the language adds semicolons you didn't expect that trip you up the worst. The single biggest mistake is adding a newline after the `return` keyword and before the return value accidentally making a `return undefined` rather than the return value. In general JS is actually a lot closer to the Lua example than a lot of people want to believe. There's really only one ASI-related rule that needs to be remembered when dropping semicolons in JS (and it is a lot like that Lua rule of thumb), the Winky Frown rule: if a line starts with a frown it must wink. ;( ;[ ;` (It has a silly name because it keeps it easy to remember.)
ameliaquining 8mo ago
Python doesn't have automatic semicolon insertion.
- gingerBill 8mo ago
  Yes it does. You can even type `;` anywhere too, go an try it. Because of how good the rules are for Python's needs, most people never know that semicolons even exist in Python.
  - ameliaquining 8mo ago
    This isn't quite right. Go and JavaScript use semicolons pervasively throughout their formal grammars, and mostly don't use newlines; then, on top of that, they have special rules that allow the semicolons to be omitted in many cases depending on newline placement. Python uses newlines pervasively throughout its formal grammar, and only allows semicolons to be used in a couple specific places (at the end of a simple statement or to separate multiple simple statements on a single line). The two systems have in common that you can either include or omit a semicolon when you've got a simple statement on its own line, but under the hood they're different; the missing semicolon at the end of a line in idiomatic Python is not "automatically inserted by the parser", it is simply not needed at all. There are also behavioral differences; for example, in Go and JavaScript a semicolon on a line by itself is legal and does nothing, while in Python it's a syntax error.
    - gingerBill 8mo ago
      This might might sound weird but I think that's a distinction without a difference. Those "newline tokens" are effectively the equivalent to a semicolon in the parser. They are statement terminators. The way that Odin or Python handles them is effectively the same except when I tokenize the newlines, they are treated as semicolons but with the "text" being "\n". Thus the distinction here is a matter of what you call it, not how it is treated. That is the same as a form of "automatic statement-terminator insertion" where that statement-terminator is whatever you want it to be. And to me, that is as form of "semicolon" (which is being used as a generalization for statement-terminator) insertion.
g947o 8mo ago
Syntax, or how humans perceive the syntax, is only a very small part of the problems when designing a programming language. There is a lot more about how a compiler would handle the syntax (efficiently) and about how the syntax affects actual code and ecosystem. The recent go blog on error handling should make it clear that syntax is often not worth worrying about. https://go.dev/blog/error-syntax https://go.dev/blog/error-syntax
hyperhello 8mo ago
I like the semantics you type in the google search bar when using it for impromptu calculations. You can use ^ to raise to a power, for example. Just type sin 45. It’s all least surprise.
- 1e1a 8mo ago
  I love how it works with units too, eg. c/433MHz or 4 bytes * 20hz * 24 hours
  - hyperhello 8mo ago
    Syntactically it probably has a ceiling, to be so casual. Least surprise won’t work for very complex programs. But maybe the programs wouldn’t be so complex if you didn’t have to stick together complex program syntax either.
- ivanjermakov 8mo ago
  I wonder how many people use REPL of a language of choice as a calculator as I do.
wavemode 8mo ago
> Lua is an example of such a language, and when a semicolon is necessary is when you have something that could be misconstrued as being a call: (function() print("Test1") end)(); -- That semicolon is required (function() print("Test2") end)() Tangential, but I sidestepped this ambiguity in a language I've been designing on the side, via the simple rule that the function being called and the opening parenthesis can't have whitespace between them (e.g. "f()" is fine but "f ()" or "f\n()" is not). Ditto for indexing ("x[y]"). If these characters are encountered after whitespace, the parser considers it the beginning of a new expression. By sacrificing this (mostly unused, in practice) syntactic flexibility, I ended up not needing any sort of "semicolon insertion" logic - we just parse expressions greedily until they're "done" (i.e. until the upcoming token is not an operator).
- recursivecaveat 8mo ago
  I definitely think needless whitespace flexibility often causes problems. For eg I'm pretty sure Bjarne chose :: instead of : for the namespace operator in C++ due to ambiguity. A little bit of required whitespace around jump labels and ternary expressions and we could have saved an extra character in an operator that often occurs multiple times per line. Everybody runs linters that enforce that anyways. Likewise the inability to use a hyphen in an identifier has wasted a lot of my time over the years, but nobody uses squashed subtraction expressions.
  - 1718627440 8mo ago
    > nobody uses squashed subtraction expressions I do.
- gingerBill 8mo ago
  That sidestepping only introduces significant whitespace, which may not be what people want in the first place. It can be quite common to align call expressions by the parentheses if they span multiple lines for clarity, and you preventing might not be desireable.
- 1718627440 8mo ago
  I wouldn't like that, because I always put a single space in front of the parenthesis. Mostly for aesthetic reasons, and to distinguish it from function-like macros. Not intended as a criticism, just a data point.
dnautics 8mo ago
in the era of LLMs, syntax might matter more than you think. The c form of `type name;` is ambiguous because it could actually be more than one thing depending on context. Even worse if you include macro sheananigans. The alternate (~rust/zig) is `var/const/mut name type` is unambiguous. For humans, with rather long memory of what is going on in the codebase, this is ~"not a problem" for experts. But for an LLM, its knowledge is limited to the content that currently exists in your context, and conventions baked in with the training corpus, this matters. Of course it is ALSO a problem for humans if they are first looking at a codebase, and if the types are unusual.
- wavemode 8mo ago
  I hope that someday LLMs will interact with code mostly via language servers, rather than reading the code itself (which both frequently confuses the LLM, as you've noted, but is also simply a waste of tokens).
  - dnautics 8mo ago
    why? I suspect that writing code itself is extremely token efficient (unless like your keywords happen to be silly, super-long alien text). Like which do you think is more token-efficient? 1) <tool-call write_code "my_function(my_variable)"/> 2) <tool-call available_functions/> resp: <option> my_function </option> <option> your_function </option> <option> some_other_function </option> <option> kernel_function1 </option> <option> kernel_function2 </option> <option> imported_function1 </option> <option> imported_function2 </option> <option> ... </option> <tool-call write_function_call "my_function"/> resp: <option> my_variable </option> <option> other_variable_of_same_type </option> <tool-call write_variable "my_variable"/>
    - wavemode 8mo ago
      Not sure I follow. You seem to have omitted the part of 1) explaining how the LLM knew that my_function even existed - presumably, it read the entire file to discover that, which is way more input tokens than your hypothetical available_functions response.
cfiggers 8mo ago
I am an S-exp enjoyer, and more for practical reasons than aesthetic ones—I really like the editor tooling that's possible with S-expressions. So I will absolutely choose a Lisp or a lisp if given the option, even at some level of inconvenience when it comes to the maturity of the language itself. I will always write Hy[0] rather than Python, for example. [0] https://hylang.org https://hylang.org (I am aware of Combobulate[1] for Emacs folks, of which I'm sadly not one.) [1] https://GitHub.com/mickeynp/combobulate https://GitHub.com/mickeynp/combobulate
- kgwgk 8mo ago
  The most machine-friendly syntax - and the least appropriate for our LLM overlords which get confused by parenthesis because they don’t see the structure.
  - andersmurphy 8mo ago
    Have you tried? LLMs are really good at elisp, which is strange because elisp code is almost always GPL. There's an option beyond lisp. Forth has even less syntax.
    - kgwgk 8mo ago
      In my experience, they find counting parenthesis as difficult as counting the r's in strawberry if it was spelled srtrawrrrbrrerryrrrr.
netbioserror 8mo ago
Major syntactic structures definitely have an influence on my language choices. Outside of compilation and runtime model, modeling the domain (both data and procedures) changes drastically between paradigms. Syntax is what enables or hamstrings different modeling paradigms. My two biggest considerations when picking a language are: - How well does it support value semantics? (Can I pass data around as data and know that it is owned by the declaring scope, or am I chained to references, potential nulls, and mutable handles with lifetimes I must consider? Can I write expression-oriented code?) - How well does it support linear pipelining for immutable values? (If I want to take advantage of value semantics, there needs to be a way to express a series of computations on a piece of data in-order, with no strange exceptions because one procedure or another is a compiler-magic symbol that can't be mapped, reduced, filtered, etc. In other words, piping operators or Universal Function Call Syntax.) I lean on value semantics, expression-oriented code, and pipelining to express lots of complex computations in a readable and maintainable manner, and if a language shoots me in the foot there, it's demoralizing.
jiriknesl 8mo ago
I don't want to be overly negative, but it seems to me that author considers just different flavours of C. There is a massive difference between Clojure, Prolog, and Forth. The whole: type name = value—type-focused name: type = value—name-focused var name type = value—qualifier-focused Is so much deep into details of how syntax might look like. If you are choosing between Kotlin and Go, it is for the platform, not the syntax. If you decide between Haskell, Idris, Scheme, you do it with the syntax in mind.
- ErroneousBosh 8mo ago
  All programming languages are basically Algol or Lisp, even the ones I like. C? Basically Algol. Pascal? Basically Algol, actually quite closely. Go? Basically Algol, via Pascal. Lua? Basically Algol, surprisingly closely. Forth? Basically Lisp. Postscript? Basically Lisp.
  - ivanjermakov 8mo ago
    When I ponder about PL semantics, crossroad feature is currying. This decides whether partial application, pattern matching, function composition, combinators, and other functional features would play a major role in the language design. Functions are curried? ML style. Not curried? C style.
    - ErroneousBosh 8mo ago
      What's "ML" in this context?
      - ivanjermakov 8mo ago
        ML (Meta Language) https://en.wikipedia.org/wiki/ML_(programming_language) https://en.wikipedia.org/wiki/ML_(programming_language)
- gingerBill 8mo ago
  Those syntax examples are literally just general examples, not the only way you have to write them. But to categorize the ones you wrote: * Clojure is qualifier-focused * Prolog is name-focused * Forth is qualifier-focused (`:` is the qualifier in this case)
juancn 8mo ago
I never got why compilers don't have pluggable syntaxes. I mean, once you decide the "flavor" (e.g.: typed, imperative, with a dash of functional and some oop for good measure), you could have more than one syntax and easily switch to whatever the reader wants. We had an integration language in a product I worked on that had three flavors (you can check it here: https://docs.oracle.com/cd/E13154_01/bpm/docs65/pdf/OracleBPM-StudioGuide_10.3.pdf https://docs.oracle.com/cd/E13154_01/bpm/docs65/pdf/OracleBP... , page 254) The original syntax scared some people, so we had the compiler use the same AST with three different parsers: Original, Java and VB. The editor (which had syntax highlighting and auto completion) would let you see the code however you wanted. You could even have a setting in the IDE that always showed the code as you wanted. We even respected some weirdness in the spacing and indentation of comments and code when needed. For some languages, like rust it may be a stretch, but for most vanilla languages, you could easily re-skin them to look much more like something else, that's comfy for whoever is looking at the code.
- hyperpape 8mo ago
  > I never got why compilers don't have pluggable syntaxes. An interesting question, but the answer is "because it's a bad idea" that doesn't actually solve the problem. That said, the right way to implement this is as a "transpiler" that compiles one syntax into another. And only the people who want to use it pay the costs.
  - zahlman 8mo ago
    > An interesting question, but the answer is "because it's a bad idea" that doesn't actually solve the problem. This doesn't really explain anything, and it isn't clear that both of you have the same model of "the problem" in mind.
    - tialaramex 8mo ago
      The usual way people get here is that they didn't realise programs are for reading by humans. That's why we have formatting conventions (the compiler doesn't care but humans do) and so it's also why a single syntax is important. If there are six syntaxes for a hypothetical language L, then either every L practitioner must learn all six syntaxes (ew, no thanks) or most L programmers can't read each other's programs and so it's basically unmaintainable.
zahlman 8mo ago
> I am still perplexed by how people judge a language purely by its declaration syntax, and will decide whether to use the language purely based on whether they like that aspect or not. Throughout the article, OP seems baffled that people have aesthetic preferences. Well, yes, of course we do; dealing with ugly things is the computer's job. It also comes across like OP hasn't seen a lot of examples of really interesting language syntax, i.e. things outside, shall we say, the extended Algol family. The discussion seems to accommodate brace-less languages like Python, but not e.g. the Lisp or Forth families. > and thus just becomes a question of ergonomics or “optimizing for typing” (which is never the bottleneck). It might not be a bottleneck in terms of time needed. But unpleasant syntax is annoying and breaks flow. Thoughts creep in about how you wish the language looked different and that you didn't have to type these other bits. (Which is why a lot of people feel so strongly about type inference.) > From what I gather, this sentiment of not understanding why many “modern” languages still use semicolons is either: OP seems to conflate "semicolon" with "visible, explicit token that separates statements. There's no reason it couldn't be some other punctuation, after all. Describing Python's approach to parsing as "automatic semicolon insertion" is wild to me; the indented-block structure is the point and statements are full lines by default. Semicolons in Python are a way to break that rule (along with parentheses, as noted), which are rarely seen as useful anyway (especially given the multiple assignment syntax). > To allow for things like Allman braces, Odin allows for extra single newline in many places in its grammar, but only an extra single newline. This is to get around certain ambiguities between declaration a procedure type and a procedure literal Right; and the point of Python's approach is to not need braces in the first place, and therefore sidestep any considerations of brace style. And when you do that, it turns out that you don't need to think nearly as hard about whether a newline should terminate a statement. It's a package deal. > Maybe I don’t need to be as cynical and it is a lot simpler than all of that: first exposure bias. It’s the tendency for an individual to develop a preference simply because they became familiar with it first, rather that it be a rational choice from a plethora of options. > However I do think there are rational reasons people do not like a syntax of a language and thus do not use it. Sometimes that syntax is just too incoherent or inconsistent with the semantics of the language. Sometimes it is just too dense and full or sigils, making it very hard to scan and find the patterns within the code. For what it's worth, before I ever touched Python I had already used (in no particular order) multiple flavours of BASIC, Turing, probably at least two kinds of assembly, Scheme, C, C++, Java and Perl. To be fair, I had also used HyperTalk and Applescript, so maybe that does explain why I glommed onto Python. But BASIC came first. In my mind, a mid-line semicolon is exactly the kind of sigil described here, and an end-of-line sigil is simply redundant. Multi-line statements should be the explicitly-marked exception, if only because long statements should be less common than shorter ones.
norir 8mo ago
I personally would prefer to hear more about what is uniquely good about Odin semantically or syntactically than more ad hominem attacks on the intelligence of the critics of the language, which I have seen in multiple recent pieces by this author.
- zahlman 8mo ago
  Agreed; this communication style by itself makes me less inclined to try out the language.
shevy-java 8mo ago
This is the old "syntax does not matter" claim. Syntax is not the most important thing in the world when it comes to programming languages, but it does matter too. I was using perl, then PHP then ruby. There is no comparison here; ruby beats the other two languages hands down. I get to be able to do more, with less syntax and it is easier to read too (provided you write good code; you can write horrible code in any language of course). Most of the languages that are created anew, end up being a clone of C or C++. Go is one of the few exceptions here; Rust is not an exception. It is basically C++ really, from the syntax - or even worse. Sadly it is not possible to try to convince people who claim that syntax does not matter, that it does matter. They just keep on repeating that syntax is irrelevant. I don't think syntax it is irrelevant at all. It has to do with efficiency of expression. Clear thoughts. Clear design. It is all inter-connected.
- tialaramex 8mo ago
  > Rust is not an exception. It is basically C++ really, from the syntax - or even worse. That's a superficial impression. Yes the resemblance is on purpose, but it doesn't go very deep which suggests you haven't stared at this for more than a few seconds.
- gingerBill 8mo ago
  I literally had to write an extra article because of the number of people who thought I was saying syntax doesn't matter. It matters a hell of a lot: https://www.gingerbill.org/article/2026/02/21/does-syntax-matter/ https://www.gingerbill.org/article/2026/02/21/does-syntax-ma... I was trying to be as clear as I possibly could within that article to state I was only focusing on those two specific topics, rather syntax as a whole. How people judge a language based purely on its declaration syntax and nothing else. Where the declaration syntax makes the least difference compared to the rest of the syntax in the language. And still people wrongly interpreted the article.
Garlef 8mo ago
Hmm... I don't know how serious this wants to be taken - first example argues that syntax is interchangeable - but then the author tries to sell me his semis ??? And who even cares in the time of LLMs and auto formatting? "My hammer has this slight angle and if I hit the nail with just the right motion, it feels really good"
- gingerBill 8mo ago
  I was trying to be EXTREMELY clear I am talking specifically about DECLARATION syntax only and how for the most part, the concrete syntax for the DECLARTAION syntax is not that important in many languages. However concrete syntax matters a heck of a lot and cannot be trivially interchangeable. I had to write a follow-up article to clarify this because of people like yourself wrongly interpreting the article: https://www.gingerbill.org/article/2026/02/21/does-syntax-matter/ https://www.gingerbill.org/article/2026/02/21/does-syntax-ma...
thom 8mo ago
This is one of those things that I’m glad remains highly personal and stochastic. Programming languages thrive when people are able and willing to create value with them. People thrive when there are options and they can find a language that sings to them.

40 points by todsacerdoti 8mo ago

chrsw 8mo ago

Language syntax is like the weather. When it's good (or when you're acclimated to it, I guess) you don't notice it. When the weather is perfect you don't even feel like the atmosphere even exists. When a language is so ingrained in your mental models, you don't even notice syntax, you just see semantics.

ivanjermakov 8mo ago
True to any design in general.
gingerBill 8mo ago
In the follow up article, I wrote something like this in the conclusion: > Designing a language is more than just getting the syntax right, and denotation semantics are a lot more important in most ways, but that does not mean syntax does not matter. When you get syntax right, people won’t even know you’ve done anything at all. But when you’ve got it wrong (and have actually tried using the language), they will complain instantly. Follow-up Article: https://www.gingerbill.org/article/2026/02/21/does-syntax-matter/ https://www.gingerbill.org/article/2026/02/21/does-syntax-ma...

IshKebab 8mo ago

A lot of programming is taste, and syntax gives you a very quick judgement about how good the language designer's taste is. How familiar they are with what we know about which syntax works well, and so on. For example if you're designing a language in 2026 that uses `type name` instead of `name: type`... that is highly suspicious. Also syntax is the interface through which you interact with the language, so bad syntax is going to be something annoying you have to deal with constantly. Sure you'll be able to write good programs in a language with bad syntax choices, but it's going to be less fun. > Odin’s rules, which are very similar to Python’s, are to ignore newline-based “semicolons” within brackets (( ) and [ ], and { } used as an expression or record block). Honestly I always thought that was a bit crap in Python and I'm surprised anyone thought this was a sensible thing to copy. Really, just use semicolons. As soon as an "easy" rule becomes even vaguely difficult to remember it's better to bin it and just require explicitness, because overall that is easier.

gingerBill 8mo ago
Did you even read the article, even the heading of that section? You know there is a huge majority that do not want semicolons whatsoever, so saying people should just suck it up is actually a determent to the adoption of the language because of people's general tastes.

imglorp 8mo ago

As Ken Iverson noted in "Notation as a Tool of Thought"[1], yeah the syntax absolutely matters. The same program might resonate and make sense in one language but be incomprehensible if translated 1:1 in another. Computer languages are for humans to understand and communicate. 1. https://www.eecg.utoronto.ca/~jzhu/csc326/readings/iverson.pdf https://www.eecg.utoronto.ca/~jzhu/csc326/readings/iverson.p...

d-us-vb 8mo ago
Iverson's point is more regarding semantics than syntax, though. The only mention of syntax suggests its better for it to be simple (presumably so that the semantics are closer to the surface). Every programming language is a notation for describing computation; notation is a catch all for all three levels: orthography, syntax, and semantics. APL is interesting because it not only uses an unconventional syntax, but also an unconventional orthography (obligate usage of special symbols), and its semantics are different as well from most languages (array programming). Iverson's point is that APL as a notation is valuable for making the structure of certain computations obvious, and that this point generalizes across programming languages. GingerBill's article is making a narrower claim: that semantics are what determines a good notation usually, not syntax.
- imglorp 8mo ago
  > Iverson's point is that APL as a notation is valuable for making the structure of certain computations obvious, Yes, very much so, where as usual, there are local maxima where each notation excels at representing some problems nicely and is awkward for others.

majorchord 8mo ago

Syntax is what keeps me away from Rust. I have tried many times to get into it over the years but I just don't want to look at the syntax. Even after learning all about it, I just can't get over it. I'm glad other people do fine with it but it's just not for me. For this reason (coming from C++) I wished Swift were more popular because that syntax is much more familiar/friendly to me, while also having better memory safety and quality of life improvements that I like.

tialaramex 8mo ago
Do you have some examples of what you couldn't get along with? I know this is a lot to ask, but to me while I do write Rust and I don't write C++ or Swift in volume (only small examples) the syntax just doesn't feel that different really. If you do like Swift you might want to just bite the bullet and embrace the Apple ecosystem. That would be my recommendation I think.
rrgok 8mo ago
This resonate so much to my relationship with Rust. Also with Go. I'm having hard time learning Rust's advacend concepts because of its syntax. Strangely enough I find Lisp's parentheses much more attractive.
g947o 8mo ago
Swift's syntax may look nice, but as soon as you run into "The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions" you'll forget all of that. Hint: they are related.
- O-stevns 8mo ago
  It didn't have to be like that though... It hasn't always been this bad. Personally I think they've been ruining Swift since version 4. It's particularly terrible in SwiftUI context nowadays but you can also make it chuck on something as simple as a .map(...)
rtfeldman 8mo ago

shortercode 8mo ago

A languages syntax and its error messages are its user interface. Yes you can have a good tool that you don’t enjoy looking at. You can also have a good tool that’s frustrating to learn because its user interface isn’t clear and doesn’t do what you expect. Can I not hope for something that does what I need, is easy to use, and looks good? I dislike the “you can change the syntax” argument because that just doesn’t happen. Closest thing is a new language that compiles to another.

nice_byte 8mo ago

I have really just one wish when it comes to syntax: no syntactically significant whitespace. Space, newline, tab, etc. should ALL map to the same exact token. In practice this also means semicolons or something like them are needed as well, to separate expressions/statements. I dislike langs that try to insert semicolons for you, but at least it's better than the alternative. the way python treats whitespace is a huge design mistake that has probably wasted like a century (if not more) worth of time across all users, on something really trivial.

JamesTRexx 8mo ago
That's one of the things I like about C, the independence in how one can write code. I was able to develop my own style thanks to that, visualising the structure of the code to distinguish the different parts of statements and make it more clear (at least to myself). (edited several times to try to correct changes in formatting for an example here, but it's just screwed up :-/ )
- liveoneggs 8mo ago
  https://www.perlmonks.org/?node_id=45213 https://www.perlmonks.org/?node_id=45213
zzo38computer 8mo ago
I agree, that I do not like automatic semicolon insertion (in my opinion it is one of the worst features of JavaScript, and possibly the really worst one), and I think it is a good idea that you should use semicolons or whatever to separate expressions and statements (except for a programming language where it is already unambiguous (e.g. because you are required to have brackets around them instead), in which case it is unnecessary). However, spaces, line breaks, tabs, page breaks, etc are not normally tokens (and should not be tokens), but will separate tokens. However, that is not the only issue with the syntax, although it is a significant one.
- nice_byte 8mo ago
  Yeah I misused the term "token". What I really meant is that they should just be token separator and nothing more (i.e. once we encounter whitespace it means the current token has ended)

wduquette 8mo ago

Semantics are where the rubber meets the road, certainly; but syntax determines how readable the code is for someone meeting it the first time. Contrast an Algol-descendant like C, Pascal, Java, or even Python with a pure functional language like Haskell. In the former, control structure names are reserved words and control structures have a distinct syntax. In the latter, if you see `foo` in the body of a function definition you have no idea if it's a simple computation or some sophisticated and complex control structure just from what it looks like. The former provides more clues, which makes it easier to decipher at a glance. (Not knocking Haskell, here; it's an interesting language. But it's absolutely more challenging to read.) To put it another way, syntax is the notation you use to think. Consider standard math notation. I could define my own idiosyncratic notation for standard algebra and calculus, and there might even be a worthwhile reason for me to do that. But newcomers are going to find it much harder to engage with my work.

IshKebab 8mo ago
I absolutely agree about Haskell (and also OCaml). They both suffer from "word soup" due to their designers incorrectly thinking that removing "unnecessary" punctuation is a good idea, and Haskell especially suffers from "ooo this function could be an operator too!".
zahlman 8mo ago
> Contrast an Algol-descendant like C, Pascal, Java, or even Python with a pure functional language like Haskell. In the former, control structure names are reserved words and control structures have a distinct syntax. In the latter, if you see `foo` in the body of a function definition you have no idea if it's a simple computation or some sophisticated and complex control structure just from what it looks like. The former provides more clues, which makes it easier to decipher at a glance. (Not knocking Haskell, here; it's an interesting language. But it's absolutely more challenging to read.) For what it's worth, Python has been moving away from this, taking advantage of a new parser that can implement "soft keywords" like 3.10's "match" statement (which I'm pretty sure was the first application). Believe it or not, the motivation for this is to avoid reverse compatibility breaks. Infamously, making `async` a keyword broke TensorFlow, which was using it as an identifier name in some places (https://stackoverflow.com/questions/51337939 https://stackoverflow.com/questions/51337939). In my own language design, there's a metaprogramming facility that lets you define new keywords and associated control structures, but all keywords are chosen from a specific reserved "namespace" to avoid conflicts with identifiers.

hackyhacky 8mo ago

An article about diversity of language syntax that somehow only deals with C-adjacent curly-brace languages (and,tbf, Odin). This is a blinkered viewpoint. If you want to talk about syntax, at least mention the Haskell family (Elm, Idris, F*, etc), Smalltalk, and the king of syntax (less) languages, LISP (and Scheme), which teach us that syntax is a data structure.

gingerBill 8mo ago
The article does no such thing and just focused on declaration syntaxes and semicolons. I can class literally any language into the three categories for declaring variables. * Haskells are name-focused languages. * Smalltalk is a name-focused language. * LISPs are qualifier-focused languages. I think you might have a blinkered viewpoint in how you have interpreted the article.
- hackyhacky 8mo ago
  > * Haskells are name-focused languages. * Smalltalk is a name-focused language. * LISPs are qualifier-focused languages. First, I reject the idea that all languages can be classified according to this metric. The fact that you think that they can reveals how little experience you have with different languages. Second, your proposed classification of these languages, even by the naive standards of the article, is wrong. You've proved my point.
  - gingerBill 8mo ago
    First, tell me languages which have named value declarations which don't fit into that category. I'd love for my hypothesis to be proven wrong. Second, how are they wrong? You haven't proved any point as you were extremely vague.
    - hackyhacky 8mo ago
      You're missing the point. Your categories are irrelevant. It's like if I announced proudly "All cars can be divided three categories: those with rear lights angled up, those with rear lights angled down, and those with rear lights straight." True but useless. But if you're going to categorize, your categorization is wrong. Just because a language puts a qualifier first in no way means that it is qualifier focused.

WorldMaker 8mo ago

The syntax of a language is the poetry form, it defines things like meter, scansion, rhyming scheme. Of course people are going to have strong aesthetic opinions on it, just as there are centuries of arguments in poetry over what form is best. You can make great programs in any language, just like you make beautiful poetry in almost every form. (Leaving an almost there for people that dislike Limericks, I suppose.) Language choice is one of the (sometimes too few) creative choices we can make in any project. > Another option is to do something like automatic semicolon insertion (ASI) based on a set of rules. Unfortunately, a lot of people’s first experience with this kind of approach is JavaScript and its really poor implementation of it, which means people usually just write semicolons regardless to remove the possible mistakes. Though the joke is that the largest ASI-related mistakes in JavaScript aren't solved by adding more semicolons, it's the places that the language adds semicolons you didn't expect that trip you up the worst. The single biggest mistake is adding a newline after the `return` keyword and before the return value accidentally making a `return undefined` rather than the return value. In general JS is actually a lot closer to the Lua example than a lot of people want to believe. There's really only one ASI-related rule that needs to be remembered when dropping semicolons in JS (and it is a lot like that Lua rule of thumb), the Winky Frown rule: if a line starts with a frown it must wink. ;( ;[ ;` (It has a silly name because it keeps it easy to remember.)

ameliaquining 8mo ago

Python doesn't have automatic semicolon insertion.

gingerBill 8mo ago
Yes it does. You can even type `;` anywhere too, go an try it. Because of how good the rules are for Python's needs, most people never know that semicolons even exist in Python.
- ameliaquining 8mo ago
  This isn't quite right. Go and JavaScript use semicolons pervasively throughout their formal grammars, and mostly don't use newlines; then, on top of that, they have special rules that allow the semicolons to be omitted in many cases depending on newline placement. Python uses newlines pervasively throughout its formal grammar, and only allows semicolons to be used in a couple specific places (at the end of a simple statement or to separate multiple simple statements on a single line). The two systems have in common that you can either include or omit a semicolon when you've got a simple statement on its own line, but under the hood they're different; the missing semicolon at the end of a line in idiomatic Python is not "automatically inserted by the parser", it is simply not needed at all. There are also behavioral differences; for example, in Go and JavaScript a semicolon on a line by itself is legal and does nothing, while in Python it's a syntax error.
  - gingerBill 8mo ago
    This might might sound weird but I think that's a distinction without a difference. Those "newline tokens" are effectively the equivalent to a semicolon in the parser. They are statement terminators. The way that Odin or Python handles them is effectively the same except when I tokenize the newlines, they are treated as semicolons but with the "text" being "\n". Thus the distinction here is a matter of what you call it, not how it is treated. That is the same as a form of "automatic statement-terminator insertion" where that statement-terminator is whatever you want it to be. And to me, that is as form of "semicolon" (which is being used as a generalization for statement-terminator) insertion.

g947o 8mo ago

Syntax, or how humans perceive the syntax, is only a very small part of the problems when designing a programming language. There is a lot more about how a compiler would handle the syntax (efficiently) and about how the syntax affects actual code and ecosystem. The recent go blog on error handling should make it clear that syntax is often not worth worrying about. https://go.dev/blog/error-syntax https://go.dev/blog/error-syntax

hyperhello 8mo ago

I like the semantics you type in the google search bar when using it for impromptu calculations. You can use ^ to raise to a power, for example. Just type sin 45. It’s all least surprise.

1e1a 8mo ago
I love how it works with units too, eg. c/433MHz or 4 bytes * 20hz * 24 hours
- hyperhello 8mo ago
  Syntactically it probably has a ceiling, to be so casual. Least surprise won’t work for very complex programs. But maybe the programs wouldn’t be so complex if you didn’t have to stick together complex program syntax either.
ivanjermakov 8mo ago
I wonder how many people use REPL of a language of choice as a calculator as I do.

wavemode 8mo ago

> Lua is an example of such a language, and when a semicolon is necessary is when you have something that could be misconstrued as being a call: (function() print("Test1") end)(); -- That semicolon is required (function() print("Test2") end)() Tangential, but I sidestepped this ambiguity in a language I've been designing on the side, via the simple rule that the function being called and the opening parenthesis can't have whitespace between them (e.g. "f()" is fine but "f ()" or "f\n()" is not). Ditto for indexing ("x[y]"). If these characters are encountered after whitespace, the parser considers it the beginning of a new expression. By sacrificing this (mostly unused, in practice) syntactic flexibility, I ended up not needing any sort of "semicolon insertion" logic - we just parse expressions greedily until they're "done" (i.e. until the upcoming token is not an operator).

recursivecaveat 8mo ago
I definitely think needless whitespace flexibility often causes problems. For eg I'm pretty sure Bjarne chose :: instead of : for the namespace operator in C++ due to ambiguity. A little bit of required whitespace around jump labels and ternary expressions and we could have saved an extra character in an operator that often occurs multiple times per line. Everybody runs linters that enforce that anyways. Likewise the inability to use a hyphen in an identifier has wasted a lot of my time over the years, but nobody uses squashed subtraction expressions.
- 1718627440 8mo ago
  > nobody uses squashed subtraction expressions I do.
gingerBill 8mo ago
That sidestepping only introduces significant whitespace, which may not be what people want in the first place. It can be quite common to align call expressions by the parentheses if they span multiple lines for clarity, and you preventing might not be desireable.
1718627440 8mo ago
I wouldn't like that, because I always put a single space in front of the parenthesis. Mostly for aesthetic reasons, and to distinguish it from function-like macros. Not intended as a criticism, just a data point.

dnautics 8mo ago

in the era of LLMs, syntax might matter more than you think. The c form of `type name;` is ambiguous because it could actually be more than one thing depending on context. Even worse if you include macro sheananigans. The alternate (~rust/zig) is `var/const/mut name type` is unambiguous. For humans, with rather long memory of what is going on in the codebase, this is ~"not a problem" for experts. But for an LLM, its knowledge is limited to the content that currently exists in your context, and conventions baked in with the training corpus, this matters. Of course it is ALSO a problem for humans if they are first looking at a codebase, and if the types are unusual.

wavemode 8mo ago
I hope that someday LLMs will interact with code mostly via language servers, rather than reading the code itself (which both frequently confuses the LLM, as you've noted, but is also simply a waste of tokens).
- dnautics 8mo ago
  why? I suspect that writing code itself is extremely token efficient (unless like your keywords happen to be silly, super-long alien text). Like which do you think is more token-efficient? 1) <tool-call write_code "my_function(my_variable)"/> 2) <tool-call available_functions/> resp: <option> my_function </option> <option> your_function </option> <option> some_other_function </option> <option> kernel_function1 </option> <option> kernel_function2 </option> <option> imported_function1 </option> <option> imported_function2 </option> <option> ... </option> <tool-call write_function_call "my_function"/> resp: <option> my_variable </option> <option> other_variable_of_same_type </option> <tool-call write_variable "my_variable"/>
  - wavemode 8mo ago
    Not sure I follow. You seem to have omitted the part of 1) explaining how the LLM knew that my_function even existed - presumably, it read the entire file to discover that, which is way more input tokens than your hypothetical available_functions response.

cfiggers 8mo ago

I am an S-exp enjoyer, and more for practical reasons than aesthetic ones—I really like the editor tooling that's possible with S-expressions. So I will absolutely choose a Lisp or a lisp if given the option, even at some level of inconvenience when it comes to the maturity of the language itself. I will always write Hy[0] rather than Python, for example. [0] https://hylang.org https://hylang.org (I am aware of Combobulate[1] for Emacs folks, of which I'm sadly not one.) [1] https://GitHub.com/mickeynp/combobulate https://GitHub.com/mickeynp/combobulate

kgwgk 8mo ago
The most machine-friendly syntax - and the least appropriate for our LLM overlords which get confused by parenthesis because they don’t see the structure.
- andersmurphy 8mo ago
  Have you tried? LLMs are really good at elisp, which is strange because elisp code is almost always GPL. There's an option beyond lisp. Forth has even less syntax.
  - kgwgk 8mo ago
    In my experience, they find counting parenthesis as difficult as counting the r's in strawberry if it was spelled srtrawrrrbrrerryrrrr.

netbioserror 8mo ago

Major syntactic structures definitely have an influence on my language choices. Outside of compilation and runtime model, modeling the domain (both data and procedures) changes drastically between paradigms. Syntax is what enables or hamstrings different modeling paradigms. My two biggest considerations when picking a language are: - How well does it support value semantics? (Can I pass data around as data and know that it is owned by the declaring scope, or am I chained to references, potential nulls, and mutable handles with lifetimes I must consider? Can I write expression-oriented code?) - How well does it support linear pipelining for immutable values? (If I want to take advantage of value semantics, there needs to be a way to express a series of computations on a piece of data in-order, with no strange exceptions because one procedure or another is a compiler-magic symbol that can't be mapped, reduced, filtered, etc. In other words, piping operators or Universal Function Call Syntax.) I lean on value semantics, expression-oriented code, and pipelining to express lots of complex computations in a readable and maintainable manner, and if a language shoots me in the foot there, it's demoralizing.

jiriknesl 8mo ago

I don't want to be overly negative, but it seems to me that author considers just different flavours of C. There is a massive difference between Clojure, Prolog, and Forth. The whole: type name = value—type-focused name: type = value—name-focused var name type = value—qualifier-focused Is so much deep into details of how syntax might look like. If you are choosing between Kotlin and Go, it is for the platform, not the syntax. If you decide between Haskell, Idris, Scheme, you do it with the syntax in mind.

ErroneousBosh 8mo ago
All programming languages are basically Algol or Lisp, even the ones I like. C? Basically Algol. Pascal? Basically Algol, actually quite closely. Go? Basically Algol, via Pascal. Lua? Basically Algol, surprisingly closely. Forth? Basically Lisp. Postscript? Basically Lisp.
- ivanjermakov 8mo ago
  When I ponder about PL semantics, crossroad feature is currying. This decides whether partial application, pattern matching, function composition, combinators, and other functional features would play a major role in the language design. Functions are curried? ML style. Not curried? C style.
  - ErroneousBosh 8mo ago
    What's "ML" in this context?
    - ivanjermakov 8mo ago
      ML (Meta Language) https://en.wikipedia.org/wiki/ML_(programming_language) https://en.wikipedia.org/wiki/ML_(programming_language)
gingerBill 8mo ago
Those syntax examples are literally just general examples, not the only way you have to write them. But to categorize the ones you wrote: * Clojure is qualifier-focused * Prolog is name-focused * Forth is qualifier-focused (`:` is the qualifier in this case)

juancn 8mo ago

I never got why compilers don't have pluggable syntaxes. I mean, once you decide the "flavor" (e.g.: typed, imperative, with a dash of functional and some oop for good measure), you could have more than one syntax and easily switch to whatever the reader wants. We had an integration language in a product I worked on that had three flavors (you can check it here: https://docs.oracle.com/cd/E13154_01/bpm/docs65/pdf/OracleBPM-StudioGuide_10.3.pdf https://docs.oracle.com/cd/E13154_01/bpm/docs65/pdf/OracleBP... , page 254) The original syntax scared some people, so we had the compiler use the same AST with three different parsers: Original, Java and VB. The editor (which had syntax highlighting and auto completion) would let you see the code however you wanted. You could even have a setting in the IDE that always showed the code as you wanted. We even respected some weirdness in the spacing and indentation of comments and code when needed. For some languages, like rust it may be a stretch, but for most vanilla languages, you could easily re-skin them to look much more like something else, that's comfy for whoever is looking at the code.

hyperpape 8mo ago
> I never got why compilers don't have pluggable syntaxes. An interesting question, but the answer is "because it's a bad idea" that doesn't actually solve the problem. That said, the right way to implement this is as a "transpiler" that compiles one syntax into another. And only the people who want to use it pay the costs.
- zahlman 8mo ago
  > An interesting question, but the answer is "because it's a bad idea" that doesn't actually solve the problem. This doesn't really explain anything, and it isn't clear that both of you have the same model of "the problem" in mind.
  - tialaramex 8mo ago
    The usual way people get here is that they didn't realise programs are for reading by humans. That's why we have formatting conventions (the compiler doesn't care but humans do) and so it's also why a single syntax is important. If there are six syntaxes for a hypothetical language L, then either every L practitioner must learn all six syntaxes (ew, no thanks) or most L programmers can't read each other's programs and so it's basically unmaintainable.

zahlman 8mo ago

> I am still perplexed by how people judge a language purely by its declaration syntax, and will decide whether to use the language purely based on whether they like that aspect or not. Throughout the article, OP seems baffled that people have aesthetic preferences. Well, yes, of course we do; dealing with ugly things is the computer's job. It also comes across like OP hasn't seen a lot of examples of really interesting language syntax, i.e. things outside, shall we say, the extended Algol family. The discussion seems to accommodate brace-less languages like Python, but not e.g. the Lisp or Forth families. > and thus just becomes a question of ergonomics or “optimizing for typing” (which is never the bottleneck). It might not be a bottleneck in terms of time needed. But unpleasant syntax is annoying and breaks flow. Thoughts creep in about how you wish the language looked different and that you didn't have to type these other bits. (Which is why a lot of people feel so strongly about type inference.) > From what I gather, this sentiment of not understanding why many “modern” languages still use semicolons is either: OP seems to conflate "semicolon" with "visible, explicit token that separates statements. There's no reason it couldn't be some other punctuation, after all. Describing Python's approach to parsing as "automatic semicolon insertion" is wild to me; the indented-block structure is the point and statements are full lines by default. Semicolons in Python are a way to break that rule (along with parentheses, as noted), which are rarely seen as useful anyway (especially given the multiple assignment syntax). > To allow for things like Allman braces, Odin allows for extra single newline in many places in its grammar, but only an extra single newline. This is to get around certain ambiguities between declaration a procedure type and a procedure literal Right; and the point of Python's approach is to not need braces in the first place, and therefore sidestep any considerations of brace style. And when you do that, it turns out that you don't need to think nearly as hard about whether a newline should terminate a statement. It's a package deal. > Maybe I don’t need to be as cynical and it is a lot simpler than all of that: first exposure bias. It’s the tendency for an individual to develop a preference simply because they became familiar with it first, rather that it be a rational choice from a plethora of options. > However I do think there are rational reasons people do not like a syntax of a language and thus do not use it. Sometimes that syntax is just too incoherent or inconsistent with the semantics of the language. Sometimes it is just too dense and full or sigils, making it very hard to scan and find the patterns within the code. For what it's worth, before I ever touched Python I had already used (in no particular order) multiple flavours of BASIC, Turing, probably at least two kinds of assembly, Scheme, C, C++, Java and Perl. To be fair, I had also used HyperTalk and Applescript, so maybe that does explain why I glommed onto Python. But BASIC came first. In my mind, a mid-line semicolon is exactly the kind of sigil described here, and an end-of-line sigil is simply redundant. Multi-line statements should be the explicitly-marked exception, if only because long statements should be less common than shorter ones.

norir 8mo ago

I personally would prefer to hear more about what is uniquely good about Odin semantically or syntactically than more ad hominem attacks on the intelligence of the critics of the language, which I have seen in multiple recent pieces by this author.

zahlman 8mo ago
Agreed; this communication style by itself makes me less inclined to try out the language.

shevy-java 8mo ago

This is the old "syntax does not matter" claim. Syntax is not the most important thing in the world when it comes to programming languages, but it does matter too. I was using perl, then PHP then ruby. There is no comparison here; ruby beats the other two languages hands down. I get to be able to do more, with less syntax and it is easier to read too (provided you write good code; you can write horrible code in any language of course). Most of the languages that are created anew, end up being a clone of C or C++. Go is one of the few exceptions here; Rust is not an exception. It is basically C++ really, from the syntax - or even worse. Sadly it is not possible to try to convince people who claim that syntax does not matter, that it does matter. They just keep on repeating that syntax is irrelevant. I don't think syntax it is irrelevant at all. It has to do with efficiency of expression. Clear thoughts. Clear design. It is all inter-connected.

tialaramex 8mo ago
> Rust is not an exception. It is basically C++ really, from the syntax - or even worse. That's a superficial impression. Yes the resemblance is on purpose, but it doesn't go very deep which suggests you haven't stared at this for more than a few seconds.
gingerBill 8mo ago
I literally had to write an extra article because of the number of people who thought I was saying syntax doesn't matter. It matters a hell of a lot: https://www.gingerbill.org/article/2026/02/21/does-syntax-matter/ https://www.gingerbill.org/article/2026/02/21/does-syntax-ma... I was trying to be as clear as I possibly could within that article to state I was only focusing on those two specific topics, rather syntax as a whole. How people judge a language based purely on its declaration syntax and nothing else. Where the declaration syntax makes the least difference compared to the rest of the syntax in the language. And still people wrongly interpreted the article.

Garlef 8mo ago

Hmm... I don't know how serious this wants to be taken - first example argues that syntax is interchangeable - but then the author tries to sell me his semis ??? And who even cares in the time of LLMs and auto formatting? "My hammer has this slight angle and if I hit the nail with just the right motion, it feels really good"

gingerBill 8mo ago
I was trying to be EXTREMELY clear I am talking specifically about DECLARATION syntax only and how for the most part, the concrete syntax for the DECLARTAION syntax is not that important in many languages. However concrete syntax matters a heck of a lot and cannot be trivially interchangeable. I had to write a follow-up article to clarify this because of people like yourself wrongly interpreting the article: https://www.gingerbill.org/article/2026/02/21/does-syntax-matter/ https://www.gingerbill.org/article/2026/02/21/does-syntax-ma...

thom 8mo ago

This is one of those things that I’m glad remains highly personal and stochastic. Programming languages thrive when people are able and willing to create value with them. People thrive when there are options and they can find a language that sings to them.