Garbage collection and manual memory management both have their places. Saying that "it's now year 20xx, why is manual memory management even still a thing" is akin to saying "640KB is more than we'll ever need." It's short sighted and shows a lack of understanding. <div>
<br></div><div>I like a good scripting language as much as anyone. In fact, JavaScript might just be my favorite language. But,<span></span> even when scripting, you should be aware of how you are, or think you are, using the memory. If you go around creating global variables all the time because ou don't like dealing with scope, then you're going to exhaust your memory limits pretty dern quick. Likewise, if you write your code in such a fashion that it is clear, even to humans, when your memory objects should be freed, then your program will be much more efficient.</div>
<div><br></div><div>That's why you should care about memory management. And also, that's why you should understand how the interpreter, or virtual machine/runtime, for your chosen language handles your memory allocations. <br>
<br>On Monday, March 25, 2013, Ron Frazier (ALE) wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
James Sumners <<a href="javascript:;" onclick="_e(event, 'cvml', 'james.sumners@gmail.com')">james.sumners@gmail.com</a>> wrote:<br>
<br>
>On Mon, Mar 25, 2013 at 6:48 PM, Ron Frazier (ALE)<br>
><<a href="javascript:;" onclick="_e(event, 'cvml', 'atllinuxenthinfo@techstarship.com')">atllinuxenthinfo@techstarship.com</a>> wrote:<br>
>> Actually, in the 21st century, I believe the programmer should NEVER<br>
>have to think about things like memory allocation ... EVER!<br>
><br>
>There's no chance you're going to see eye-to-eye with pretty much any<br>
>programmer that reads this list. [1] is basically about the dangers of<br>
>glossing over these sorts of topics (i.e. not learning them/using<br>
>them).<br>
><br>
>Going back to the original topic, there is only one way learning a<br>
>language is going to be fun -- you have to like the language. For me,<br>
>there's no book ever written, or will be written, that will make<br>
>learning Ruby fun. I hate the language and its conventions. So, Ruby<br>
>appeals to you at a basic level, just pick a project and start working<br>
>on it. That's the only real way to learn it.<br>
><br>
>N.B. when I say "learning a language" I mean the standard library<br>
>and/or framework(s). Learning the syntax and constructs is easy.<br>
><br>
>[1] --<br>
><a href="http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html" target="_blank">http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html</a><br>
><br>
><br>
>--<br>
>James Sumners<br>
><a href="http://james.roomfullofmirrors.com/" target="_blank">http://james.roomfullofmirrors.com/</a><br>
><br>
>"All governments suffer a recurring problem: Power attracts<br>
>pathological personalities. It is not that power corrupts but that it<br>
>is magnetic to the corruptible. Such people have a tendency to become<br>
>drunk on violence, a condition to which they are quickly addicted."<br>
><br>
>Missionaria Protectiva, Text QIV (decto)<br>
>CH:D 59<br>
<br>
Hi James,<br>
<br>
I certainly didn't mean any offense by my statements and I'm sorry you hate Ruby. I'll admit my experience is limited and some of my points of view might be wrong, or obsolete. I guess the only way to really know if I love or hate Ruby is to work with it for a while.<br>
<br>
I appreciate the link you sent and will look at it later.<br>
<br>
My main point about memory allocation is this. I've programmed a number of high level languages in my life, mostly in academic settings. Those include basic, pascal, and delphi. I spent several years programming clipper for Delta Air Lines. None of these languages even HAD commands for tinkering with memory, as far as I know. I just built the program and the compiler / linker / interpreter figured out what to do with the variables I used.<br>
<br>
I have (had) the most knowledge of clipper, so I'll comment about it. As a programmer, I just opened the dbase style table on the LAN server and went about searching it or adding records to it. No doubt, the database engine (which was likely written in C) had to worry about memory allocation and had to figure out where it would stuff the data from the table that I wanted to access. But I, as an applications programmer, did not. I just manipulated the file, and it just worked.<br>
<br>
What I did have to worry about was variable scope. The way clipper worked, the variables had a scope of whatever element they were declared in. There were a couple of variations on the way you could declare them. But, essentially, if I declared a variable in the main startup function, it would live as long as the program was running. This was very handy for things that any function might need, such as status indicators, login credentials, system time, etc. On the other hand, variables declared in a subroutine were visible only to that routine. If I created something named UserName in a report printing routine, once that routine exited, that variable was no longer accessible. I did create some data warehousing routines with static variables which were persistent, in case one subroutine needed to save some data that other routines would have access to. The data warehousing module I built had function calls which allowed any routine in the program to add, change, and de!<br>
lete name value pairs to / from this internal database. It was kind of like an internal temporary registry.<br>
<br>
Now, I'll admit I never used recursive function calls, which could get ugly memory wise. But, as I said, the application language never even gave me commands to tinker with memory. So I never did. I presume the compiler and linker figured out how and when I would need to allocate memory and deallocate it based on the variable allocation and scoping.<br>
<br>
For the most part, I don't see why that isn't just the way things are done.<br>
<br>
Sincerely,<br>
<br>
Ron<br>
<br>
<br>
<br>
--<br>
<br>
Sent from my Android Acer A500 tablet with bluetooth keyboard and K-9 Mail.<br>
Please excuse my potential brevity if I'm typing on the touch screen.<br>
<br>
(PS - If you email me and don't get a quick response, you might want to<br>
call on the phone. I get about 300 emails per day from alternate energy<br>
mailing lists and such. I don't always see new email messages very quickly.)<br>
<br>
Ron Frazier<br>
770-205-9422 (O) Leave a message.<br>
linuxdude AT <a href="http://techstarship.com" target="_blank">techstarship.com</a><br>
<br>
<br>
_______________________________________________<br>
Ale mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'Ale@ale.org')">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</blockquote></div><br><br>-- <br>James Sumners<br><a href="http://james.roomfullofmirrors.com/">http://james.roomfullofmirrors.com/</a><br><br>"All governments suffer a recurring problem: Power attracts pathological personalities. It is not that power corrupts but that it is magnetic to the corruptible. Such people have a tendency to become drunk on violence, a condition to which they are quickly addicted."<br>
<br>Missionaria Protectiva, Text QIV (decto)<br>CH:D 59<br>