3 ms·

Notable quote: That's one option: to admit that functional programming is the wrong paradigm for some types of problems. Fair enough. I'd put money on that. Bu

Notable quote: That's one option: to admit that functional programming is the wrong paradigm for some types of problems. Fair enough. I'd put money on that. But it also may be that almost no one has been thinking about problems like this, that functional programming attracts purists and enamored students. The language features that help with the problems small programs have are intrinsically easier to show off than those that help manage larger systems. Beyond a certain point, I don't care how easy something makes a program that will never grow beyond a page, though. (If that isn't easy, your language has serious problems!) I'm more interested in how these techniques / paradigms break down, not how well they work on examples chosen for them. You can't always choose your problems. (And yes, one of the main things I've learned from Unix is that it's usually better to break large systems into a team of smaller components, but that's neither here nor there. Also, informed use of multiple paradigms is likely the best long-term approach, but that's not a position that necessarily translates well into sound-bytes.) Of course, it's easier to hype languages that let you do short parlor tricks, particularly on web forums. Also, he has a followup posted here: http://prog21.dadgum.com/4.html http://prog21.dadgum.com/4.html

miloshh 17y ago
languages that let you do short parlor tricks Quite the opposite - functional programming is becoming very appealing as a practical alternative for building large, multi-threaded, correct systems. True, it might be a bit more tedious to write a program that type-checks, but as many (including me) have been repeatedly amazed, it often works correctly right away, with minimal debugging. But it also may be that almost no one has been thinking about problems like this Mutable state is a fundamental issue that every functional programmer deals with every day. Indeed, it might be sometimes frustrating to pass around state that in C would be directly modifiable, but the benefits are huge. Pure code has been called a "scarce resource", and that's exactly right - once it works, it will always work, no matter how huge is the system you build on top of it.
- silentbicycle 17y ago
  OCaml is one of my favorite languages. I use it, despite its many warts, because it works. (I think there's a much smaller, cleaner language waiting to get out, though.) I wish more languages had decent module systems, for example. The ML family does this better than most, but I bet it's not a very glamorous area to experiment in, because it's hard to really show the benefits of a well-designed module system in small examples. That's what I'm complaining about. BUT, pure functional programming is an intrinsically poor fit for some problems, and this is seldom addressed by hype. I think functional programming hype needs a reality check now, the same way C++-style OO hype could have used more way back when. I think we would all be better off if, instead of heralding it as the next technique that solves all problems, we work on getting a clearer idea of its strengths and weaknesses.
  - miloshh 17y ago
    Oh, I agree with the strengths and weaknesses, and obviously I don't use FP for all my programming. But I somehow cannot see any functional programming hype. Where are the people heralding it as solving all problems? Even in a place like HN with a highly non-average community of programmers, the FP links are quite rare and very intro-level. I would say FP is a high-hanging fruit that's only starting to find a few niches in real-world programming. So I son't see anything close to an FP hype, nowhere near to the Java hype or Ruby hype.
    - AlisdairO 17y ago
      Reddit has an ...ardent community, and I suspect regulars there may gain an unrealistic impression of the amount of FP hype there is out in the wider world.
  - jganetsk 17y ago
    I'm disappointed that I have yet to see a decent discussion on HN on comparing the ML-style module system with OOP. It's really worth talking about. Also, OCaml is sometimes called a "higher-order imperative programming language" instead of a functional programming language. It does have strict evaluation and first-class mutation, after all. I would argue that there is NOTHING awkward about writing code in it, controlling for libraries and development tools.
- didroe 17y ago
  Indeed, it might be sometimes frustrating to pass around state that in C would be directly modifiable, but the benefits are huge. Such as? Ok, so you get better multithreaded behaviour but now you're copying state all the time and having to thread it though all your functions. Sometimes just updating state is the right thing to do. Personally, I think a good tradeoff is immutable data but mutable references.
  - miloshh 17y ago
    The main benefit, as I mentioned above, is that if a pure function works once, it works all the time. This is captured by the saying "in Haskell, if it compiles, it works", which is surprisingly often true. If you have a function that moves a player in a game such as movePlayer :: PlayerState -> PlayerState, you know that it only changes the state of this player, and nothing else. In an OO language you would do something like player.doUpdate(), which has absolutely no guarantees. Plus there are many facilities available to deal with threading and hiding state.
    - silentbicycle 17y ago
      > you know that it only changes the state of this player, and nothing else. This gets ugly when the state of every actor can potentially affect the state of every other actor, though. This is pretty common in games. That's the main point the linked article is making.
      - miloshh 17y ago
        Yes, and it is a weak point. My point, instead, was that FP does not break down when things get ugly; on the contrary, it gives much stronger guarantees on correctness. Of course, it takes effort to express the problem in the more restrictive functional paradigm.
        ellyagg 17y ago
        Yeah. I fail to see how scads of global data is less ugly.
thalur 17y ago
Theres also a related series of articles starting here: http://prog21.dadgum.com/23.html http://prog21.dadgum.com/23.html
kragen 17y ago
Beyond a certain point, I don't care how easy something makes a program that will never grow beyond a page, though. (If that isn't easy, your language has serious problems!) Maybe we can call your thesis "verbosity is power". A page of COBOL is easy to understand and easy to write; a page of APL is much slower to understand and fiendishly difficult to write. That doesn't mean you should prefer COBOL over APL. It's a result of the fact that you can express more in a line of APL than in a page of COBOL. And, in fact, that line of APL is easier to write and easier to read than that page of COBOL. Ideally, any time you're solving a problem that's a small variation of a problem somebody has already solved, you should be able to write your program by referencing their solution and describing the variation. In such a world, no program is more than a page.
- silentbicycle 17y ago
  Whoa, whoa, whoa. You're arguing with what you think I'm saying, not what I'm trying to say. There are diminishing returns in focusing on extreme brevity. If I'm going to write a script, I just use Lua. (Other people like Python or Ruby. Sure.) Squeezing 10% more out of an already small program is well past the point of diminishing returns. Depending on the problem, APL/J/K might make more sense. Or awk, make, SQL, etc. (My only experience with the APL family is playing around with J a bit, but they seem like awk in that they gain their conciseness in exchange for being focused on a certain problem domain. That's usually a good trade-off, though.) I'd rather see more focus into techniques to make larger projects manageable, like module systems, type inference, declarative programming. As techniques, they're intrinsically harder to show off in this medium, though (except for small amounts of type inference, but its payoff increases with project size). That's all I'm saying.
  - kragen 17y ago
    I think I kind of agree with you, but kind of not. Try looking at it from this perspective: There is really only one program. It is running on the internet and the disconnected nodes that only exchange data by sneakernet. It never stops running. Every bit of software that we think of as a separate program is really a part of this program. What are the techniques that make this program manageable (in the sense that it continues to perform useful functions and people continue to extend it)? I don't think they're module systems and type inference. I think REST, for example, plays a much bigger role. Full-text search of documentation plays a big role. NANOG plays a big role. Most of the things that really matter most in keeping it manageable are interpersonal and institutional rather than purely technical. But this large program is made up largely of code, and nearly all of that code is made up of individual lines of code. Many of the technical things that help us most to keep it manageable are precisely the ones that allow us to write self-contained modifications more and more incrementally — a page, or a paragraph, or a line of code at a time. So in that sense, things like type inference and programming higher on the declarativeness scale (e.g. DSLs, libraries) are important in managing the large project precisely because they can be compellingly demonstrated in "programs" of less than a page.

miloshh 17y ago

languages that let you do short parlor tricks Quite the opposite - functional programming is becoming very appealing as a practical alternative for building large, multi-threaded, correct systems. True, it might be a bit more tedious to write a program that type-checks, but as many (including me) have been repeatedly amazed, it often works correctly right away, with minimal debugging. But it also may be that almost no one has been thinking about problems like this Mutable state is a fundamental issue that every functional programmer deals with every day. Indeed, it might be sometimes frustrating to pass around state that in C would be directly modifiable, but the benefits are huge. Pure code has been called a "scarce resource", and that's exactly right - once it works, it will always work, no matter how huge is the system you build on top of it.

silentbicycle 17y ago
OCaml is one of my favorite languages. I use it, despite its many warts, because it works. (I think there's a much smaller, cleaner language waiting to get out, though.) I wish more languages had decent module systems, for example. The ML family does this better than most, but I bet it's not a very glamorous area to experiment in, because it's hard to really show the benefits of a well-designed module system in small examples. That's what I'm complaining about. BUT, pure functional programming is an intrinsically poor fit for some problems, and this is seldom addressed by hype. I think functional programming hype needs a reality check now, the same way C++-style OO hype could have used more way back when. I think we would all be better off if, instead of heralding it as the next technique that solves all problems, we work on getting a clearer idea of its strengths and weaknesses.
- miloshh 17y ago
  Oh, I agree with the strengths and weaknesses, and obviously I don't use FP for all my programming. But I somehow cannot see any functional programming hype. Where are the people heralding it as solving all problems? Even in a place like HN with a highly non-average community of programmers, the FP links are quite rare and very intro-level. I would say FP is a high-hanging fruit that's only starting to find a few niches in real-world programming. So I son't see anything close to an FP hype, nowhere near to the Java hype or Ruby hype.
  - AlisdairO 17y ago
    Reddit has an ...ardent community, and I suspect regulars there may gain an unrealistic impression of the amount of FP hype there is out in the wider world.
- jganetsk 17y ago
  I'm disappointed that I have yet to see a decent discussion on HN on comparing the ML-style module system with OOP. It's really worth talking about. Also, OCaml is sometimes called a "higher-order imperative programming language" instead of a functional programming language. It does have strict evaluation and first-class mutation, after all. I would argue that there is NOTHING awkward about writing code in it, controlling for libraries and development tools.
didroe 17y ago
Indeed, it might be sometimes frustrating to pass around state that in C would be directly modifiable, but the benefits are huge. Such as? Ok, so you get better multithreaded behaviour but now you're copying state all the time and having to thread it though all your functions. Sometimes just updating state is the right thing to do. Personally, I think a good tradeoff is immutable data but mutable references.
- miloshh 17y ago
  The main benefit, as I mentioned above, is that if a pure function works once, it works all the time. This is captured by the saying "in Haskell, if it compiles, it works", which is surprisingly often true. If you have a function that moves a player in a game such as movePlayer :: PlayerState -> PlayerState, you know that it only changes the state of this player, and nothing else. In an OO language you would do something like player.doUpdate(), which has absolutely no guarantees. Plus there are many facilities available to deal with threading and hiding state.
  - silentbicycle 17y ago
    > you know that it only changes the state of this player, and nothing else. This gets ugly when the state of every actor can potentially affect the state of every other actor, though. This is pretty common in games. That's the main point the linked article is making.
    - miloshh 17y ago
      Yes, and it is a weak point. My point, instead, was that FP does not break down when things get ugly; on the contrary, it gives much stronger guarantees on correctness. Of course, it takes effort to express the problem in the more restrictive functional paradigm.
      - ellyagg 17y ago
        Yeah. I fail to see how scads of global data is less ugly.

thalur 17y ago

Theres also a related series of articles starting here: http://prog21.dadgum.com/23.html http://prog21.dadgum.com/23.html

kragen 17y ago

Beyond a certain point, I don't care how easy something makes a program that will never grow beyond a page, though. (If that isn't easy, your language has serious problems!) Maybe we can call your thesis "verbosity is power". A page of COBOL is easy to understand and easy to write; a page of APL is much slower to understand and fiendishly difficult to write. That doesn't mean you should prefer COBOL over APL. It's a result of the fact that you can express more in a line of APL than in a page of COBOL. And, in fact, that line of APL is easier to write and easier to read than that page of COBOL. Ideally, any time you're solving a problem that's a small variation of a problem somebody has already solved, you should be able to write your program by referencing their solution and describing the variation. In such a world, no program is more than a page.

silentbicycle 17y ago
Whoa, whoa, whoa. You're arguing with what you think I'm saying, not what I'm trying to say. There are diminishing returns in focusing on extreme brevity. If I'm going to write a script, I just use Lua. (Other people like Python or Ruby. Sure.) Squeezing 10% more out of an already small program is well past the point of diminishing returns. Depending on the problem, APL/J/K might make more sense. Or awk, make, SQL, etc. (My only experience with the APL family is playing around with J a bit, but they seem like awk in that they gain their conciseness in exchange for being focused on a certain problem domain. That's usually a good trade-off, though.) I'd rather see more focus into techniques to make larger projects manageable, like module systems, type inference, declarative programming. As techniques, they're intrinsically harder to show off in this medium, though (except for small amounts of type inference, but its payoff increases with project size). That's all I'm saying.
- kragen 17y ago
  I think I kind of agree with you, but kind of not. Try looking at it from this perspective: There is really only one program. It is running on the internet and the disconnected nodes that only exchange data by sneakernet. It never stops running. Every bit of software that we think of as a separate program is really a part of this program. What are the techniques that make this program manageable (in the sense that it continues to perform useful functions and people continue to extend it)? I don't think they're module systems and type inference. I think REST, for example, plays a much bigger role. Full-text search of documentation plays a big role. NANOG plays a big role. Most of the things that really matter most in keeping it manageable are interpersonal and institutional rather than purely technical. But this large program is made up largely of code, and nearly all of that code is made up of individual lines of code. Many of the technical things that help us most to keep it manageable are precisely the ones that allow us to write self-contained modifications more and more incrementally — a page, or a paragraph, or a line of code at a time. So in that sense, things like type inference and programming higher on the declarativeness scale (e.g. DSLs, libraries) are important in managing the large project precisely because they can be compellingly demonstrated in "programs" of less than a page.