Live data from Hacker News

Why I Prefer Functional Programming

morgenthum.dev

91–100 of 163 posts

Re: Why I Prefer Functional Programming

#91
post #17

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…

[deleted]

Re: Why I Prefer Functional Programming

#92
post #17

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…

Obligatory C#:

    var input = new string[] { "abc", "ab", "abcdef", "abcdefgh" };
    var maxLength = input.Select(e => e.Length).Max();
    var output = input.Select(e =>
    {
        var padding = (maxLength - e.Length) / 2;
        return new String(' ', padding) + e;
    });
Most modern `oop` languages these days all support functional constructs and achieve the same thing in same amount of code & style. Language and oop/functional style are not mutually exclusive anymore, which this article seems to overlook by comparing both languages and styles at the same time.

Re: Why I Prefer Functional Programming

#93
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 fundamentally do not like attaching methods to my structs/records/whatever, since I think that forces strong and unnecessary coupling.

I see it almost exactly backwards from that. I like being able to make it so that nobody other than a select set of functions can modify my structs/records/whatever. To me that prevents unnecessary coupling.

Re: Why I Prefer Functional Programming

#94
post #21

Earlier quoted context omitted.

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.

It's multi-paradigm. Want FP? Do it. Want OOP? Do it. Want both? Do it.

Re: Why I Prefer Functional Programming

#95

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…

You chose a very bad example for "imperative code". It seems artificially complicated.

    def fib(n: int) -> int:
        prev, cur = 0, 1
        for _ in range(n-1):
            prev, cur = cur, prev + cur
        return cur
I think most humans will find this variant more readable and understandable then functional one.

Re: Why I Prefer Functional Programming

#96
post #83
post #21

Earlier quoted context omitted.

Then you should look into Scala

Scala is fine, but do you not feel that it tries to do too much sometimes? Like, I like Scala if I'm the only person writing it; I basically write Haskell while still having access to all of Java's libraries, but I absolutely dread having to collaborate with people using Scala. A coworker of mine (whom I respect very much) said it pretty well once: "I write Scala...but in a Java accent"...he doesn't use the functiona…

It was in response to the parent lacking OOP in FP.

I think this is a problem with any language that supports multiple paradigms and ways to skin a cat.

Enforcing guidelines is a way to combat that. Ofc you might also just opt for a more specific language

Re: Why I Prefer Functional Programming

#98
post #42

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.

Well said. I think a lot of people are drawn to Haskell because the abstractions are so well integrated. I remember reading the Prelude and muttering "wow so true" all the way. But then I got stuck when designing a first program.

OOP to me is not imperative control flow but about managing responsibilities. What does this object know, what can I ask it to do, what does it need for the job? If I look at my program at the level of for-loops I'm lost in the brush. And granted, sometimes I do miss Haskell's expressiveness in the brush.

Re: Why I Prefer Functional Programming

#99

Earlier quoted context omitted.

> I don't want to believe that is what experts of the paradigm consider object-oriented programming. Once you get to the scientific literature about the subject (where actual experts reside), it tends to be much more common to see the conclusions of "there isn't any formal difference between OOP and FP languages", or that in Haskell in particular "implements an strict superset of OOP". The problem is that FP and OOP…

In what sense is Haskell a "strict superset" of OOP?

In the sense that you can recreate all the usual OOP syntax and behavior on Haskell. What people only do on practice for very limited extents, because it's not very useful to import those concepts to a language aimed at dealing with pure functions.

Re: Why I Prefer Functional Programming

#100

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…

Agreed. Ruby is a very fundamentally OO language, but its Enumerable interface is more comprehensive than many FP languages' equivalents (in addition to the standard map/reduce/select, it has methods for iterating over permutations of elements, n-sized slices, etc, all of which can be made lazy), and because it's an interface you can use it with custom data types easily. But FP enthusiasts often speak as if the ML and Lisp language families have a duopoly on higher-order functions. It's odd.
Post reply on HN