On Fri, Mar 16, 2012 at 8:35 AM, Felipe Almeida Lessa < felipe.lessa@gmail.com> wrote:

If you're asking about performance, as in "is there a problem that can be solved in O(f(n)) time in Java but not in Haskell-sans-IO-and-ST?", then it becomes a harder question. I'm not sure what the answer is.

Cheers,

-- Felipe.

</lurk> an interesting question emerges: even though i may be able to implement an algorithm with O(f(n)) in Haskell, and write a program that is O(g(n)) < O(f(n)) in C++ or Java... could Haskell be said to be more efficient if time spent programming / maintaining Haskell is << C++ or Java?? i'm still trying to learn Haskell, but it seems to me to be *much* less verbose than C and it's derivatives, and while jumping through monads just to print to a screen or write a file seems a small expence to pay to be able to express what you want easier... justin <lurk> -- * The wise man said: "Never argue with an idiot. They bring you down to their level and beat you with experience." * As a programmer, it is your job to put yourself out of business. What you do today can be automated tomorrow. ~Doug McIlroy No snowflake in an avalanche ever feels responsible. --- CFO: “What happens if we train people and they leave?” CTO: “What if we don’t and they stay?”

If the question is "when can I have my output", then both are equally relevant and can be safely conflated. That said, while some programming problems *are* of this type, I think most aren't, and your points certainly stand. On Fri, Mar 16, 2012 at 3:31 PM, Chris Smith wrote:

On Fri, Mar 16, 2012 at 3:43 PM, serialhex wrote:

...

an interesting question emerges:  even though i may be able to implement an algorithm with O(f(n)) in Haskell, and write a program that is O(g(n)) < O(f(n)) in C++ or Java...  could Haskell be said to be more efficient if time spent programming / maintaining Haskell is << C++ or Java??

There are two unrelated issues: (a) the efficiency of algorithms implementable in Haskell, and (b) the efficiency of programmers working in Haskell.  It makes no sense to ask a question that conflates the two.  If you're unsure which definition of "efficient" you meant to ask about, then first you should stop to define the words you're using, and then ask a well-defined question.

That being said, this question is even more moot given that real Haskell, which involves the IO and ST monads, is certainly no different from any other language in its optimal asymptotics.  Even if you discount IO and ST, lazy evaluation alone *may* recover optimal asymptotics in all cases... it's known that a pure *eager* language can add a log factor to the best case sometimes, but my understanding is that for all known examples where that happens, lazy evaluation (which can be seen as a controlled benign mutation) is enough to recover the optimal asymptotics.

-- Chris Smith

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Ryan Ingram:

Other external state is harder to emulate. For example, communication over a network most definitely requires some concept of a 'computation with side effects' since the network's response could change from request to request.

In GHC, even IO objects are pure, but they conceptually represent functions that modify the state of reality. I believe I begin to become a sectarian, with some idées fixes not so well shared...

It is the third or the fourth time that somebody recently puts the equivalence between the communication with the outer world, and "side effects". I contest that very strongly, perhaps a TRUE guru might instruct me. What a computer and the program it runs do to its hard environment has NOTHING to do with side-effects. Even a completely angelic, pure as a Cherub (but real) program will consume some electricity. And so what?! Of course, in classical physics the state of the world changes constantly (in a quantum world it is extremely ambiguous...), but the question of purity of a program - in my opinion - concerns the program, and nothing else. The networking is not expected to break the referential transparency, or does it? Jerzy Karczmarczuk

Quoth Jeff Shaw , ...

I'm thinking that side effects are really only necessary because Haskell programs expect to mutate the state of a computer outside of the haskell program.

I'm not a computer scientist, but in English, "side effect" is an effect that accompanies some other effect. E.g., you may take an antihistamine to relieve hay fever, and experience a side effect of drowsiness. Let's call the first an `intended effect'? Then in the matter of the computer outside the Haskell program - which is intended effect, and which is side effect? I'd have said, side effects would be like memory paging, deferred resource access for other processes, etc.? Some programs might leave behind temporary files ... I hope the answer is not that in computer science we regard all effects as side effects because the ideal computer program simply exists without consequence. Donn

Quoth Chris Smith , ...

The answer is that side effects has become something of a figure of speech, and now has a specialized meaning in programming languages.

When we're talking about different uses of the word "function" in programming languages, side effects refer to any effect other than evaluating to some result when applied to some argument. For example, in languages like C, printf takes some arguments, and returns an int. When viewed as just a function, that's all there is to it; functions exist to take arguments and produce return values.

I'm surprised by the use of "function" as a unit. I would have expected "expression" or something, but maybe that isn't semantically interesting as long as one can't exist independent of the other.

... But C extends the definition of a function to include additional effects, like making "Hello world" appear on a nearby computer screen. Because those effects are "aside from" the taking of arguments and returning of values that functions exist to do, they are "side effects"... even though in the specific case of printf, the effect is the main goal and everyone ignores the return value, still for functions in general, any effects outside of producing a resulting value from its arguments are "side effects".

If that's so, it's unfortunate. It would have been more profitable to confine the application of this term (side effect) to the context of the program, where it 1) makes sense in English, and 2) applies to a programming device that has always been of some interest. I have a little trouble defending this point of view because there's some overlap, inasmuch as the program may also retrieve values via external I/O. And Haskell provides writeIORef/readIORef as a convenient way to demonstrate that as a technical side effect without resorting to actual I/O. Still, the use of I/O and similar techniques to create a side effect are interesting as such, and my point is that if we call every I/O a side effect, the term loses its value as a way to describe this programming feature. Donn