197

I've read some texts about declarative/functional programming (languages), tried out Haskell as well as written one myself. From what I've seen, functional programming has several advantages over the classical imperative style:

  • Stateless programs; No side effects
  • Concurrency; Plays extremely nice with the rising multi-core technology
  • Programs are usually shorter and in some cases easier to read

  • Productivity goes up (example: Erlang)

  • Imperative programming is a very old paradigm (as far as I know) and possibly not suitable for the 21st century

Why are companies using or programs written in functional languages still so "rare"?

Why, when looking at the advantages of functional programming, are we still using imperative programming languages?

Maybe it was too early for it in 1990, but today?

Péter Török
  • 114,404
  • 31
  • 268
  • 329
pankrax
  • 2,037
  • 3
  • 13
  • 5
  • 1
    **NOTE:** this question has been discussed on meta at least twice, and the consensus is that it *should* be kept, albeit archived via the "historical significance" lock mentioned above. I strongly encourage anyone viewing this with an eye toward unlocking it to instead stop and give thanks for not having to participate in yet another tedious discussion about this question, enjoy the answers as they are, and go on about their business. – Shog9 Feb 29 '16 at 21:05

11 Answers11

529

Because all those advantages are also disadvantages.

Stateless programs; No side effects

Real-world programs are all about side effects and mutation. When the user presses a button it's because they want something to happen. When they type in something, they want that state to replace whatever state used to be there. When Jane Smith in accounting gets married and changes her name to Jane Jones, the database backing the business process that prints her paycheque had better be all about handling that sort of mutation. When you fire the machine gun at the alien, most people do not mentally model that as the construction of a new alien with fewer hit points; they model that as a mutation of an existing alien's properties.

When the programming language concepts fundamentally work against the domain being modelled, it's hard to justify using that language.

Concurrency; Plays extremely nice with the rising multi-core technology

The problem is just pushed around. With immutable data structures you have cheap thread safety at the cost of possibly working with stale data. With mutable data structures you have the benefit of always working on fresh data at the cost of having to write complicated logic to keep the data consistent. It's not like one of those is obviously better than the other.

Programs are usually shorter and in some cases easier to read

Except in the cases where they are longer and harder to read. Learning how to read programs written in a functional style is a difficult skill; people seem to be much better at conceiving of programs as a series of steps to be followed, like a recipe, rather than as a series of calculations to be carried out.

Productivity goes up (example: Erlang)

Productivity has to go up a lot in order to justify the massive expense of hiring programmers who know how to program in a functional style.

And remember, you don't want to throw away a working system; most programmers are not building new systems from scratch, but rather maintaining existing systems, most of which were built in non-functional languages. Imagine trying to justify that to shareholders. Why did you scrap your existing working payroll system to build a new one at the cost of millions of dollars? "Because functional programming is awesome" is unlikely to delight the shareholders.

Imperative programming is a very old paradigm (as far as I know) and possibly not suitable for the 21th century

Functional programming is very old too. I don't see how the age of the concept is relevant.

Don't get me wrong. I love functional programming, I joined this team because I wanted to help bring concepts from functional programming into C#, and I think that programming in an immutable style is the way of the future. But there are enormous costs to programming in a functional style that can't simply be wished away. The shift towards a more functional style is going to happen slowly and gradually over a period of decades. And that's what it will be: a shift towards a more functional style, not a wholesale embracing of the purity and beauty of Haskell and the abandoning of C++.

I build compilers for a living and we are definitely embracing a functional style for the next generation of compiler tools. That's because functional programming is fundamentally a good match for the sorts of problems we face. Our problems are all about taking in raw information -- strings and metadata -- and transforming them into different strings and metadata. In situations where mutations occur, like someone is typing in the IDE, the problem space inherently lends itself to functional techniques such as incrementally rebuilding only the portions of the tree that changed. Many domains do not have these nice properties that make them obviously amenable to a functional style.

Sarah Vessels
  • 30,930
  • 33
  • 155
  • 222
Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
  • 41
    "When Jane Smith in accounting gets married and changes her name to Jane Jones, the database backing the business process that prints her paycheque had better be all about handling that sort of mutation." There will be a record Jane Smith's former name, we don't retroactively update all instances of Jane's former name to her new name ;) – Juliet May 14 '10 at 16:55
  • 40
    @Juliet: Sure. My point is that if you have an object that represents an employee, it makes sense to think of the operation "change the name of the employee" to be a mutation of the object representing the employee *that does not change object identity*. When Jane Smith changes her name you don't create a *different* employee called Jane Jones that is otherwise the same. There aren't two employees with two different names. It is natural to model this process as a mutation of an object, not as the construction of a new object. – Eric Lippert May 14 '10 at 16:58
  • Funtional programming is indeed old. Is there any high-level programming language older than LISP? – Gabe May 14 '10 at 17:00
  • 24
    This is a good answer, but I think you overstate your case at times. Like Juliet said, although people might think of it as a name change, it really is a name replacement on a deeper level. And although functional programs might be harder for people to read (because it *is* a learned skill), that isn't generally because they're longer. A Haskell program will almost always be more terse than, say, a Java program — even in a "bad fit" domain with lots of inherent state. – Chuck May 14 '10 at 17:17
  • 4
    @Chuck: Harder to read doesn't necessarily mean longer. While Java is a very verbose language, it's possible to write it so that it reads close to plain English. My experience with functional languages is limited, but I've usually had to switch mental gears and parse out the syntax before beginning to understand the code. – Adam Lear May 14 '10 at 17:25
  • 2
    Look at the brilliant design of F#, which blends functional, concurrent, procedural, and OO styles, including access to the .NET BCL and non-F# .NET assemblies. If F# had been strictly a functional language derived from ML and OCaml its relevance, usefulness, and adoption rate in the .NET universe would be much less. – Simon Chadwick May 14 '10 at 17:33
  • @Chuck: The point is that you're replacing (or updating) the name, NOT creating a whole new employee with a different name who has all of the same attributes, characteristics, etc. Looking at it from a real-world point of view, you don't fire a person just because their name changes and then re-hire them immediately with a new name. In a "Grand Design" view, you aren't taking someone's life (with your own hands/program) and then creating a new person who IS that newly deceased person except that the person's name is different. – Dustin May 14 '10 at 22:54
  • 2
    @Gabe: Well, FORTRAN, but just by a year or so. – Tim Goodman May 15 '10 at 17:44
  • 29
    +1 It was such a breath of fresh air to read this answer. Fantastic to hear such pragmatism (with an underlying passion for functional programming) from someone in your position. – Dhaust Aug 03 '10 at 05:13
  • 3
    Random perspective from Philosophy (Specifically the problem of personal identity and free will) which I'll just state rather than support (hard to do with this character limit): when you shoot that Alien, a new Alien with less hitpoints is indeed returned. Whether you mutate state or take an old state to return a new one they are both just two ways of modelling the same thing. That "same thing" is an abstraction that transcends any one true representation. So use whichever one gets the job done faster :) (Freaking epic post btw. I wish I could upvote again) – TheIronKnuckle Dec 05 '11 at 12:18
  • 11
    "Because all those advantages are also disadvantages. Stateless programs; No side effects": As far as I understand (I do not know enough about FP to write an authoritative answer) this is **not correct**. Functional programming is about referential transparency not about avoiding state (even though state must be handled appropriately to ensure referential transparency). Haskell **does allow** state and mutation. It just provides different (one could argue, better) tools for reasoning about it. – Giorgio Mar 21 '13 at 12:49
  • 1
    That name change after marriage is a bad example. What if Jane Jones later gets divorced (let's just focus on the problem itself), should she be given a new name which is her old name, or should she just get her old name back. In terms of FP, when Jane gets a new name, her old name val is shadowed by the new one, but after her marriage context is finished, that shadow is gone, and her name val automatically falls back to the old one. – Sheng Oct 09 '13 at 14:42
  • 3
    @sheng I assure you that is not how name changes work legally, and it is therefore probably a bad idea to model them like that. Don't get caught up in the details of the example. The point is that things change, and so it makes sense to model that as mutations that preserve identity. – Eric Lippert Oct 09 '13 at 14:54
  • @EricLippert My point is if you consider Jane herself as an object (FP can live together with OOP, Scala is such an example), when her name changes, we create a new object with name equal to the new one, and all the other attributes still point to whatever they were before the change. Note that there is no mutation happening here. Once the living period the new name expires, we just need to fall back to the old name, and then the new object naturally falls back to the old. It is not a terrible idea, and as far as I know things like STM and GIT share some similar aspects. – Sheng Oct 09 '13 at 17:46
  • 2
    @Sheng: But that's not how name changes work with respect to marriage and divorce. It's not that Jane has one last name and then another last name in the context of her marriage, and then reverts back to the previous name when she is divorced. Rather, a marriage, a divorce and a name change are all separate legal events; one simply files the change-of-legal-name paperwork at the same time as the marriage or divorce papers are filed. Modeling it as a *reversion* to the previous state is wrong; it is two mutations. – Eric Lippert Oct 09 '13 at 17:52
  • 5
    @Sheng: But again, that's not relevant to my point. We have languages with mutation and with referential identity because *the domains we intend to model are domains that have mutation and referential identity*. Can we simulate both those things in functional languages? Of course. Can we successfully write programs in functional languages to model these domains? Of course. But when the idioms of a language naturally match the characteristics of the modeled domain, it is easier for developers to understand and maintain the mapping from the real world to the model. – Eric Lippert Oct 09 '13 at 17:54
  • @EricLippert: After divorce, Jane not necessary needs to fall back to the one before marriage, she could become a new entity. From the perspective of FP, these 2 objects are the same and least of its concern, but I guess this thought would definitely worry the imperative programmers. Also you think Jane before and after her name change is the same entity, and mutation would be a great fit in this case. I can also argue she has become a new entity after name change. It's sort of like a philosophical argument, but this is exactly the difference/conflicts between imperative p and functional p. – Sheng Oct 09 '13 at 19:37
  • @EricLippert: "My point is that if you have an object that represents an employee, it makes sense to think of the operation "change the name of the employee" to be a mutation of the object representing the employee that does not change object identity". Actually that does not make sense at all. In most practical cases in the real world you want to add an update and retain the old information for auditability and validation purposes (legally required in the finance and insurance industries). I've seen a lot of real problems caused by this idea that defacing yesterday's data "makes sense". – J D Mar 27 '15 at 15:02
  • "But when the idioms of a language naturally match the characteristics of the modeled domain, it is easier for developers to understand and maintain the mapping from the real world to the model". Just because you cannot time travel in the real world does not mean your software should not be able to rerun old queries. – J D Mar 27 '15 at 16:30
  • 1
    "We have languages with mutation and with referential identity because the domains we intend to model are domains that have mutation and referential identity". That's ridiculous. C# has that because C had that because Algol had that because it was a thin veneer over mutable registers and the addresses of mutable memory locations. The only thing from the real world that is accurately modeled by that is the internal workings of a computer. – J D Mar 27 '15 at 16:35
  • This is written from the perspective of someone who does *not* know FP. Ex: (1) FP does have state...restricted to a specified location (onValue, doAction). So programs are easier to reason about. (2) You miss the whole point of FP and concurrency. It's super easy to write concurrent programs in FP! Can't believe this is the most popular answer. – U Avalos Jul 02 '15 at 19:23
  • 2
    @UAvalos: I have said many times that functional techniques make reasoning about programming easier, and that functional techniques are key to taming concurrency problems. However, it is not a panacea; complex state and complex control flows ultimately result in complex programs regardless of the style used. I believe I understand functional programming techniques reasonably well, having spent a great many years designing functional features into programming languages, and using those techniques in building their compilers. – Eric Lippert Jul 02 '15 at 19:29
37

Masterminds of Programming: Conversations with the Creators of Major Programming Languages

[Haskell]

Why do you think no functional programming language has entered the mainstream?

John Hughes: Poor marketing! I don't mean propaganda; we've had plenty of that. I mean a careful choice of a target market niche to dominate, followed by a determined effort to make functional programming by far the most effective way to address that niche. In the happy days of the 80s, we thought functional programming was good for everything - but calling new technology "good for everything" is the same as calling it "particularly good at nothing". What's the brand supposed to be? This is a problem that John Launchbury described very clearly in his invited talk at ICFP. Galois Connections nearly went under when their brand was "software in functional languages," but they've gone from strength to strength since focusing on "high-assurance software."

Many people have no idea how technological innovation happens, and expect that better technology will simply become dominant all by itself (the "better mousetrap" effect), but the world's just not like that.

Community
  • 1
  • 1
Nick Dandoulakis
  • 42,588
  • 16
  • 104
  • 136
27

The stock answer is that neither will or should replace the other - they are different tools that have different sets of pros and cons, and which approach has the edge will differ depending on the project and other "soft" issues like the available talent pool.

I think you're right that the growth of concurrency due to multi-core will increase the percentage (of the global set of development projects) when functional programming is chosen over other styles.

I think it's rare today because the majority of today's professional talent pool is most comfortable with imperative and object-oriented technologies. For example, I have more than once chosen Java as the language for a commercial project because it was good enough, non-controversial, and I know that I will never run out of people that can program (well enough) in it.

G__
  • 7,003
  • 5
  • 36
  • 54
  • This is very insightful and delightfully pragmatic. Definitely the best answer I've seen to this question in all its forms. – Benson May 14 '10 at 16:46
  • Maybe by a language for which both are first class citizens will become popular. – Kevin Kostlan Nov 17 '14 at 20:12
  • 1
    Agree 110%. On several occasions, I've tried to get into FP, but I lost the will to continue after a few weeks. I've been programming procedurally for over 30 years and I'm just too used to imperative programming. This is true of the IT industry at large. Change will not come easily nor quickly. – Richard Eng Jun 23 '15 at 16:04
26

Despite the advantages of functional programming, imperative and object oriented programming will never go away completely.

Imperative and object-oriented programming is a step-by-step description of the problem and its solution. As such, it can be easier to comprehend. Functional programming can be a bit obscure.

Ultimately, a useful program will always have side effects (like providing actual output to the user for consumption), so the purest of functional languages will still need a way to step into the imperative world from time to time.

The current state-of-the-art is that imperative languages (such as C#) borrow features from the functional world (such as lambda statements) and vice-versa.

Anton Tykhyy
  • 19,370
  • 5
  • 54
  • 56
Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
  • 3
    Isn't OOP some sort of subset of imperative programming? – pankrax May 14 '10 at 16:35
  • 9
    OOP is a superset. OOP is to imperative as C++ is to C. – Robert Harvey May 14 '10 at 16:44
  • 10
    I don't think OOP is necessarily reliant on imperative programming. Look a Clojure or CLOS -- both are functional, yet object-oriented. – Gabe May 14 '10 at 16:55
  • 9
    OO languages tend to be imperative, but don't have to be. OCaml is a strongly (though not purely) functional language whose entire raison d'etre is OO. – Chuck May 14 '10 at 17:09
  • 1
    and then you can get OO languages which are neither imperative nor functional. Like good old Smalltalk – TheIronKnuckle Dec 05 '11 at 12:20
  • 7
    I am not getting why OOP is a superset of imperative programming. Not all imperative code is OOP, and not all functional code is non-OOP. I would rather say that OOP is to imperative programming and functional programming like aerodynamic wings are to racing cars, or planes, or rockets, or cooling fans, or windmills, or ... i.e., the concepts are related, but not tightly coupled in a 1-to-1 connection. – Sebastian Mach May 24 '13 at 09:27
  • I agree. Almost every application I've worked on was typically "a set of things that happen and the changing of state in response to interactions with a user". Only very small parts of these applications required purely functional concepts. Structured, imperative and object oriented programming seems to just make more sense, at least for most common applications' needs. – Nick Bedford Apr 16 '15 at 01:19
21

Hasn't it?

Smalltalk was a great object-oriented system back in the day. Why hasn't object-oriented programming taken over? Well, it has. It just doesn't look like Smalltalk. Mainstream languages keep getting more Smalltalk-like with C++, Java, C#, etc. Fashion and style change slower than anything, so when OO went mainstream, we got it by gluing parts of OO to old languages so it looked enough like C to swallow.

Functional is the same way. Haskell was a great functional language. But we've got even more mass of mainstream programmers using C-like syntax today than 20 years ago. So it has to look like C. Done: look at any LINQ expression and tell me it isn't functional.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Ken
  • 9,797
  • 3
  • 16
  • 14
  • 2
    Interesting point, but how have mainstream languages been getting more Smalltalk-like? C++, Java and C#, for instance, are not based on message-sending, which (I believe) is the most important part of the Smalltalk paradigm. – Jonathan Sterling May 16 '10 at 03:06
  • 4
    Jonathan: Pick any Smalltalk feature, and observe how it's weakest in C++ (the oldest), OK in Java, and better in C#. For example, GC (Java/C# only), autoboxing (later Java/C# only), closures (C# only), and reflection (present in Java, better in C#). If you want message-passing, look at C# 4's `dynamic`. That's the most Smalltalk-y of these features, so it's no surprise to me that it's only present in the latest version of the most modern of these three languages. :-) – Ken Jun 02 '10 at 17:54
  • Javascript, python, and ruby are good illustrations of how it indeed has – nafg May 20 '14 at 06:47
15

I believe that imperative languages are more prevalent simply because that's what more people are used to. Neither functional programming nor the imperative programming model is more obscure or academic than the other. In fact, they are complements.

One poster said that imperative code is easier to understand than functional programming code. This is only true if the reader has already seen imperative code, especially if the prior examples are part of the same "family" (for example, C/C++, Perl, PHP and Java). I would not claim that it's true for any imperative language; take a comparison of Java and Forth, to make an extreme example.

To a layperson, all programming languages are indecipherable gibberish, except maybe the verbose languages such as Hypertalk and SQL. (Of note, SQL is a declarative and/or functional language and enjoys enormous popularity.)

If we had been initially trained on a Lisp-y or Haskell-y language from the start, we'd all think functional programming languages are perfectly normal.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Barry Brown
  • 20,233
  • 15
  • 69
  • 105
  • "One poster said that imperative code is easier to understand than functional programming code. This is only true if the reader has already seen imperative code, especially if the prior examples are part of the same "family" (for example, C/C++, Perl, PHP and Java).": Very true (+1): I remember how much effort I had to put into learning Pascal and C when I started to program. And how easy it is to read Scala, Haskell or Scheme now that I have some experience with these languages. – Giorgio Nov 11 '12 at 11:13
  • 2
    The only reason why I still consider mutable state useful sometimes is that it offers an easy way to write fast code (no copying); but the reason for that might be that I do not know enough functional programming and that, for 90% of the situations, you can write fast functional code without using mutable state. – Giorgio Nov 11 '12 at 11:15
  • 3
    One of the most widely used, and long-lived, environments for organising computation is the spreadsheet; essentially a functional programming environment with cells rather than named variables. I don't believe that people, in general, inherently conceive of programs as a series of steps. Programmers steeped in widespread imperative languages, maybe. – jpnp Jan 23 '14 at 16:08
14

You've gotten enough answers already that I'll mention only a couple of things I don't see mentioned yet.

First and (in my mind) foremost, procedural languages have benefited greatly from their degree of commonality. For one example, almost anybody who knows almost any of the mainstream procedural (or OO) languages to almost any degree can read most of the others reasonably well. I actively avoid working in Java, C#, Cobol, Fortran, or Basic (for just a few examples) but can read any of them reasonably well -- almost as well, in fact, as people who use them every day.

On the functional side, that's much less true. Just for example, I can write Scheme quite reasonably as well, but that's of little use in reading Ocaml or Haskell (for only a couple of examples). Even within a single family (e.g., Scheme vs., Common Lisp) familiarity with one doesn't seem to translate nearly as well to the other.

The claim that functional code is more readable tends to be true only under a narrow range of conditions. For people who are extremely familiar with the language, readability is indeed excellent -- but for everybody else, it's often next to nonexistent. Worse, while differences in procedural languages are largely of syntax and therefore relatively easily learned, differences in functional languages are often much more fundamental, so they require considerable study to really understand (e.g., knowing Lisp is of little help in understanding Monads).

The other major point is that the idea that functional programs are shorter than procedural ones is often based more on syntax than semantics. Programs written in Haskell (for one example) are often quite short, but its being functional is a rather small part of that. A great deal if it is simply that Haskell has a relatively terse syntax.

Few purely functional languages can compete well with APL for terse source code (though, in fairness, APL supports creating higher level functions as well, so that's not quite a large a difference as in some other cases). Contrariwise, Ada and C++ (for only a couple examples) can be quite competitive in terms of number of operations necessary to accomplish a given task, but the syntax is (at least usually) substantially more verbose.

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
  • Excellent comment! I agree wholeheartedly. I find most procedural languages fairly easy to read and understand, even though I'm only a bona fide expert in a couple of them. Can't say the same about FP languages. – Richard Eng Jun 23 '15 at 16:30
  • 1
    Another important point is, in any given paradigm, you find a range of expertise, from newbies to gurus. FP code may be easily readable and comprehensible for experts, but middling programmers may still struggle. Experts usually comprise a very small fraction of the FP community. – Richard Eng Jun 23 '15 at 16:37
11

No Perceived Need

I recall my old Boss Rick Cline's response when I showed him a copy of John Backus' Turing Award lecture entitled Can Programming Be Liberated from the von Neumann Style?

His response: "Maybe some of us don't want to be liberated from the von Neumann style!"

Mark Harrison
  • 297,451
  • 125
  • 333
  • 465
10

Why hasn't functional programming taken over yet?

Functional is better for some things and worse for others so it will never "take over". It is already ubiquitous in the real world though.

Stateless programs; No side effects

Stateless programs are easier to test. This is now widely appreciated and often exploited in industry.

Concurrency; Plays extremely nice with the rising multi-core technology Programs are usually shorter and in some cases easier to read Productivity goes up (example: Erlang)

You're conflating concurrent and parallelism.

Concurrency can be done effectively using communicating sequential processes (CSP). The code inside a CSP can mutate its local state but the messages sent between them should always be immutable.

Purely functional programming plays extremely badly with multicore because it is so cache unfriendly. Cores end up contending for shared memory and parallel programs don't scale.

Why are companies using or programs written in functional languages still so "rare"?

Scala is often regarded as a functional language but it is no more functional than C# which is one of the most popular languages in the world today.

Why, when looking at the advantages of functional programming, are we still using imperative programming languages?

Purely functional programming has lots of serious disadvantages so we use impure functional languages like Lisp, Scheme, SML, OCaml, Scala and C#.

J D
  • 48,105
  • 13
  • 171
  • 274
7

When I think about what functional programming might bring to my projects at work I'm always led down the same path of thought:

  1. To get the full advantages of functional programming you need laziness. Yes, there are strict functional languages, but the real benefits of functional programming don't shine as well in strict code. For example, in Haskell it's easy to create a sequence of lazy operations on a list and concatenate them and apply them to a list. Eg. op1 $ op2 $ op3 $ op4 $ someList. I know that it's not going to build the entire list and internally I'm just going to get a nice loop that walks through the elements one at a time. This allows you to write really modular code. The interface between two modules can involve handing over potentially vast data structures, and yet you don't have to have the structure resident.

  2. But when you have laziness, it becomes hard to reason about memory usage. Changing the Haskell compiler flags frequently changes the amount of memory used by an algorithm from O(N) to O(1), except sometimes it doesn't. This isn't really acceptable when you have applications that need to make maximum use of all available memory, and it's not great even for applications that don't need all memory.

Lance Roberts
  • 22,383
  • 32
  • 112
  • 130
sigfpe
  • 7,996
  • 2
  • 27
  • 48
  • Laziness also interacts less-than-ideally with debugging. – Brian May 15 '10 at 00:35
  • 3
    As I find that many of the bugs I chase in other languages are related to lack of referential transparency I'm less worried about the debugging issues, even though they can be a pain sometimes. – sigfpe May 15 '10 at 23:15
6

Two things:

  1. It just takes time no matter how good a technology is. The ideas behind FP is about 70 years old. But its mainstream usage in Software Engineering (in the trenches, in industry) is probably less than 10 years. Asking developers to adopt racially new mindsets is possible but just takes time (many, many years). For example, OOP really got mainstream usage in the early 1980's. However, it did not gain dorminance until the late 1990's.
  2. You need people to be forced to face a technology's strength before it hits it big. Currently, people are using tools that does not not make use of parallelism and things works okay. When apps that do not use parallelism become unbearably slow; then many people will be forced to use parallelism-tools and FP may shot up in popularity. This may also apply to FP's other strengths.
Phil
  • 2,143
  • 19
  • 44
  • 3
    FP is _very_ good at code reuse. Probably better then OO. I've had to deal with it at work a few times, migrating to different types, and a new system and it was painless. – nlucaroni May 14 '10 at 17:35
  • @Freddy Rios and @nlucaroni. I reworded the comment to clear up misinterpretation. – Phil May 14 '10 at 22:30