Xah Lee wrote: > besides syntactical issues, another thing with doing functional > programing in imperative languages is that they become very inefficent. > Functional languages are optimized by various means of functional > programings styles. Doing them in imperative languages usually comes > with a order of execution penalty because imperative language compilers > are usually dumb.
The itertools module and the new generator feature tries to make this better as it is lazily evaluated, in a sense. But its side effect is nasty. Usable though need to twist my mind a bit, not like when I do it in haskell. But the occasion imperative dip makes some of my programs easier to code. > > though, one can't totally blame for Python's lack of ability to do > functional programing. Its language's syntax of using indentations for > blocks by design, pretty much is in odds with functional programing's > sequencing of functions and other ways. (such as generic mechanism for > prefix/postfix syntax, or macros or other transformations and patterns, > or heavy reliance on the free flow of expressions/values) That I am not sure. haskell also use this indentation but I don't see a problem about it. One thing I find it odd though is the @decorator construct. I just don't understand why it is viewed as simple. It becomes very ugly IMO when there is a number of it, I am doing some web apps which requres varies decorators(one over the other). @format @login_block @validate @something def my_func(): I find it easier to read and under stand in the form of format(login_block(validate(something(my_func))))) though haskell's $ and . is even better. format.login_block.validate.somethin.my_func > > I don't blame Python that it doesn't cater to functional programing BY > DESIGN. But i do hate the mother fucking fuckheads Pythoners for one > thing that they don't know what functional programing really is, and on > the other hand fucking trumpet their righteousness and lies thru their > teeth of their ignorance. (that Guido guy with his Python 3000 article > on his blog is one example, possibly forgivable in that particular > instance. (http://xahlee.org/perl-python/python_3000.html)) That seems to be the case, I mean the design. For fairness, list comphrehension sometimes looks cleaner, though becomes ugly when you do the pipe/chain like programming in FP(multiple for). This again is an odd choice. It seems to be a flattening of multiple line for loop, yet at the same time python seems to be moving towards being more explicit(no map/filter/etc as they can be done in for loop). But I believe Python is designed for easy to code and read and maintain in mind. One has to admit that without some training, FP is not very intuitive, my head spin when I see haskell code. A for loop is easier to understand. Well, if you want clean FP, you can always try haskell which is getting better and better in terms of real world module support(file system, network etc). > > (excuse me for lashing out) > > Xah > [EMAIL PROTECTED] > ∑ http://xahlee.org/ -- http://mail.python.org/mailman/listinfo/python-list
