[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: parsing markup with Perl

• From: Shlomi Fish <shlomif@shlomifish.org>
• To: ihe.onwuka@gmail.com
• Date: Mon, 10 Feb 2014 14:48:58 +0200

Hi Ihe (and all),

On Mon, 10 Feb 2014 11:14:56 +0000
Ihe Onwuka <ihe.onwuka@gmail.com> wrote:

> On Mon, Feb 10, 2014 at 10:47 AM, Shlomi Fish <shlomif@shlomifish.org> wrote:
> > Hi Ihe,
> >
> 
> Hello Again,
> 
> >
> > I guess I agree that it's a false dichotomy, but please don't attribute it
> > to Mr. Poe, because I was quoting and possibly paraphrasing on what he said
> > from memory. In any case, the Freecell Solver core source code alone
> > ( http://fc-solve.shlomifish.org/ - my own project ) now contains source
> > code and markup in C, Perl 5, GNU make, Python, Ruby, CMake, AsciiDoc,
> > Bash, and possibly other languages and I noticed that some other open
> > source projects also contain quite a bit of mishmash of stuff (don't know
> > how the situation is with proprietary software). So while not a dichotomy,
> > the situation is still certainly possible and may badly affect the
> > accessibility and approachability of contributing for the project.
> >
> 
> Well thats a different kettle of fish because there you have people
> contributing in multiple general purpose languages so I can agree with
> you there.

I see. Yes you are right. I have had some good reasons for writing everything
in what I did (i.e: CTypes only available for Python and was deemed as
necessary for testing, or C for the core library code for maximising speed and
minimising memory consumption (though it wasn't kept in Perl due to
historical legacy), or the fact that writing text/file/etc. manipulation scripts
or test scripts in C is not convenient) but I agree that what "Ovid", you and
I described can be a slippery slope. 

> 
> 
> >>
> >> Domain specific language vs Domain specific language masquerading as a
> >> possibly non-(standard|compatible|interoperable|performant|optimized)
> >> domain specific library in a general purpose language.
> >>
> >> Choose as your poison the one that is less likely to make you sick/die.
> >>
> >
> > Not sure I understand, but I think you mean something like that if working
> > in PHP or Perl (for example) you should not parse HTML and XML directly by
> > using one-off regular expressions, but rather use a normal and sane parser.
> > (To give an example for what you mean and not keep it abstract). I can 100%
> > agree with it, but it is may be sometimes better to reinvent small wheels
> > (in a good way) than to drag an entire framework (or even module or
> > library) for that.
> >
> 
> It depends on the domain of the project subject matter.
> 
> For example at what point does the amount of math you are doing mean
> you should be using R/Matlab/Mathematica or Octave. Perhaps if you are
> a Python Developer and/or know/believe in numpy/scipy the answer may
> well be never.

Hmmmm... not sure I fully understand your point. I was told some hard-core
Matlab users (researchers with Ph.D./etc.) etc. use the interactive Matlab REPL
to manage their files because they are so used to that and are familiar with it
(and they didn't install or bother learning a decent shell/scripting language
for Windows).

> 
> 
> > Moreover, sometimes writing "ugly"/complicated/inelegant code with some
> > so-called anti-patterns can go a long way in making sure your code is kept
> > simple (see https://en.wikipedia.org/wiki/KISS_principle ). This is instead
> > of using an abstraction that tries to produce the most elegant code any
> > time, and ends up being hard to learn, use and read (there's some previous
> > discussion on it in this thread of Sayeret Lambda (an Israeli group of
> > programming languages' enthusiasts)
> >
> 
> People who code in Python but can't grok List Comprehensions use the
> exact same argument.

It doesn't mean it's not a good argument. I've heard several criticisms of
Python's List Comprehensions (like "List comprehensions are not.") and arguably
the situation is worse in Haskell, whose most
code portions I was shown I found hard to understand due to the stringification
of lots of built in functions with those $ and . and what not that I'm not sure
of their purpose (note that my Haskell knowledge was always incomplete and is
now quite rusty due to disuse).

Anyway, I often resorted to writing somewhat more verbose (and less
abstract) code, just to keep it simple. Like using foreach ... { push
@results, ; } instead of map when I felt the map went out of hand.

> 
> >> >
> >> > Perfect is often the
> >> > enemy of good.
> >> >
> >>
> >> Very true but often used as an excuse to unnecessarily implement crap.
> >>
> >
> > That's right. Someone I know used to have "Good is the enemy of great." as
> > his signature. It shouldn't be taken as gospel, and quotes (like the Rules
> > of Acquisition) can only be considered as guidelines, and I have my share
> > of two apparently conflicting quotes, and quotes that I know which are
> > amusing, but that I can no longer agree with (including ironically some
> > quotes of my own.).
> >
> > I also read somewhere that many "famous" quotes and aphorisms are used to
> > feign authority, and so should be avoided as much as possible.
> >
> 
> Well I don't think I introduced any in our conversation :).

You didn't (which is arguably a good thing), but I did. I was criticising
myself.

> 
> But a more economical way of expressing the DSL vs DSL masquerading as
> library point would have been to state Greenspun's Tenth Rule (
> applied to the DSL being aped rather than Lisp).
> 

Yes, I know what Greenspun's Tenth Rule is ( for reference
https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule ) and I made some
parallels for it to Perl templating systems (with Template Toolkit as the
equivalent for Lisp) and Perl Object Systems (with Moose as Lisp). But I
think I see your point now.

Regards,

	Shlomi Fish

-- 
-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
Freecell Solver - http://fc-solve.shlomifish.org/

I invented the term Object‐Oriented, and I can tell you I did not have C++ in
mind.                  — Alan Kay (Attributed)

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

• Follow-Ups:
  • Re: parsing markup with Perl
    • From: Ihe Onwuka <ihe.onwuka@gmail.com>

• References:
  • parsing markup with Perl
    • From: "Simon St.Laurent" <simonstl@simonstl.com>
  • Re: parsing markup with Perl
    • From: Arjun Ray <arjun.ray@verizon.net>
  • Re: parsing markup with Perl
    • From: Michael Sokolov <msokolov@safaribooksonline.com>
  • Re: parsing markup with Perl
    • From: Shlomi Fish <shlomif@shlomifish.org>
  • Re: parsing markup with Perl
    • From: Ihe Onwuka <ihe.onwuka@gmail.com>
  • Re: parsing markup with Perl
    • From: Shlomi Fish <shlomif@shlomifish.org>
  • Re: parsing markup with Perl
    • From: Ihe Onwuka <ihe.onwuka@gmail.com>
  • Re: parsing markup with Perl
    • From: Shlomi Fish <shlomif@shlomifish.org>
  • Re: parsing markup with Perl
    • From: Ihe Onwuka <ihe.onwuka@gmail.com>