4 ms·

This is silly. The semantics are entirely different!

phoronixrly 11mo ago
How so? Quite literally symbols are used as an immutable string with a shorter syntax. So much so that I've been finding their literal constraints limiting lately.
- giraffe_lady 11mo ago
  Almost the entire value of symbols separate from strings is at the level of programmer communication rather than PL semantics. It tells a reader of the code that this term is arbitrary but significant, probably represents an enmeshment with another part of the code, and will not be displayed to any user. When seeing a new term in code that is a lot of the things you're going to need to figure out about it anyway. It's a very valuable & practical signal. If you need to mutate or concat or interpolate or capitalize or any other string operation it, it probably shouldn't be a symbol anymore, or shouldn't have been to start with.
  - masklinn 11mo ago
    > Almost the entire value of symbols separate from strings is at the level of programmer communication rather than PL semantics. That's the opposite of reality. Symbols are necessitated by PL semantics, which is why languages which don't have those problematic string semantics tend to not bother with symbols. > It tells a reader of the code that this term is arbitrary but significant That you can do that with symbols is not why they exist (you can need to associate additional semantics with pretty much any first or third-party type after all, that's why the newtype pattern is so popular in modern statically typed languages). And it's not like you need formal symbols to do it in the first place. For instance like an other nearby commenter in Python I do that by using single and double-quoted strings, having taken up that habit from Erlang (where symbols are single quoted and strings are double quoted).
    - giraffe_lady 11mo ago
      > And it's not like you need formal symbols to do it in the first place. I mean we don't need any of this shit. Go take a long bath and then write some assembly I don't care. Symbols are a useful tool in some languages, for the reasons I described. That you're creating ad hoc quoting conventions to recover part of the functionality of this feature in languages that don't have it is a pretty strong signal I'm correct! Opposite of reality my ass lol.
masklinn 11mo ago
> This is silly. Oh my bad, great counterpoint. > The semantics are entirely different! They're not. A symbol is an arbitrary identifier, which can be used to point to system elements (e.g. classes, methods, etc...). These are all things you can do just fine with immutable interned strings. Which is exactly what languages which have immutable interned strings do. You'd just have a broken VM if you used mutable strings for metaprogramming in Ruby, so it needs symbols. Both things it inherited from all of Perl, Smalltalk, and Lisp.
- byroot 11mo ago
  Ruby always had immutable (frozen) strings, so no, this never was a reason for Symbols existence.
  - dragonwriter 11mo ago
    They aren't interned frozen strings (unless they were symbols; String#intern was, and still is, an alias for String#to_sym, and String#freeze did not and does not imply String#intern or String#to_sym), and it also (even for literals) took an extra step to either freeze or intern them prior to Ruby 2.3 introducing the "# frozen_string_literal: true" file-level option (and Ruby 3.4 making it unnecessary because it is on by default.) Amusingly, string literals interned by default in 3.4 or because of the setting in earlier >2.3 Rubies are still (despite being interned) Strings, while Strings interned with String#intern are Symbols.
    - byroot 11mo ago
      > They aren't interned frozen strings Doesn't matter. The parent claim was: > You'd just have a broken VM if you used mutable strings for metaprogramming in Ruby From day one it was possible to freeze strings used in metaprograming. I mean Ruby Hashes do that to strings keys. > Ruby 3.4 making it unnecessary because it is on by default. That's incorrect: https://byroot.github.io/ruby/performance/2025/10/28/string-literals.html https://byroot.github.io/ruby/performance/2025/10/28/string-...

How so? Quite literally symbols are used as an immutable string with a shorter syntax. So much so that I've been finding their literal constraints limiting lately.

giraffe_lady 11mo ago
Almost the entire value of symbols separate from strings is at the level of programmer communication rather than PL semantics. It tells a reader of the code that this term is arbitrary but significant, probably represents an enmeshment with another part of the code, and will not be displayed to any user. When seeing a new term in code that is a lot of the things you're going to need to figure out about it anyway. It's a very valuable & practical signal. If you need to mutate or concat or interpolate or capitalize or any other string operation it, it probably shouldn't be a symbol anymore, or shouldn't have been to start with.
- masklinn 11mo ago
  > Almost the entire value of symbols separate from strings is at the level of programmer communication rather than PL semantics. That's the opposite of reality. Symbols are necessitated by PL semantics, which is why languages which don't have those problematic string semantics tend to not bother with symbols. > It tells a reader of the code that this term is arbitrary but significant That you can do that with symbols is not why they exist (you can need to associate additional semantics with pretty much any first or third-party type after all, that's why the newtype pattern is so popular in modern statically typed languages). And it's not like you need formal symbols to do it in the first place. For instance like an other nearby commenter in Python I do that by using single and double-quoted strings, having taken up that habit from Erlang (where symbols are single quoted and strings are double quoted).
  - giraffe_lady 11mo ago
    > And it's not like you need formal symbols to do it in the first place. I mean we don't need any of this shit. Go take a long bath and then write some assembly I don't care. Symbols are a useful tool in some languages, for the reasons I described. That you're creating ad hoc quoting conventions to recover part of the functionality of this feature in languages that don't have it is a pretty strong signal I'm correct! Opposite of reality my ass lol.

masklinn 11mo ago

> This is silly. Oh my bad, great counterpoint. > The semantics are entirely different! They're not. A symbol is an arbitrary identifier, which can be used to point to system elements (e.g. classes, methods, etc...). These are all things you can do just fine with immutable interned strings. Which is exactly what languages which have immutable interned strings do. You'd just have a broken VM if you used mutable strings for metaprogramming in Ruby, so it needs symbols. Both things it inherited from all of Perl, Smalltalk, and Lisp.

byroot 11mo ago
Ruby always had immutable (frozen) strings, so no, this never was a reason for Symbols existence.
- dragonwriter 11mo ago
  They aren't interned frozen strings (unless they were symbols; String#intern was, and still is, an alias for String#to_sym, and String#freeze did not and does not imply String#intern or String#to_sym), and it also (even for literals) took an extra step to either freeze or intern them prior to Ruby 2.3 introducing the "# frozen_string_literal: true" file-level option (and Ruby 3.4 making it unnecessary because it is on by default.) Amusingly, string literals interned by default in 3.4 or because of the setting in earlier >2.3 Rubies are still (despite being interned) Strings, while Strings interned with String#intern are Symbols.
  - byroot 11mo ago
    > They aren't interned frozen strings Doesn't matter. The parent claim was: > You'd just have a broken VM if you used mutable strings for metaprogramming in Ruby From day one it was possible to freeze strings used in metaprograming. I mean Ruby Hashes do that to strings keys. > Ruby 3.4 making it unnecessary because it is on by default. That's incorrect: https://byroot.github.io/ruby/performance/2025/10/28/string-literals.html https://byroot.github.io/ruby/performance/2025/10/28/string-...