By "fundamentals," strlen means "memory management," "pointers," the gritty stuff. You can't escape memory management by using Ruby and Python, and a rudimentary understanding of pointers are also essential.
a = ["Hello", "World"]
b = a
b[0] = "Goodbye"
print a
The first time I tried this, I was baffled why ["Goodbye", "World"] showed up. The answer lied in the way this scripting language used pointers, and it wasn't until I learned C that I really understood that.
As for memory management, I often accidentally write scripts that use gobs of memory thanks to silly mistakes; e.g. not using weak references when I should (oh look, more pointers!), creating new objects instead of reusing old ones , forgetting to unregister event handlers in my nodejs apps, etc. C's "every malloc() must be free()d" policy teaches these things to you in a very explicit way. Sometimes you have to clean things up when your scripting runtime doesn't know it should.
Even after using python for many years, I still occasionally make this mistake. It is a tough "bug" to track down. Can anyone comment as to why deep-copy is not the norm?
def f(b):
b[0] = 'Goodbye'
a = ['Hello', 'world']
f(a)
It's more efficient to pass function arguments by reference, and it would be fairly baffling if function argument passing did not work like assignment (c.f. C++ copy construction being similar to, but slightly distinct from, assignment).
Less philosophically, everything in Python has pass-by-reference semantics, even ints. The things you might think are passed by value are immutable, so it doesn't really matter whether they are passed by value or by reference. For example:
a = 1
a = a + 1
conceptually creates a new integer object and binds the name a to it, and so does
Simply because it is slow. In the GP's example if a was a much bigger array, copying it over to b would be expensive. On a related note, in C++ for many containers (if not all) in the standard library, copying is the norm; in "The C++ Programming Language" Bjarne Stroustrup warns that it may be slow.
As for memory management, I often accidentally write scripts that use gobs of memory thanks to silly mistakes; e.g. not using weak references when I should (oh look, more pointers!), creating new objects instead of reusing old ones , forgetting to unregister event handlers in my nodejs apps, etc. C's "every malloc() must be free()d" policy teaches these things to you in a very explicit way. Sometimes you have to clean things up when your scripting runtime doesn't know it should.