"'Hood JS"


#1

So in the code

function kebab2Snake(x) {
   return x.replace (/-/g,"_");
}

kebab2Snake("under-the-hood");

it’s said that the string “under-the-hood” isn’t replaced because “strings can never be replaced in JavaScript” because they’re immutable and what’s happening really “under the hood” or “behind the scenes” in this code is that JS makes a copy of the string, outputting the copy – which appears to us as changing the string as intended.

Now why is this even “a thing” – why hold a string in memory and serve out copies of it??

And are there any other examples of this? I’ve heard that variables are also never destroyed – so what else “persists” despite all appearances??

And more generally, any other “under-the-hood” stuff I should know, stuff about how things really work despite appearances onscreen?

THANKS!!!


#2

It’s hard to list out concrete pros and cons of the mutability of different objects
Immutable strings make it easier to make assumptions about the state of a string
It’s a functional way of handling string, transforming to string to another rather than mutating one string

In languages like C you could shoot yourself in the foot
char* ptr = "abc"

An array of characters with length 4 initialized with a character string literal.
You could easily try and modify the array and add more characters than it was intended to hold causing undefined behavior.
Most languages abstract away the programmer dealing with allocating precise memory for strings. Strings are tricky in the sense that they often unknown in size.


#3

Well, okay, but how’s it an advantage to hold a string in memory when the intention is for it to be changed??

I mean, it’s as if these things had immortal souls, where x is in some sense always its original value due to string immutability…talk about ye olde “ghost in the machine!”

I don’t get it and I guess I’ll just have to google further. Thanks, though!


#4

The string is not held in memory. The function returns a new one and gives back all its memory upon exit.

The only place in memory where the string still exists is in the code namespace, written inside the argument list. This is where JavaScript found it.


#5

Wait, what??

Doesn’t everything exist in memory???

I guess there’re different senses of the word “memory” in computer science, then…I’m simply saying that if something’s immutable, it must persist in memory somewhere, right? There’s a record of it – and this record is itself its very “memory”…not to get all philosophy-o-mind here but how can something be in the namespace but not in RAM???

Now you say there’s some kind of argument list which JavaScript refers to…but why should it this list keep a record of all the values of, say, x???


#6

This is called a state, and states change. If it is an active object, yes it will use memory. That has nothing to do with immutability, though, as our friend above stated. It’s the way strings are defined at the machine level. The clock ticks involved in changing allocated memory is immense, and not worth the price for such a lowly object as a string.

All values, any that lose their references are garbage collected. In other words, if we write,

a = "this string"

the value is written to memory. Now if we write,

a = 'some string'

it becomes the value in memory and the old value is queued up for garbage collection and its memory recovered. That value will not have the same slot in memory as the old one, but a new slot. The variable table is updated to point to the new slot.

If more than one variable references the same value, they all point to the same location in memory.

Computers are dumb, and programs do not keep records, that is why we have logging. If there is a reason to keep a record of all the values of x then it is the programmer’s and not the computer’s. But again, logging is how to get that information out to a permanent storage device and out of memory.


#7

Hmmm…so it’s immutable because in order to change it clock cycles would have to be expended to change it and even delete it (is this correct?)…okay, I can see that, then…if that’s what’s really going on: instead of spending “money” to get something repaired, it’s cheaper to just buy a brand new one and trash the broken thing!

Is that a good analogy??? (Dreadful as this throwaway mentality of our consumer society is!)

Interesting! My mind map/mental model of how things work was totally incorrect!

Okay, thanks so much for all this introduction to the JS “'hood!”


#8

HEY, BTW, WHERE CAN I LEARN MORE ABOUT MACHINE-LEVEL OPERATIONS AS THEY RELATE TO JAVASCRIPT???

I mean, as a beginner…like, where it’s written for a beginning student without a CS background…it seems that at least half of my bewilderment comes from not knowing under-the-hood stuff…I’d love it if it were all collected somewhere – and not just mentioned here and there as necessary – and if it were all in beginner-friendly language – and not in some CS textbook…

THANKS A TERRIFICALLY BIG BUNCH!!!


#9

Not really, no. Nothing is trashed. The memory is recovered. The process of allocating memory is like the arrow of time. We can never go back. That is why we have garbage collection to recover memory that is no longer referenced.

In a four year electrical engineering degree program.


#10

Okay: “recycled”??

I don’t really understand why you’re introducing The Second Law of Thermodynamics here (“arrow of time”) WRT memory allocation because we’re talking about memory recovery (I now understand) and while allocation’s obviously related, I don’t see why it’s brought up and thus how the arrow of time relates to anything here.

Forgive me if I’ve lost the thread of our correspondence but it seems like things work this way:

  1. memory is allocated to a variable that’s been assigned a string (two separate acts of memory allocation, meaning two memory addresses, right?)
  2. upon re-assignment of that variable, a different memory address (or two or however many) is allocated for the new value while the old memory address holding the old value is “garbage-collected” and “recovered” and eventually “re-allocated”

Is that right?

You’re joking. Right?

Seriously, with all the damned tutorials and blog posts out there on every little bit of esoterica, no one’s thought to just collect “all the ‘under-the-hood’ CS concepts as they relate to common JS operations for dummies, idiots, and beginners”ever???

Right. I’ll have to do it myself. One day?