4 ms·

For comparaison, Ruby 3 is gonna introduce a pretty big breaking change (frozen string literals) but they already shipped a way to optional enable it by-file (m

by dorianm 10y ago

For comparaison, Ruby 3 is gonna introduce a pretty big breaking change (frozen string literals) but they already shipped a way to optional enable it by-file (magic comment) and globally to the ruby interpreter (just a parameter) so that all the libraries and projects can slowly fix it in a compatible manner (often just calling .dup is enough). So that's when it's time for Ruby 3 the transition will be pretty painless. More info: https://wyeworks.com/blog/2015/12/1/immutable-strings-in-ruby-2-dot-3 https://wyeworks.com/blog/2015/12/1/immutable-strings-in-rub... (Frozen string literals allows strings to be in memory only once and not having to reallocate each time, so a pretty big memory and cpu optimization) (Also for instance rubocop already recommends adding the magic comment to all ruby files)

uiri 10y ago
(Frozen string literals allows strings to be in memory only once and not having to reallocate each time, so a pretty big memory and cpu optimization) Isn't this the purpose of symbols in the language? This seems like a pretty basic optimization, surely there were good reasons not to introduce it in earlier versions.
- dorianm 10y ago
  e.g. 1000.times { "hello" } creates strings 1000 times but: 1000.times { "hello".freeze } only one time. The thing about frozen strings is they can't be changed "inline": e.g. : "Hello".freeze << " world" doesn't work but "Hello".freeze + " world" does because it creates a new string. (It's funny because << is often recommended as an optimization)
maxerickson 10y ago
Magic imports from __future__ are the usual way of turning on features in Python. The incompatibilities introduced in Python 3 weren't done that way to save on implementation effort among other reasons.
- dorianm 10y ago
  Maybe python2 --enable-print-parentheses and other flags could have been useful to slowly detect future issues on python 2 code.
  - maxerickson 10y ago
    Python 2.6 has from __future__ import print_function. There the saving of implementation effort would be not supporting print statements in 3.0.
    - dorianm 10y ago
      Nice it actually gives "SyntaxError: invalid syntax", but then it affects all the imported libraries so I still prefer the per-file way as a transition.
      - ambivalence 10y ago
        __future__ imports are per file. A few posts up you were proposing an interpreter-wide switch. Did you change your mind?
        dorianm 10y ago
        Awesome. I think both are great, first doing file-per-file and once it's working switching the global switch is a pretty good transition workflow.
eveningcoffee 10y ago
This is a quite good example about myself. After I realized that too many people around Ruby do not understand the concept of immutability, I stopped to care about the whole ecosystem around it. If this catches up, it is worth to give the Ruby a fresh look.
- dorianm 10y ago
  There are a few immutability options, for instance Hamster: https://github.com/hamstergem/hamster/blob/core/README.md https://github.com/hamstergem/hamster/blob/core/README.md

by dorianm 10y ago

uiri 10y ago

(Frozen string literals allows strings to be in memory only once and not having to reallocate each time, so a pretty big memory and cpu optimization) Isn't this the purpose of symbols in the language? This seems like a pretty basic optimization, surely there were good reasons not to introduce it in earlier versions.

dorianm 10y ago
e.g. 1000.times { "hello" } creates strings 1000 times but: 1000.times { "hello".freeze } only one time. The thing about frozen strings is they can't be changed "inline": e.g. : "Hello".freeze << " world" doesn't work but "Hello".freeze + " world" does because it creates a new string. (It's funny because << is often recommended as an optimization)

maxerickson 10y ago

Magic imports from __future__ are the usual way of turning on features in Python. The incompatibilities introduced in Python 3 weren't done that way to save on implementation effort among other reasons.

dorianm 10y ago
Maybe python2 --enable-print-parentheses and other flags could have been useful to slowly detect future issues on python 2 code.
- maxerickson 10y ago
  Python 2.6 has from __future__ import print_function. There the saving of implementation effort would be not supporting print statements in 3.0.
  - dorianm 10y ago
    Nice it actually gives "SyntaxError: invalid syntax", but then it affects all the imported libraries so I still prefer the per-file way as a transition.
    - ambivalence 10y ago
      __future__ imports are per file. A few posts up you were proposing an interpreter-wide switch. Did you change your mind?
      - dorianm 10y ago
        Awesome. I think both are great, first doing file-per-file and once it's working switching the global switch is a pretty good transition workflow.

eveningcoffee 10y ago

This is a quite good example about myself. After I realized that too many people around Ruby do not understand the concept of immutability, I stopped to care about the whole ecosystem around it. If this catches up, it is worth to give the Ruby a fresh look.

dorianm 10y ago
There are a few immutability options, for instance Hamster: https://github.com/hamstergem/hamster/blob/core/README.md https://github.com/hamstergem/hamster/blob/core/README.md