5 ms·

ES6 transpiling has been a bit of a revelation to me lately. Object destructuring is also exceedingly useful. On a bit of a tangent from the article, I'm inter

by iMark 12y ago

ES6 transpiling has been a bit of a revelation to me lately. Object destructuring is also exceedingly useful. On a bit of a tangent from the article, I'm interested by the use of const as the default for variable declaration. My background is such that I've always considered constants as things that are class level constants (thank you Java), but reading up on Swift has made me rethink this. Clearly const has the potential to reduce runtime errors. I'd appreciate it if anyone could recommend any further reading on the subject.

acjohnson55 12y ago
I'm not sure about the best possible resource to read, but in the traditional of functional programming, immutability is preferred in nearly all cases. This is particularly important when it comes to data with long-lived scope (e.g. members of objects, data within the scope of closures, etc.) because the functions that operate on non-constant data lose purity and become more difficult to reason about and test. In other words, mutability leads to side-effects, wherein operations on data in one part of a program are visible within other function, without explicitly being passed in. In many functional languages, mutation of variables is only allowed in special cases, and in some languages, it's not allowed at all. This can be weird if you learned programming in a tradition where modifying variables is one of the first things you were taught, but once you get used to not mutating your variables, the benefits really start to shine. As you mentioned, it often prevents entire categories of errors. For instance, I haven't written a for loop with an index variable in well over a year, in favor of using map/flatMap/filter/fold and friends, and for that reason, I can't remember my last fencepost error. Like I said, I don't know the best resource, but learning Scala was really influential for me in immutable programming, and the Functional Programming Principles in Scala Coursera course [1] and the (unrelated) Functional Programming in Scala book taught me a lot of what I know on the topic. [1] https://www.coursera.org/course/progfun https://www.coursera.org/course/progfun [2] http://manning.com/bjarnason/ http://manning.com/bjarnason/
- tel 12y ago
  Double down on Rúnar's book! You have only learned half of Scala until the day that "FP in Scala" is trivial to you.
- Touche 12y ago
  In JavaScript const is not immutable. const foo = {}; foo.bar = 'baz'; This is valid, you cannot reassign foo, but you can mutate it. Native immutables in JavaScript would be great, but would be hard to pull off given prototypical inheritance. EDIT: Now const + Object.freeze gets you close to immutable. I'm not sure what that means for inherited functions, can the parent prototypes not be mutated either?
  - acjohnson55 12y ago
    Yeah, this is also true of the `val` statement in Scala too. I suppose though that in Scala, one would probably make all data members of classes `val` as well, whereas in Javascript, there's no in-line syntax for constant object properties (Object.freeze being a bit verbose to use everywhere). But even that limited form of enforced immutability is helpful. I personally find it easier to understand a complex function when I can assume that no names are being rebound.
- iMark 12y ago
  Ta muchly - I shall investigate.

by iMark 12y ago

acjohnson55 12y ago

I'm not sure about the best possible resource to read, but in the traditional of functional programming, immutability is preferred in nearly all cases. This is particularly important when it comes to data with long-lived scope (e.g. members of objects, data within the scope of closures, etc.) because the functions that operate on non-constant data lose purity and become more difficult to reason about and test. In other words, mutability leads to side-effects, wherein operations on data in one part of a program are visible within other function, without explicitly being passed in. In many functional languages, mutation of variables is only allowed in special cases, and in some languages, it's not allowed at all. This can be weird if you learned programming in a tradition where modifying variables is one of the first things you were taught, but once you get used to not mutating your variables, the benefits really start to shine. As you mentioned, it often prevents entire categories of errors. For instance, I haven't written a for loop with an index variable in well over a year, in favor of using map/flatMap/filter/fold and friends, and for that reason, I can't remember my last fencepost error. Like I said, I don't know the best resource, but learning Scala was really influential for me in immutable programming, and the Functional Programming Principles in Scala Coursera course [1] and the (unrelated) Functional Programming in Scala book taught me a lot of what I know on the topic. [1] https://www.coursera.org/course/progfun https://www.coursera.org/course/progfun [2] http://manning.com/bjarnason/ http://manning.com/bjarnason/

tel 12y ago
Double down on Rúnar's book! You have only learned half of Scala until the day that "FP in Scala" is trivial to you.
Touche 12y ago
In JavaScript const is not immutable. const foo = {}; foo.bar = 'baz'; This is valid, you cannot reassign foo, but you can mutate it. Native immutables in JavaScript would be great, but would be hard to pull off given prototypical inheritance. EDIT: Now const + Object.freeze gets you close to immutable. I'm not sure what that means for inherited functions, can the parent prototypes not be mutated either?
- acjohnson55 12y ago
  Yeah, this is also true of the `val` statement in Scala too. I suppose though that in Scala, one would probably make all data members of classes `val` as well, whereas in Javascript, there's no in-line syntax for constant object properties (Object.freeze being a bit verbose to use everywhere). But even that limited form of enforced immutability is helpful. I personally find it easier to understand a complex function when I can assume that no names are being rebound.
iMark 12y ago
Ta muchly - I shall investigate.