Name: Anonymous 2011-11-06 11:55
* estimating the complexity of an algorithm: case analysis on any value what-so-ever can require arbitrary computation - so the run time of an algorithm doesn't just depend on the structures you input but also what methods are computing them: combine this with recursion and you've completely lost the ability to say anything meaningful about the algorithms run time.
* memory usage: All of the above applies to memory usage too. It's impossible to write tight programs that run in under a certain level of memory. Therefore you always have to expect a lazy program to crash at any momemnt.
* monads: normal lazy programming is pure, then the time comes when you want to print out values or read in some inputs. At this point you have to rewrite your entire program using monads. Frankly monadic programming implies the programmer doesn't understand continuations. I can undertsand beginner programmers not getting continuations, but language designers? that's just appalling.
* type systems: enforcing a strict type system can help beginner programmers but modern type systems (such as system F variants) will *never* be able to enforce that all your pattern matches are complete, that a program runs safely is a semantic property - syntactic methods like type systems are just conservative approximations of safe programs - so you really are wearing water wings when you use a type system. More generally, it stops you using advanced programming techniques where the type of the objects input and/or returned by a procedure change depending on the circumstances. In the turing tarpit sense, they're right when they say "it's not a limitation" but in terms of pragmatics, it is a huge burden for an advanced programmer.
* infinite streams: every list data type is also an infinite stream type, there's no distinction between finite and infinite. This goes against basic philosophical results and introduces a terrible fuzzyness and implicit assumptions about whether a list is finite or not all over your code. It's completely possible to create infinite streams in strict languages, so lazy programming never gets you anything new. It just make life harder for you.
* efficiency: it's also the case that compilation is much much harder and even on the algorithmic level, programing without state never match up to the efficiency of real programming since all data structures are forced to be persistent, but this just isn't how real computers work. You're denying reality when you program lazy.
* concurrency: programming paradigms come as modules in monadic programming, the result of this is again that you need to rewrite everything if you want to use concurrency. More fundamentally the language itself is hostile to concurrency so it will need a redesign if it wants to be relevant in the future. Who knows when ithe whole language will need to be redesigned from scratch again?
All in all the conclusion is that lazy programming is a fad, a waste of time, just some stupid game people are playing around for a while worse than python. hopefully it will die sooner or later so that more peoples effort isn't wasted on a dead paradigm.
* memory usage: All of the above applies to memory usage too. It's impossible to write tight programs that run in under a certain level of memory. Therefore you always have to expect a lazy program to crash at any momemnt.
* monads: normal lazy programming is pure, then the time comes when you want to print out values or read in some inputs. At this point you have to rewrite your entire program using monads. Frankly monadic programming implies the programmer doesn't understand continuations. I can undertsand beginner programmers not getting continuations, but language designers? that's just appalling.
* type systems: enforcing a strict type system can help beginner programmers but modern type systems (such as system F variants) will *never* be able to enforce that all your pattern matches are complete, that a program runs safely is a semantic property - syntactic methods like type systems are just conservative approximations of safe programs - so you really are wearing water wings when you use a type system. More generally, it stops you using advanced programming techniques where the type of the objects input and/or returned by a procedure change depending on the circumstances. In the turing tarpit sense, they're right when they say "it's not a limitation" but in terms of pragmatics, it is a huge burden for an advanced programmer.
* infinite streams: every list data type is also an infinite stream type, there's no distinction between finite and infinite. This goes against basic philosophical results and introduces a terrible fuzzyness and implicit assumptions about whether a list is finite or not all over your code. It's completely possible to create infinite streams in strict languages, so lazy programming never gets you anything new. It just make life harder for you.
* efficiency: it's also the case that compilation is much much harder and even on the algorithmic level, programing without state never match up to the efficiency of real programming since all data structures are forced to be persistent, but this just isn't how real computers work. You're denying reality when you program lazy.
* concurrency: programming paradigms come as modules in monadic programming, the result of this is again that you need to rewrite everything if you want to use concurrency. More fundamentally the language itself is hostile to concurrency so it will need a redesign if it wants to be relevant in the future. Who knows when ithe whole language will need to be redesigned from scratch again?
All in all the conclusion is that lazy programming is a fad, a waste of time, just some stupid game people are playing around for a while worse than python. hopefully it will die sooner or later so that more peoples effort isn't wasted on a dead paradigm.