Re: [xml-dev] parsing markup with Perl

[Ihe Onwuka <ihe.onwuka@gmail.com>]

On Tue, Feb 11, 2014 at 9:47 AM, Shlomi Fish <shlomif@shlomifish.org> wrote:
> 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.
>

It's just a variation on guilt by association which was your original
comment... doesn't mean anything more.

>
> 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.
>

KISS and DRY are guidelines not to be mechanistically applied.

The value of DRY is in maintenance - so that  you don't have to fix
things in multiple places - it's not about readability or simplicity -
because it may be real hard to come up with a function call that reads
elegantly enough to encapsulate the semantic of the procedural
abstraction you are implementing. There may not even be a cohesive
semantic - might just be a sequence of lines of code that you have
seen repeated - hence it is all about how well you can name the
abstraction.

KISS  is problematic because it depends on your background. For some
it might mean a 20 line for loop for me it is more likely to mean a 2
line list comprehension.

When you can come back to your code 6 months later and read it without
saying WTF you've got it right. I confess I'm not there yet -  more
especially with anything that contains a regex.