mcartyem

(thank you for the willingness to write such a detailed response)

There exists a point on the memory management continuum where management starts being more automatic (gc) than manual (malloc/free). I would like to understand the forces surrounding this specific point, right before the scale tips towards automatic.

If you tried to build a dynamic language without automatic management, what would break and why?

There have been a lot of posts related to garbage collection lately but none of them touched upon what I see as a crucial issue: why is garbage collection needed to begin with?

Could you do without it? What is the key point that made it necessary?

I'm aware of it being introduced by McCarthy in the original Lisp paper in 1960 of course. But I suspect what McCarthy originally meant is not what garbage collection turned out to be. What I suspect he meant was that there needs to be a way for memory to be managed. malloc/free offer a way for memory to be managed, and presumably they weren't invented until C was nine years later. What McCarthy might have meant is what became malloc/free in C, which doesn't need garbage collection.

C isn't the only flag here. Was there any OS on the IBM 704 used to implement the original Lisp? Did the OS support multiprocessing? Because if it didn't (UNIX wasn't invented until 1969 either) it would make sense for memory to be available for a single process. And it would mean when people said garbage collection they were envisioning malloc/free.

(Also, databases and operating systems can live without whatever makes garbage collection necessary, since they don't use it, and those are pretty complex and fast pieces of software.)

So, what makes garbage collection different than malloc/free, and why is it necessary? I'd love to learn more about that.

What about it is a nightmare?

Isn't storing, tracking, and managing billions of entries done directly in a database anyway?

This might be a silly thing to ask, but why don't they save their data in flat files on a shared filesystem?

They wouldn't need Memcached, since the OS caches files anyway; replication with rsync becomes easy; they don't need transactions anyway; and they wouldn't have so much software to manage.

This is great research, thank you.

The word innovator might be ill-suited to support the argument that mastery generally takes time.

For example physicists and mathematicians do their best work in their early twenties. Arguably they get worse with age.

Many jobs are crappy because companies want guarantees. They would rather have peace of mind that things are moving at a known rate compared to any risk of uncertainty.

The jobs are not necessarily crappy because companies are interested in keeping wages down. Companies are more interested in boosting profits compared to keeping wages down.

The humorous part is so many jobs continue to remain crappy even when you make a boss look good by generating orders of magnitude more value than he bargained for when hiring you.

Even if you explained to the boss how you could generate such value at the time of hire, they still wouldn't be able to assimilate it's possible. They don't see how one can generate such much value, even when you present plans on how it can be done.

It's as if the boss is trying hard not to let you generate more value than expected.

How about: what's the most important thing people refuse to accept?

Mine is compilers. Which is another way of saying: automating; reducing the work I have to do manually.

I have a question about it: can anyone tell how it deals with redundancy?

It seems to be distributed. If you are running Plan 9 on 3 machines, and one goes down, what happens to the rest of the system. Does it become unavailable?