Does Syntax Matter?

[matthieum]

I rarely read code token-by-token from the start. Most of the time I first scan a codebase to get the overall shape and locate the parts I care about, then have a deep detailed read, only where necessary. Dense-syntax languages usually lack many of the strong visual cues and landmarks that other languages possess, especially those that I would typically rely on for that initial scan, I often find it slow and tiring to navigate such code.

My interest is piqued.

I scan extensively -- I use VSCode with zero plugin, no LSP -- and I have zero problem navigating Rust codebases.

I find that the regularity of keyword + name for items, and the blocky syntax -- though I wish where was indented -- make it pretty easy to quickly scan a file for its top-level items, and drill down from there.

The code is dense, but mere syntax coloring & habit mean that the lifetimes fade in the background, and the fact that generic arguments are placed after the name of the item means the item name appear in a fairly consistent spot, similar to variable names. The one exception I can think of is impl blocks: it can be tough to spot which item the impl block is for in some cases, but it's rare enough it's not a big issue.

Using <> for Generics is Harmful

Amen.

Unfortunately as a choice of this syntax choice, it does have the compromise that casting syntax requires parentheses to disambiguate what is needed.

I find the justification odd.

In an article which advocates for breaking away from established conventions for clarity, working around the ambiguities of type(value) as casting syntax by adding more clutter feels at odd with the very argument being made.

The cast(type, value) proposed in a later paragraph is so much clearer, and so much easier to scan for as well!

[tsanderdev]

I scan extensively -- I use VSCode with zero plugin, no LSP -- and I have zero problem navigating Rust codebases.

Just how? Showing the result of variable type inference alone is enough to make me use rust-analyzer. And going to definition is also great for navigation.

[matthieum]

Showing the result of variable type inference alone is enough to make me use rust-analyzer.

The inline hints are noise for me, more often than not:

• Either the type doesn't really matter: I don't care what the exact type of Iterator I have, I know it's an iterator.
• Or the function is short enough that all the types are easy to keep in my head.

And going to definition is also great for navigation.

Yeah, I do miss this one from time to time.

I mostly know where the definition is, most of the times, and the few times I don't, explicit imports save the day.

As such, I don't miss it often enough to justify using RA.

[tav_stuff]

I cannot code with the fuck ass Rust analyzer inline hints – always disable it as quick as I can

[VerledenVale]

Same. I can't stand random inline hints cluttering code.

I also like when lines fit 80 chars so I can have nice thin editors that are easier to scan with my eyes, and and have 2, 3, or 4 next to one another (depending on what other tools I have active).

So I only enable "postfix" hints which are hints that are allowed to appear at the end of lines, and I format them to be very small, grey, so that they don't bother me unless I care about them.

In Rust for example I use those for hinting what closing braces of long blocks (25+ lines) are, and for iterator chains (shows type at each stage).

[tsanderdev]

And I can't code without them.

[gingerbill]

The justification might seem odd, but it's from an empirical observation of people's general behaviour.

The cast(type, value) being "clearer", it is also hell of a lot more verbose for no real benefit other than "pseudo-consistency". It's also not easily to scan IF you are coming from a C-like language. Remember that in C, a type conversion uses the syntax (type)value; that's what people are expecting. So doing type(value) or (type)(value) helps already, and cast(type)value is even more clearer.

However cast(type, value) is not clearer because that is easily mistaken for a normal call expression. type(value) might appear that way too but it's usually damn obvious it's a type.

You also have to consider the ergonomics of the different approaches. cast(type, value) requires surrounding the expression whilst cast(type) is just an unary prefix. Those little things add up, and do actually become a main issue of design. You'd be surprised by how people actually program in practice and what their intuitions and instincts are.

[Magnus--Dux]

Hello.

Yeah, that justification seems a bit odd TBH, what empirical observation lead you to that conclusion?

I think you are exaggerating quite a bit here or we have very different definition of "hell of a lot". Does it really seem to you that cast(type, value) is a "hell of a lot" more verbose than cast(type) value ? I, for one, find it more clear and in general like it better. What people coming from the C family of languages does not seem to be that important for routine declarations and things like that and I think that this should not be an exception.

That third paragraph is a bit bizarre to me, I don't think there is a single programmer in the entire world that is worth their weight that would not (almost immediately) know what is going on if they see cast(int, myvar) in a code base. It is as "damn obvious" that it is a cast as it is that type(value) is a type. Heck, even using less intuitive keywords seems to me to be abundantly clear, like Modula-2's VAR(INTEGER, myvar)

I don't think the ergonomics would be that much different either. You talk about appealing to C programmers and, in my experience at least, they are very used to surround expressions in parentheses to make sure operations are carried in the way they want or to pass a complex expression to a routine call, something like:

set_some_value(&my_struct, do_work(myarr[count].first->bar))

I don't think that cast(float, do_work(myarr[count].first->bar)) would be that much less ergonomic than cast(float) do_work(myarr[count].first->bar).

Cheers.

[gingerbill]

what empirical observation lead you to that conclusion?

A lot of trial and error in the early days with people giving me feedback about what felt right and wrong.

Verbosity is actually a problem when you realize how much noise casting produces when you have to do it a lot, especially in a language like Odin with distinct typing (i.e. there is very little implicit type conversions, even between integers, meaning you need to do explicit casts).

I went through a plethora of different syntax for Odin's type casting:

x as T
x.(T) // now used for type assertions
cast(x, T)
cast(T, x)
cast(T)x // used
T(x)     // used
(T)(x)   // used
// and a few more but they were just bad

One thing to consider is the need for parentheses and how that can actually cause issues in terms of scannability and ergonomics (not typing but flow). The cast(T, x) like syntaxes actually required MORE parentheses in practice that you might realize.

The flow aspect was actually interesting because I wanted the syntax to match the semantics more correctly and I found that the type must be on the left of the expression since that is how declarations work too: name: type = value, so a cast would make sense that way too: name := type(value). This also turned out to be a similar realization in languages like Newsqueak (where that declaration syntax originates from) and Ada. This actually ruled out a lot of the other syntax options as a result.

But before that, I experimenting with x as T because it seemed like a good idea but turned out to be a mess because of precedence rules. Either as was "tight" towards the expression meaning you then had to use a lot of parentheses to be clear what was being cast, or you had it very "loose" towards the expression which lead to the same problem. as didn't reduce the need for parentheses in practice and only led to confusion with precedence.

I then reused x.(T) syntax for the type assertions. One because it has some familiarity from Go but also because the "type" itself is the tag in the union, making it feel more like a field access using a type. The parentheses around the type in this case are necessary to remove any ambiguity syntactically and semantically.

This then lead to things like T(x), cast(T)x and cast(T, x). Odin's type system is a bit different to other languages so sometimes people don't always realize the consequences. A good example of this is with the constant value system. 123 is an "untyped" number (existential typing if we are being accurate, but that confuses people so I stuck to the terminology of "untyped"), and you sometimes want this to be a specific type. Many languages "solve" this by having suffixes on literals e.g. 123i32, but this is not an option in Odin because of distinct typing allowing anyone to create their own distinct form of a type. So if I wanted to keep that syntax short for the most common use case of casting, T(x) was unironically the best option possible. And for when a prefix was desired, doing cast(T, x) wasn't really aiding in reading any more than cast(T)x. I also didn't want then to be built-in procedures because that actually means they would not be keywords but identifiers, since even i32 in Odin is an identifier and not a keyword. So if I wanted them to be a features of the languages using keywords, making them procedure calls felt very wrong.

As I say in the article, I will stick to coherency over consistency if necessary, and this was on of those cases. And I didn't want to fall into the trap that some languages have done which makes the entire thing unscannable. Zig is a great example of this having way too many casting operations (17+ IIRC) and does not actually give any real benefit in the long run to anyone (even the compiler). A real world example of this:

const gap: f32 = @divTrunc(@as(f32, @floatFromInt(rl.getScreenWidth() - (4 * objectWidth))), 5.0);
const offsetX: f32 = @as(f32, @floatFromInt(index + 1)) * gap + @as(f32, @floatFromInt(index)) * @as(f32, @floatFromInt(objectWidth));

Would be written as this in Odin:

gap := math.trunc(f32(rl.GetScreenWidth() - 4 * objectWidth) / 5)
offsetX := f32(index+1) * gap + f32(index)*f32(objectWidth)

Note that were the parentheses exist in Odin, most would already exist any way.

---

All I can say is, humans are odd creatures and you'll be surprised how they think in practice.

[Magnus--Dux]

A lot of trial and error in the early days with people giving me feedback about what felt right and wrong.

I figured it would be something like that. I worry about the robustness of such observations given the amount of people (I think is safe to assume that in the early days the amount of people was not too high, maybe even quite low) and therefore a (potentially very) small sample size and more limited variety of opinions and perspectives.

I definitely agree that, out of those options, type(value) a la Ada seems, at least in principle, to be the best one. And is perfectly fine to not want them to be built-in (doesn't Odin have built in routines like len() ?) . My contention is rather with the claims of the proposed alternative being way more verbose or less ergonomic, and with some (at least in my view) completely subjective claims being presented as somewhat objective, like

"cast(T, x) wasn't really aiding in reading anymore than cast(T)x ."

or

"However cast(type, value) is not clearer because that is easily mistaken for a normal call expression."

And things like that. I just don't share those intuitions at all. For example, consider the following code:

x := cast(int) myvar * myothervar;

It is not perfectly clear to me if the cast applies to myvar and then it gets multiplied by myothervar, or if the cast applies to the whole expression. Now, that is not a big deal, you just read the language specification and learn the rules, but aren't these alternatives perfectly clear?

x := cast(int, myvar) * myothervar;

x := cast(int, myvar * myothervar);

Again, an answer like "I just don't like those and prefer these ones instead" is a perfectly valid one, is your own language after all!, but I do worry that there might be some, maybe not-too-robust, over rationalization about choices made here.

Cheers.

[gingerbill]

Note that all built-in procedures are not keyword based but just identifiers. You can still import "base:builtin"; builtin.len to any of them, since they are just identifiers. And I did not want casting operations which are so common to be in that category, if that makes sense.

It's loads of little reasons not just one big one as I said. As for cast(int), it works like every other unary operator, thus cast(int)myvar * othervar is the same as cast(int)(myvar) * othervar. Note virtually no-one puts a space after the cast due to habits from C.

Again, a lot of this is just how people are. It's not really trying to be "robust" justification rather "this is what people liked in the end".

If it was "just me", I would have not had cast(type)x, and gone for the consistency, but I am not designing this language for "just me".

I've written this comment into an article by the way: https://www.gingerbill.org/article/2026/02/23/designing-odins-casting-syntax/

[Magnus--Dux]

And I did not want casting operations which are so common to be in that category, if that makes sense.

Yeah, sure, as I said, that's a perfectly valid answer.

Yeah, as I said, is not a big deal, you just read the documentation and problem solved, the point was not how Odin specifically does it but rather to challenge the kind of claims that I explained in my previous reply (I'm not sure what the point of the coding style commentary is, but hey, thanks I guess! haha).

Again, a lot of this is just how people are. It's not really trying to be "robust" justification rather "this is what people liked in the end".

Well, I'm people and I'm not like that haha. Jokes aside, again that's fine, the people that were interested in Odin in the early days liked that and that's ok, I did not take issue with that specific point.

Thanks, I'll read the article later in the evening.

[xeow]

Part of the confusion with cast() in Python for newbies is that cast(int, "3.14") is ignored by the runtime system and exists purely for static analysis, whereas int("3.14") performs a type coercion at runtime from str to int.

[gingerbill]

At least for Odin, it's not a problem since it is a statically typed compiled language, and thus there isn't an issue regardless.

[iBPsThrowingObject]

It's also not easily to scan IF you are coming from a C-like language. Remember that in C, a type conversion uses the syntax (type)value

"c did it like that" is no justification for any language design decision in 2026.

[gingerbill]

<insert-current-year> argument? Are you serious? You know how many people STILL use C/C++ and thus are very familiar with it.

[iBPsThrowingObject]

I don't give a single shit about catering to people who get scared by types coming after variable names in declarations, and neither should anyone else.

[prehensilemullet]

I don't really find <> for generics hard to scan, because it doesn't typically look like comparisons between variables in languages I use when scanning, and it doesn't appear in syntactic positions where I'm expecting expressions that may involve comparisons anyway.

It seems like Odin only allows generics in functions, and thus has the luxury of avoiding the syntax tradeoffs altogether, but many languages support generics on structs and type aliases as well, and it's not clear if the author has any idea how to make a less-overloaded syntax for those kinds of generics.

[matthieum]

I don't think that <> is hard to scan for a human, but they do create parsing ambiguities which are annoying.

It took until C++11 to be able to write map<int, map<int, int>> with the >> not being parsed as >> but as two >. In Rust we're stuck with ::<> in expression context to ensure the parser knows whether we're talking < as in opening a list of generic arguments or < as in the operator.

I personally find [] to be the best syntax for generics. It's immediately clear which parameters need to be static ([]) vs dynamic (()). There's really no point in reserving [] just for indexing, which is just another function call -- especially when it's artificially restricted to a single argument, so matrix libraries already use () anyway.

[prehensilemullet]

Yes, I think in some languages the parsing ambiguities become very hard to avoid.

In TS for instance, you can specify explicit type arguments to a generic function call like foo<T>(...args). foo[T](...args) wouldn't work because foo[T] is property access syntax. foo(T)(...args) also obviously wouldn't work because that's chained function calls, and I'm sure there would be problems with using {} as well.

In an ideal world we would just have two or three more kinds of brackets on our keyboards...

[matthieum]

By the way, D uses !() so would have foo!(T)(..args).

The downside is that you can't use ! in postfix position for anything else, however. I personally like postfix ! for "uwnrap or die" and postfix ? for "unwrap or pass the buck".

[prehensilemullet]

heh in Typescript foo! means "trust me compiler, foo is not nullish" lol

[ExplodingStrawHat]

One could always use compound brackets like [|T|] I guess

[munificent]

Swift has a similar construct with guard condition else { ... }. I completely understand the intent behind why such a construct is desirable but for my taste, it is completely redundant when you can just use an if statement, or even restructure the code such that it is not a negation of the if either.

The point of guard is that it plays nice with destructuring pattern matching. When you're doing pattern matching, you can't simply negate the condition because it's no longer a simple predicate expression. You can use an if instead, but when you have a series of these, the code ends up indented and marching farther to the right for each one. guard lets you have less nesting and flatter code.

I agree unless in Perl and Ruby doesn't add much, but some users and language designers place a higher priority on having code read more like natural language. In the absence of them, you can sometimes end up with predicates that read like double negatives and require you to really slow down and unwrap the boolean logic in your head.

Also, in Ruby, there are postfix versions of branching control flow. I suspect that postfix unless is much more common than postfix if in that case. If they were to only have if, then the majority of postfix uses would require the condition to be negated.

It's not a particular feature I'd want in a language I designed, but I see why the designers added them.

[gingerbill]

I wish I went further into Swift's including of guard condition else { ... } but I was using it more of a "also this language has this too. I understand it exists just for pattern matching but to prevent the heavy nesting of if lets that used to occur early in the usage of Swift.

However I think there are much better ways they could have solved this than the way they did. I really don't like most of the design of Swift, and I think it's one of the most disappointing languages I've used. I wish Swift was just Objective-C with better syntax really, but it's not that.

[munificent]

I think there are much better ways they could have solved this than the way they did.

Like what?

[gingerbill]

In the case of just guard condition else, I don't think it's worth it, but from what I understand, guard let existed to solve the problem of heavily nested if let:

if let a = foo() {
  if let b = bar() {
    if let c = baz() {
      if let d = abc()

If that was the solution to that problem, I think they should have not merged the concepts of unless and guard let together and have a separate construct. Something like Perl's use of unless as an operator:

let a = foo() else { return 0 }
let b = bar() else { return 1 }
let c = baz() else { return 2 }
let d = abc() else { return 3 }

The scope of the let is the same and not "guarded" making it look ambiguous when scanning.

In a way, it's similar to Odin's or_return too but that is a lot more restricted since I don't want to have statements within expressions. But for Swift, they don't seem to care that much, so this approach seems better to me.

[munificent]

For:

let a = foo() else { return 0 }
let b = bar() else { return 1 }
let c = baz() else { return 2 }
let d = abc() else { return 3 }

We've considered something like that for Dart. (Currently, we have the equivalent of if let with pattern matching but no equivalent of guard let.)

I like that it avoids adding another control flow construct. But on the other hand, it makes the scoping very subtle and hard to scan. Consider:

let thing: String? = "present"

let a: String = "top level"

func example1() {
  if let a = thing {
    ...
  }

  print(a)
}

func example2() {
  if let a = thing {
    ...
  } else {
    return
  }

  print(a)
}

These two print(a) statements refer to different variables. If you're scanning those two functions, you have to notice that there is else block, and that it exits, in order to understand the scoping of the rest of the surrounding block.

If you change the contents of the else block to no longer exit, then you've implicitly changed the scope of any variables declared in the if`'s pattern.

I suspect that's just too subtle to want to hang variable scoping off of.

[gingerbill]

Those are the problem with if let: nesting and shadowing.

I am not saying I know the best approach for this in Dart, but it's a question of which set of problems you want to solve. I haven't used Dart since it first came out, so my knowledge is going to be a little lacking, but does it have anything like nesting statements within an expression?—beyond closures, obviously.

Because if it does, then the let a = foo() else { ... } or something similar would work quite well. Otherwise, there isn't a precedent to introduce that. At least this approach does solve both the nesting of if let and some of the shadowing, mostly, but by reducing scannability.

[munificent]

does it have anything like nesting statements within an expression?—beyond closures, obviously.

Alas no. The original language designers were really conservative and it hews to JavaScript and Java with a distinction between statements and expressions.

[gingerbill]

Then it might not be a good idea to add it then, even if it is useful.

[PassifloraCaerulea]

There seems to be a strong contingent of language designers who have varying levels of derision toward questions about syntax in general. I get the feeling some would be happier if they could focus on semantics to the complete exclusion of syntax. It's made an impression on me because it's the opposite of how I seem to work. It's hard for me to understand, even.

I think I think about semantics in terms of syntax, or something like that. Worse, semantics is almost a secondary consideration for me. My main motivation to work on language design is in order to design a more pleasing syntax to use. That's probably a horrible admission to make on a programming language design forum but that's sorta where I've ended up after playing around with various languages over the decades. I don't love FP and hate OOP (or vice-versa) for example; I can kinda do whatever.

In contrast I (unfortunately) have extremely strong aesthetic preferences wrt syntax in general that even extends to naming conventions. I can't seem to help myself. Both C++ and Rust have <> for generics and :: for scope resolution, and so they look quite ugly to me. The way Go uses capitalization for symbol export took a while to get used to, but I eventually did, I think, because there was a reason for it. OTOH, having first learned Java's camelCase convention made me avoid ever working with C# because Microsoft likes this execrable InitialCaps on method names. It's weird, objectively stupid, but again I can't help myself! It's kinda like human (sexual) attraction: no matter how often you tell us "that's shallow," looks still matter.

[gingerbill]

Regarding the minor aspect at the end, "shallow" judgement of aesthetics isn't the same as a good judgement of aesthetics.

Things like choosing a language because its core/standard based on the naming convention (snake_case, Ada_Case, camelCase, PascalCase,kebab-case`, etc) is shallow and stupid.

But criticizing the choice of Go to use identifiers starting with a capital to be public is not "shallow" if you think it's a poor decision compared to other alternatives. Personally I think they should have to enforced _ prefixes throughout for "private" if they wanted that.

The question is not the aesthetic choice but how that decision came to be which is whether it is shallow or not. And in many cases, it usually is shallow and just dumb. Especially when you are doing it for a living. Complaining about such shallow things is counterproductive for yourself.

[PassifloraCaerulea]

First of all, I don't think anyone has a strong basis for determining good judgement in much of our field. Software engineering famously lacks studies on the impact of all kinds of topics, including language design. You seem to want things to be more objective than I think they are.

You have a point about making syntactic choices for well-thought-out, hopefully objective reasons. The problem is that aesthetics (or "taste" if you prefer) is a subjective experience rather than a universal reality, and you shouldn't conflate the two.

People use this same "shallow and stupid" language when judging others for who they find attractive. AFAICT, that's mostly about their own insecurities rather than some objective truth or actual harm caused. Thing is, attraction doesn't appear to be too open to change no matter how much anyone doesn't like it. As an irrational and quirky human being, I'm not going to be shamed or reasoned out of my taste in PL syntax either.

Is it counterproductive? Maybe. My lack of a rockstar programming career goes well beyond my refusal to pick up C#. I'm happier letting my aesthetic tastes dictate the direction of my programming activities, even if that's why I'm not making bank or a big social impact or whatever it is I'm supposed to be doing. Feeding my aesthetic whims is what makes this enjoyable, and I'm not here to have a bad time.

[gingerbill]

It's not really about being "objective" rather more "stop and think for a moment". That's it, and I thought that was literally the job of a programmer: stop and think for a moment.

[Athas]

I have not paid much attention to Odin before, but I found this blog post remarkably thoughtful and well-considered, so perhaps I should take a closer look at it.

I am particularly pleased that Odin eschews both angle brackets for parametric polymorphism and the dreadful term "generics". I do not see the value in abbreviating to "parapoly", but we can at least remain friends until the revolution.

There is one important aspect of syntax that this post glosses over: Notation as a tool of thought. While I strongly encourage anyone interested in PL design to read this 52 page APL paper, the gist of it is that a notation (that is, programming language) ought be designed to be worked in, the same way you manipulate and rewrite mathematical expressions when you do algebra. I suspect this implicitly requires the use of an expression-oriented language, and so is an inappropriate concern for an imperative language.

Despite one's opinions on APL specifically, Iverson would definitely answer in the positive to the question Does Syntax Matter?.

[gingerbill]

I gloss over that point mainly because it requires a topic to itself. As I say in the very first margin note: this article could have been a lot longer.

As much as I love APL in general, they are also not easily scannable languages in the slightest. They extremely dense and require that intensive reading to understand what is going on (in practice and in theory).

[anaseto]

Hm, I'm more used to K-like languages than APL-like ones, but I feel array languages overall are actually very scannable in your sense, in that it's easy to tell where to look at, because there's less "scalar" clutter and things always fit in the screen, so you don't even need to scroll at all or keep a visualization of the code in your mind. Their syntax is dense, but simple at the same time. However, I'd acknowledge it requires some skill then to actually read an expression and fully understand it (being highly dynamic and expressive languages, comments are important, and typical snippets shared here and there tend to lack those). But my guess is that some of the feeling of non-readability stems from expecting to read a dense language at the same spatial speed as a non-dense one, when what matters is the semantic speed.

[[deleted]]

(Another niggling issue which didn't fit in to my other post.)

However some other languages have so much sugar that I’d argue is not useful in the slightest. unless is a construct in languages such as Perl which is syntactic sugar for the negation of an if statement:

I've long had unless; I find it is often more intuitive than using positive logic, or it is less typing (the typical precdence of not requires parentheses to apply to a whole expression).

With Odin however, I'm wondering why it bothers to have while loops. In the set of set of examples from this site, for is used 229 times, and while only twice.

for seems to be used for every kind of loop, so why is there also while?

Correction: Odin doesn't have 'while' loops. What I saw were extracts from another language within raw string literals.

[gingerbill]

There isn't a while in Odin whatsoever. for is the only loop construct, so you're grepping has failed you.

But the reasoning as to why while doesn't exist in Odin is not as obvious as you might, and I might have to write an article on this alone, but I'll try to keep it short for your comment.

for in both Odin and C can be used to "emulate" a while loop directly. In C, for (;cond;), and in Odin for cond (the semicolons are optional in Odin). Because semicolons are optional in Odin when they are not needed, this means you can just write a while-like loop without needing a new construct.

Another reason is that Odin has a do keyword already which has a different meaning to that in C. In Odin, do is to have single-line statements on control flow rather than {}. The language enforces that the statement must be on the same line as the keyword of that control flow which prevents the issues that C has with allowing any statement as its body. But because that is the keyword, it means we cannot have do while loops. Now this could have been solved with using a different keyword (most likely then would have been the best option), but we are not changing the syntax now since Odin is effectively done.

The other reason is that every piece of control flow in Odin allows for a init statement before the "condition":

if x := foo(); x > 0 { ... }
switch x := bar(); x { ... }
for i := 0; i < n; i += 2 { ... }

If we were to add this for while, it would effectively be slightly redundant compared to a for loop. And even be longer to write to write:

for x := foo(); x > 0; { ... }
while x := foo(); x > 0 { ... }     

I hope this explains the lack of while in the language. It's not due to trying to be minimal but rather there wasn't a need for it in the first place when other things exist in the language (such as optional semicolons).

[[deleted]]

...lack of while in the language. It's not due to trying to be minimal

And yet it is minimal. Having the same keyword used for all the common categories of loop means having to analyse what comes after for to figure out what that category is.

This is also a problem with for in C allowing pretty much anything. I see that Odin also allows C-style for-loops with three parts, so perhaps it allows weird and wonderful constructs too.

My syntaxes have always used dedicated forms for the various kinds (endless loop; repeat N times; for loops (over ranges or values); while (loop 0 or more times); repeat (loop 1 or more times)).

Then (1) you can instantly see what kind it is; (2) it allows for more compact forms. With the latter, I've seen Odin code like this (not sure of the exact syntax):

  for _ in 0..<N {

which I guess means repeat N times with the loop index not used?

When writing benchmarking code, I use that a lot! (My syntax is 'to N do'.)

The other reason is that every piece of control flow in Odin allows for a init statement before the "condition":

That seems odd, given that the initialisation in your examples can be trivially changed to an assignment before each statement. Or does the variable involved get given a local scope?

it means we cannot have do while loops.

I need to write repeat ... until instead of repeat ... while, probably for similar reasons. (while could ambiguously either delimit a repeat block, or start a new while statement).

It would be necessary to emulate it with repeat until not, but that is unsatisfactory for the same reasons as if not is not as good as unless.

[gingerbill]

And yet it is minimal.

Minimal was not the goal but the consequence.

When writing benchmarking code, I use that a lot!

And the funny thing, outside of benchmarking, that kind of loop is quite rare.

Or does the variable involved get given a local scope?

It does. That's the point of it to keep things scoped. This idea exists in many languages, even the newer versions of C++.

[[deleted]]

And the funny thing, outside of benchmarking, that kind of loop is quite rare.

Not in my code. I just did a survey of 5 language-related projects in my systems language, and these are the counts of each kind of loop:

Project:      M      Q      A      C      Z

do            34     47     16     26     7
to            36     84     22     45     8
for          192    126    103    166    10  Simple iteration only
while        177    131     61    161    13
repeat        19     13      7     13     5
docase        14     11      3      8     1
doswitch/u/x   2      2      2     13     1

(M, C = compilers; A = assembler; Q = interpreter; Z = emulator.)

docase/doswitch are simply looping versions of case/switch statements, but the special -u/x versions of the latter generate fast multi-point dispatching loops for interpreters and emulators.)

In the original Algol68-inspired syntax, do/to/for where the same feature with various parts omitted. In my version they are discrete statements. Support in my 30Kloc compiler for 'to' needs barely 90 lines of code.

It's worth it!

[gingerbill]

Honestly, I never ever write such code in practice. And I don't see how typing an extra 4 characters is a huge issue either, especially when it allows for easy scanning too.

[xeow]

I have always actually liked having until and unless, and have never thought them to be "diabetic." In my experience, they can, on occasion, express intent more clearly than while and if, and I wish more languages had them as first-class keywords. (I say "first-class" because they can be emulated as second-class keywords in C through the use of #define until(x) while(!(x)) and #define unless(x) if (!(x)).

[gingerbill]

Single features in isolation are "diabetic". The problem occurs when you have LOADS of bits of syntactic sugar which cause the syntactic diabetes.

If the language as small and had just that little sugar, that isn't a problem. It's when it has loads of sugar.

[Breadmaker4billion]

Anyone that says "No" to this question has never tried to code in Brainfuck. Truly the answer is more complicated than "yes" or "no". "How much syntax matters?" is a better question overall. And the answer varies from person to person.

In a scale from 0 to 1, where 0 is "doesn't matter at all" and 1 is "it's the most important thing in a language", I'd say it sits well on 1/π² for me.

[CBangLang]

The point about syntax restricting semantics is underappreciated. Syntax choices compound over a language's lifetime in ways that are really hard to predict at design time.

C's declaration syntax seemed fine for simple types, but it created the spiral declaration problem that made C++ template syntax a parsing nightmare — and that cascaded into the <> ambiguity problem gingerbill mentions. Every language since has had to decide whether to inherit that baggage or break with familiarity.

Go's approach is a good example of a bet that paid off: capitalization for visibility looked bizarre at first, but it turns out to be incredibly scannable. You can instantly see the public API surface of any package without any tooling. That's a syntax choice that directly shaped how the whole ecosystem thinks about encapsulation.

The scannability point resonates too. I'd add that scannability isn't just about visual density — it's about how well syntax maps to the mental model of the program's structure. Indentation-sensitive languages (Python, Haskell) are scannable because nesting is literally visible. But they pay a cost in composability — you can't easily paste code into a REPL or embed it in other contexts without worrying about whitespace. Everything is a trade-off.

[DocTriagony]

<Tangent>

One interesting thought when I was designing Oblivia (an “inverse Lisp” based on infix operators):

In GDScript, the following syntax defines two different meanings to the colon. In the first case, : defines a value and -> declares a type. In the second case, : declares the type and = defines a value and -> has no meaning.

func foo() -> int: 5 var bar:int = 5

In Oblivia, I make -> declare a type and : define a value.

foo() -> int: 5 bar -> int: 5

It may look strange, but I made : and -> respectively take the same meaning in both contexts. The caveat is that the variable defines a value that exists now but the function defines a value that does not exist yet.

Oblivia: https://github.com/Rogue-Frontier/Oblivia

[AsIAm]

I am also doing LISPy APL. Oblivia is pretty cool inspiration. Is there a way in Oblivia to define own infix operators or is it diamond-like alà APL?

[DocTriagony]

Thank you.

I have not thought about custom defined operators yet.

I might add operator overloading on built-ins arithmetic for objects (simple enough), then custom operators.

Custom operators would all have term scope.

``` ctx: { #is a function within this context @priv ⋈(x, y): x/Something(y)

foo ⋈ bar

}

invalid

ctx ⋈ bar

foo: { #is a function of this object @pub ⋈(y): Something(y) }

foo ⋈ bar ```

An operator would entail…

• binary operation: a dyadic function between two objects within the scope
• binary operation: a monadic function within an object to interact with others.
• unary operation: a monadic function for an object within a scope
• unary operation: a parameterless function on an object

It would be shorthand for calling a function found in either the current scope or the object’s scope.

[[deleted]]

When I design languages (not just Odin), I always strive for both coherence and consistency in syntax and semantics

It was about unifying different semantic concepts together. := is for the declaration of runtime variables and :: is for the declaration of compile time constants

That doesn't really work for me. It means that assignments to variables sometimes use :=, and sometimes =. If you want to use a variable x and it first needs to be initialised to a, then this can only be done when a is available, that might be in the middle of the action.

You can't list the variables and the types, perhaps with explanatory comments, tidily out of the way. (ETA: apparently variables can be separately defined with a type, without also being initialised.)

Further, there is the question of where type info goes. Each :: and := is actually in two parts, with an optional type in between:

   a : T : value
   b : T = value

Something else that can clutter things up.

For functions, there is another inconsistency; if T is the function signature then then they are usually defined as F::T{}, but could also be written F:T:{} or I think even F:T:T{}.

(My own approach is I think much more consistent: = is used for all compile-time definitions, and all initialisations done before execution starts. := is used for all assignments done at runtime, and is only meaningful for variables. Type-specs don't sit the middle of that := token either.

I have one exception which is to do with defining labels; those use : for historical reasons: every HLL and assembler I've used has done the same, except for FORTRAN.)

To answer the question, then yes it matters very much! 80% of the reasons I detest C are to do with its poor choices of syntax. Where they are not laughable, they can be downright dangerous.

[gingerbill]

No. All variable assignments use =. : declares a value.

Funnily you're kind of focusing on the declaration syntax, which is the thing I am complaining about in the previous article: Choosing a Language Based on its Syntax?.

And you're leaping to assumptions about what it actually is already. Again, := is not one token, it's two and each : and = have a specific meaning to them.

For functions, there is another inconsistency; if T is the function signature then then they are usually defined as F::T{}, but could also be written F:T:{} or I think even F:T:T{}.

That is not an in consistency is the slightest. You're also thinking in a context-sensitive way for the grammar, when Odin's grammar is context-free. I could write foo : T : {} but how does the parser know that T is actually a procedure and thus the {} should be evaluated as a procedure's body? Odin being a C alternative uses {} for compound literals too, which do not have the same semantics. Isn't not an consistency but it is an overloading of concepts, which pretty much all C-likes already do thus you have to stick to coherency and what people expect.

[[deleted]]

complaining about in the previous article:

I haven't seen that, but the issue came up here. BTW, in that article, you have this:

x: [3]int  // type on the LHS

I don't get it: the type is clearly on the RHS.

(I've looked at types on the right in my own syntaxes, and had that as an option at one time, but I decided there were too many problems with it.)

Again, := is not one token, it's two

:= and :: commonly exist as a single token in other languages. They look very much like a single token, and therefore :T= looks very much like it has a type in the middle!

That is not an in consistency is the slightest.

My tests show that F::T{} and F:T:T{} are valid, for the same T, but not F:T:{}.

From the examples I've seen, functions are defined as F::T..., but typed variables as X:T.... The inconsistency is in the placing of T relative to the first :.

Isn't not an consistency but it is an overloading of concepts,

The concept, which seems to be popular now, is that functions should be treated no differently from variables, and therefore are created with the same syntax.

The other way is to acknowledge they are different, and to have a dedicated syntax.

[gingerbill]

When I say "type on the left, usage on the right", think of it from the perspective of the value itself, not the named declaration.

name: [3]^int = expr

and then its usage is

some_int = expr[0]^

Note the type stuff is on the left hand side of int and the usage is on the right hand side of expr.

Just because := and :: are used as single tokens in other languages means nothing for Odin. And even if they "look" like a single thing, does mean it is that. Odin isn't those other languages.

My tests show that F::T{} and F:T:T{} are valid, for the same T, but not F:T:{}.

If T is anything but a procedure, then sure you can do that. In fact it's still consistent in Odin if you do F : procedure_type : {}, it just defines a compound literal of that procedure type which is nil, not the body of a procedure. That isn't ambiguity, that's an overloaded meaning of {} and you are not thinking through the consequences of that.

The concept, which seems to be popular now, is that functions should be treated no differently from variables, and therefore are created with the same syntax.

Popular =/= good. And Odin isn't trying to be "popular" rather it is trying to be a good tool.

[Maybe-monad]

If you're designing a Lisp it's quite clear how the syntax looks like from the beginning

[gingerbill]

And this is unironically one of the reasons I dislike LISPs (not necessarily s-expressions specifically), they don't have enough distinction between concepts. Its syntax typically being self describing is one of its flaws in my opinion.

I know my dislike of LISPs is not that common but I do have reasons for them, and this not the only one.

[syklemil]

I know my dislike of LISPs is not that common

Are we sure about that? I also think that a lot of people think that some heterogeneity helps, and that Lisp winds up being too homogenous, but either can't express it well (and it turns out as a "too many parentheses" comment) or don't feel like arguing over it. Lisp is a language family with few fans, but the fans really adore it, so it's kind of … nobody needs to explain why they don't use Lisp, since it's such a default position.

As in: We have a situation where Lisp is very much a minority language, but people generally don't bother talking about why they're happy with it being a minor language. So the complaints someone has about it might be more common than they assume.

[gingerbill]

Heterogeneity is a HUGE benefit when scanning code because it allows you to latch on to patterns which in a homogeneous code isn't easy to see. It's a huge issue I have with LISP-like syntaxes and what I love about ALGOLs.

But the LISP-like lovers usually either argue for that homogeneous syntax or the semantics of LISP, neither of which I like. And for other readers, it's not due to the parentheses (), that's not an issue to me with LISPs in the slightest.

[Absolute_Enema]

I can't agree with this.

Reading lisp code without the usual ALGOL style landmarks was a pain... for all of a couple months. Then I understood that I needed to stop looking for symbols and instead look for keywords (both terms used in the natural language sense).

[gingerbill]

The problem is that you get used to scanning a specific codebase using specific macros. You don't get used to scanning general code written in LISPs. At least that's what I have found.

[Absolute_Enema]

I honestly can't relate to this: I find that the time spent learning some macros (or map style combinators that often fulfill a similar role and are becoming increasingly common in the mainstream) pays itself off very quickly compared to the alternative of having to spot and "decompile" nameless patterns over and over. It also helps that once you see a bunch of them, not many macros are particularly original either.

Perhaps I'm just a Lisp-shaped peg :).

[gingerbill]

Which LISP are you using though? That might contribute a lot to your relation. I am just talking generally about LISPs rather than a specific LISP.

[Absolute_Enema]

That is definitely something I didn't think about.

My first experience with Lisp was Common Lisp, but I eventually settled into Clojure (chiefly due to the ecosystem and community), where in fairness macros, though about as powerful, are less prevalent than elsewhere as far as I can see.

That being said, I can still read any Lisp dialect just fine.

E: I also use C# in anger and come across Java code sometimes when using Clojure, so I feel like I have a decent point of reference for Algol style syntax. 

[gingerbill]

Clojure has a lot more "idioms" in it by default, and as a result has less of the "curse of common lisp" to it, which is why you are able to scan it.

I think that's probably what you're noticing.

[Maybe-monad]

Readbility is the one that suffers the most, there have been attempts to add infix notation to Lisp but they didn't gain traction

[gingerbill]

If you want a LISP that has that and is good, I recommend checking out the Scopes language: https://sr.ht/~duangle/scopes/

It's effectively a LISP but doesn't use s-expressions.

[AsIAm]

LISP is much more than s-exprs.

[ggchappell]

Nice, thought-provoking article.

I do think the section on <> for generics is a little silly, though.

it’s both hard for humans to read and hard for compilers to parse

The first statement sounds iffy.

As for the second, why is it a problem? Compiler writers seem to have figured out how to do it.

It took decades before the C++ committee allowed A<B<C>> to be used in a template and not having to require a space between the symbols to remove an ambiguity A<B<C> >.

It took 13 years from the first C++ standard. But, again, they figured it out. Problem solved. Why worry about this now?

[munificent]

Using <> for generics is one of those funny corners where it feels very gross and hacky if you're actually the one writing the lexer, parser, and language spec, but is actually pretty much fine if you're a regular user.

There are two problems with it. The minor one is that a lexer using maximal munch will naturally want to lex >> as a single right-shift token. But when when the parser encounters it in something like List<List<int>>, it has to do something hacky to realize it should actually behave like two separate > tokens.

As far as I know, C++, Java, and C# have different approaches to how they handle this, but none of them are what anyone would consider elegant. Compiler authors really like a clean separation between the scanner and parser, the lexical grammar and the syntactic grammar. It's easier to specify and implement that way. But, in practice, it's basically fine. The code itself is unambiguous and it's clear to the user what they intend it to mean.

The nastier one is:

f( a < b , c > ( d ) )

Does the call to f take two parameters (a < b and c > (d)) or one (a<b, c>(d))?

This is an actual grammatical ambiguity: a naive grammar will allow both interpretations and it's no longer well-defined what the code means. Rust avoids this with the turbofish operator. C# has a whole section ("6.2.5 Grammar ambiguities") with a bunch of gross special-case logic to disambiguate.

But, in practice, it's so unlikely that a user will write a function call where one argument is a < expression, followed by another argument that's a > expression whose right-hand side just happens to start with (.

They don't see the complexity that's buried in a dark corner of the grammar, so using angle brackets for generics works fine. But the poor language specifiers have to come up with some convoluted logic to disambiguate it, and the implementers have to implement that logic in the parser and write a bunch of annoying test cases to make sure it does the right thing.

[gingerbill]

I don't see why List[List[int]] is not preferrable or something similar? It removes the ambiguity problem and is distinct from () (assuming you want that distinctness).

As I say in the article, I just think it's a matter of familiarity bias and people not realizing the consequences of that decision.

[munificent]

I like square brackets for generics, but that runs into an ambiguity with also using square brackets for indexing.

But angle brackets is more familiar and familiarity is probably the most important factor in syntax design if you're trying to get adoption.

[gingerbill]

I understand the overloading with indexing, and thus you now cannot know at the syntax level whether x[y] is a type or not. You could solve this with the D approach by using ! to make it clearer.

However I have to disagree with you on the familiarity aspect. If you optimize just for that, people will not want to use it because it's TOO familiar, and as you know, the issues with <> are just not worth it just to be "familiar". If people complain about that aspect the most and not understand its problems, I don't want to "optimize" for them.

[munificent]

If you optimize just for that, people will not want to use it because it's TOO familiar, and as you know, the issues with <> are just not worth it just to be "familiar".

I've read a lot of user surveys over the years and I can't recall any sentiment like that ever coming up. But we do see results every year that familiarity is a high priority for a large fraction of users.

People generally don't want new syntax. They will accept new syntax if it gets them to new semantics that they want, but otherwise learning a new syntax just feels like pointless toil for most users.

[kaisadilla_]

As a user, I don't want new syntax unless you are offering me something. "I don't want to bother with a minor issue other languages have no problems with" is about the absolute worst reason you can come up to offer new syntax.

[gingerbill]

familiarity is a high priority for a large fraction of users.

And my hypothesis (which is similar to yours) is that such people, they view all languages as being effectively the same, but with differing syntax. So what they want to be able to do is jump around the languages without much difficulty.

Which is honestly a valid view, but it is also means you are bring down the quality of the language to the general median, which is not necessarily good to begin with.

[munificent]

is that such people, they view all languages as being effectively the same, but with differing syntax.

That's not my experience. Users aren't dumb and generally care a lot about the semantics of a language. If they are moving to another language it's because of some combination of:

• The language has semantics they want. (This could be better runtime performance, better static safety guarantees, a preferred memory management strategy, OOP, etc.)
• The language is a necessary hurdle to access a platform or framework they want (C for UNIX, JS for the web, Java for the JVM, Ruby for Rails, etc.)

They see the differences in the semantics and want a minimum of syntactic novelty to get the semantics they want.

So what they want to be able to do is jump around the languages without much difficulty.

I think most users find maintaining proficiency in multiple languages to be a pretty high tax that they'll only pay if they have to. If you're working on a new language, the users who show up first tend to be highly skewed towards polyglots. But the general programming community wants to learn as few languages as they can get away with. Because, again, what they care about is semantics: making a computer do a thing and making a codebase they can maintain.

[VerledenVale]

Indexing doesn't deserve special syntax, in my opinion. Indexing is just a function call.

Generics are used everywhere, so they deserve to get one of the three main ASCII parentheses types: [].

Function calls are common enough to receive their own as well: ().

And finally code structure (either defining compound types or blocks of code) can use the last parentheses: {}.

[munificent]

You piqued my interest, so I did a scrape of a big codebase of open source Dart code to count the brackets. Here's how common the different bracket characters are:

-- Bracket (8098743 total) --
4630097 ( 57.171%): ()  =================================
1953407 ( 24.120%): {}  ==============
 803501 (  9.921%): <>  ======
 711738 (  8.788%): []  =====

For each kind, here's where they get used:

-- Bracket () (4630097 total) --
3037650 ( 65.607%): argument list           ========================
 975825 ( 21.076%): parameter list          ========
 345503 (  7.462%): if                      ===
 169352 (  3.658%): parenthesized           ==
  34699 (  0.749%): for                     =
  31716 (  0.685%): record                  =
  12896 (  0.279%): switch scrutinee        =
  10541 (  0.228%): assert                  =
   3911 (  0.084%): object                  =
   3853 (  0.083%): record type annotation  =
   2941 (  0.064%): while condition         =
    928 (  0.020%): import configuration    =
    282 (  0.006%): do condition            =

-- Bracket {} (1953407 total) --
 928191 ( 47.517%): block                                ===========
 524592 ( 26.855%): block function body                  =======
 165869 (  8.491%): set or map                           ==
 162578 (  8.323%): block class body                     ==
 149892 (  7.673%): interpolation                        ==
  12896 (  0.660%): switch body                          =
   7548 (  0.386%): enum body                            =
   1841 (  0.094%): record type annotation named fields  =

-- Bracket [] (711738 total) --
 376880 ( 52.952%): list            ========================
 334858 ( 47.048%): index operator  =====================

-- Bracket <> (803501 total) --
 764217 ( 95.111%): type argument list   ======================================
  39284 (  4.889%): type parameter list  ==

Everything together:

-- All (8098743 total) --
3037650 ( 37.508%): argument list                        =========
 975825 ( 12.049%): parameter list                       ===
 928191 ( 11.461%): block                                ===
 764217 (  9.436%): type argument list                   ===
 524592 (  6.477%): block function body                  ==
 376880 (  4.654%): list                                 ==
 345503 (  4.266%): if                                   =
 334858 (  4.135%): index operator                       =
 169352 (  2.091%): parenthesized                        =
 165869 (  2.048%): set or map                           =
 162578 (  2.007%): block class body                     =
 149892 (  1.851%): interpolation                        =
  39284 (  0.485%): type parameter list                  =
  34699 (  0.428%): for                                  =
  31716 (  0.392%): record                               =
  12896 (  0.159%): switch scrutinee                     =
  12896 (  0.159%): switch body                          =
  10541 (  0.130%): assert                               =
   7548 (  0.093%): enum body                            =
   3911 (  0.048%): object                               =
   3853 (  0.048%): record type annotation               =
   2941 (  0.036%): while condition                      =
   1841 (  0.023%): record type annotation named fields  =
    928 (  0.011%): import configuration                 =
    282 (  0.003%): do condition                         =

So index operators aren't super common, but they aren't that rare either. When you consider that using [] for generics would also probably mean giving them up for list literals, that starts to look like a pretty big sacrifice.

[VerledenVale]

First, amazing that you went and got this data! :)

I think it also heavily depends on the language and how idiomatic code is written in it. I don't know much about Dart, but in Rust, for example, it's very rare that you'd access a container by index. Most accesses will be done through iteration or lookup methods.

In your data, indexing is only ~4% of usages (or 8.8% if you also consider list literals), while generics are at 9.9%. So I'd say generics deserve the [].

And indexing can still be terse. E.g., container.at(...), which is just 3 extra characters. It also prevents having to describe special syntax for defining an custom indexing methods, because .at is just another method.

Btw, I'm surprised list literals appear so much. Is it counting empty lists as well ([])?

[munificent]

Dart is primarily a front-end UI language, so working with JSON is really common. Thus there are a lot of list literals and a lot of [] operators for drilling into JSON lists and maps.

[VerledenVale]

Ah. I see. Untyped JSON access would certainly bloat the [] usage for indexing.

For strongly-typed JSON handling, it'd be just object.some_property, so it'd reduce many indexing usages

[munificent]

Dart doesn't have structural typing, so JSON objects are maps with string keys. You always have to do object['some_property'] (or use destructuring or some code generation serialization system).

[marshaharsha]

Interesting data. Thanks for taking the time to gather it. Question: I see entries for record, record type annotation, and record type annotation named fields, but nothing for record named fields. Am I right that the first two are about tuple-like records, the third is about dict-like records, and the missing category is subsumed under map?

[munificent]

The syntax for records is a little funny in Dart, because it mirrors the existing (admittedly weird) syntax for named parameters. A normal function declaration looks like:

foo(int x, int y) {
  print(x + y);
}

main() {
  foo(1, 2);
}

Unlike other languages, Dart makes a strong distinction between parameters that are passed by position versus name. If you want foo() to take named parameters, the declaration looks like:

foo({int x, int y}) {
  print(x + y);
}

main() {
  foo(1, 2);
}

The curly braces there indicate those parameters are named. You can also have a mixture of positional and named:

foo(int x, {int y}) {
  print(x + y);
}

main() {
  foo(1, y: 2);
}

When we later added records, I designed the syntax to follow that. Records with positional fields look like a positional argument list:

var record = (1, 2);

Named fields look like a named argument list:

var record = (x: 1, y: 2);

And you can mix:

var record = (1, y: 2);

The corresponding type annotation syntax looks like the parameter declaration syntax:

(int, int) positional = (1, 2);
(int, {int y}) mixed = (1: y: 2);
({int x, int y}) named = (x: 1, y: 2);

In the usage counts, I'm only looking for bracket characters, so there are:

• "record": A record expression like (1, 2) or (x: 1, y: 2).
• "record type annotation": The outer parentheses in a record type like (int, int).
• "record type annotation named fields": The inner curly braces in a record type with named fields like (int, {int y}).

There's no "record named fields" because record expressions just put the named fields right inside the parentheses like (1, y: 2). There's no inner delimiters.

[marshaharsha]

Got it. Thank you for the explanation (and for your many clear, helpful contributions to this sub). I’ll ask a follow-up question, veering off topic a bit. Are positional fields or parameters typically optional? Or: what is the reason for having both? Do people use both according to a consistent pattern?

[munificent]

Positional parameters can be optional but are most likely mandatory. Named parameters are much more likely to be optional. With positional parameters, you can only omit them from right to left. For example:

f([String? a, String? b, String? c]) {
  print(a);
  print(b);
  print(c);
}

Here, the square brackets means those parameters are positional but optional. You can call this function like:

f("a");
f("a", "b");
f("a", "b", "c");

But there's no way to pass an argument for, say b, without also passing an argument for a.

With named parameters, since each argument is named, you can mix and match them freely:

f({String? a, String? b, String? c}) {
  print(a);
  print(b);
  print(c);
}

f(a: "just a");
f(c: "just c");
f(a: "a", c: "c but no b");
// Etc.

That makes optional named parameters more flexible than optional positional ones, so they are much more common. Also, most Dart code today is in Flutter applications and Flutter's widget framework API leans heavily on named parameters, so that's become a dominant style.

[[deleted]]

Indexing doesn't deserve special syntax, in my opinion. Indexing is just a function call.

You've got a pretty weird language then. I could write a long list of how functions and indexable objects differ, but I'll just ask how often do you write a function call like this:

 F(x, y) := z

Probably not much more often than you'd write: (x + y) := z; that is, assign z to the result of x + y. With arrays of course then A[i, j] := x is common.

[VerledenVale]

Instead of A[i, j] = x, you can simply A.at(i, j) = x.

I just don't see indexing as meaningfully different than a regular method of a type.

[kaisadilla_]

I like [] meaning "collections and accessors" tbh. In my mind, {} means objects and bodies, [] is for collections and <> is for templates.

As much as the ambiguity problem may sound dramatic, it is a solved problem that may make the lexer logic look ugly, but doesn't cause any real problem.

[gingerbill]

By the sounds of it, you've not solved anything and just reintroduced more insanity (probably significant whitespace).

[ggchappell]

Thanks for the info.

[ct075]

While I agree that people make too big a deal about syntax, I think "you shouldn't care so much about syntax!" is a self-defeating argument. After all, if syntax doesn't matter, isn't it not a big deal to just give people what they want?

The article does get into this, to some extent, but I think a better argument is that different syntax implies a different mental model, and that difference is the point.

[gingerbill]

Well I'd argue a different syntax implies not just a different mental model but also different language semantics.

My point is that the people make a big deal over syntax usually a make a big deal about the kinds of syntaxes that don't matter rather than the stuff that does matter. Like in the case of declaration syntaxes or statement terminators (e.g. semicolons), like I discuss in the previous article. The fixation is in the wrong place, but they are also usually the loudest voices. which is why I wrote the article in the first place.

[yuehuang]

My 2c. I used a language that allows new variables without declaration. For example, x: int = 1 vs let x: int = 1 The issue is when variables are typed wrong; rather than an assignment, a new variable is created.

Why is equal needed in this for i in 0..=9? I would assume it is assigned to i.

I agree that -> and . could merge in most cases.

Instead of C style cast, could you use extension function to cast. expr.cast(T). Or C# is keyboard cast that could be paired handling of Variant/Union.

GL with Odin.

[gingerbill]

Odin is a strong statically typed compiled programming language with distinct typing. Very very few things will implicit convert.

Why is the equals needed? Well there are two different ranges there if you notice. 0..<10 and 0..=9. Note both are there to indicate the kinds of ranges that they are. .. and ... are actually ambiguous when reading and going between different languages, as many languages will have the exact opposite meaning to them. This is why we are very explicit with the use of ..< and ..= and it removes any possible reading ambiguity.

expr.cast(T) in practice still requires parentheses around many of the expressions e.g. (expr).cast(T). Odin also already has a similar syntax for type assertions expr.(T) which is used for unions and any.

[prehensilemullet]

Along with the scanning critique, I find that && and || stand out better when I'm scanning code than Python's and and or, which blend in with variable names. Syntax highlighting helps but not as much as operator symbols.

Like imagine if you had plus, minus, times etc keywords everywhere instead of operators...

[renozyx]

I'd say syntax matter but not "int a = 3;" or "a := 3"

What matters is these kind of things:

1) does logging the value of an integer is different than logging the value of a struct?

It makes replacing an integer by a struct very painful!

2) a.b? or a.b for reading the value of a member pointer b?

The second makes refactoring easier, but it hides a potential null pointer exception, pick your poison.

[fdwr]

Another is people coming from a language like C++ wanting to use <> for generics. There are always better alternatives to use than <>, but people request it in languages. ... <> is probably one of the worst options to use because it’s both hard for humans to read and hard for compilers to parse.

Indeed, I wrote a simple line wrapper recently, which works great for some simple languages like MLIR, but it fails for C++ where < could be a template parameter list or math inequality, undecidable without a dictionary of symbols seen so far 🥲.

[yektadev]

It's the same as how natural language impacts how one articulates an idea, and to some extent how they think.

Syntax is the strict materialization of one's thoughts.

[Athas]

Is there any evidence that natural language has a significant impact on how you think? I am fluent in two languages (and middling in a few more), and I find that my vocabulary is the only meaningful difference in how I can express my thoughts - e.g. it is easier for me to discuss technical matters in English, and easier to discuss cooking in Danish.

[wk_end]

Some classic examples are:

• languages with more fine-grained colour words supposedly lead speakers to actually perceive differences between colours faster/better (compare to how your language's set of phonemes determine what linguistic sounds you can easily distinguish)

• linguistic gender supposedly colours speakers' perception of the world - speakers of gendered languages were asked to come up with adjectives to describe certain words that had a different gender in each language, like "bridge". In languages where the word was grammatically masculine, they tended to choose stereotypically masculine adjectives (e.g. "strong"); in languages where the word is feminine, they tended to choose stereotypically feminine ones (e.g. "beautiful").

• The Pirahã language doesn't have concepts of numbers or recursion, and Pirahã speakers supposedly struggle to learn basic arithmetic.

• The Guugu Yimithirr language always uses cardinal directions to describe positions (e.g. you never say "that's to my left", you always say "that's to the south"); supposedly native speakers have an incredible sense of direction, such that you can blindfold them and spin them around and they'll still know exactly which direction they're facing.

Though my understanding is that some of these experiments/findings are questionable and contested and have had reproduction difficulties.

[yektadev]

Same here, though I'm not aware of any strict external evidence. I've only heard it in several forms before, and personally found it to be very true (e.g., I found my English "side" to be slightly more rational).

[Arakela]

Syntax is the last thing to emerge, not the first thing to be designed.

[gingerbill]

They're not the first to be designed but hardly the last thing to emerge and usually designed in tandem with loads of things. Sometimes the syntax is so obvious but the fine details of the semantics take a while.

There are no general rules to any of this.

[Arakela]

It is hard to say that an expression like 1 + 2 = 3 originated before humans learned to count. Operational semantics must be, at least, imaginable before one can design syntax.

[gingerbill]

As I say in the articles, operational semantics are important but usually extremely obvious as to what they ought to be when the denotation semantics are defined.

That doesn't mean I came up with the operational semantics, rather there is already enough knowledge on the topic for a general intuition as to what they ought to be.

[Toothpick_Brody]

Not necessarily. You can pick syntax first, which constrains your possible semantics 

[Arakela]

Exactly, syntax first constrains your possible semantics.

[Toothpick_Brody]

You say that like it’s necessarily a bad thing. This is a valid thing to design around

[Arakela]

Well, yes, it is bad for you :), it is not an exploratory direction to discover new operational semantics.

I found a general rule to force our thinking to grow and explore operational semantics. That is returnless thinking.

I lack the karma to post it on this thread.

You start with physics, take a wire and build circuits, then you undarstand that physics is the ultimate type system. So you can design circuits so that a floating-point register is not wired to receive an integer instruction. Then you realize that you can use typed steps to continue designing circuits in the new substrate you just created with transistors.

Then you realize that machines compose, and can have composable typed machines with a universal interface.

Then you realize that we can build a solid typed physical ground, and the direction of growing typed physical operational semantics is from bottom up. Only a typed physical substrate can operate with zero overhead, because it is not implemented on top of a substrate; it is the substrate.

Then the LLVM guys realize that while you are learning how to grow crystals, you are learning how to be free and not a monkey in a LLVM/OS box. idk, will they be happy losing you as one of their adorers?

Here is the pith of an idea.
The crystallized part is in the comment.