10 ms·

"If you were to design a new language today, he said, you would make it without mutable (changeable) objects, or with limited mutability."

estava 11y ago
Indeed. That may mean fewer opportunities for "meta-programming" if by meta-programming we mean mutation of core structures. It could also be a good chance to turn around the default of declaring variables to declaring constants instead. Complex data structures would still have to be mutable by default I guess, but they would be the obvious next target to becoming immutable by default.
- eru 11y ago
  Why would your complex data structures be mutable? Wouldn't immutability pay off especially in complex cases?
  - cillian64 11y ago
    If you make my huge NumPy arrays immutable, I will be very unhappy (unless I am significantly misunderstanding how this everything-is-immutable strategy works). There might be a lot to be said for rust-style immutable-by-default.
    - juliangregorian 11y ago
      I assume using some form of copy-on-write.
    - eru 11y ago
      First, you'd still have optional mutability. Second, arrays are rather simple data structures, but ones where you often care about performance--small tight loops are common. Compare that to the data structure that eg holding your options and flags for the computation: you don't do much computation on that, but you have lots of invariants that you want to uphold---ie lots of code, but each bit executed roughly once, no tight loops.
  - DasIch 11y ago
    Algorithms on immutable data structures tend to have very bad worst case peformance.
    - zeckalpha 11y ago
      Naïve algorithms on immutable data structurs tend to have very bad worst case performance.
      - eru 11y ago
        And there would always be the optional mutability. Your complex data structures are seldom the ones driving performance. Ie often you have to get the complex data structures right (lots of logic, not much computation) to set up your computations on the simple ones (eg lots of number crunching on your arrays).
        zeckalpha 11y ago
        Yes, it's easier to reason about correctness in immutability land and add mutability in after the fact as a compiler optimization than to remove mutability for safety as a compiler pass.
        eru 11y ago
        Haskell sort-of does this. Laziness can be seen as a very disciplined form of mutability. (Haskell also allows mutability that is visible to the semantics of the program, that's where the famous monads come in.)
bitL 11y ago
In other words you'd make it slow without the ability to allow it to be fast.
- porker 11y ago
  Is that true? It doesn't match many of the comments on HN around React, Om, Clojure etc...
  - bitL 11y ago
    Yes, it is slow. Immutability is allowing you to write elegant concurrent algorithms at the expense of speed and memory. Imagine you are forced to never change an array of numbers for an algorithm computing matrices, rather creating new matrices for each step and specifying numbers only during initialization. But hey, you can cache them and keep track of every single copy without any confusion now! Now imagine a non-concurrent language like JavaScript - what exactly are you going to get by using immutable structures except for the feeling you are going with the times? Reference counting and caching are probably the only areas where immutability can help for most programs. Immutability is in fashion nowadays due to functional programming being in fashion despite the inability to ever achieve "pure" functional programming in reality - I/O is by default "dirty" (I really hate these charged words in computing), no amount of flatmapping (i.e. monads) is going to help with that.
    - porker 11y ago
      Thanks, that's a great answer and helps me understand. I guess there are subsets of problems where immutability is a good idea (anything needing state, 'Undo' capabilities), neutral, and a bad idea (number crunching, data processing, 'traditional'(??) programming). I have been wowed by the beauty of the immutable approach in web apps, but definitely subscribe to the right technique for a task. I can't imagine doing the data processing in physics using an immutable language...
      - bitL 11y ago
        Indeed it boils down to what you need to achieve. You might want to use both approaches and combine them for best performance/readability. There are specialized high-performance structures that are mutable (e.g. disruptor in HFT trading) optimizing all the way down to CPU cache lines to achieve unbelievable speeds, yet they work nicely if the objects they refer to are immutable. So just take all advices to switch to immutability with a grain of salt and learn to figure out which approach is suitable for what part of your system to have it both performing well and being able to conceptualize and maintain the code nicely ;-)
amyjess 11y ago
Honestly, I found that kind of disappointing, because one of the things I like most about Python is its metaprogramming capabilities. I'm honestly not fond of languages like Rust that try to restrict mutability. The only one of the new breed of languages I've found that I really like is Nim.
- ptx 11y ago
  Doesn't Nim go a bit too far in that direction, though? Mutable strings seems a bit dangerous to me – won't you have to copy them all the time to make sure they don't get modified somewhere else?
marcosdumay 11y ago
Let's just keep in mind that the entire reason languages with immutable data are trending is because we already have all those languages with mutable data to use where they are fit. A new language today shouldn't really implement Python metaprogramming, because Python already does that.
- amyjess 11y ago
  Yes, and I think the reason why Nim got so much attention was because it filled the niche of metaprogramming in a statically-typed, AOT language, which is probably the last frontier of mutability and metaprogramming. It's probably the last major new language with metaprogramming front and center we'll see for a very long time. Honestly, I don't think I'll ever create my own general-purpose language precisely _because_ I already know languages that are perfectly tailored to my use. If I start thinking of "what would my dream language look like", I start mentally re-creating Python. And sometimes, I might be in a different mood, and I'll think "wait, I'll make a statically-typed, AOT version of Python that I can use as a systems programming language instead of C/C++", and I end up mentally re-creating Nim, even to the point of going "well, I'll borrow the static typing part from Modula-3 because Modula-3 is cool and Python has a lot of Modula-3 in it already...", which is basically what Nim did.

estava 11y ago

Indeed. That may mean fewer opportunities for "meta-programming" if by meta-programming we mean mutation of core structures. It could also be a good chance to turn around the default of declaring variables to declaring constants instead. Complex data structures would still have to be mutable by default I guess, but they would be the obvious next target to becoming immutable by default.

eru 11y ago
Why would your complex data structures be mutable? Wouldn't immutability pay off especially in complex cases?
- cillian64 11y ago
  If you make my huge NumPy arrays immutable, I will be very unhappy (unless I am significantly misunderstanding how this everything-is-immutable strategy works). There might be a lot to be said for rust-style immutable-by-default.
  - juliangregorian 11y ago
    I assume using some form of copy-on-write.
  - eru 11y ago
    First, you'd still have optional mutability. Second, arrays are rather simple data structures, but ones where you often care about performance--small tight loops are common. Compare that to the data structure that eg holding your options and flags for the computation: you don't do much computation on that, but you have lots of invariants that you want to uphold---ie lots of code, but each bit executed roughly once, no tight loops.
- DasIch 11y ago
  Algorithms on immutable data structures tend to have very bad worst case peformance.
  - zeckalpha 11y ago
    Naïve algorithms on immutable data structurs tend to have very bad worst case performance.
    - eru 11y ago
      And there would always be the optional mutability. Your complex data structures are seldom the ones driving performance. Ie often you have to get the complex data structures right (lots of logic, not much computation) to set up your computations on the simple ones (eg lots of number crunching on your arrays).
      - zeckalpha 11y ago
        Yes, it's easier to reason about correctness in immutability land and add mutability in after the fact as a compiler optimization than to remove mutability for safety as a compiler pass.
        eru 11y ago
        Haskell sort-of does this. Laziness can be seen as a very disciplined form of mutability. (Haskell also allows mutability that is visible to the semantics of the program, that's where the famous monads come in.)

bitL 11y ago

In other words you'd make it slow without the ability to allow it to be fast.

porker 11y ago
Is that true? It doesn't match many of the comments on HN around React, Om, Clojure etc...
- bitL 11y ago
  Yes, it is slow. Immutability is allowing you to write elegant concurrent algorithms at the expense of speed and memory. Imagine you are forced to never change an array of numbers for an algorithm computing matrices, rather creating new matrices for each step and specifying numbers only during initialization. But hey, you can cache them and keep track of every single copy without any confusion now! Now imagine a non-concurrent language like JavaScript - what exactly are you going to get by using immutable structures except for the feeling you are going with the times? Reference counting and caching are probably the only areas where immutability can help for most programs. Immutability is in fashion nowadays due to functional programming being in fashion despite the inability to ever achieve "pure" functional programming in reality - I/O is by default "dirty" (I really hate these charged words in computing), no amount of flatmapping (i.e. monads) is going to help with that.
  - porker 11y ago
    Thanks, that's a great answer and helps me understand. I guess there are subsets of problems where immutability is a good idea (anything needing state, 'Undo' capabilities), neutral, and a bad idea (number crunching, data processing, 'traditional'(??) programming). I have been wowed by the beauty of the immutable approach in web apps, but definitely subscribe to the right technique for a task. I can't imagine doing the data processing in physics using an immutable language...
    - bitL 11y ago
      Indeed it boils down to what you need to achieve. You might want to use both approaches and combine them for best performance/readability. There are specialized high-performance structures that are mutable (e.g. disruptor in HFT trading) optimizing all the way down to CPU cache lines to achieve unbelievable speeds, yet they work nicely if the objects they refer to are immutable. So just take all advices to switch to immutability with a grain of salt and learn to figure out which approach is suitable for what part of your system to have it both performing well and being able to conceptualize and maintain the code nicely ;-)

amyjess 11y ago

Honestly, I found that kind of disappointing, because one of the things I like most about Python is its metaprogramming capabilities. I'm honestly not fond of languages like Rust that try to restrict mutability. The only one of the new breed of languages I've found that I really like is Nim.

ptx 11y ago
Doesn't Nim go a bit too far in that direction, though? Mutable strings seems a bit dangerous to me – won't you have to copy them all the time to make sure they don't get modified somewhere else?

marcosdumay 11y ago

Let's just keep in mind that the entire reason languages with immutable data are trending is because we already have all those languages with mutable data to use where they are fit. A new language today shouldn't really implement Python metaprogramming, because Python already does that.

amyjess 11y ago
Yes, and I think the reason why Nim got so much attention was because it filled the niche of metaprogramming in a statically-typed, AOT language, which is probably the last frontier of mutability and metaprogramming. It's probably the last major new language with metaprogramming front and center we'll see for a very long time. Honestly, I don't think I'll ever create my own general-purpose language precisely _because_ I already know languages that are perfectly tailored to my use. If I start thinking of "what would my dream language look like", I start mentally re-creating Python. And sometimes, I might be in a different mood, and I'll think "wait, I'll make a statically-typed, AOT version of Python that I can use as a systems programming language instead of C/C++", and I end up mentally re-creating Nim, even to the point of going "well, I'll borrow the static typing part from Modula-3 because Modula-3 is cool and Python has a lot of Modula-3 in it already...", which is basically what Nim did.