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

Why I Prefer Functional Programming

morgenthum.dev

Post reply on HN
Print view View original

71–80 of 163 posts

Re: Why I Prefer Functional Programming

#71

Post by carapace »

AlexCoventry wrote: post #18

I prefer functional programming because referentially transparent functions are easier to reason about and test. Brevity of control flow hasn't brought me much benefit.

Yeah, in his Turing Award lecture introducing FP Backus made a big deal of the ability to reason about programs mathematically. I've been playing with a functional language Joy that combines (IMO) the best features of Forth and Lisp and one of the neat things about it is that you can derive functions from simple (almost geometric) syntactic manipulations as the whole language is just referentially transparent functions. ( http://joypy.osdn.io/notebooks/index.html )

Re: Why I Prefer Functional Programming

#72

Post by robocat »

jimbokun wrote: post #43
yoz-y wrote: post #17

Earlier quoted context omitted.

To me this looks like perl golfing, but for some reason perl golfing is bad but writing extremely terse functional programs is not. Personally I like to combine both approaches. In swift I would write something like this: let l = ["abc", "ab", "abcdef", "abcdefgh"] width = l.reduce(0, { max($0, $1.count) }) let centered = l.map({ (line: String) -> String in var padding = (width - line.count) / 2 return String(repeati…

"To me this looks like perl golfing" I think that's preposterous and totally unfounded. The identifiers have names like "alignCenter", "replicate", "maximum" and "length". Those are all actual full English words, nothing remotely obfuscated about them. "map", "++" for concatenation, and "x/xs" for an arbitrary list of things are all idiomatic so can be kept short because they are used so often, like pronouns in Engli…

It does look like APL or Perl without enough understanding of Haskell (which I know very little about). I am guessing you have some experience writing Haskell code, so it looks clear to you.

The example used idiomatic one or two letter variable names (x, n, xs) which I found difficult to read. The rewritten example was much clearer to me because I could see the variables.

Re: Why I Prefer Functional Programming

#73

Post by lemmsjid »

kbuchanan wrote: post #20
AlexCoventry wrote: post #18

I prefer functional programming because referentially transparent functions are easier to reason about and test. Brevity of control flow hasn't brought me much benefit.

Couldn't agree more! ... I just had to laugh to myself at how this, THIS is why functional programming is so... rarely adopted. Like, "referentially transparent functions"?! What happened to `website.run.now!`?!

Referential transparency is a handy thing to think about in OOP as well as functional programming. If you provide the same parameters to a function, will you always get the same result? If yes, and if the function is 'pure', e.g. does not result in some side effect like state manipulation, you could replace the function itself with the output of that function. If so, and the function is computationally expensive, you can memoize the function, which is a specific form of caching where you auto cache the results by the parameters passed to the function.

This is a handy chain of reasoning in any language, and in a more dedicated functional language might be supported as a concept in the language itself.

Like in OOP, you don't have to have that term memorized to actually use a functional language, just remember the pattern.

Re: Why I Prefer Functional Programming

#74

Post by foobar_ »

roywiggins wrote: post #37
foobar_ wrote: post #14

I still don't get the point of immutability. Sure state change is a problem. How about a log like data structure that stores all modifications of the data? I'm sticking to procedural coding for the next 10 years and I will try my best to unwash young coders from poop.

That seems like an implementation detail. If you have an append-only log, you can always rely on each entry to never change. That's a kind of immutability. If you hold on to a reference to the log at a particular time, it will never change out from under you.

There should be an alternative to both extremes - complete mutability and complete immutability.

Re: Why I Prefer Functional Programming

#75

Post by gdy »

jlg23 wrote: post #45
AtlasBarfed wrote: post #33

Earlier quoted context omitted.

This opinion is flameworthy and stereotypes heavily: what seems to happen in FP is that the overall community is substantially math-IQ smarter than the imperative languages. Alas, that ALSO means the overall community loses social-IQ in the process. This leads to: 1) higher barrier to entry for the general programmers, in language semantics, documentation, examples... 2) a tendency to overabstract, underdocument, and…

Opinions only backed by ~"I know due to my experience" but nothing else are not even "flameworthy".

And this opinion is backed by your experience?

Re: Why I Prefer Functional Programming

#76

Post by ignoramous »

fauigerzigerk wrote: post #61

I think these sorts of examples dodge the real issue. Of course you can show a (perhaps needlessly) verbose procedural example of an algorithm that lends itself perfectly to FP and then demonstrate how FP is far more concise. But the real issue, in my view, is what happens when the algorithm is not ideally suited to FP, otherwise we're back to the cute inheritance hierarchies in OOP textbooks. Say we're dealing with…

> The open question in my mind is whether pure functional languages scale well to problems of real life complexity.

I came across this website [0] on news.yc way back when: It has a nice one-to-one mapping of GoF design patterns in C++/Java to Clojure.

> The open question in my mind is whether pure functional languages scale well to problems of real life complexity

OCaml [1] really shines in this aspect having used it in a project involving static code analysis. Facebook's ReasonML is based on it. The rust-lang compiler was once written in OCaml. And then there's amirmc's unikernel.org / mirage.io, as well.

[0] https://mishadoff.com/blog/clojure-design-patterns/

[1] https://ocaml.org/learn

Re: Why I Prefer Functional Programming

#77

Post by Koshkin »

jimbokun wrote: post #43
yoz-y wrote: post #17

Earlier quoted context omitted.

To me this looks like perl golfing, but for some reason perl golfing is bad but writing extremely terse functional programs is not. Personally I like to combine both approaches. In swift I would write something like this: let l = ["abc", "ab", "abcdef", "abcdefgh"] width = l.reduce(0, { max($0, $1.count) }) let centered = l.map({ (line: String) -> String in var padding = (width - line.count) / 2 return String(repeati…

"To me this looks like perl golfing" I think that's preposterous and totally unfounded. The identifiers have names like "alignCenter", "replicate", "maximum" and "length". Those are all actual full English words, nothing remotely obfuscated about them. "map", "++" for concatenation, and "x/xs" for an arbitrary list of things are all idiomatic so can be kept short because they are used so often, like pronouns in Engli…

> $0, $1

Re: Why I Prefer Functional Programming

#78

Post by bsznjyewgd »

DonaldPShimoda wrote: post #39
biznickman wrote: post #2

I think this most effectively demonstrates why I like a lot of OOP: it can be verbose. This is example function is relatively illegible: alignCenter :: [String] -> [String] alignCenter xs = map (\x -> replicate (div (n - length x) 2) ' ' ++ x) xs where n = maximum (map length xs) One of the most verbose languages I've used, Objective C, has made this a best practice. Despite the brackets (which scare people off), it…

> I think this most effectively demonstrates why I like a lot of OOP: it can be verbose. Verbosity is not inherently good. In fact, I think verbosity is inherently bad . Have you read much first-year programmer code? It's absurdly verbose at the cost of legibility. The real issue is clarity . Your code should be sufficiently verbose that its purpose is self-evident, but it should not be overly verbose such that your…

Fibonacci is usually introduced as "the next term is the sum of the two previous terms" (sometimes with the story about rabbits or whatever). There's two obvious ways to implement this:

  1. Direct recursion
  2. Keep track of the two previous terms
If you start with (1), you run it and it takes exponential time, and so you should instead remember the two previous terms, leading you to (2). When you go with (2), you either use 2 mutable variables and a loop in the imperative version, or you have 2 accumulators and tail recursion in the functional version... which is the same thing, since a tail recursive function is just a named loop.

There's nothing about laziness or self-referencing an incomplete structure here, which is just a Haskell thing. Taking the tail of an incomplete structure, in particular, is indirect and hard to understand.

If you want to demonstrate laziness, you can still do it directly by doing something like:

  fibs a b = a : fibs b (a + b)
  fib n = fibs 0 1 !! n

Re: Why I Prefer Functional Programming

#79

Post by robocat »

jimbokun wrote: post #53
hinkley wrote: post #31

Earlier quoted context omitted.

I'm finding that in Javascript, I really enjoy map() and filter(), but map() caused some friction on code reviews at one place, from someone I don't think had any FP background. The are best when they are one liners, of the form .map((val) => someFunction(val)) or .filter((val) => val.length > 1) reduce() on the other hand is always illegible to me. I get pretty grumpy when I am 'forced' to use a reduce because the c…

"but map() caused some friction on code reviews at one place" Someone not familiar or comfortable with "map" should not be working as a professional programmer today. Most languages now support "map" or something very similar. Try to move to a different team or different company with actual professional developers.

> Someone not familiar or comfortable with "map" should not be working as a professional programmer today.

I completely disagree - you are measuring the quality of a programmer on a single dimension.

I have worked with very weak programmers that produce gold e.g. great at pulling a team together, great at producing outcomes that clients love, great at focusing on features that sell.

I have also worked with great programmers that just stick to what they know - they don't know map() because they concentrate on being productive rather than continually chasing the next greatest language or library.

I have also worked with technically awesome programmers that produce absolute crap e.g. struggle to communicate, struggle to make good engineering compromises, struggle to understand requirements. One smart guy was so creepy no women could work with him which meant he was actually pretty useless - I saw one friend who worked as a consultant there hide under her desk to avoid him!

Re: Why I Prefer Functional Programming

#80

Post by commandlinefan »

CJefferson wrote: post #5

I don't see why "Object Orientated Programming" requires for loops, over map / streams (which Java has). Is there a definition of "OOP" which requires using for/while? This doesn't really sure any OOP at all. A better example would be to show a case where OOP would be useful, say having a base class and deriving it several times (iostreams for example). Show me how FP does somewhere where (traditionally) OOP is consi…

> I don't see why "Object Orientated Programming" requires for loops

Yeah, I think he (and most people who talk about FP vs. OOP) actually use OOP as a short-hand for "not FP": Scala is actually very object-oriented and very functional at the same time; they're not mutually exclusive.

Post reply on HN