Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Admitting That Functional Programming Can Be Awkward (2007)

prog21.dadgum.com

Post reply on HN
Print view View original

11–20 of 148 posts

Re: Admitting That Functional Programming Can Be Awkward (2007)

#11

Post by marcan_42 »

voodootrucker wrote: post #9

I wrote an exercise once while I was teaching: "pure functional pacman". Really I did it to teach myself Redux, and it was a pretty fun way to learn. Totally agree with the article: sometimes functional is the right tool for the job, sometimes OOP. A more recent example: parsing USB descriptors in Rust. The parser would have been trivial and easy to understand if I could have multiple mutable references to nodes, but…

Off topic, but may I ask what USB stack you're working on? Because it might have a chance at being the first USB stack not full of exploitable bugs.

(I've deliberately and accidentally triggered bugs in pretty much every mainstream USB stack; it's a sad state of affairs, mostly because USB is practically designed to include the maximum number of implementation pitfalls... but I'm sure you know this already)

Re: Admitting That Functional Programming Can Be Awkward (2007)

#12

Post by jasperry »

Could it be the case that functional structure makes programs more reliable and easier to reason about in the large, but functional style/syntax may not be the best way to write code locally?

Trying to wrap an entire function's computation into one expression is a fun mental exercise, but the resulting code may be harder to read than a sequence of statements. Haskell's "do" notation seems to be an acknowledgment of this, but to me it's adding another layer of abstraction just to recover what imperative syntax gives in the first place. Why not start from the imperative model, and then find other ways to try to limit side effects and mutation? Languages like Rust may be heading in that direction; "Return of the statement" as it were.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#13

Post by Avshalom »

kibwen wrote: post #6

I think it's time we stop using the phrase "functional" to describe this paradigm; at this point, every imperative language made in the past 30 years has first-class functions, and there is no other first-class language feature common to all the self-described "functional" languages. IMO, a more accurate term would be stateless programming. This paradigm is about minimizing state. Of course, as the OP mentions, state…

It's a bit more subtle but the lack of statements that is, everything returns a value, is an important feature/quality.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#14

Post by dnautics »

I'm confused by this article. The author says he's in erlang (which, btw, is not pure functional). And then goes on to describe a system which sounds like an object oriented system. But a game programmer would probably actually implement it not as object per se, but maybe backed by an entity component system. But it seems like BEAM languages would be actually quite good at expressing entity systems, which, correct me if I'm wrong, are similar to say checking out and manipulating data in a database.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#15

Post by cmrdsprklpny »

savanaly wrote: post #8

>Sure, there have been games written in Lisp and some games written by language dilettantes fond of Objective Caml, but they never turn out to be programmed in a functional style. You can write imperative code in those languages easily enough. I would like to know more about this. I've written several games in Elm, a js counterpart to Haskell, and I guess foolishly assumed that meant I was writing them in the functio…

My understanding (which there's a good chance is incorrect) is that all code written in Elm has to be in a functional style because the language strictly enforces it; but this enforcement doesn't exist in Lisp and OCaml, so they can be used to write imperative or object-oriented code, as happened in the cases described.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#16

Post by makapuf »

savanaly wrote: post #8

>Sure, there have been games written in Lisp and some games written by language dilettantes fond of Objective Caml, but they never turn out to be programmed in a functional style. You can write imperative code in those languages easily enough. I would like to know more about this. I've written several games in Elm, a js counterpart to Haskell, and I guess foolishly assumed that meant I was writing them in the functio…

Your answer may be in the comment just after: in elm you explicit the state, you isolate it and you can reason about its structure, but there still is a state.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#17

Post by JD557 »

savanaly wrote: post #8

>Sure, there have been games written in Lisp and some games written by language dilettantes fond of Objective Caml, but they never turn out to be programmed in a functional style. You can write imperative code in those languages easily enough. I would like to know more about this. I've written several games in Elm, a js counterpart to Haskell, and I guess foolishly assumed that meant I was writing them in the functio…

I think it helps if you don't think about a single axis (functional vs imperative), but in two axis (functional vs procedural, declarative vs imperative).

When you use IO with do notation, you are actually doing imperative functional programming.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#18

Post by heavenlyblue »

Avshalom wrote: post #13
kibwen wrote: post #6

I think it's time we stop using the phrase "functional" to describe this paradigm; at this point, every imperative language made in the past 30 years has first-class functions, and there is no other first-class language feature common to all the self-described "functional" languages. IMO, a more accurate term would be stateless programming. This paradigm is about minimizing state. Of course, as the OP mentions, state…

It's a bit more subtle but the lack of statements that is, everything returns a value, is an important feature/quality.

Expressional or equational programming

Re: Admitting That Functional Programming Can Be Awkward (2007)

#19

Post by dustingetz »

kibwen wrote: post #6

I think it's time we stop using the phrase "functional" to describe this paradigm; at this point, every imperative language made in the past 30 years has first-class functions, and there is no other first-class language feature common to all the self-described "functional" languages. IMO, a more accurate term would be stateless programming. This paradigm is about minimizing state. Of course, as the OP mentions, state…

I think it's called functional because it emerges from the lambda calculus (truly just lambdas at the bottom) – but note this definition excludes javascript-with-immutability as well as clojure, not sure if lisp counts

Re: Admitting That Functional Programming Can Be Awkward (2007)

#20

Post by voodootrucker »

marcan_42 wrote: post #11
voodootrucker wrote: post #9

I wrote an exercise once while I was teaching: "pure functional pacman". Really I did it to teach myself Redux, and it was a pretty fun way to learn. Totally agree with the article: sometimes functional is the right tool for the job, sometimes OOP. A more recent example: parsing USB descriptors in Rust. The parser would have been trivial and easy to understand if I could have multiple mutable references to nodes, but…

Off topic, but may I ask what USB stack you're working on? Because it might have a chance at being the first USB stack not full of exploitable bugs. (I've deliberately and accidentally triggered bugs in pretty much every mainstream USB stack; it's a sad state of affairs, mostly because USB is practically designed to include the maximum number of implementation pitfalls... but I'm sure you know this already)

I'm talking to a bunch of UVC webcams using https://docs.rs/rusb/0.6.4/rusb/ for some conferencing software. So sadly no help for your (very valid) concerns.
Post reply on HN