From: Phillip Gawlowski Date: 2011-04-03T20:50:32+09:00 Subject: Re: Lambda Shambda On Sun, Apr 3, 2011 at 1:00 PM, Robert Klemme wrote: > > I am not sure I fully agree to this observation.  First, I believe languages > are rather becoming simpler than more complex these days.  On the other hand > with increased power of hardware and increased volume of library code the > problems that we tackle today are becoming increasingly complex.  Also, the > mere fact that we need to utilize concurrency to solve problems (because > single CPU isn't going to grow that much in the near future) does make > applications more complex. Further, if anyone thinks that using a modern language is complex and / or difficult, I recommend some quality time with x86 assembly. I still have nightmares from IT class back in school, and it's been *years*. ;) > Personally what I find most difficult to grasp about functional programming > is not the paradigm itself but rather the feature of Lisp that macros and > functions are syntactically indistinguishable.  While this makes for elegant > solutions on one hand it can be confusing to read on the other (and just > think about the various quoting mechanisms of Lisp).  YMMV though. Though, I'd be careful in calling LISP a functional programming language. While it *does* use the lambda calculus, it doesn't guarantee that functions are free from side effects. And its raison de entrée is that data and code are mutable, which is antithetical to pure-bred functional programming languages. Though, considering that LISP was one of, if not the, first language to use the lambda calculus as basis for a programming language, it is certainly a forefather of today's crop of functional programming languages, like Scheme, ML, Erlang, Haskell, or F#. > Even if there weren't where's the argument?  All engineering is based on > results of science of one form or another (and math is often one of them). >  If research turns up something which can be used to model real world > phenomena of a particular class more efficiently than other approaches then > it should (and will) be used.  There's still enough room to apply other > approaches and nobody forces Mike to go functional, does he? Speaking of engineering and functional programming: http://www.erlang.org/faq/introduction.html#id49899 Functional programming and the lambda calculus are far from academic topics, but have some real implications and solve engineering problems. Personally, I wouldn't want to program a CRUD app using functional programming, but if I had to deal with an industrial robot, I'd hope that some sort of functional programming is possible. Nor would I want to write a financial statement using functional programming tools or pradigms (mathematically speaking, it's only addition; the rule set is what makes bookkeeping difficult). -- Phillip Gawlowski Though the folk I have met, (Ah, how soon!) they forget When I've moved on to some other place, There may be one or two, When I've played and passed through, Who'll remember my song or my face.