Phoenix.pm: Parameter parser

[Hal Goldfarb]

I had started to make a reply to this, but I decided to just surrender 
instead.  I was wrong -- mainly to respond in the first place.

Viva La Bad Code !!!  Create a maintenance job today!

-Hal

On Tuesday 03 December 2002 05:51 pm, you wrote:
> This question is as old as programming.
>
> 3/4 of projects are considered failures - they are obsolete, hopelessly
> over budget, or the market has changed - before they are finished, and
> before the maintenance phase.
>
> Brain Foote, a well spoken and frequently published writer, wrote
> a "big ball of mud" pattern, off of
> http://www.laputan.org/foote/papers.html ...
>
> Java interests me, but I don't enjoy writing it. I've been not enjoying
> writing it for over 6 years now. I also know people who work in exclusively
> as their day job.
>
> * No language does everything, so eventually some sort of "idiom" develops.
> The "Gang of Four" book documents things that don't directly exist in the
> language and require shared knowledge to understand - idioms.
>
> * Developing abstraction in case it is needed in the future leads to code
> bloat and complexity above and beyond what is required by the actual
> problem. The logic of what is done and how it is done is burried in
> thousands of lines of "framework", making it painful to understand an
> application of this sort.
>
> * Making a heavy investment in applications development should not be done
> unless there is a worthy reward. Many Java shops take this backwards: they
> refuse to write throw away-scripts. Obviously the effort put into a program
> should be matched to the expected benefit. I've wittnessed horrible
> personally suffering on the part of programmers that were perfectly capable
> to changing the situation because of strict management policies about the
> creation of code. In Perl-land, throw-away scripts often evolve into
> something more, forming a new source of innovation.
>
> My proposed solution?
>
> * Programmers should be accountable for their own work for works for hire.
> Specifically, trust metrics should be in place to ferret out programmers
> that cause more harm than good on the whole.
>
> * Code should be provided without warrenty included, keeping the business
> of providing warrenties an open possibility. For this to work, either
> vendors would have to make the source available or include the warrenty,
> which is not the case now.  Throw-away scripts should be
> market as exactly that, but should not be done away with because of
> notations that all code should be high quality. Joel, of
> http://www.joelonsoftware.com, states that it takes 10 years to write a
> mature application and gives numerous examples. I agree. That doesn't mean
> that we should banish software to "pre-alpha development" for 10 years
> before using it.
>
> * Code should be abstracted after the fact, and it should be abstracted
> again later, and then abstracted again, into as many layers as make sense.
> "Proactive abstracting" should be absolished.
>
> * Literate programming, as proposed by Knuth, needs to be resurrected.
> Programmers should make the effort to communicate the thought behind their
> algorithms - and they should write algorithms, not just code - and other
> programs should take time to learn it. Idioms should be spread this way.
> People should study the idioms of a language with the language (and damnit,
> they should read http://wiki.slowass.net).
>
> Perl culture is dead-on in some reguards, and horribly ignorant on
> other accounts. Java has a lot we can learn, but I feel very strongly
> that they shouldn't be eating our cake right now, and they are.
>
> -scott
>
> > On Tuesday 03 December 2002 10:09 am, Doug Miles wrote:
> > > Hal Goldfarb wrote:
> > > > I highly approve of your coding style and modular breakdown (similar
> > > > to mine).  Consistency is wonderful  : )
> > >
> > > Thanks.  I tend to optimize for readability.
> > >
> > > <SNIP>
> >
> > Now, if we can just get ALL programmers to agree, maintenance positions
> > would become attractive.  Problem is that certain individuals seem to
> > think that other formats are "cute", "artsy", or otherwise
> > self-expressive.  Architects have a single printing style (individuals
> > all attempt to write the same way); engineers tend to use small block
> > lettering (more coincidence, or possibly similar personality quirks); we
> > could even argue that doctors share the same "chickenscratch" language,
> > decodable only by pharmacists and some nurses. And don't even get me
> > started on spelling, grammar, and organization.
> >
> > When 80% to 90% of the lifecycle of a system is spent in the maintenance
> > phase, I feel that my rant is well warranted.
> >
> > This is one of the many reasons I feel that our field is so
> > unprofessional. Thank you for listening to one more very frustrated
> > unemployed software type.
> >
> > -Hal