Re: [xml-dev] parsing markup with Perl

[Shlomi Fish <shlomif@shlomifish.org>]

Hi Ihe,

thanks for your message.

On Tue, 11 Feb 2014 13:29:20 +0000
Ihe Onwuka <ihe.onwuka@gmail.com> wrote:

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

Ah, I think I understand. Let's drop it anyway.

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

Yes, right.

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

Well, I meant DRY in the extreme sense of making sure your code is free of
anti-patterns and repetitive things, not necessarily that you have two almost
identical pieces of code lying around which can be easily extracted into a
subroutine. Some languages give you more meta-lingual constructs to abstract
them away, than just subroutines/procedures/functions/etc. up-to the macros of
the Lisp family of languages.

Here is an example for what I mean. Let's suppose you have these two methods:

method foo(obj)
{
	obj.foo1();
	obj.foo2();
	obj.foo3();

	return;
} 

method bar(obj)
{
	obj.bar1();
	obj.bar2();
	obj.bar3();

	return;
}

(I'm not proposing to call the methods "foo1", "foo2", etc. - they will have
more meaningful names in production code).

Now arguably, this cascade of method calls is a pattern and "obj." is
duplicated and you may consider creating a higher-order-method (like higher
order function) that will accept the names (assuming your language is symbolic)
or references to methods and generate a new method that will call all these
methods in succession. E.g:

# [ ... ] is an array constructor
method foo = make_succession( [ foo1,foo2,foo3 ] ); 

That's exactly what I did in some object-oriented Perl 5 code, and now I think
it's pretty evil, because it will make many people (including me) say "WTF?" at
the code, and it didn't make it much shorter. I won't be surprised if you can
do something similar in Haskell using meta-Monad operations and you can
certainly do it in Common Lisp using a macro.

Yet another case is abstracting this cascade of function calls:

function my_func()
{
	return foo(bar(baz(quux(bagel())))); # Hope I didn't forget a parens.
}

These things can be seen quite often in less capable languages and Haskell has
something to do already.

One can argue that they do not really involve repeating yourself, but they
still can be abstracted away in higher level and/or more capable languages.

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

I guess you are right. 

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

What are you saying "WTF?" about. That it's not simple and stupid (KISS)
enough? I guess you are right. 

And we're back to discussing regexes. “So - how's the weather?” ;-).

Regards,

	Shlomi Fish

-- 
-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
List of Portability Libraries - http://shlom.in/port-libs

Chuck Norris can read Perl code that was RSA encrypted.
    — http://www.shlomifish.org/humour/bits/facts/Chuck-Norris/

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