Hacker News Reader

Comment by hood_syntax | Hacker News Reader

A key point (perhaps well known but still very important) is the "let mutable" vs "let" for declaring mutable variables. It really does change tendencies of developers by putting the burden of effort on one of two paths, and encouraging people to write code a certain way can have significant effects on the end product.

View on HN

While true, I'm not sure that it's necessarily because of the increased burden.

In Scala, for example, immutable variables are declared with "val" while mutable ones are declared with "var". Here's there's no great cost in typing or screen space (and to the uninitiated, it may not even jump out at you). But Scala developers will almost universally use val; in the language idiom var is an unusual thing that feels wrong. And I say above that it won't jump out to beginners; but to experienced Scala developers that l vs r is a huge glaring difference -- your brain just gets trained that way.

I think the key takeaway is that some languages are designed with first-class support for immutable variables, and in those languages, you tend to use immutable variables. Even in Java, modern style tends to use "final" for local variable definitions, though the support in the language for immutable types is much weaker, so the tendency isn't as strong. In a language like C, immutability is a practically non-existent practice, and "const" does not serve the same function.

I find your statement confusing -- you appear to be attempting to argue that "let mutable" vs "let" would have no impact because "var" vs "val" has no impact. But you point out yourself that there's no cost to typing either in Scala... whereas there's a huge (in context) cost to typing "let mutable" vs "let. If you had to type "constant var foo =" vs "var foo =" (or similar) then presumably average Scala code would have quite a different distribution of mutable vs. immutable values.

The argument is that whether people choose to use mutable when it's not necessary has nothing to do with being harder to type. In Scala, using mutable is not harder and people still do the right thing.

Any studies exploring that? Many claims like this are highly prone to confirmation bias. Specifically, you will notice the times it favorably changes your tendencies. Ignoring all of the times it was irrelevant or cumbersome.

Note that I am specifically not arguing against immutability. I have, however, seen bugs caused both ways. When I was a TA, Java students were notorious for not understanding why calling "trim" on their string left the whitespace. To often disastrous consequences. I would be delighted to see empirical studies to weigh against all of the anecdotes in my head. :)

It's a kind of trivial side-note, but F# would provide a compiler warning (configurable to be a compilation error, if you like), if you were to call myString.Trim() without binding the result to a value, unless you explicitly pipe the result to "|> ignore". This language in particular has oodles of great default behaviors, most of which can be overridden, but you must do so explicitly.

Unfortunately, I have no more data on the real-world results than anyone else. :-)

Can I butt in with an aside about how nice F#'s physical unit type handling is? Seriously, that's some nice design right there.

I remember this study about the use of final and const keywords in Java/C.

http://dl.acm.org/citation.cfm?id=2884798&CFID=985095807&CFT...

It's a small example, maybe it's a start.

Fun read, thanks for sharing!

It is just a start, so I am hesitant to pick at it. I am excited to see this getting explored, I was hoping for a dive into bug reports against software, though.

That is, I share the same bias most of software developers share that mutable code is ultimately dangerous and should be avoided. The flipside, only when working with established codebases does this really bother me. Greenfield projects that are not close to shipping are usually quite clean and not a concern. Battle worn codebases, though...

To that end, the CWE attempt (https://cwe.mitre.org/) was an interesting start. Especially if it was backed by numbers in the CVE database. So my question is, how many of the CVE reports could have fully been laid to this class of bugs? (I'll see if I can put together a notebook going over this idea. Still hoping someone else has already given this a better treatment than I am likely to.)

I didn't necessarily mean the effects would be positive, just that there would be effects. I would also like to see studies done regarding decisions such as the one we're discussing

Reply on news.ycombinator.com