[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: parsing markup with Perl
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 .
[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
|