Comment by masklinn
6 hours ago
OP is really tying themselves into knots.
Symbols are special cased pseudo-strings for langages which have either extremely inefficient strings (erlang) or mutable ones (ruby). That’s about the extent of it.
Python or Java don’t really have a use for them because their strings are immutable, and likely interned when metaprogramming is relevant (e.g. method or attribute names).
Symbol is the only feature I miss after switching to Python. It makes code so much more readable to distinguish keys and normal strings.
Much like yccs27 above, I do that using single and double quoted strings (a habit I got from Erlang).
Whenever Perl encounters a string literal in the code (especially one used as a hash key or a bareword), it often "interns" it. This means it stores a single, canonical, read-only copy of that string in a memory pool.
That's the core idea, and then Ruby has surface stuff like the symbol syntax and class. I'm pretty sure it's fine to use strings as hash keys though if you like.
Could not read OP, clownflare is down.
> Symbols are pseudo-strings
Can guess by LISP: Symbols reside in the symbol table, which is global scope. Strings reside in the variable tables, subject to local scope.
It is two different storage mechanisms
> inefficient strings
Ruby does not care for efficiency, so there is no point to argue for symbols vs string performance
> Ruby does not care for efficiency, so there is no point to argue for symbols vs string performance
Symbols existed entirely for performance reasons and were once never GC'd: this is absolutely Ruby "car[ing] for efficiency."
Today, Ruby's Symbol is GC'd (and is much closer to 'String' in practicality) but still has enormous impacts on performance.
> It is two different storage mechanisms
An irrelevant implementation detail. Interned strings are also stored globally, and depending on implementations interned strings may or may not be subject to memory reclaiming.
> Ruby does not care for efficiency, so there is no point to argue for symbols vs string performance
Which is why Ruby's having symbols is associated with mutable strings, not inefficient strings.
And there's a gulf between not caring too much about efficiency and strings being a linked list of integers, which is what they are in Erlang.
What about LISPs? They have atoms too.
Generally mutable strings there too, like Ruby
This is silly. The semantics are entirely different!
> 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.
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.
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.
2 replies →
That’s really not true for Lisp.
Ruby, like its predecessor Perl, is one of the finer examples of Greenspunning and shows a lot of Lisp influence.
Unfortunately I can’t read the actual submission right now due to the cloudflare outage.
> That’s really not true for Lisp.
It's completely true of lisp. Lisp strings are generally mutable (although literal strings may be interned and non-mutable, or even worse mutation of literal strings may be UB). Same for Smalltalk.
OP here, you can read it here https://github.com/stonecharioteer/tech-blog/blob/main/conte...