You are not logged in.

#1 2012-10-26 20:18:12

bsilbaugh
Member
From: Maryland, USA
Registered: 2011-11-15
Posts: 141

So you learned functional programming. Any regrets?

I have been using Object Oriented Programming (OOP) techniques--with C++, and Python--for nearly a decade, and every now and then I come across a post or blog prophesying Functional Programming (FP) as the next big paradigm. Arguments in favor of FP usually include:

  • Code correctness: FP languages are declarative, and are thus easier to reason with and visually verify; if an FP code compiles, it is most likely correct.

  • Programmer productivity: FP languages enable efficient expression of abstract concepts.

  • Parallelism and Concurrency: FP data is immutable, and thus race conditions that tend to plague imperative languages cannot happen.

So, my question is, are these claims true, or is this just propaganda from FP enthusiasts? That is, is there a silent majority of programmers who have gone down the FP road, only to become disillusioned and return to Object Oriented Programming (OOP)?

I have started reading up on Haskell. In particular, I'm in the process of reading Learn You A Haskell for Great Good. I have to say, I am really warming up to the concept. The "toy" problems I've applied FP to certainly seem convincing, but I have yet to dive into a large scale project.

Some Relevant Background:

The problem domain I work in, is scientific computing. Many of the codes I develop and maintain employ Finite Element or Finite Volume methods to solve Partial Differential Equations (PDE's). The programs are typically a composition of numerical algorithms together with a data structure, that run as batch processes. That is, they load a set of configuration parameters and initial data (from disk), then iteratively/recursively construct an approximate solution using the specified algorithm(s). The software complexity usually arises from the need to support a variety of numerical methods that are composed together at runtime per user specification; the individual algorithms are usually quite trivial to implement.

Traditionally, these codes were written using procedural programming (e.g. Fortran) with a plethora of control blocks to route the flow of control between the desired algorithms; however, some (younger) scientific programmers have started to embrace the OOP design philosophy with positive results (myself included). My only complaint with OOP, is that it still requires a fair bit of programmer effort to realize a clean design (readable/verifiable, reusable, and efficient). Also, my experience with C++ and Python suggests that rigorous unit testing is a must for any OOP code--which is an additional cost on top of the initial design effort. (This could also be said about procedural programming; e.g. Fortran and C.) To make matters worse, many scientific programmers are research scientists/engineers that are expected to develop the software they need on the "side" (i.e. it's a byproduct of their research), and it is very difficult to find the time needed to properly design an OOP code. So, I find myself wondering, should I really be using FP instead of OOP?

EDIT: The last question, "... I find myself wondering, should I be using FP instead of OOP?", should have been expressed as, "... I find myself wondering, should I be putting more effort into learning FP?".

Last edited by bsilbaugh (2012-10-28 17:50:21)


- Good judgement comes from experience; experience comes from bad judgement. -- Mark Twain
- There's a remedy for everything but death. -- The wise fool, Sancho Panza
- The purpose of a system is what it does. -- Anthony Stafford Beer

Offline

#2 2012-10-27 03:19:00

drcouzelis
Member
From: Connecticut, USA
Registered: 2009-11-09
Posts: 4,092
Website

Re: So you learned functional programming. Any regrets?

bsilbaugh wrote:

So, my question is, are these claims true, or is this just propaganda from FP enthusiasts? That is, is there a silent majority of programmers who have gone down the FP road, only to become disillusioned and return to Object Oriented Programming (OOP)?

This question strikes me as odd. Are you suggesting functional programming and object oriented programming are mutually exclusive? I assume that's not what you meant, but I'll say this before anyone else does: use the best programming paradigm for the task, be in functional, object oriented, procedural, or whatever.

As an aside, I went through a "try to do everything in OOP" phase for a while. It drove me bonkers. tongue

Anyway, I haven't really done functional programming since I was in college about ten years ago. I remember thinking it was amazing, and I still try to apply the principles I learned from it as much as possible when I program in C and Python.

Offline

#3 2012-10-27 03:34:36

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 19,739

Re: So you learned functional programming. Any regrets?

Interesting post.  I've been around long enough not to worry about the next trend;  Structured, Object Oriented, Functional, Extreme, Agile, Waterfall, ... Bah!  Good tools and methodologies all; provided they don't turn to religion.

bsilbaugh wrote:

Also, my experience with C++ and Python suggests that rigorous unit testing is a must for any OOP code--which is an additional cost on top of the initial design effort. (This could also be said about procedural programming; e.g. Fortran and C.)

Here, I wholeheartedly disagree.  Unit testing is cheap -- it pays for itself many times over, and over, and over ....  (This is the point of my post)


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way

Offline

#4 2012-10-27 03:39:56

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,441
Website

Re: So you learned functional programming. Any regrets?

This stikes me a bit as a carpenter, having mastered the hammer, discovering a saw and asking "is the saw the next big thing, is it going to replace my hammer."


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#5 2012-10-27 03:48:21

Diaz
Member
From: Portugal
Registered: 2008-04-16
Posts: 366

Re: So you learned functional programming. Any regrets?

Ever since I learned FP many ideas stuck and I apply many of them, like short clear functions easy to debug that given a certain input always give back the same result (no  side effects), recursion, or at least thinking about big things and how to reduce them to the basics.

Offcourse if I would try to write something in Haskell again I would cry a little because I don't remember most of the stuff big_smile

Offline

#6 2012-10-27 04:46:02

bsilbaugh
Member
From: Maryland, USA
Registered: 2011-11-15
Posts: 141

Re: So you learned functional programming. Any regrets?

drcouzelis wrote:

This question strikes me as odd. Are you suggesting functional programming and object oriented programming are mutually exclusive? I assume that's not what you meant, but I'll say this before anyone else does: use the best programming paradigm for the task, be in functional, object oriented, procedural, or whatever.

I apologize for my poor choice of words. I did not intend to imply that FP and OOP concepts were mutually exclusive. My objective is to get a better understanding of the actual merits of FP for real-world projects. I'm particularly interested in possibly solving problems using functional languages (e.g. Haskell), as opposed to emulating FP concepts with non-functional languages (e.g. C++).

trilby wrote:

This stikes me a bit as a carpenter, having mastered the hammer, discovering a saw and asking "is the saw the next big thing, is it going to replace my hammer.

With all due respect, no. A hammer and saw are designed to solve distinct problems. The desiderata for choose a hammer or saw is clear cut (pun intended). However, both FP and OOP were conceived to solve the same set of problems; e.g. both Haskell and Java claim to be "general purpose" languages. Thus, as a developer, the choice between FP and OOP for a given project cannot be made based on the definitions alone. The decision can only be based on experience, which I do not yet have. So, before I start making any major investments in learning/mastering FP, and learning the hard way which problems FP does not work well for, I though it made sense to gather intel from those who already have experience using FP, and who could speak to its strengths and weaknesses.


- Good judgement comes from experience; experience comes from bad judgement. -- Mark Twain
- There's a remedy for everything but death. -- The wise fool, Sancho Panza
- The purpose of a system is what it does. -- Anthony Stafford Beer

Offline

#7 2012-10-27 05:04:50

headkase
Member
Registered: 2011-12-06
Posts: 1,975

Re: So you learned functional programming. Any regrets?

I think defining whether or not you should use functional programming depends on the "problem domain" you are trying to solve.  Some types of problems are very suited to FP and other problems may be better suited with a different methodology.

See: http://stackoverflow.com/questions/2078 … rogramming

Or google yourself: "functional programming problem domains."

Edit: As another example?  Graphic User Interfaces?  OOP all the way for those: GUIs fit onto OOP almost perfectly.

Last edited by headkase (2012-10-27 05:10:00)

Offline

#8 2012-10-27 08:18:08

Awebb
Member
Registered: 2010-05-06
Posts: 6,272

Re: So you learned functional programming. Any regrets?

bsilbaugh wrote:

With all due respect, no.

trilby has a valid point. While it is possible to solve the same problem with different programming paradigmas, there is one excelling in that particular task. You can divide a wooden board into two halfs using a hammer, but the saw would be the better choice. You can convince a nail to stay inside a wall with a saw, but you would have to saw a slit from the doorframe all the way to the destination of the nail. The last one is especially aimed at people insisting to use OOP for everything.

I really wonder why that meaningless debate is still around after such a long time of empty phrases and interwebs drama. They should have learned by now, that there is no single one way, that you have to master as many techniques as possible to [lengthy rant about programming philosophy]

One thing you should clarify: Are you talking about "functional" or "procedural" or both? A lot of people mix those two up, mostly because of inconsistency in languages and literature.

Offline

#9 2012-10-27 11:16:18

Morn
Member
Registered: 2012-09-02
Posts: 886

Re: So you learned functional programming. Any regrets?

Usually large computer models in science need to run on several cores in parallel, which is why Fortran is preferred. I don't think Haskell's support for parallelization is anywhere near where e.g. a general circulation model of the atmosphere could be done in it and perform fast enough on the big iron. Code in FP languages is more elegant than Fortran, but a well-optimized Fortran program will run faster because its instructions are closer to CPU instructions (i.e., machine code itself is procedural). So if a model is run many times, not just once, it usually pays to spend the extra time to do it in Fortran.

In my field (atmospheric science) the big models are programmed in Fortran for speed, and then you fetch the results to your PC and process them with Python, Matlab or whatever language you prefer. This allows cleaner, more functional code with fewer side effects than Fortran. For one-off analysis code it's usually more important to be bug-free than fast, so FP and OO paradigms are great for it. Numpy/Scipy/Matplotlib is a pretty fantastic combination for data analysis and plotting.

Offline

#10 2012-10-27 21:23:14

bsilbaugh
Member
From: Maryland, USA
Registered: 2011-11-15
Posts: 141

Re: So you learned functional programming. Any regrets?

Morn wrote:

So if a model is run many times, not just once, it usually pays to spend the extra time to do it in Fortran.

I think this is a key statement. If you're using an existing code/model for routine analysis (e.g. an aerodynamicist studying a new vehicle design, or a meteorologist forecasting the weather) then it pays to have all the fine grained code optimizations you can. As you implied, the development cost can be amortized over each reuse.  In our lab, however, our tools are in a constant state of evolution. Either we're directly involved in the development of some new computational method (for engineering analysis), or we need to revise/extend our codebase to support the study of a new design concept. Thus, development time is an important factor for us. (This is not to imply that CPU time isn't.)

Morn wrote:

In my field (atmospheric science) the big models are programmed in Fortran for speed, and then you fetch the results to your PC and process them with Python, Matlab or whatever language you prefer. This allows cleaner, more functional code with fewer side effects than Fortran. For one-off analysis code it's usually more important to be bug-free than fast, so FP and OO paradigms are great for it. Numpy/Scipy/Matplotlib is a pretty fantastic combination for data analysis and plotting.

This is a pretty typical work flow for us, and I've been a pretty heavy user of Numpy and Matplotlib over the years. For pre and post processing, Python is hard to beat. Although, I'm beginning to wonder if Haskell could be a strong contender in this arena--especially since GHC provides automatic parallelization.


- Good judgement comes from experience; experience comes from bad judgement. -- Mark Twain
- There's a remedy for everything but death. -- The wise fool, Sancho Panza
- The purpose of a system is what it does. -- Anthony Stafford Beer

Offline

#11 2012-10-28 11:47:56

Morn
Member
Registered: 2012-09-02
Posts: 886

Re: So you learned functional programming. Any regrets?

I also wonder if a more "mathematical" programming language such as Haskell wouldn't be a bit too stringent for many real-world scientifc applications. E.g. during the first few time steps, a tracer concentration in a chemistry transport model may briefly go negative at a few grid points as the model tries to adjust to an equlibrium. In a Fortran model, you try to go on and ignore the error because after a little while it will correct itself. Iterations in the code will be explicit and just stop at some upper limit, so you just get some junk time steps. Models can be very strange, ugly, and pragmatic inside and still produce valid results in the mean/long-term. For a very mathematically clean problem, Haskell might be great, but in other areas, excessive mathematical correctness might prevent you from getting any results at all, e.g. if Haskell thinks mass has to always be positive for a valid solution.

For a while there was this fad to write scientific models in C++, but I think people soon discovered there are even more ways to shoot yourself in the foot in C++ than in Fortran. And the language is more malleable, so it's more difficult to understand and integrate someone else's code quickly.

Personally, I've been following the development of Google Go with some interest. Lack of exceptions are what's holding the language back I think. Apparently they have implemented something called panic/recover now, but I haven't checked that out yet. Fortran compilers are still the most powerful tools for maximum parallel computation speed, and it might take a while for Haskell, Go, or any other competitor to fully catch up to that. And I'm saying that as someone who absolutely hates having to code anything in Fortran.

Offline

#12 2012-10-28 13:22:19

Trent
Member
From: Baltimore, MD (US)
Registered: 2009-04-16
Posts: 990

Re: So you learned functional programming. Any regrets?

Morn wrote:

machine code itself is procedural

An astute observation. In my particular (low-level) domain one rarely encounters functional programming; when you're counting cycles and bytes to optimize performance, small functions that do one thing with no side effects can be a frivolous waste of both. (These problems can more often be optimized away when you're working on a high level, e.g. tail recursion.)

One possible exception I don't have personal experience in might be low-level multiprogramming, where no side effects means you can share code between processing units operating concurrently on different data. I'd be interested to hear if anyone with that kind of experience can corroborate this notion.

Offline

#13 2012-10-28 13:31:19

fsckd
Forum Fellow
Registered: 2009-06-15
Posts: 4,173

Re: So you learned functional programming. Any regrets?

Morn, haskell doesn't restrict things like that. Haskell is not "mathematical" anymore than C is.


aur S & M :: forum rules :: Community Ethos
Resources for Women, POC, LGBT*, and allies

Offline

#14 2012-10-28 16:59:33

bsilbaugh
Member
From: Maryland, USA
Registered: 2011-11-15
Posts: 141

Re: So you learned functional programming. Any regrets?

Morn wrote:

I also wonder if a more "mathematical" programming language such as Haskell wouldn't be a bit too stringent for many real-world scientifc applications... excessive mathematical correctness might prevent you from getting any results at all, e.g. if Haskell thinks mass has to always be positive for a valid solution.

You bring up an interesting point. If a person is interested in modeling the long-term dynamics of some system (e.g. finding equilibrium points, periodic response, etc), it is common to use iterative techniques to "find" the equilibrium/periodic solution. In fact, use of time marching methods, with non-physical initial conditions, to compute steady solutions is quite popular in CFD. In your example, however, think for a moment about the requirement for mass to be positive. If I were to assert, "mass must be positive for all time", would I be making a mathematical assertion, or a physical one? In other words, wouldn't it be possible to create a mathematical model (a numerical method) with an abstract quantity that converges to "mass" in the limit? In fact, isn't this what you're effectively doing one you allow mass to temporarily go negative?

In other words, Haskell, like any other programming language, doesn't care about physics. If you can identify a relationship that generates a convergent sequence, you can implement it in Haskell (or whatever language you like).

Morn wrote:

For a while there was this fad to write scientific models in C++, but I think people soon discovered there are even more ways to shoot yourself in the foot in C++ than in Fortran. And the language is more malleable, so it's more difficult to understand and integrate someone else's code quickly.

There are some scientists/engineers that can barely handle Fortran 95, and requiring them to code in C++ would be a nightmare; I blame the excessive use of Matlab in the curriculum. Anyway, I think many of the development issues are mostly due to side-effects (non-intuitive mutations of state). So, perhaps FP could succeed even here.

Morn wrote:

Fortran compilers are still the most powerful tools for maximum parallel computation speed, and it might take a while for Haskell, Go, or any other competitor to fully catch up to that. And I'm saying that as someone who absolutely hates having to code anything in Fortran.

I realize that Fortran is the de-facto standard in HPC (our lab still uses it a lot). However, I think this may have more to do with legacy than some intrinsic property of the language. Consider:

(1) No one actually writes parallel code in Fortran. Either you augment your Fortran code with OpenMP directives (SMP/shared memory), or you use an MPI library (SPMD/distributed memory), or a hybrid of the two. In either case, the parallel model you're using has nothing to do with Fortran. What is even more interesting is that most MPI libraries are written in C. In regards to the "Fortran is faster than C" argument, this is dead now that C99 has the restrict keyword; I belive most C++ compiles also support the use of "restrict".

(2) There is some evidence to suggest that imperative languages are actually quite horrible for parallel computing, due to the possibility of non-deterministic behavior (see The Downfall of Imperative Programming). In fact, this is one of the principle reasons FP is being (re)considered by some developers.

As a side note, I think some members of the HPC community have misplaced values. I've literally heard some say, "speed is everything". They're like the Ricky Bobbys of computing. But what about correctness? Regardless of how fast your code is, if you're not 100% sure that it's doing what you intended it to do, then what is the point?


- Good judgement comes from experience; experience comes from bad judgement. -- Mark Twain
- There's a remedy for everything but death. -- The wise fool, Sancho Panza
- The purpose of a system is what it does. -- Anthony Stafford Beer

Offline

#15 2012-10-28 19:56:55

Morn
Member
Registered: 2012-09-02
Posts: 886

Re: So you learned functional programming. Any regrets?

fsckd wrote:

Morn, haskell doesn't restrict things like that. Haskell is not "mathematical" anymore than C is.

Maybe I was thinking of OCaml? I'm pretty sure there is a functional language where you write your function definitions almost like in mathematical notation, e.g. "where m is >= 0".

bsilbaugh wrote:

You bring up an interesting point. If a person is interested in modeling the long-term dynamics of some system (e.g. finding equilibrium points, periodic response, etc), it is common to use iterative techniques to "find" the equilibrium/periodic solution. In fact, use of time marching methods, with non-physical initial conditions, to compute steady solutions is quite popular in CFD. In your example, however, think for a moment about the requirement for mass to be positive. If I were to assert, "mass must be positive for all time", would I be making a mathematical assertion, or a physical one? In other words, wouldn't it be possible to create a mathematical model (a numerical method) with an abstract quantity that converges to "mass" in the limit? In fact, isn't this what you're effectively doing one you allow mass to temporarily go negative?

Yes, but I would want a FP language for physics to be more physical and to hide more numerical nitty-gritty. It should know about units and scaling factors, it should check units for me. Ideally it would only allow me to do stuff that physically makes sense. Maybe atmosphere models are particularly bad offenders, because right now they have so much stuff in them which does not e.g. guarantee conservation of mass, energy, and momentum. But things are changing slowly, thanks to faster computers and higher grid resolutions. No more need for Fourier transforms backward and forward at each time step, either. So these models are actually starting to look more like the equations they are supposed to solve.

As for Haskell, my question would be how good it is at handling large arrays. Does it have array slicing, etc., because that's a very important feature of both Fortran and Numpy.

bsilbaugh wrote:

There are some scientists/engineers that can barely handle Fortran 95, and requiring them to code in C++ would be a nightmare; I blame the excessive use of Matlab in the curriculum. Anyway, I think many of the development issues are mostly due to side-effects (non-intuitive mutations of state). So, perhaps FP could succeed even here.

Well, Matlab must have seemed revolutionary at the time. Compared to doing it all in Fortran with some numerical libraries, it was. It's just when you compare it to Python you realize the Matlab language leaves a lot to be desired.

I guess we've all been through a phase where we thought FP was the answer and solution to all programming problems. However, I think bugs exist because computer code sometimes does not look at all like the simple representation of a problem a human uses internally. So we have e.g. the elegant primitive equations in one corner and the messy procedural advection algorithm that nobody fully comprehends in the other corner. But not all problems are best expressed in FP. Sometimes procedural is best, sometimes OO. That's why multi-paradigm languages like Python and Common Lisp with CLOS are so popular (well, Python is, the problem with CL is mainly lack of standard libaries): You can select which approach gives you the shortest, most comprehensible representation of your problem as code. Understandable code is bug-free code.

But don't assume that lack of side effects alone is enough to make everyone's life easier. Data hiding via OO was supposed to be the magic bullet too and sometimes it's wonderful, but to me a language that only supports OO, or only FP, or only procedural isn't really worthy of consideration at this point anymore. I've been spoiled by Python and to a lesser extent, Common Lisp.

bsilbaugh wrote:

I realize that Fortran is the de-facto standard in HPC (our lab still uses it a lot). However, I think this may have more to do with legacy than some intrinsic property of the language. Consider:

(1) No one actually writes parallel code in Fortran. Either you augment your Fortran code with OpenMP directives (SMP/shared memory), or you use an MPI library (SPMD/distributed memory), or a hybrid of the two. In either case, the parallel model you're using has nothing to do with Fortran. What is even more interesting is that most MPI libraries are written in C. In regards to the "Fortran is faster than C" argument, this is dead now that C99 has the restrict keyword; I belive most C++ compiles also support the use of "restrict".

(2) There is some evidence to suggest that imperative languages are actually quite horrible for parallel computing, due to the possibility of non-deterministic behavior (see The Downfall of Imperative Programming). In fact, this is one of the principle reasons FP is being (re)considered by some developers.

Lately there seems to be a renewed interest in Haskell, specifically, I've noticed it too. I guess it would be useful to see some multi-core benchmarks for Haskell vs Fortran. I know there's a site with these benchmarks out there, I've visited it a few months ago, but I don't have the URL right now.

bsilbaugh wrote:

As a side note, I think some members of the HPC community have misplaced values. I've literally heard some say, "speed is everything". They're like the Ricky Bobbys of computing. But what about correctness? Regardless of how fast your code is, if you're not 100% sure that it's doing what you intended it to do, then what is the point?

Indeed, that's why Python is so great. I'd rather spend one hour writing a program that runs flawlessly for nine hours (and lets me read up on research papers in the meantime) than take nine hours writing and debugging a program that does the same work in an hour. Code correctness tests, unit tests for libraries, etc. are pretty commonplace now but still vastly underused in scientific computing.

But to answer the question in the first post, it's certainly a good idea to investigate FP and other languages in general, even if you are stuck with Fortran right now. It broadens you horizon. Definitely read "On Lisp" by Paul Graham, it's freely available at his site. See all the great Lisp features Python is still missing! And of course all other programming languages are just a subset of Lisp, so you save a lot of time by starting with it. smile

Last edited by Morn (2012-10-28 19:57:45)

Offline

#16 2012-10-28 20:11:11

Basu
Member
From: Cornell University
Registered: 2006-12-15
Posts: 296
Website

Re: So you learned functional programming. Any regrets?

Functional programming has its pros and cons. While i think that learning functional programming will make you a better programmer and software engineer for the rest of your days, that's a separate question for whether or not you should use it for your work today. Learning a strongly typed, functional programming language will give you a better understanding of how you should develop your data structures and write functions that manipulate them. Since you cannot just "reach in" and change things like in standard you will have to think more carefully about what your functions are doing and how to separate them into cleaner, well-defined components. I think you should learn functional programming even if you don't use it.

That being said, i do not think Haskell is a good fit for your use case. There is one feature of Haskell that I think makes it explicitly unsuitable for heavy duty computation: laziness. Haskell uses lazy evaluation. Basically arguments to a function are not evaluated when the function is called, but rather when those arguments are "needed". The problem with this approach is that it makes it harder to reason about the performance characteristics of your program and that might trip you up if you're doing computational heavy lifting.

I would suggest that you continue exploring functional programming on the side. Personally I use C and Python for most of my work but I write my Python in a pretty functional style for the most part. You will probably find ways to incorporate the lessons you've learned from functional programming into your work and code without having to move to a purely functional language. You'll find yourself separating your data and your operations and writing functions that do not depend on mutating external state. That will make your code easier to reason about and debug.

If you really do want to start using a functional language for your work, I suggest you look into OCaml instead. It is similar enough to Haskell that you'll be able to apply most of what you learned. But it does not use lazy evaluation so you won't get bitten by hard-to-trace performance issues.


The Bytebaker -- Computer science is not a science and it's not about computers
Check out my open source software at Github

Offline

#17 2012-10-28 20:57:18

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 19,739

Re: So you learned functional programming. Any regrets?

bsilbaugh,
Out of curiosity, what is the nature of what you are modeling?  If you cannot share that, can you share things such as the number of dimensions, whether you are doing time domain or freqency domain, etc...   

Also, on a personal note:  Best of wishes to you and the entire Eastern seaboard over the next couple days.  It looks like the storm may go north of you, but I still would not want to be on the bay.  I was in Solomon Island a couple years back; not the place to be in a hurricane.   Baton down and stay safe.


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way

Offline

#18 2012-10-29 02:34:51

bsilbaugh
Member
From: Maryland, USA
Registered: 2011-11-15
Posts: 141

Re: So you learned functional programming. Any regrets?

ewaller,

I specialize in computational aeromechanics; i.e. I develop and study (numerical) methods for physics based simulation (predictive modeling) of aerospace vehicle design concepts; i.e. numerically solving coupled fluid-structure-control problems. I work mostly in the time-domain, but time-spectral methods (frequency domain) are also of interest to me.

I'm the developer of a flexible multi-body dynamics code (for modeling arbitrary mechanical systems with flexible components), and I collaborate on the development of a CFD solver (overset URANS). I've also developed a software integration framework for coupling these two codes together to simulate fluid-structure-control problems.

Problem sizes are typically on the order of 40 million state variables. Certainly not huge by HPC standards. The bigger issue is that these problems tend to be rather stiff (large disparity in time scales); e.g. if the largest time scale is unity, then I need to take time steps on the order of 0.0001 for reasonable temporal accuracy. A typical run will take anywhere from 3 days (steady flight) to 2-weeks (maneuvers) on 32 cores (4 cluster nodes). Using more cores at this time is hard to justify due to limitations with our parallel efficiency; i.e. I can use more than 32 cores, but I won't see a justifiable reduction in runtime. All of this is just to compute the evolution of the state variables. An additional post processing of the state variables is usually required to extract the quantities of interest (e.g. vortical structures, structural loads, vibration, acoustics, etc); this is usually done on a multicore workstation.

P.S. Thanks for the well wishes regarding the "perfect storm" that's about to hit. The nice thing about hurricanes is that you can see them coming and prepare.


- Good judgement comes from experience; experience comes from bad judgement. -- Mark Twain
- There's a remedy for everything but death. -- The wise fool, Sancho Panza
- The purpose of a system is what it does. -- Anthony Stafford Beer

Offline

#19 2012-10-29 02:59:48

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 19,739

Re: So you learned functional programming. Any regrets?

bsilbaugh wrote:

The nice thing about hurricanes is that you can see them coming and prepare.

The funny part is that I prefer our earthquakes -- They are come-as-you-are; no anxiety as to whether it will hit or miss, no chance to prepare, no runs to the sold out stores, no deciding whether to take precautions or if things will be okay.   

Take care, see you on the other side.


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way

Offline

#20 2012-10-29 14:51:09

Morn
Member
Registered: 2012-09-02
Posts: 886

Re: So you learned functional programming. Any regrets?

Back on topic, I think we need to differentiate between basic FP that you can even do in plain C by passing function pointers, e.g. mapping an input function to an array, and more powerful FP as e.g. in Lisp. Lisp higher-order functions (macros) are more like accessing the parse tree in Python, except less clunky. In Lisp, you don't program so much in the language as adapt the language via macros to fit the problem domain. You can change absolutely everything about how it behaves. (No wonder the first computer algebra systems like Reduce or Macsyma were all written in Lisp.)

The main problem with Lisp for physical sciences is probably finding modules for e.g. NetCDF output or plotting. Otherwise I would definitely use CL instead of the slower Python. The main advantage of Python is the modules included in the standard distribution. Just add Numpy and perhaps Scipy and you are good to go.

I've always wondered why Lisp isn't more popular in science. I've certainly noticed that quite a few scientists love to fiddle endlessly with their Emacs configurations. Then again, Emacs Lisp is a "bad Lisp" IMO (e.g., dynamic scope), so maybe that's the explanation right there: Emacs Lisp scares everyone away from CL because they think it's just MOTS.

In short, there are plenty of other reasons for looking into FP, not just the parallel programming benefits (that may or may not be an improvement over the classic Fortran approach), but also self-modifying code and domain-specific languages. Things that go beyond the more basic benefit of hiding a few side effects via FP.

Offline

#21 2012-10-30 15:09:25

bsilbaugh
Member
From: Maryland, USA
Registered: 2011-11-15
Posts: 141

Re: So you learned functional programming. Any regrets?

basu wrote:

That being said, i do not think Haskell is a good fit for your use case. There is one feature of Haskell that I think makes it explicitly unsuitable for heavy duty computation: laziness. Haskell uses lazy evaluation. Basically arguments to a function are not evaluated when the function is called, but rather when those arguments are "needed". The problem with this approach is that it makes it harder to reason about the performance characteristics of your program and that might trip you up if you're doing computational heavy lifting.

So, are you implying that Haskell generally yields poor performance, or simply that its performance is hard to predict, or even non-deterministic? (I have no idea how an FP compiler works.)

In regards to Haskell's performance, these benchmarks suggest that GHC can generate reasonably efficient machine code. Although, I realize that these benchmarks may not be a good representation of real-world performance.

There are some cases where a person is researching a particular algorithm (for academic reasons) and wants study its algorithmic complexity. For example, showing that naive square matrix multiplication is on the order of N^3, whereas the Fast Multipole Method (FMM) scales on the order of N*log(N). In this case, I could see why lazy evaluation (and FP in general) might be a poor choice, as you have little control over how your expressions are evaluated. I presume you could still implement an algorithm like FMM, but it might scale differently? (Similar questions could be raised regarding the impact of FP on the algorithmic complexity of sorting algorithms.)

On the other hand, there are times when a person simply wants to solve a system of equations, or evaluate an (complicated) expression. What matters most is that they can consistently get the right answer at a reasonable cost. For example, solving a moderate sized system of ODE's using the Runge Kutta method. In this case, I would care more about preserving its numerical stability and accuracy than algorithmic complexity (so long as it doesn't take too long). Perhaps lazy evaluation would be less of an issue in this case?


- Good judgement comes from experience; experience comes from bad judgement. -- Mark Twain
- There's a remedy for everything but death. -- The wise fool, Sancho Panza
- The purpose of a system is what it does. -- Anthony Stafford Beer

Offline

#22 2012-11-01 18:38:40

Basu
Member
From: Cornell University
Registered: 2006-12-15
Posts: 296
Website

Re: So you learned functional programming. Any regrets?

The performance is hard to reason about and unpredictable. You can force strict evaluation of particular expressions but that makes your code look very awkward if you do it too much. By and large Haskell's actual performance is pretty good. A lot of work has gone into GHC and it has good support for concurrency as well, but laziness can give you unpredictable performance in certain cases. If that isn't an issue and you mostly care about getting the right answer and performant code in most cases then yes, Haskell can still be a good choice, especially if your problem is naturally expressible as function applications to start with.


The Bytebaker -- Computer science is not a science and it's not about computers
Check out my open source software at Github

Offline

#23 2012-11-04 08:38:58

EN1RA
Member
Registered: 2012-08-14
Posts: 4

Re: So you learned functional programming. Any regrets?

Basu wrote:

The performance is hard to reason about and unpredictable. You can force strict evaluation of particular expressions but that makes your code look very awkward if you do it too much. By and large Haskell's actual performance is pretty good. A lot of work has gone into GHC and it has good support for concurrency as well, but laziness can give you unpredictable performance in certain cases. If that isn't an issue and you mostly care about getting the right answer and performant code in most cases then yes, Haskell can still be a good choice, especially if your problem is naturally expressible as function applications to start with.

This sums up Haskell pretty well when it comes to performance. Make no doubt about it, Haskell is very fast given how unfriendly it's paradigms are to your computer's Turing machine model of computation. Last benchmark I looked at had it beat only by lower-level imperative languages like C and Fortran. That's pretty good given how high-level it is. Laziness can be a pain and is one of the most significant disadvantages about Haskell in my opinion, but you gain a lot in return. GHC is really good at taking advantage of the extreme features of the language that most others don't have. You'd think purity and laziness would make for a horrible language, but in Haskell you can have nice performance and eat your cake too. Though it bugs me that Haskell's advertised elegance has a tendency to run counter to its performance.

bsilbaugh wrote:

(1) No one actually writes parallel code in Fortran. Either you augment your Fortran code with OpenMP directives (SMP/shared memory), or you use an MPI library (SPMD/distributed memory), or a hybrid of the two. In either case, the parallel model you're using has nothing to do with Fortran. What is even more interesting is that most MPI libraries are written in C. In regards to the "Fortran is faster than C" argument, this is dead now that C99 has the restrict keyword; I belive most C++ compiles also support the use of "restrict".

(2) There is some evidence to suggest that imperative languages are actually quite horrible for parallel computing, due to the possibility of non-deterministic behavior (see The Downfall of Imperative Programming). In fact, this is one of the principle reasons FP is being (re)considered by some developers.

This, I think, will be the deciding factor behind FP's future in mainstream usage. If things like Cloud Haskell, Eden, Parallel Haskell, and Concurrent Haskell can bear fruit and make GHC and the core language notably friendly to parallel programming, then I'd say Haskell's got a serious future. Programming parallelism in C and MPI feels very unnatural and there are colleges out there that are starting their students off with functional languages rather than imperative ones because there is no point in preparing your students for a world of parallelism with a programming language that is inherently antagonistic towards the idea.

Provided Haskell conquers these two challenges of parallelism and lazy evaluation, I can't see any reason why investing time in it could be a waste.

Offline

#24 2012-11-04 09:25:10

kinleyd
Member
From: Bhutan
Registered: 2012-09-21
Posts: 142

Re: So you learned functional programming. Any regrets?

I like Clojure a lot. I find it has the right balance of good design, simplicity, and code elegance, as well as powerful features like concurrency and immutability. I find its support for functional programming and embrace of open data structures, particularly hash tables or maps, a refreshing alternative to the OOP paradigm. No regrets going with FP here.

Offline

#25 2012-11-08 10:08:42

Nisstyre56
Member
From: Canada
Registered: 2010-03-25
Posts: 85

Re: So you learned functional programming. Any regrets?

Morn wrote:

excessive mathematical correctness might prevent you from getting any results at all, e.g. if Haskell thinks mass has to always be positive for a valid solution.

You wouldn't get that with Haskell unless you introduce ad-hoc dependent types via type arithmetic or something. If you were using a language like Agda or Epigram you would (but only if you used a type like Nat or something, which doesn't allow for negative integers).

fsckd wrote:

Morn, haskell doesn't restrict things like that. Haskell is not "mathematical" anymore than C is.

This is actually not true, you can have type level restrictions that do not allow certain values, see: http://www.haskell.org/haskellwiki/Smar … ype_system

Last edited by Nisstyre56 (2012-11-08 10:11:23)


In Zen they say: If something is boring after two minutes, try it for four. If still boring, try it for eight, sixteen, thirty-two, and so on. Eventually one discovers that it's not boring at all but very interesting.
~ John Cage

Offline

Board footer

Powered by FluxBB