Re: OOP and memory management

From: goose (ruse_at_webmail.co.za)
Date: 06/28/04 

Date: 28 Jun 2004 04:24:40 -0700

Calum <calum.bulk@ntlworld.com> wrote in message news:<cbjkck$smd$1@newsg1.svr.pol.co.uk>...
> goose wrote:
>
> > "Thomas G. Marshall" <tgm2tothe10thpower@replacetextwithnumber.hotmail.com> wrote in message news:<uZGCc.2600$L8.2545@nwrdny02.gnilink.net>...
> >
> > <snipped>
> >
> >>You don't see how easy it is to program something when you don't have to
> >>worry about deallocation?
> >>
> >>Sure, you can bind up periodically. But having to worry a few times about
> >>GC congestions is certainly a great trade for not having to worry about
> >>every little allocation.
> >>
> >>Think of all the potential bugs that can occur from a tirade of malloc's,
> >>not from being a dope, but from being human.
> >
> >
> > The problem, from my viewpoint, is not whether or not GC is a
> > good thing to have (it is, right?), but whether the programmer
> > who /needs/ it is a good one to hire.
> >
> > The are more resources that a single program must manage
> > than just memory. Memory allocation/deallocation just happens
> > to be the easiest to manage.
> >
> > Cleaning up after yourself (especially if writing a library)
> > cannot be stressed enough. Unfortunately, reliance on GC for
> > new programmers just means that they never get any experience
> > managing resources properly. No language should /force/ the
> > programmer to rely on GC as this just means that programmers
> > will get forgetful about resource management.
> >
> > all memory allocated must be deallocated.
> > all files opened must be closed.
> > all network connections opened must be terminated.
> > all threads/tasks started must be ended.
> > all temporary files must be deleted.
> >
> > It goes even further when you are managing physical
> > resources, as then you would have to manage creating
> > and deleting queues (think printer spools), or
> > even as far as multiplexing a single ADC channel
> > between n inputs (think about the latency inherent
> > in switching a piece of wire between various
> > sources, and taking the capacitance into account).
> >
> > Not managing memory is the slippery slope of the thin
> > end of the wedge. The programmer who does not learn
> > to manage memory efficiently is not much use other
> > than as a code grunt. When all we have left are languages
> > that dont let the new programmer learn some very important
> > concepts (which hopefully wont be soon), then we must
> > not complain when we get second-rate programmers.
>
> Interesting... I think that there is a generational thing going on here:
> any tool that makes life "too easy" is not "proper programming".

I never said nor implied that. Read above where I said that the language
should not /force/ one to use GC.

> I
> expect people who have used card feeders smirk at how easy us people
> with hard disks have it.
>
> Personally I feel very lucky to have been able to program on a ZX81 with
> a wobbly RAM-pack, or to scratch my head over random segmentation faults
> in C. Kids of today have it far too easy! (and I'm only 30 ;-) It
> makes you realize how much you can achieve with so little by not
> squandering resources. I too feel that people who have not experienced
> this have missed out, are not so careful with resources, and have no
> motivation or ability to write tight code.
>
> The down-side is to not accept new technologies when they do offer
> improvements. Making life easy is a good thing. Make kids learn C,
> since then they'll actually see how a language executes, and then
> they'll appreciate the newer language features. Unfortunately you
> really need to get your hands dirty to really get to grips with a
> language, so the art of programming as we romantically remember it may
> be a dying art.
>
> But like snaring rabbits or building a dry-stone wall, these skills may
> not be necessary in the future??
>

I really doubt that resource management is not necessary for the future.
/Just maybe/ we can get away with having automatic memory management,
but the whole point of using a machine to do hundreds of calculations
and lookups per second is to streamline our resources.

Programmers who think that they need not have any ability managing
resources are going to be just as piss-poor at writing software as those
that think that theres no need to learn arithmetic.

Once again, I dont think that GC is bad (anymore:-), I think that a
language that *forces* one to use GC (and there are quite a few of those)
is going to have naturally poor programmers.

goose,

Relevant Pages

  • Re: Confused about gcnew and object lifetime
    ... It's a different story when those programmers later go to an unmanaged environment, ... Being sloppy there means scarce system resources may remain locked indefinitely. ... In fact, in ..NET you can't deallocate memory, only the system can, but you still MUST deallocate resources. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: How come Ada isnt more popular?
    ... bother with *manual* memory management neither. ... Today manual memory management is a low-level thingy that you don't have to care about, unless you *really* want to. ... The problem is that few programs rely on only memory and in a typical case there are lots of resources that are not memory oriented and they have to be managed, ... When GC is a shiny center of the language, those other kinds of resources suffer from not having appropriate support. ...
    (comp.lang.ada)
  • Re: Why do some people hate java?
    ... programming language like Java to exist, or if Java must exists, there's ... The majority of programmers at the time were using C++, ... and other resources that are just as important to ...
    (comp.lang.java.programmer)
  • Re: Why do some people hate java?
    ... C++ templates can do some things that Java generics can not. ... memory is the only resource that must be managed. ... and other resources that are just as important to ... To the extent that the language ...
    (comp.lang.java.programmer)
  • Re: One resource file per CDialog or VSS solution
    ... Tom: We have about 200 dialogs and a very short delay to produce this big ... Another possible clash is if both programmers create a dialog ... The first part of the solution to this problem is to **checkin resources as ... there is an easy solution: Allocate a string id range to each ...
    (microsoft.public.vc.mfc)