>> Typos like the above become not possible.

In my 15 years of programming experience of programming every single day, I have made this kind of typo maybe 2 or 3 times in total and it took me less than a minute to identify and fix the problem each time.

On the other hand, the amount of time that it would have taken me to type out that extra ':' a few million times would have been much more costly.

This is a really arrogant statement. In C, `if(a = b)` could cause incredibly subtle bugs. It was prominent enough that it got addressed in all the best practices books, like "Writing Solid Code", with a style that got later termed "yoda conditions" - a style that was prominent in spite of being acknowledged as less readable, because it forced a compiler error more often. It's hard to even think of many other types of bug with that kind of significance, and you just dismissed it out of hand with "I don't make those kinds of mistakes".

If the problem is so bad, why not simply use a linter? Actually, almost all instances of this typo can be caught by a simple regular expression.

Well, that's pretty much equivalent to the the language preventing bugs, for the purpose of the conversation. You can imagine similar cases that would be harder for a linter to pick up. Things like type errors, or accessing the wrong side of a union - in C++ people used Hungarian Notation for a good while to try to make these kind of errors more detectable; now some languages have tagged unions/sum types to make them nearly impossible. The point where a linter is distinct from the language in catching syntactically evident errors is that, even if I use a linter for my own code, that isn't the same as having buy-in from the whole team to block any code that doesn't pass the linter from shipping to production; language syntax, on the other hand, is implicitly agreed upon.

Addressing this specific example, historically, running a linter all the time wasn't always practical, and `if(a = b)` was used intentionally a lot, e.g. to inline a check for a null pointer with an assignment.

> I have made this kind of typo maybe 2 or 3 times

Pardon my french, but that is some straight-up horseshit.

Even if you were the best programmer in the world, I would be skeptical at you saying that you make that kind of typo less than two or three times a year or per project, much less over the course of fifteen whole years.

I can see it, in the beginning I may have made that mistake more often for a while, but I don't think I've made this mistake in years. The difference is absolutely ingrained, just like I wouldn't mistake plus for minus. Perhaps it's different for people who read a lot of math.

I would agree that having equals-assignments as valid expressions is bad, I just don't think it's such a big deal. If you are using such a language, you should be using a linter anyway.

Using := would be very annoying for me, even though I can see the argument and would favor it in theory.

How about JavaScript and '==' versus '==='?

Or going back and forth between languages that use '==' and JavaScript?

Let's say over all of history there have been a million C/C++ programmers, and each of them has made that mistake ~5 times, in total.

And let's be generous and say that 95% of the time it was found before it got anywhere near production.

That is still 250,000 bugs introduced.

Not to mention how much time is spent tracking down the bug once it has been in the code base for awhile. If it goes unnoticed for a couple of weeks debugging becomes non-linearly harder.

> How about JavaScript and '==' versus '==='? > Or going back and forth between languages that use '==' and JavaScript?

That's a mistake I make often, but it's exactly because Javascript is different here from all other languages that I use.

Let's say I had to use a language with ':=' as assignment, I would still accidently type '=' all the time.

> Let's say over all of history there have been a million C/C++ programmers, and each of them has made that mistake ~5 times, in total.

> And let's be generous and say that 95% of the time it was found before it got anywhere near production.

> That is still 250,000 bugs introduced.

Well, so what? That's 250,000 out of maybe a hundred million bugs. I'm not saying it's good language design to have this behavior, quite the opposite. I'm saying it's not a big deal, especially considering all the other footguns in these languages. It's also not like these languages are going change it.

So you admit that he refuted your contention that

> A language cannot prevent someone from making stupid mistakes.

Yes, but the total input requirement must be considered too.

A very expressive language may have that ”:=” overhead while also providing many robust and useful operators too.

Yes, the product may look like line noise, but it was Uber efficient to create in basic cost terms

Best of both worlds:

(let [x 1]

  (if (= x 1)

    ...))

While the language can prevent certain errors on itself, errors can also be found with static analysis and testing, and prevented with paradigms and experience.

I am personally more likely to forget the : than a second =. Happened all the time when I was writing plsql.