OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] parsing markup with Perl

Hi Ihe,

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

> On Tue, Feb 11, 2014 at 2:29 PM, Shlomi Fish <shlomif@shlomifish.org> wrote:
> > Hi Ihe,
> >
> > thanks for your message.
> >
> Hello Shlomi
> >
> > 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.
> >
> (foo o bar o baz o quux o bagel) in SML?

I don't know SML too well, but seems like it, though having to use "o" in
succession may also be considered superflouos syntax.

> FP and OOP are supposed to be two sides of the same coin but I find
> OOP to be more complicated without being more powerful. Because the
> instances where OOP is genuinely needed are limited, given the choice
> I avoid it - ergo I am and intend to remain blissfully unaware of
> pattern literature.
> If I am wrong about that (on patterns not on OO being more
> complicated) I plead Norvig on most OO design patterns being missing
> language features.

I wasn't quoting the OO "Design Patterns" (which I read, but since forgot what
most of the pattern names were about) Gang of Four book and related obsession of
these books by Addison Wesley for having various kinds of patterns, just saying
that you are likely to run into cases which involve doing something similar more
than one time (i.e: a pattern, not necessarily in the strict Gang of
Four/Portland Pattern Repository/sense), and this may not be desirable
according to the most extreme DRY/modularity/language-design interpretation.

I read in several places that design patterns are a way to overcome the
limitations of languages (e.g: "the subroutine pattern" or the "class/object
pattern"), and not sure what to think about it, although I admit that
programmers of higher level (and especially dynamically typed and especially
Lisp) languages are less in need of using such design patterns. There are
other patterns and anti-patterns that were identified, including some
techniques described in Martin Fowler’s Refactoring book (which I found the
introduction chapter about the "code smells" the most usefl).

Regarding FP vs. OOP - I don't feel that FP (or even Purely Functional
Programming, with no side-effects whatsoever) is necessarily a replacement for
OOP (or that the two are "two sides of the same coin" as you put it), but
rather that the two can be combined for a greater effect. There are some
languages that support both paradigms like Scala, OCaml and O’Haskell and you
can look at https://metacpan.org/pod/Parser::MGC for an interesting ways in
which both method calls and closures/lambdas are combined (and I've used that
module at times to write recursive-descent parsers because I feel I
almost fully understand how it does what it does, and because it was relatively
easy to debug the code I wrote using it).

I got some heat from someone once who read a little about
(Purely) Functional Programming being programming without side effects who
insisted that a recursive subroutine similar this in Perl (to calculate the
factorial) was not a function in the strict FP sense because it assigned a
value to a variable with a name once:

sub factorial
	my ($n) = @_;

	if ($n <= 1)
		return 1;
		return ($n * factorial( $n - 1 ));

I hope you agree with me that it is still in fact a function.

> >>
> >> 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.
> WTF was I thinking when I wrote that.

Heh. :-). Assuming you were not joking (or if you were), I'd like to add that
there are several aspects about one's code that can make you go "WTF?"
including KISS, DRY, algorithmic complexity/performance, style, and probably
other factors. Often KISS would be the first thing you'll notice because you'll
wonder "What the hell is going on here? I cannot understand it.".


	Shlomi Fish

> _______________________________________________________________________
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

Shlomi Fish       http://www.shlomifish.org/
Rethinking CPAN - http://shlom.in/rethinking-cpan

Only dead fish go with the flow.
    — via Nadav Har’El

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]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS