How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?
joshuamaurice at gmail.com
Wed Aug 25 23:01:49 CEST 2010
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
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.".
More information about the Python-list