I love that you are using colon for the assignment operator. This is absolutely correct. Most languages use the equal sign as the assignment operator in most contexts and then the colon in limited contexts. This comes from Fortan and its just wrong. The equal sign should be reserved for comparisons, because that is what it means in mathematics.

To push back a little: Designing the syntax of a programming language always involves tradeoffs; nothing is "just wrong". For better or worse, equal sign as assignment has become widely used and understood. I think the author's use of colon is neat, but it is confusing if you're used to seeing that as the type indicator; again, a tradeoff. I like the look of := as the assignment operator but it adds another shifted key to type, which can push you that much closer to RSI for such a common operation.

> The equal sign should be reserved for comparisons, because that is what it means in mathematics.

This is touching on a pet peeve of mine: Mathematics and programming are similar in many aspects, but this is not one of them. In mathematics = is not a comparison, but a statement.

More generally, mathematics is about tautologies, that is statements that are always true. In programming, a comparison is evaluated to either true or false.

That doesn’t mean that there’s no room for conditionals in mathematics (one example is piecewise function definitions). But it’s not the same. Heck, even the definition of “function” is different between mathematics and programming.

> The equal sign should be reserved for comparisons, because that is what it means in mathematics.

"let x = 1" has the same meaning in mathematics as well as JavaScript and Rust.

> I love that you are using colon for the assignment operator. This is absolutely correct.

Historically, distinguishing an equality operator from an assignment one has existed for many decades. Whether using colon for the latter is "absolutely correct" is the subject of valid debate.

An equally compelling case could be made for any of the following assignment operators as well:

  foo <- 42
  foo -> 42
  foo <= 42
  foo => 42
  foo <-> 42   if expressing substitutability is important
  foo := 42    Pascal lives!
  (foo 42)     so does LISP!
  foo is 42    for those who prefer English operators
  f(foo) = 42  for mathematically inclined languages

> because that is what it means in mathematics

Personally, I think this argument only holds water for languages that are rooted in mathematics (e.g. Haskell, Lean, Rocq, F*, ...). If your computational model comes from a place of physical hardware, instructions, registers, memory etc. you're going to end up with something very different than an abstract machine based on lambda calculus. Both valid ways to design a PL.

I’d argue there’s a very big difference between “x: y” and “x : y”. I can only see the former as assignment and the latter as the has-type relation.

(I find it baffling in the extreme that in many mainstream languages the convention is to write type annotations as “x: T”, both prima facie and because in those languages the notation then collides with field assignment!)

Mathematics, famous for consistent readable notation. Next idea should be to just stop declaring variables at all assuming they mean what they usually mean in similar programs. Starting array indexes from 1 instead of 0 is another one although that was already tried :)

what about:

    f(x) = x * 2

I'd like to see language designers make function calls happen in the order you read them.

For example, in most languages you have a notation like f(g(h(x))) which calls the functions in the exact opposite order of reading which is unnecessarily confusing.

Even this is wrong. Programming should be explicit and easy for anyone to read.

    c = a + b;

Nope, make it explicit. You're moving the value of an expression to a placeholder. The only sensible way to write that would be

    ADD a TO b GIVING c

Sure but mathematics is better. There you can switch LHS with RHS.

Instead of := you should use => for assignment.