That said, there is a lot of Haskell I like, and despite billing myself upfront as a failed Haskell programmer, I still hold out hope of making progress in using it. Though I may need to transition to it through one or two other languages first.Have you taken a look at Prolog? It requires a very different mindset, yet without static typing or monads.
And it is much harder to verify a proof than a program. You can run a program and subject its results to tests. Something you cannot easily do with formal mathematical notation. Of course, a big part of the desire for FP is the ability to have a compiler that takes standard mathematical notation and converts it to a running program. But then, you not only have to verify the notation, you also have to verify the compiler that does the conversion, and the results it produces, and the results that what it produces, produce.Hmm. You don't have to prove anything. You can still run your functional program and test it like you normally would (also take a look at: QuickCheck). But now you *get* the option to prove (informally) and reason about your programs if you so desire. It's an extra bonus feature that you don't get with an imperative program (New and Improved! Now with 20% more features!)
Although I'm probably getting *really* OT, here's an excerpt I like from "The Way of Z: Practical Programming with Formal Methods" by Jonathan Jacky:
Many programmer believe that fomal specification are not useful. They believe that the program text -- the code itself -- can be the only really complete and unambifuous description of what a program does. This vew holds that a formal specification is nothing more that the program written over again in another language. It misinterprets Z to be some kind of very high-level programming language.You can find the answer on page 34 by searching for the book on books.google.com.This example shows they are wrong. See for yourself; Here is the code in C.
The code couldn't be simpler. It is well structured and very brief -- in fact it looks trivial. But what does it do? Is seems to be adding up a series of number -- but why? And it returns the counter, rather than the sum -- is that a mistake? Try to answer before you turn the page.int f(int a) { int i, term, sum; term=1; sum=1; for (i=0; sum <= a; i++) { term=term+2; sum=sum+term; } return i; }
And that's my problem with much of the hyperbole that surrounds and infuses FP.I think our biases must be pretty different. Oh, sure, there are going to be some enthusiastic advocates of any language, but other than a few fly-by-night blog posts, I have a hard time seeing the hyperbole that surrounds and infuses FP.
This paper is saying that "we don't need to deal with errors, exceptions, dirty data etc.", or "need a language that is Turing complete" (elsewhere in the paper) except on "rare occasions", but that just doesn't make sense to me.Hmm. Maybe experience comes to play here also. I 100% agree with the paper (incidently it one of my favorite CS papers, my number one favorite probably being Can Programming be Liberated from the von Neumann Style?). Most of the programs I write (in any language, and I use plenty of Perl) are about (guestimating) 90+% purely functional in nature (engineering analysis mostly). In fact, I don't think I've probably ever professionally written a program where I didn't think I had at least a rough idea complexity of the algorithm.
Show me the code.Maybe something like xmonad, is real world, yet small enough to get your feet wet?
In reply to Re^6: Is it worth using Monads in Perl ? and what the Monads are ?
by Anonymous Monk
in thread Is it worth using Monads in Perl ? and what the Monads are ?
by rootcho
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |