Yes, but not because laziness was a technical failure, but for something more resembling PR reasons. Haskell's laziness by default ends up being a large stumbling block for many developers not used to thinking in that way.
Although I understand why Idris is strict by default, there is a part of me that dies a little from that understanding :(
It's not so much a PR failure, as an ergonomics issue -- making laziness the default makes it too easy for people to create performance problems for themselves.
Haskell's laziness undoubtedly works and is useful; you might say it was Haskell's strictness that needed improving.
What does strict mean in this context? I don't know too much about these concepts. I think lazy means only evaluated when needed, like in generators (using Python as an example, which I know - I don't know Haskell or Idris). And I thought (from what little I've read), that the opposite of lazy evaluation was eager evaluation. So in Python at least, an example of eager vs. lazy would be returning a list vs. returning a generator from a function. For the former (list), the whole list would have to be created/populated and then returned (thereby occupying memory for the duration of its use), whereas for the latter (generator), items from it would only be yielded on demand, e.g. one at a time, when next() is called, or when the generator is iterated over, and so would not use as much memory as needed for the sum of the sizes of the items in the list. So where does strict fit in here?
Feel free to point if I've got any of the above wrong.
Strict evaluation is a synonym for eager evaluation.
In Haskell, the primary mechanism for inducing evaluation is the case expression (if/then/else and pattern matching are syntactic sugar for case).
Thunks (lazy expressions) in Haskell are created with let and then forced with case. It's very straightforward at the most basic level, there's just a lot of abstraction built on top of it that can obscure what's going on.
