While its true that lazy evaluation makes it harder to think about performance (specially memory use), the flipside is that it makes it easier to reason about programs at a higher level and you have more freedom when defining abstractions.

For example, in Haskell you can freely rewrite common subexpression with a let whenever you want and in whatever order you want.

    --original
    (f x) ... (f x)

    --let
    let y = f x in y ... y

On the other hand, if your language has side effects these sort of transformations are not always safe.

having side effects and having lazy evaluation are distinct features though. One can conceive of a strictly evaluated haskell-like which isolates side effects in monads and is still largely composed of pure functions.

> having side effects and having lazy evaluation are distinct features though

Fair enough, but lazyness also plays nicer with things like `if` and `&&` that comput things lazily. (Without lazyness you need to add lots of wrapper anonymous functions).

Another thins is that, from a hystorical point of view, the only reason Haskell managed to be so pure in the first place was the lazyness. If your language is not lazy its very tempting to add sideeffects.

One can conceive of it, and yet it's never been done. Curious.

Yes it has. Mercury is a perfect example of a purely functional language which is not lazy. I/O is made functional via a uniqueness typing system.

Right, so it uses uniqueness typing and not monads presumably.

There is Idris: http://idris-lang.org/

It seems similar to what plinkplonk is talking about.

Hmm, I always thought of Idris, Coq and Agda as proof assistants rather than programming languages, but perhaps that's just me being unimaginative.

Idris is explicitly billed as a programming language. You can do pretty sophisticated programming in Coq too (Coq can be reasonably straightforwardly compiled down to Ocaml, Haskell and some other languages.)

I'd better spend some time checking it out then!

what about disciple and mu ?

http://stackoverflow.com/questions/10784124/non-lazy-branch-...

http://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf

I'm not really sure how "pure" Disciple can be considered to be, and it doesn't use monads does it? Perhaps I'm being ignorant though.

Mu is a great example. I wish there was more information about it publically available.

Writing short and clear code in Haskell is definitely easy. As for optimization - it quite often does it for you too!

!!!

I have never met a single person who has said this, let alone capable of following through.

If you are capable, I am envious of your determination/natural talent. Or alternatively I and every programmer I know are idiots. Actually both seem like possibilities.

> Or alternatively I and every programmer I know are idiots.

Most programmers haven't taken the time to actually learn Haskell.

Haskell only seems hard at first because it incorporates a lot of ideas that other languages do not. For a lot of developers, learning Haskell is a little bit like learning to program from scratch all over again.

In that sense, yes, I guess it's hard, but so was whatever language you learned first.

> For a lot of developers, learning Haskell is a little bit like learning to program from scratch all over again.

I find this to be the greatest joy of learning a new paradigm, everything is new and unknown, so even simple things are fun (again).

> Haskell only seems hard at first because it incorporates a lot of ideas that other languages do not. Indeed, even if you know Haskell, it may take years to master all classes in its standard library and most commonly used modules (like Parsec.)

I have to agree with the GP here. Haskell is actually an exceptionally simple, easy language to work with, once you get the basic concepts down. I have occasionally suffered some confusion in Haskell because of poorly documented third-party libraries, but the language itself is a joy.

I'd add a qualifier that if you know what you're writing and you're writing from scratch, it's relatively easy. Modifying existing programs can present an interesting challenge.

For example once you have a working program and decide that actually some value could be read/written using a file instead of computed at runtime and the place you use it is 10 levels deep after calling a non-IO function, you've got two choices. Unsafe IO (then why not use it everywhere) or a minor program redesign. Haskell is the only language where I run into this kind of situation. (it's still quite simple despite this)

I'd actually argue that modifying existing programs is where Haskell really shines. Strong static types and purity allow you to know a LOT more about arbitrary bits of code than any other language in mainstream use today.

If your program is well factored then it probably won't be hard to switch to IO ten levels deep. Bonus: Haskell makes refactoring easy!

Yes, but what happens to apps which depend on this piece of code? Suddenly the signatures change and you affect everyone with a change which should be completely transparent for them.

It's hard to discuss without an example.

Haskell has a difficult learning curve, that is all. A person coming to Vim from a modeless editor might feel the same way, but nobody doubts that someone familiar with Vim finds it easy to use. It took me a couple of years to "get" Haskell, but once you do it is very easy write clear, concise code with.

!!! I'm sure you're not an idiot.

Have you tried the School of Haskell, it incorporates the minimum viable skills for learning haskell (pulling code apart in the REPL, and understanding type signatures, pattern matches and compiler type check errors)

https://www.fpcomplete.com/school/how-to-use-the-school-of-h...