Phoenix.pm: Parameter parser
scott at illogics.org
Wed Dec 4 00:42:48 CST 2002
No! Please post your reply - I'd like to see it, and like I said, it's an
I'm also guilty of playing devils advocate in attempt to provoke you.
I've been thinking about the topic a lot lately, and misery loves company.
My goal is to engage you, not to disprove you ;)
I've been stuck maintaining horrible code, trying to iron bugs out of
something that was never thought out or organized in the first place.
I could tell horror stories... Motorola has provided me with more than
a few =)
Hoare on APL: "...I conclude that there are two ways of constructing a software
design: One way is to make it so simple there are obviously no deficiencies
and the other way is to make it so complicated that there are no
I did say that Perlers can learn a lot from the Java folks. I just think
that the Java folks have some things to learn from us - I'm picking on the
Java folks as being hardcore "clean code" OO freaks.
Idioms save complexity, time and typing, but also lead to unreadable code.
The Perl Cookbook has become part of Perl as written language at the
cost of excluding newbies from being able to read most Perl. Is this
good or bad? Should Perl be less expressive? How much behavior would
be better as part of a language standard library rather than in core?
Novices benefit from the ease of being able to write Perl without worry
of defining interfaces, classes, types, and so forth, but because it
is easier to pick up Perl than a hardcore OO language, more novices pick
Perl, giving Perl a bad name by all of the newbie code left laying around.
Should Perl make it more difficult to write amature code, pushing users
towards things like strict? This is a commonly argued idea.
I'm sorry... phoenix-pm-list is pleasanlty free of the sort of ongoing
rant you see on P5P and parrot internals... I shouldn't pollulte it.
I'm still developing my opinions, and I'm over eager for feedback on them.
Thank you for suffering my views - if you have any counter points or
insights, I shall enjoy hearing them.
> 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!
> 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
More information about the Phoenix-pm