Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Re^2: GHC shuffle more efficient than Perl5.

by nothingmuch (Priest)
on Apr 22, 2005 at 22:25 UTC ( [id://450604]=note: print w/replies, xml ) Need Help??


in reply to Re: GHC shuffle more efficient than Perl5.
in thread Why is the execution order of subexpressions undefined?

This remark is uncalled for.

Monads are a part of haskell. Without them the language wouldn't be useful at all. They are an integral feature, and not anything like inline assembler.

The only difference is that monadic functions and pure ones are separated by the type system, and that previously when haskell was not a very practical language, monads didn't exist at all.

Otherwise this is a part of haskell as much as sort is a part of perl.

-nuffin
zz zZ Z Z #!perl

Replies are listed 'Best First'.
Re^3: GHC shuffle more efficient than Perl5.
by BrowserUk (Patriarch) on Apr 22, 2005 at 23:26 UTC

    The distinction is that in a pure FP language, Autrijus' emminently clever code would not be possible.

    The inclusion of the monad into the previously pure FP Haskell, is testiment to the practical restrictions that pure FP implies. There are some tasks that FP algorithms are far and away the best alternative. There are some tasks that imperative algorithms (with their inherent utilisation of side effects) are more practical.

    Once you remove the "no side-effects" aspect from FP, you end up with the main distinction between FP and imperative code being the syntax used. For some algorithms, a declarative syntax is the most clear and concise. For some algoriths, a recursive definition is the easiest to code, understand and maintain--whether using declarative or imperative syntax. For some algorithms, good ol'imperative loops and blocks and side-effects is just the ticket.

    My preference--and there is no implication in this that seeks to restrict anyone else to my choices--is for a language that supports all these styles of syntax, without artificial restristions. For me, currently, the best choice available is Perl, which is why I come back to Perl in preference to all the other languages I've tried over the last few years.

    My conclusion from Autrujus' example, is that to address the constraints imposed by my posted problem (memory), the requirement is to utilise side-effects. What Autrujus demonstrated was that this can indeed be done within Haskell.

    So, we reach the point where the given task can be tackled in both languages, so the choice of language comes down to personal preference--mine is Perl.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco.
    Rule 1 has a caveat! -- Who broke the cabal?
      The distinction is that in a pure FP language, Autrijus' emminently clever code would not be possible.

      That is not correct at all. All programs exist to generate side-effects; otherwise they will be indistinguishable from no-ops that take lots of time to run. This is true for all programming languages of all times, FP or not.

      The distinction that a pure FP language makes, is merely that pure functions and side-effectful actions are separated, because the former is always inlinable and memoizable, and the latter always executed sequentially. In contrast, in a language that does not make this distinction, both are executed in some arbitary order.

      In other words, functions never have side-effects, but a program does. In Haskell and other pure FP languages, you can write functions that defines composable actions, and group them under the main function. The action defined by main will then be executed as the program itself.

      Personally, if I was to implement a fair shuffle in real-world situations, I also would choose Perl instead of Haskell, since it would save me some time, to the order of one minute versus ten minutes. But if memory use (or, sometimes, speed) is of critical importance, as often demanded in my paying work, then GHC is a much more elegant alternative than GCC to me. Which is why I'm working on Inline::GHC after all...

      Also, I have no doubt that Perl 6, as compiled by Pugs to Parrot, can be even more efficient than GHC here. :-)

        Thankyou Autrijus for clarifying what I was (clumsily) trying to say.

        Once you accept that side-effects are impossible to avoid, you can conceal them, segregate them, and move them to other places, but you cannot avoid them. You have to deal with them.

        The distinction between Haskell (and FP languages in general) and imperative languages (exempified by Perl), are in how you choose to deal with them.

        My only statement that could be considered "against" Haskell, is that personally, I prefer the permissive syntax and semantics of Perl as my tool for doing so, than I do, (what I consider to be, in my admittedly breif experiences of them), the restrictive syntax and semantics of Haskell and other FP languages.

        That is a biased viewpoint. In part by my greater experience with imperative langauges in general and Perl in particular. In part, by my feelings and opinions regarding the barrier that is formed between the general (and even the programming) population by viewing the world through opaque glasses of mathematical notation.

        I see the need for mathematical notation. Just as I believe that it is necessary for programmers to read, understand and use the full expressive power of their chosen computer languages, so I see that for the mathematician, the short-hand of math notation is their tool that allows them to express and convey (to other equally conversant practitioners) their ideas and concepts.

        But, just as the artist has no need for the constraints and precision of the draughtsmans tools to express and encapsulate his/her ideas, I don't think that the programmer needs the tools and nomenclature of the mathematician to express and encapsulate theirs.

        It may be mathematically correct to view the length of a string as a recursive function that processes the string as a list of characters counting them until the list is empty. And it may well be that a compiler can optimise this operation to the point where the counting is only ever done once. And the fact that the compiler actually reduces the operation to storing the length, as state in concert with the string, and adjusts it whenever the length of that string changes, whether through visible or concealed side-effect, is actually exactly what Perl does. It just advertises that fact rather than conceals it.

        At the final analysis, it comes down to which syntax you prefer to use. Through my inherent bias, which we all have, I prefer the imperative view of the world to the functional. I find it more natural.

        But my preference, nor my stating of that preference on this site, dedicated as it is to Perl, in no way belittles the power of FP, anyones preference for FP, or the frankly awe-inspiring use you have made of that power to the good of Perl.

        I am in awe. Of it, and you, and the use you have made of it.

        You have my thanks for your work and the benefits that it has already accrued and continues to accrue to the future of Perl.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco.
        Rule 1 has a caveat! -- Who broke the cabal?

        All programs exist to generate side-effects; otherwise they will be indistinguishable from no-ops that take lots of time to run.

        Well, if they take any time to run, then they must have side effects somewhere.

        the lowliest monk

      Monads are both pure and side-effectful. This isn't really a Functional Zen Koan (or hey, maybe it is), it's just that purity and side-effects are not really mutually exclusive.

      Rather than sharing with you my second-hand understanding, I suggest you check out Simon Peyton-Jones' Awkward Squad paper. It has quotes that directly bear on this conversation such as:
      "Call-by-need (or lazy) languages, such as Haskell, wear a hair shirt because their evaluation order is deliberately unspecified."
      This paper may answer some of your earlier questions in greater detail.

      In any case, I do think we should each use the language(s) we prefer. But I also think it's hard to know whether or not you prefer a language if you haven't tried it.

      --Shae Erisson (lambafolk in the process of learning Perl from the inside out)

        Thankyou for what from my breif scan so far, is another step on my elightenment. I will read it and all it leads to thoroughly as time permits.

        Update: It turns out that I already had the [file://localhost/C:/download/marktoberdorf/marktoberdorf.html|marktoberdorf] presentation in html form on machine, having read it some time ago when I first started looking at Haskell. Admittedly, at that point my understanding the concepts it discusses was even less than it is now, so I will re-read it over the next few days and see if anything changes in my reaction to it.

        I do have more to say on this subject. I am slowly putting that more together. When I asked the original question, I had no intentions of exposing where my thought patterns that led to the question were leading. In my attempts to counter the "C did it that way therefore it is the only way" argument for the status quo, I inadvertantly allowed bits and pieces of the thought-train that led me to question Perl's need for undefined execution order to leak out.

        That was, as this thread proves, a very big mistake. It has led to my attempting to initially explain the question, and then to defend the parts of the thinking that were exposed by that explaination.

        I'm a fool. I have this view of the world that everyone wants to explore new ideas and concepts, even the outlandish and crazy ones, even if they don't look like they might go anywhere, and ultimately don't. This is my approach to the world, as well as programming. It is not enough for me to read that X doesn't work. I need to understand both why it doesn't work, and what would have been the benefits of it if it did.

        It is very clear from this thread that: not everyone takes that view; and what a fool I was for believing enough might to allow me the priviledge of pursuing knowledge, that way, in public for this extnded thread to be fruitful.

        So, I have attempted to stop this thread, despite the obvious concequence of how a certain set of people would view that attempt. I have, through the inclusion of "late breaking developments", felt the need to renew my interaction. In part, so as not to be rude--which I abhor. In part, because those developments, including your posts, form interesting and fruitful extensions that I wish to pursue.

        But, until I have completed writing up the full details of though patterns, reading and ideas that led to my original question--incorporating stuff that has been months and years in gestation and is not easy to encapsulate--I would prefer to suspend this thread indefinitely. As I said in my reply to your previous post, I would welcome private contact, but trying to sustain a multi-threaded, all-comers, all-biases and all-dogmas open conversation, without mixing up the threads and directions in my replies proved to be beyond my ability (or desire) to do.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco.
        Rule 1 has a caveat! -- Who broke the cabal?

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://450604]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (3)
As of 2024-03-29 14:18 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found