Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: parsing markup with Perl
 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. 
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
