Comment by ttoinou

4 days ago

Is it the future path of any successful JIT / dynamic typed / scripting language to realize they needed all optimizations from compiled / statically typed / lower level languages ?

Would Ruby be as successful if they had all those complicated features right from the start ?

Or do all languages start from a nice simple clean slate tabula rasa to get developers hooked, until the language is enough famous to get well developed and starts to be similar to all others big programming languages ?

I would actually say it’s the opposite in this case: it’s extremely common in scripting languages for strings to be immutable, mutable strings are usually only available in lower level languages. I’m very surprised Ruby had this feature at all.

  • Even in C, string literals are immutable, and mutating them is undefined behavior.

  • But in the syntax of scripting language its very easy to create a new string from the old string, destroy old string, replace variable by new string. Which appears mutable from the point of view of the developer

  • Common Lisp and Smalltalk have mutable strings, I think. So it’s not too surprising that ruby does too, since it was pretty heavily influenced by these languages.

    • Specifically, it's non-literal strings that are mutable. Implementations of either may allow you to modify the literals, but it's likely to break something due to interning. The Common Lisp standard is clear that destructive literal modification is undefined behavior. I believe it's the same in Smalltalk, and I remember you were admonished to never use the direct modification messages (like at:put: or replaceFrom:to:with:) on strings without copying them first.

      5 replies →

    • Amongst the lisps, AutoLISP had the one standout feature that was immutable strings by default. Many other lisps wished they could have that too, esp. for the GC.

  • It’s true that many languages have immutable strings, but for a web-focused scripting language it makes sense to default to mutable strings. I think the comment is about that you now need to choose mutable vs immutable, and that is framed as a consequence of broader adoption. Which is a development I have also seen before.

    • Ruby is a web-focused scripting language in the same sense that Python is an AI-focused scripting language.

      JavaScript is much more of a "web-focused scripting language" than Ruby is, and it is quite happy with immutable strings (only).

      > I think the comment is about that you now need to choose mutable vs immutable, and that is framed as a consequence of broader adoption.

      Ruby has also had immutable (frozen) strings for a very long time, so you've always had the choice. What is changing is that string literals are (eventually) going to migrate from "mutable with a strong-encouraged file level switch to make them immutable" to "immutable".

    • > for a web-focused scripting language

      Ruby is not a web focused scripting language.

  • Mutable strings were part of the perl heritage, which was one of the direct ancestors for ruby.

> all optimizations from compiled / statically typed / lower level languages

Mutable strings are totally possible (and not even especially hard) in compiled, statically typed, and lower-level languages. They're just not especially performant, and are sometimes a footgun.

> all those complicated features right from the start

Arguably, mutable strings are the more complicated feature. Removing them by default simplifies the language, or at least forces you to go out of your way to find the complexity.

  • Its not about possible / not possible its about what the language does by default and how language syntax changes to switch between different variants of strings

  • > They're just not especially performant

    What? Mutable strings are more performant generally. Sometimes immutability allows you to use high level algorithms that provide better performance, but most code doesn't take advantage of that.

    • Not in general. Immutable strings can be deduplicated, leading to a different performance tradeoff that is often quite good. This is mentioned in TFA.

      4 replies →