5 ms·

When CONSTants vary (critique of 'const' in C++)

1 points by samstokes 16y ago

samstokes 16y ago
I've argued in the past for 'const' being a feature of C++ that would add value to other languages, but this article shows it's a more subtle and confusing abstraction than it appears. I'm not convinced the abstraction actually leaks - both the author's complaints are examples of "things you thought const guarantees when it doesn't" rather than "ways to circumvent what const guarantees" - but it doesn't mean what you'd instinctively hope it means. (I feel this oblique Princess Bride reference is justified given that, if you say 'const' in any part of your program, you really do have to keep using that word.) With all the talk of "support for immutable datatypes" I hoped Scala would do more to support this sort of programming - e.g. statically guarantee a function didn't mutate its arguments - but it actually offers less than C++ did. Forcing you to make the val/var choice for each variable is a nice improvement over Java's "mutable unless you go out of your way", and having performant immutable collections solves a common case (final reference to a mutable HashMap); but you're still basically relying on code inspection or documentation to tell you whether a given class is immutable. Having the type system able to tell you that would help both the authors of a class and its consumers.
- gtani 16y ago
  Mutations inplace are often done /necessary to make things performant with the JVM, viz clojure transients. For those playing along at home, the tapir book ("Purity Inside vs. Outside) and staircase book ("What makes an object stateful? p 357) are good little summaries. http://programming-scala.labs.oreilly.com/ch08.html#PurityInsideVsOutside http://programming-scala.labs.oreilly.com/ch08.html#PurityIn...
  - samstokes 16y ago
    I'm not claiming that all data should be immutable, or even that all data in Scala should be immutable; just that when you are using immutable data, the compiler should help you do that.

1 points by samstokes 16y ago

I've argued in the past for 'const' being a feature of C++ that would add value to other languages, but this article shows it's a more subtle and confusing abstraction than it appears. I'm not convinced the abstraction actually leaks - both the author's complaints are examples of "things you thought const guarantees when it doesn't" rather than "ways to circumvent what const guarantees" - but it doesn't mean what you'd instinctively hope it means. (I feel this oblique Princess Bride reference is justified given that, if you say 'const' in any part of your program, you really do have to keep using that word.) With all the talk of "support for immutable datatypes" I hoped Scala would do more to support this sort of programming - e.g. statically guarantee a function didn't mutate its arguments - but it actually offers less than C++ did. Forcing you to make the val/var choice for each variable is a nice improvement over Java's "mutable unless you go out of your way", and having performant immutable collections solves a common case (final reference to a mutable HashMap); but you're still basically relying on code inspection or documentation to tell you whether a given class is immutable. Having the type system able to tell you that would help both the authors of a class and its consumers.

gtani 16y ago
Mutations inplace are often done /necessary to make things performant with the JVM, viz clojure transients. For those playing along at home, the tapir book ("Purity Inside vs. Outside) and staircase book ("What makes an object stateful? p 357) are good little summaries. http://programming-scala.labs.oreilly.com/ch08.html#PurityInsideVsOutside http://programming-scala.labs.oreilly.com/ch08.html#PurityIn...
- samstokes 16y ago
  I'm not claiming that all data should be immutable, or even that all data in Scala should be immutable; just that when you are using immutable data, the compiler should help you do that.