Something that comes up often: should an important distinction be made with syntax and/or with types? Doing it with types works well and scales to higher order code. Doing it with syntax only is first-order and forces error-prone boilerplate on the developer. Some examples:

Let's turn back the clock to the old days... there was a thing called Hungarian notation, where you'd use a set of naming conventions for variable names with different meanings instead of using different types... were we running out of bits to make new types? :)

No, I think that in C, people were more reluctant to make new types due to a lack of overloading (like if you have a "distance" type, you couldn't add distances together... so just keep it as an int). And wrapper types were still less convenient (and efficient?) in C++

The conventions aren't a bad idea necessarily (I like @spolsky general pt about "wrong code looking wrong" https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/) but they are just a syntactic thing you gotta remember to write and check. Better than "wrong code looking wrong" is "wrong code doesn't typecheck".

The syntactic conventions also don't have much to say about higher-order / generic code. Consider ` http://List.map ` - its power is it can be instantiated all possible combinations of types, so no one naming convention suffices (we usually call its arg 'f')

Another one that came up in Scala: should delayed computations with side effects be written as `def foo() = ...` or `def foo = ...`. There were many debates on this!

It's not the worst thing to have a convention, but when you're taking (say) a list of delayed computations as an argument in some higher-order function, there "isn't room in the syntax" to fit this information. So you want the info tracked in the types if it's important.

Another more recent one is algebraic effects, which generally avoid having any sort of syntactic distinction between pure and effectful code (but track this in the types). We do this in @unisonweb (also see Eff, Frank, Koka) and it's nice... but!

In say Haskell, there's both a syntactic AND a type distinction for pure and effectful code, and if you've been writing functional code for a while, you are so used to the syntax and the types being connected that it feels unusual at first.

Part of your brain is reminding you of the bad old days where neither syntax nor types tracked effects. But then you start to see the benefits of the approach - it's way less boilerplate.

And then a more subtle point - even though effects as values means you have to be very explicit about things like evaluation order (a theoretical benefit), in practice, the code is so mindless and/or you're using HOFs so you don't really get this benefit anyway.

Not to mention the type errors you get are not great... multiple times I've forgotten a call to `pure` in a branch of a pattern match and gotten cryptic errors that have taken me like 10 minutes to track down. And for what?