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

41–50 of 163 posts

Re: Why I Prefer Functional Programming

#41

Post by klodolph »

cerved wrote: post #21
throwaway5752 wrote: post #12

What I dislike about functional programming is that when objects are not supported or they are avoided I have seen poorly documented and complex hashes/collections data structures that end up reinventing the oop wheel (and the problem the wheel was solving in the first place). It feels like a false choice and you can have rich FP capabilities in a language that supports objects and relationships between objects.

Then you should look into Scala

You made that comment twice in this thread, but you haven’t said why people should look into Scala.

Re: Why I Prefer Functional Programming

#42

Post by ts0000 »

As someone strongly favoring a functional or even purely functional approach, I strongly dislike the flood of pro-functional-programming blog posts that attack the straw man of "imperative programming wrapped in classes". I don't want to believe that is what experts of the paradigm consider object-oriented programming. I would love to read an honest comparison of both, judging benefits and cost.

Re: Why I Prefer Functional Programming

#43

Post by jimbokun »

yoz-y wrote: post #17
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…

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 English.

Lastly, your program looks very similar (almost isomorphic) to the Haskell version, so I think it's just dumb you use it as an argument to criticize the Haskell version as "extremely terse".

Re: Why I Prefer Functional Programming

#45

Post by jlg23 »

AtlasBarfed wrote: post #33
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…

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".

Re: Why I Prefer Functional Programming

#46

Post by klodolph »

rb808 wrote: post #23

I like FP, but cautious as there aren't many big applications (open source or private) that are written that way. Am I wrong?

You don’t need to go full FP to experience the benefits. You can just apply FP principles on a small scale to sections of your code, where appropriate.

As for “many big applications”, it depends on what your threshold for “many” is. There are a number of firms that use e.g. Haskell, F#, or ML privately, e.g. Jane Street, Galois. For whatever reason, functional programming seems to be more popular in finance.

Re: Why I Prefer Functional Programming

#47

Post by nnq »

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…

What is illegible about that?!

It just says, in code: "replace each line of text with itself prefixed by a number of spaces equal with half of the difference between its length and the length of the longest line in the text".

It's like the most obvious way to think about this particular problem!

Now, how well this scales to different problems, and especially to problems where mutation is a natural way to think about things... that's a different problem and part of the reason I'm not that much in love with extremist functional programming. Mutation has its place and the monadic abstraction is something I dislike.

But for simple examples like this pure FP rocks and is very readable and intuitive!

Re: Why I Prefer Functional Programming

#48

Post by p4bl0 »

I like functional programming too, but I'm not sure it is for the same reasons. Anyway, I think what the author describes as object oriented programming is actually imperative programming. In purely object oriented languages, such as Smalltalk, control flow can be encoded in objects too (for example Booleans can be an abstract class with two methods ifTrue and ifFalse that takes a callable object, and True and False can be subclasses that implements these methods by appropriately calling or not their arguments).

Re: Why I Prefer Functional Programming

#49

Post by roywiggins »

hinkley wrote: post #31
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'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…

I've been noodling with Julia recently and the dot-syntax is really surprisingly ergonomic for transforming hunks of data. It has the benefit of making vectorization easier for the compiler, but I enjoy the syntax.

https://docs.julialang.org/en/v1/manual/functions/#man-vecto...

Re: Why I Prefer Functional Programming

#50

Post by tombert »

MauranKilom wrote: post #36
tombert wrote: post #9

I started programming (like a lot of people) after I bought one of those "Learn C++ FAST!" books (I don't remember the actual title). A large chunk of this book was about the object-oriented part of C++, and comparing it to the equivalent version in C, and acted that since the only two paradigms that exist are OOP and imperative, you should always use OOP. (NOTE: I'm paraphrasing, that was the tl;dr as I remember it…

> I do really hate the type systems of Java and C++ because I think they're restrictive Can you give an example of how the C++ type system restricts you? Is it just lack of some inbuilt mechanisms/syntactic sugars or is there something that you can't actually model with it? > I think that forces strong and unnecessary coupling How do you model/maintain invariants of a set of data in FP? That's the part that I don't u…

I haven't touched C++ for several years at this point, so bear with me a bit, but in the category of "just really annoying, not really restrictive", there is the fact that you have to constantly re-type the types for everything, like `MyType x = new MyType()`, but my understanding is that has been addressed by the `auto` keyword.

Is there some equivalent to a monad in C++? As in, something that will "pollute" the function so that if it's trying to call something with side effects, it's reflected in the type? I have no doubt that you could stitch something together with the templates to get something, but in Haskell, out of the box, your functions that don't have side effects if they don't return `IO`.

Of course, this wouldn't be a sign of it being "restrictive", just a feature that's not in there. Maybe I'm being a bit unfair to C++ by tying its type system to Java, which is terrible.

One thing that I really dislike is the fact that, in order to make class X part of interface Y, you need to have access to X's source, or extend it. I find this incredibly annoying, and with Haskell, you can attach any type to a typeclass by providing its implementation. I know C# has this with its extension methods, but AFAIK C++ doesn't have any equivalent.

> How do you model/maintain invariants of a set of data in FP? That's the part that I don't understand yet.

I don't really know what you mean by that; you can restrict the allowed input types with typeclasses or existential quantifiers, but I'm not sure that I'm answering your question.

Post reply on HN