Re: [xml-dev] parsing markup with Perl

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

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.


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


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

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

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