How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

[Joshua Maurice]

On Aug 25, 1:44 pm, John Passaniti <john.passan... at gmail.com> wrote:
> On Aug 24, 9:05 pm, Hugh Aguilar <hughaguila... at yahoo.com> wrote:
>
> > What about using what I learned to write programs that work?
> > Does that count for anything?
>
> It obviously counts, but it's not the only thing that matters.  Where
> I'm employed, I am currently managing a set of code that "works" but
> the quality of that code is poor.  The previous programmer suffered
> from a bad case of cut-and-paste programming mixed with a
> unsophisticated use of the language.  The result is that this code
> that "works" is a maintenance nightmare, has poor performance, wastes
> memory, and is very brittle.  The high level of coupling between code
> means that when you change virtually anything, it invariably breaks
> something else.
>
> And then you have the issue of the programmer thinking the code
> "works" but it doesn't actually meet the needs of the customer.  The
> same code I'm talking about has a feature where you can pass message
> over the network and have the value you pass configure a parameter.
> It "works" fine, but it's not what the customer wants.  The customer
> wants to be able to bump the value up and down, not set it to an
> absolute value.  So does the code "work"?  Depends on the definition
> of "work."
>
> In my experience, there are a class of software developers who care
> only that their code "works" (or more likely, *appears* to work) and
> think that is the gold standard.  It's an attitude that easy for
> hobbyists to take, but not one that serious professionals can afford
> to have.  A hobbyist can freely spend hours hacking away and having a
> grand time writing code.  Professionals are paid for their efforts,
> and that means that *someone* is spending both time and money on the
> effort.  A professional who cares only about slamming out code that
> "works" is invariably merely moving the cost of maintaining and
> extending the code to someone else.  It becomes a hidden cost, but why
> do they care... it isn't here and now, and probably won't be their
> problem.

I agree. Sadly, with managers, especially non-technical managers, it's
hard to make this case when the weasel guy says "See! It's working.".