Re: [xml-dev] parsing markup with Perl

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

On Tue, Feb 11, 2014 at 5:20 PM, Shlomi Fish <shlomif@shlomifish.org> wrote:
> Hi Ihe,
>

Hello

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

o is the SML compose operator. Function composition is what is going
on isn't it. So how can an operator that signifies that t be
superfluous.

Scheme has a compose operator but it is binary in its native form
(compose foo bar) so I did not use it as an example.


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

As you say programmers of higher level languages are less in need of
using such patterns. You have provided me a get-out for my ignorance
of pattern literature and it is gratefully accepted.

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

Well for me this is not a matter of opinion. They are.

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

In  FP you have functions that do different things based on the
variant of the data type.

fun circumference  shape
case shape of

  Square -> .....
  Circle   -> ....
  Triangle ->


fun area  shape
case shape of

  Square -> .....
  Circle   -> ....
  Triangle ->

In OOP the processing is organised differently

class Square

method circumference (shape) {.....}
method area (shape) {....}

If you are neutral on the relative complexities ( which I am not) and
comfortable in either sociological environment (e.g in OOP can speak
the pattern lingo and in FP you don't freak out when you see a fold or
a list comprehension) then the most appropriate paradigm to deploy is
largely dependent on  your ability to anticipate the most likely
direction in which the software will be extended.

If lots more behaviour is anticipated for your shapes then OO will
allow you to concentrate them in a few classes whereas FP will result
in a proliferation of functions. If the same behaviours are
anticipated over a wider variety of data types OO will make you
proliferate classes whereas FP will have all the processing
concentrated in a few functions.

Another factor that influences me, it is easier to do OOP in a
functional programming language (if I need to) than it is to do FP in
an OO language (Python is not tail call optimized, Java is .....well
it's Java... and it doesn't optimise tail calls either).

>
> 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;
>         }
>         else
>         {
>                 return ($n * factorial( $n - 1 ));
>         }
> }
>
> I hope you agree with me that it is still in fact a function.
>

Yes. It is a horribly inefficient factorial 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.".
>

I think these acronyms are more prevalent in OO literature which I
have already confessed I don't tend to read.
Regex related code is a constant source of WTF for me. Another is when
I have not properly documented some nuance of the data structure which
has led to the presence of code that is correct but not what one would
normally write at first glance.