FP in real world

[swisscheese]

Hi All

I just discovered FP and it seems a breakthrough in programming bigger than oops. haskell.org claims 2 to 10 time shorter code and less bugs. Whether that's an exaggeration or not, I can't understand why FP is not more mainstream. haskell.org tries to answer but something still seems missing. What's the catch? In particular I would like to take some big projects like a CAD app in c++ and start using FP for it. Is it practical to develop large apps that have a broad combination of graphics, math, data, gui, etc? Is it practical to have a hybrid app with c++ for old code and FP for new code? If FP is so good why is almost everyone just tinkering with it? FP forums are hard to find, not so many books, etc. FP seems to have started more than 10 years ago. What's holding it up?

swisscheese

[Strike]

In a word: inertia. In a few other words, lack of a big commercial entity (think Java and VB as examples) pushing an FP language. With those two things against a language, it's hard for it to succeed. The only real way around it is to fill a new niche and to be easy for substandard programmers to produce usable applications in (think PHP). Without those, it takes a while for a language to take hold.

Haskell is really cool, and I think that if it did have a large set of libraries for it and a few major apps coded in it, that it would be pretty successful.

[swisscheese]

Hi Strike

Thanks for the informative overview. Any thought about "Is it practical to develop large apps that have a broad combination of graphics, math, data, gui, etc? Is it practical to have a hybrid app with c++ for old code and FP for new code?"

swisscheese

[Strike]

I guess my response on both counts would be: "I don't see why not." Though I am hardly considered by any, let alone myself, as an expert on the use of FP languages in major projects :)

[BillLeeLee]

The best example I can think of is the Yahoo! stores (done in LISP).

[Smerdyakov]

The statement "almost everyone is just tinkering with it" is completely false, if I undestand it correctly. Functional languages are commonly used by professional researchers on very large, challenging, and complicated projects. If you have some bias against academia, that's fine, but calling what we do "tinkering" seems purposely insulting for no reason, assuming you have some idea of what really goes on at universities and research labs.

Your question about the practicality of developing large apps deserves a "yes" answer, I think. From what I've seen, the most practical languages to use are in the ML family. You can read my personal attempt to convince you to use ML (http://www.hprog.org/fhp/MlLanguage). In particular, the OCaml (http://www.ocaml.org/) and MLton (http://www.mlton.org/) compilers are very high quality and have very pragmatically minded developers and user communities.

[sicarius]

The major drawback right now with functional languages is that IO is rather clunky. It can be a turn off for developers when they see they may have to learn not only a functional language (like Haskell), but also some language like TCL or Python with which to build the interface.

There are projects right now trying to deal with the issue. For example there are several attempts at getting Haskell to use the TK package directly.

Things like this will help FP in the long run, but in the short term you aren't going to see major companies adopt it into their business plan.

It is just "too risky". The same thing happened with OOP though, so I wouldn't be too concerned.

[swisscheese]

Haskell programmers:
I'm trying to write my first Haskell program and am stuck on the "Maybe" concept. I am using one of the Find functions to find an element in a list and it returns the index with a Maybe. In my case I know the search will always find the item so I don't want the baggage of the Maybe trickling thru the entire app. But I don't get how the function that uses the Find can get rid of the Maybe situation so I can stick with simple Ints. Thanks

To Smerdyakov:
I meant no offense to researchers - I have no doubt they are doing large complex projects.

swisscheese

[Smerdyakov]

I believe there is an 'error' construct available in Haskell. I think the right thing to do is perform a case analysis on the result of the find function. Continue normally in the Just case. Raise an error in the Nothing case. There may already be a standard function to perform this for you, or you could write one.

[swisscheese]

Thanks but that does not help me as I am just learning. I have something like:

colEmpty :: [] -> Int
colEmpty mat = findIndex (==' ') mat

But interpreter complains I need type Maybe Int. But I want to handle the maybe only here and nowhere else.

swisscheese

[Smerdyakov]

Well, I think what I said _ought_ to help you, even if you are just learning. The topics you should look for information on are case expressions (which may require learning about algebraic datatypes, if you don't already know what those are) and the error facility. If you honestly can't find information on those, let me know. If you do read about those and learn how to use them, it should be easy to alter the code you have provided to meet your specification.