what makes functional programming better is the reduction of state. so for example, if I decide that the function call out to contains? is too much overhead in a tight loop, I can just copy and paste the relevant code without being concerned that I might miss some crucial piece of state it twiddles somewhere.
The true beauty of functional programming has little directly to do with modes of failure. The beauty of functional programming is transparency of code. I would argue that the kinds of errors you see are an exact result of this transparency, each one is a little X-ray window into the inner workings of the function. On Mon, Nov 9, 2009 at 12:49 PM, Mark Engelberg <mark.engelb...@gmail.com> wrote: > > Here's another way to think about it. > > Why is functional programming better than imperative programming? > > One common answer to this question is that functional programs are > easier to debug. Why? Because in an imperative program, if one part > has an error, the error doesn't necessarily manifest in the portion of > code that has the error. Instead, a little piece of memory or state > can be corrupted in one spot, and then much, much later, an error > happens as a result of this inconsistency. Thus the need for > sophisticated debuggers and steppers to identify where the corruption > happened (since the manifestation of the error doesn't really help you > know the source of the problem). > > However, in a functional program, you have these well-defined pieces > that reliably return the same output for a given set of inputs, making > it easier to test individual components, and when something produces > an error, it's pretty easy to pinpoint the function where things went > wrong. > > Unfortunately, when core functions don't produce errors for invalid > inputs, then you have a similar problem as with imperative languages. > It becomes rather easy to write a program where the consequence of an > error is far removed from the source. > > I have been told that Erlang programmers have developed a culture > where errors are generally not caught or disguised in any way. > There's sort of a "crash early and crash hard" philosophy, to increase > the likelihood that a crash will happen in the block of code that is > causing the problem and not later. > > On Mon, Nov 9, 2009 at 12:35 PM, Mark Engelberg > <mark.engelb...@gmail.com> wrote: >> On Mon, Nov 9, 2009 at 12:32 PM, Kevin Downey <redc...@gmail.com> wrote: >>> >>> the behavior of functions outside of their domain is undefined. I >>> guess I still don't get it. why would you use a function on something >>> outside of its domain? do people just pick functions at random to >>> compose their programs? >> >> Of course they don't pick functions at random, but people do make >> mistakes. Although I don't mind Clojure's approach, it is reasonable >> for people to want clear error messages when they use a function >> improperly. >> > > > > -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
