Re: [xml-dev] parsing markup with Perl

[Shlomi Fish <shlomif@shlomifish.org>]

Hi John,

On Mon, 10 Feb 2014 23:01:18 -0500
John Cowan <johnwcowan@gmail.com> wrote:

> On Mon, Feb 10, 2014 at 2:20 PM, Shlomi Fish <shlomif@shlomifish.org> wrote:
> 
> > Indeed. Lying with dogs get you fleas.
> > >
> >
> > I think I understand the idiom, but I don't know what you wish to say by it
> >
> 
> The standard for is "If you lie down with dogs, you get up with fleas."  It
> means either "If you associate with bad people, you pick up their bad
> qualities" or "If you associate with people who have bad reputations,
> you'll get a bad reputation too.
> 

Thanks for the clarification. That put aside, I think I understood that, I just
didn't know how it was applied in this context (i.e: what are the logical
implications for me and for what I said). Perhaps he meant that I agreed with
the people who thought Python’s list comprehensions were bad because I have
been talking with them a lot and influenced by them.

In any case, I think we should stop discussing Python's list comprehensions and
instead either agree (or disagree and if so - please expain) that taking
https://en.wikipedia.org/wiki/Don%27t_repeat_yourself (DRY) to its
logical extreme *may* (but not necessarily) badly reduce the simplicity,
accessibility, approachability of a code and the software developer's capability
to effectively understand, debug, and sometimes properly modify it (Which I
think all fall under the collective umbrella of
https://en.wikipedia.org/wiki/KISS_principle - "Keep it Simple and Stupid").
Whether KISS or DRY are better is a matter of debate, and some people (like
me) feel there should be a balance of them. 

A few notes:

1. I'm pretty sure I wasn't the first to come up with this sentiment and
document it. It is well-known and several people I talked with said they
believe it was true or that it makes a lot of sense.

2. Now that I think of it, it's not the only trade-off in programming. Other
factors include correctness (= making the code bug free, which
will likely make it more complex, or even more complicated, and may harm both
KISS and DRY), adding features and functionality (which will likely make it
larger and may introduce more bugs due to the increasing complexity
cross-product of using more than one feature), performance (optimisation,
scalability, etc. - highly optimised code can be extremely complex and often
unmodular), and naturally - time to market (because often a somewhat imperfect
or incomplete software application *now* is better than a perfect one that will
only be released 10 years from now).

To tell a story to illustrate my point, a few years back I collaborated with
a linguist, a software developer, and a contributor, to the Wikimedia (=
Wikipedia/Wiktionary/Wikiquote/Wikibooks/etc.) for some code he wrote in Perl
5 to transliterate text from Italian to Hebrew -
https://metacpan.org/release/Lingua-IT-Ita2heb . He wrote most of the functional
code and I found that it contains some repetitive idioms, so we ended up
converting it into some classes, traits (as in the Smalltalk paper - referred
to as "Roles" in Perl terminology), methods and possibly some
other abstractions, using Moose ( http://moose.iinteractive.com/en/ ) which is
a modern object system for Perl 5 that is more convenient than writing Perl
OOP code directly. ( Perl 5 OOP has received some criticisms for being clunky
and has span many previous, incomplete, and inadequate, attempts at combating
the situation on CPAN, and the Moose ecosystem has, by and large, took over and
made most of them mostly obsolete.)

Anyway, we made the code more modular, but due to the inherent constraints of
the task (The rules of Italian pronunciation are quite regular, but still has
some quirks), the code remained complex and with many if statements, and other
complications, and seemed a bit "ugly" and inelegant to me. Amir (= the
original originator of the code) told me that what I did using Moose was
"beautiful", but I still have an uneasy feeling about writing this code.
However, writing such complex code cannot usually be avoided when doing human
natural language processing.

The point is if the code was more DRY and/or more KISS than what we ended up
with, it would likely be less correct (i.e: have bugs) in which case we would
have not transliterated Italian to Hebrew correctly and done a bad job. H. L.
Mencken wrote in 1949 that “There is always an easy solution to every human
problem — neat, plausible, and wrong.” ( see
https://en.wikiquote.org/wiki/Problem_solving ), and while possibly that quote
is an over-generalisation, complex problems often require somewhat inelegant
solutions.

3. Naturally you may think of a good and clever way (and I mean "clever" in the
positive sense - not in the negative connotation that is associated with
“overly clever code”) to increase both the code's modularity (DRY) and its
simplicity (KISS), but I'm not sure if it's always possible, ever if you are
the smartest and best programmer in history. And, like I said previously,
software development involves juggling some other aspects, including the
developers' time.

---------------

Can we agree with that? Again, I'm not saying Python's list comprehensions are
necessarily bad, and they can increase the DRY and sometimes also its KISS
compliance and readability (assuming your programmers are clueful enough to
understand them - if they're not, they probably don't know Python too well, or
are low-grade code monkeys), so let's avoid discussing that.

Sincerely yours,

	Shlomi Fish


-- 
-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
Original Riddles - http://www.shlomifish.org/puzzles/

Chuck Norris could have built the Roman Empire in a day. And it would have
taken him even less time to destroy it.
    — http://www.shlomifish.org/humour/bits/facts/Chuck-Norris/

Please reply to list if it's a mailing list post - http://shlom.in/reply .