[ale] semi [OT] making learning ruby programming fun?

Mon Mar 25 23:12:52 EDT 2013

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.

I like a good scripting language as much as anyone. In fact, JavaScript
might just be my favorite language. But, 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.

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.

On Monday, March 25, 2013, Ron Frazier (ALE) wrote:

>
>
> James Sumners <james.sumners at gmail.com <javascript:;>> wrote:
>
> >On Mon, Mar 25, 2013 at 6:48 PM, Ron Frazier (ALE)
> ><atllinuxenthinfo at techstarship.com <javascript:;>> wrote:
> >> Actually, in the 21st century, I believe the programmer should NEVER
> >have to think about things like memory allocation ... EVER!
> >
> >There's no chance you're going to see eye-to-eye with pretty much any
> >programmer that reads this list. [1] is basically about the dangers of
> >glossing over these sorts of topics (i.e. not learning them/using
> >them).
> >
> >Going back to the original topic, there is only one way learning a
> >language is going to be fun -- you have to like the language. For me,
> >there's no book ever written, or will be written, that will make
> >learning Ruby fun. I hate the language and its conventions. So, Ruby
> >appeals to you at a basic level, just pick a project and start working
> >on it. That's the only real way to learn it.
> >
> >N.B. when I say "learning a language" I mean the standard library
> >and/or framework(s). Learning the syntax and constructs is easy.
> >
> >[1] --
> >http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
> >
> >
> >--
> >James Sumners
> >http://james.roomfullofmirrors.com/
> >
> >"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."
> >
> >Missionaria Protectiva, Text QIV (decto)
> >CH:D 59
>
> Hi James,
>
> 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.
>
> I appreciate the link you sent and will look at it later.
>
> 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.
>
> 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.
>
> 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!
>  lete name value pairs to / from this internal database.  It was kind of
> like an internal temporary registry.
>
> 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.
>
> For the most part, I don't see why that isn't just the way things are done.
>
> Sincerely,
>
> Ron
>
>
>
> --
>
> Sent from my Android Acer A500 tablet with bluetooth keyboard and K-9 Mail.
> Please excuse my potential brevity if I'm typing on the touch screen.
>
> (PS - If you email me and don't get a quick response, you might want to
> call on the phone.  I get about 300 emails per day from alternate energy
> mailing lists and such.  I don't always see new email messages very
> quickly.)
>
> Ron Frazier
> 770-205-9422 (O)   Leave a message.
> linuxdude AT techstarship.com
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org <javascript:;>
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>

-- 
James Sumners
http://james.roomfullofmirrors.com/

"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."

Missionaria Protectiva, Text QIV (decto)
CH:D 59
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20130325/b80b5c22/attachment-0001.html>