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

A Year of Functional Programming

japgolly.blogspot.com.au

Post reply on HN
Print view View original

21–30 of 172 posts

Re: A Year of Functional Programming

#21

Post by noelwelsh »

analog31 wrote: post #13

Ask HN: As somewhat of an old timer, I have a couple of questions about FP, not really worthy of creating their own thread: 1. I learned a rule (in my Pascal textbook), "avoid globals." Is FP just an embodiment of that principle? 2. I do a lot of programming involving hardware, often homemade. Hardware has state, such as whether a lamp is turned on or off. Does this just mean FP is inappropriate, or are there techniq…

1. I think "avoid globals" is a reasonable way into FP, but FP itself involves a lot more than just avoiding coupling via global state. I would say the main components are

- nested definitions;

- lexical scoping;

- first class functions;

- static typing; and

- a whole bunch of programming techniques (e.g. monads) that have grown around them.

2. You certainly can use FP ideas in low-level programming but you'll have difficulty finding a FP language that targets your hardware. There are a few small Scheme implementations that might work. Rust is viable if we're talking 32-bit CPUs, not 8-bit.

(I imagine the Rust developers would not claim Rust is a functional language, but it has absorbed a great many ideas from functional languages. I prefer to talk about modern programming languages instead of functional programming languages. Rust, Haskell, and Scala are all modern and have many features in common. Only Haskell claims to be a pure FP language though.)

Re: A Year of Functional Programming

#22

Post by threeseed »

Kiro wrote: post #3

Would you recommend starting with Scala before Haskell if one want to learn FP?

No. What I've found with Scala projects is that it ends up as a typical OO app but with some FP constructs. Yes you see a reduction in the amount of code written but with added complexity.

I would go with Clojure (if you still want to leverage Java libraries) or Haskell personally.

Re: A Year of Functional Programming

#23

Post by GarvielLoken »

pron wrote: post #7

I used to like functional programming. Now I think that it's -- more often than not -- a solution in search of a problem. I can understand some of the things FP gets you (although those come at a cost, which I'll get to later); I'm just not so sure these are the things we need, or that FP is the best solution for them. One is code reuse: yes FP code is definitely more reusable. The problem is that the kind of code it…

I found the same thing. Sure monads can help with somr cases in oo.

Overall i find Common Lisp Macros to be a better way for me to code, you can always construct your problem domain easily instead of choosing between two.

Re: A Year of Functional Programming

#24

Post by Touche »

pron wrote: post #20
babs474 wrote: post #16

Earlier quoted context omitted.

I'm not sure about haskell, but in clojure the, run code, reason, run more code cycle is very much supported with the repl. In fact I find the nature of functional code very much helps out here. With clojure, in a complicated system I can typically take any subcomponent and run it in the repl without much fuss/mocking or worrying about the state of the system. Since usually functions aren't modifying state I can reru…

Oh, absolutely. But I wasn't counting Clojure as FP in my comment. There is no definition for FP, and the OP seemed to be talking about the statically typed, pure FP, of Haskell and scalaz. Clojure is certainly not that kind of FP, as it's neither statically typed nor pure.

I know there are Haskell people who think Haskell is the only True Functional Language, but for the sake of discussion can we not go there?

Re: A Year of Functional Programming

#25

Post by discreteevent »

pron wrote: post #7

I used to like functional programming. Now I think that it's -- more often than not -- a solution in search of a problem. I can understand some of the things FP gets you (although those come at a cost, which I'll get to later); I'm just not so sure these are the things we need, or that FP is the best solution for them. One is code reuse: yes FP code is definitely more reusable. The problem is that the kind of code it…

"Haskell discounts the very useful choice of reasoning about your code after it runs, favoring, instead, all-upfront reasoning, often at the expense of facilitating the former. There are some domains where figuring everything up front is very important. Others, where trial and error is far more productive."

Yes people seem to learn much better by example. The worst teachers (we have all had them) are those who jump straight into the abstraction that solves the problem instead of going through some examples first. If they cover a few specific examples with specific solutions then the student will almost invent the abstraction themselves. The same thing came up recently about pitching startups. If you don't describe the problem first with specific examples then people won't even recognise the solution (and often these people are far from stupid). In general for most people if they are trying to do something innovative they are rarely definitive about it at first. If you asked them to explain it or prove it they couldn't. They start with a hunch, do something ill defined, and then refine it as they go. Even mathematics is like this, except that often once someone has discovered and understood something, they explain it as if they were definitive about it all along - which can be misleading to say the least.

Re: A Year of Functional Programming

#26

Post by mhaymo »

analog31 wrote: post #13

Ask HN: As somewhat of an old timer, I have a couple of questions about FP, not really worthy of creating their own thread: 1. I learned a rule (in my Pascal textbook), "avoid globals." Is FP just an embodiment of that principle? 2. I do a lot of programming involving hardware, often homemade. Hardware has state, such as whether a lamp is turned on or off. Does this just mean FP is inappropriate, or are there techniq…

1. More generally I'd say it's "minimise mutable state".

2. Almost all programs are necessarily stateful, but most of the code within them does not have to be. As such, all FP languages support working with state, e.g. Scala which is essentially just Java with more powerful types and easier creation of immutable values and lambdas, so you can program with state as easily as you can in Java. And Haskell, which separates stateful functions by type, so that the programmer and the compiler know which functions have state and which do not.

Re: A Year of Functional Programming

#27

Post by noelwelsh »

pron wrote: post #17
noelwelsh wrote: post #8

Earlier quoted context omitted.

Wow, I sure have the opposite reaction to you. Makes me wonder what kind of code you wrote. Some specific points: "One is code reuse: yes FP code is definitely more reusable. The problem is that the kind of code it enables reuse of more than OO is very small, simple loops." Combinator libraries sure are pretty useful, and they're more than small simple loops. "Writing the same 4 line method -- that could have been ab…

> Combinator libraries sure are pretty useful, and they're more than small simple loops. Useful -- yes. Useful enough to pay the price -- IMO, no. OO is decent at code reuse, and the most effective, most important code reuse, is that of big libraries with rich functionality, which is done rather well in many programming paradigms (i.e. pure, statically typed FP has little to no advantage here). > Very puzzled how you…

I don't agree with your definition of FP then. Erlang is broadly the same as Clojure: pure in the small but stateful in the large (mailboxes in Erlang store state).

Your basic argument seems to come down to Haskell (the only pure statically typed language with any widespread adoption) vs any other language. That's not an argument I'm particularly interested in.

As for OO vs FP in combinator libraries -- the same pattern is often called a fluent interface in OO. This gets to the larger point that FP is as much a programming style as a language that supports that style, and you can program in a FP style in any language. The question I'm interested in is "is FP style useful?" to which I give a resounding "yes!"

Re: A Year of Functional Programming

#28

Post by cageface »

pron wrote: post #7

I used to like functional programming. Now I think that it's -- more often than not -- a solution in search of a problem. I can understand some of the things FP gets you (although those come at a cost, which I'll get to later); I'm just not so sure these are the things we need, or that FP is the best solution for them. One is code reuse: yes FP code is definitely more reusable. The problem is that the kind of code it…

The lack of magically bug-free, FP OSs, drivers, control software, and large applications, shows that even the biggest supposed benefits of languages like Haskell, are yet to be demonstrated in the real world.

I've been reading religious advocacy of FP for almost 15 years now and yet there still don't seem to be many non-trivial apps written in any of these languages. Certainly many individual features of FP have been adopted to good effect in more mainstream languages but commercial Haskell or OCaml apps are still conspicuously thin on the ground. I think at this point it's up to the FP advocates to back up their claims with results. I'm sure there are a lot of programmers that would happy to roll up their sleeves and learn something new if it truly would make them 3x more productive.

Re: A Year of Functional Programming

#29

Post by pron »

noelwelsh wrote: post #27
pron wrote: post #17

Earlier quoted context omitted.

> Combinator libraries sure are pretty useful, and they're more than small simple loops. Useful -- yes. Useful enough to pay the price -- IMO, no. OO is decent at code reuse, and the most effective, most important code reuse, is that of big libraries with rich functionality, which is done rather well in many programming paradigms (i.e. pure, statically typed FP has little to no advantage here). > Very puzzled how you…

I don't agree with your definition of FP then. Erlang is broadly the same as Clojure: pure in the small but stateful in the large (mailboxes in Erlang store state). Your basic argument seems to come down to Haskell (the only pure statically typed language with any widespread adoption) vs any other language. That's not an argument I'm particularly interested in. As for OO vs FP in combinator libraries -- the same patt…

I agree with every word. Alas, FP does not have a definition, so, when I was saying "FP", I meant "FP as the article's author practices", which means "statically typed, pure FP". FP using Java streams, FP in Clojure/Erlang, and FP in Haskell mean very different things.

Re: A Year of Functional Programming

#30

Post by tegeek »

pron wrote: post #7

I used to like functional programming. Now I think that it's -- more often than not -- a solution in search of a problem. I can understand some of the things FP gets you (although those come at a cost, which I'll get to later); I'm just not so sure these are the things we need, or that FP is the best solution for them. One is code reuse: yes FP code is definitely more reusable. The problem is that the kind of code it…

I think you are describing extreme cases for the FP. Can you please provide one example how would you abstract away problems solved via Map, Reduce, Filter, List Comprehension, Pattern Matching, Partial Application and Currying using any OO language (say Java)? Filtering, transforming data takes a lot of code in any data driven app. You start trimming the code from the day 1 in any FP enabled language without even thinking about the pattern.

Research in Programming Languages giving us new tools to reason about our software development and FP is one of those nice tools.

Post reply on HN