Live data from Hacker News

Why I Prefer Functional Programming

morgenthum.dev

101–110 of 163 posts

Re: Why I Prefer Functional Programming

#101
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…

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…

This looks like the Java if the Java was written by someone who knows Java:

    List alignText(List texts) {
      int maxLength = texts.stream().mapToInt(String::length).max().orElse(0);
      return texts.stream().map(text -> {
        var spaceCount = (maxLength - text.length()) / 2;
        return " ".repeat(spaceCount) + text;
      }).collect(Collectors.toList());
    }

Re: Why I Prefer Functional Programming

#102

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…

Haskell is perfectly capable of expressing imperative algorithms and mutable state. Such algorithms are still expressed using pure functions, pure functions that return IO actions.

Re: Why I Prefer Functional Programming

#103
post #50

Earlier quoted context omitted.

> 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 fun…

You almost never use `new` in modern C++, and you would never use it as you suggest because it wouldn't compile, you would simply say:

     MyType x;
C++ is nothing at all like Java.

Re: Why I Prefer Functional Programming

#104
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.

> I still don't get the point of immutability If you're the sole developer, it's probably not a big deal. If you're working with a group of people, immutability is the only way to maintain your sanity.

As compared to POOP sure. How about as compared to Go? Go is a procedural language.

Re: Why I Prefer Functional Programming

#105
post #96
post #83

Earlier quoted context omitted.

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

The problem with coding guidelines is that they actually are really difficult to enforce, especially during crunch-times. To quote Carmack, if the compiler allows something, it will end up in the codebase at some point.

Of course, this is also true of Clojure; people will make use of bad JVM libraries because they're available if you follow this logic, F# can do unsafe mutables, and even a more pure language like Haskell allows binding into C.

The difference in how idiomatic and easy it is to do a bad thing. For Clojure, the language has the "right" versions of the main data structures as first-class syntax, making it unlikely that you'd call into a Java library until needed, in which case hopefully you're using the correct one; while calling into Java isn't difficult, it is made explicit, and it does feel a bit unnatural as a result. Since Scala attaches no syntactical stigma to using the "bad" Java conventions, it's common for people to do things in a bad way (e.g. using `var` everywhere instead of `val`).

Re: Why I Prefer Functional Programming

#106

Earlier quoted context omitted.

> 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…

> Verbosity is not inherently good. Agreed. > In fact, I think verbosity is inherently bad. Here I disagree. To take it to an absurd extreme: LZW compress your source code. Hey, it's less verbose! But that's not a net win. Instead, I think that there is an optimal value of terseness. More verbose than that, and you waste time finding the point. More terse than that, and you waste time decoding what's going on. Now, w…

I think we have different interpretations of what it means to be "verbose", which is why I instead directed my previous comment towards "clarity".

Wiktionary gives the following definition of "verbose" [0]:

> Abounding in words, containing more words than necessary; long-winded.

My point is that adding words for the sake of adding words is bad, always. It's one thing to say "My code tends to be on the more verbose side of things" and another to say "I prefer writing very verbose code." You should always be seeking to make your code as concise as possible while maintaining clarity.

It's that "while maintaining clarity" bit that's the tricky bit, really. On this, I think we agree. I always try to make my code as short and direct as it can be, but never at the cost of clarity. For example, I don't use cute inlined tricks unless they're idiomatic (or used everywhere in the code and explained in at least a couple places). I try to strive for clarity instead of verbosity.

[0] https://en.wiktionary.org/wiki/verbose

Re: Why I Prefer Functional Programming

#107
post #16

You can write mutation-style java tersely too... void alignCenter(String[] text) { int maxLength = 0; for (String line : text) maxLength = Math.max(maxLength, line.length()); for (int i = 0; i No lambdas to be found.

Or just use Scala

Scala is a pretty immutability-functional-happy language. My point was that the mutation/readonly functional/oop comparison was unfair.

Re: Why I Prefer Functional Programming

#108
post #95

Earlier quoted context omitted.

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

Ah yeah, I think you're absolutely right: this is much better. It's been a while since I've implemented Fibonacci iteratively haha. Thank you for pointing this out. :)

Personally, I still find the functional version a bit more direct. The iterative code still relies on me understanding what the program is "doing"; it requires me to hold state in my head and think through "okay, now `prev` has this value and `cur` has this other value" to reason about what's going on.

I would be interested to find some people with minimal programming experience and show them imperative vs functional implementations of simple functions or algorithms and see what they prefer. Maybe I'll try to do a small study on that or something.

Re: Why I Prefer Functional Programming

#109

Earlier quoted context omitted.

> Verbosity is not inherently good. Agreed. > In fact, I think verbosity is inherently bad. Here I disagree. To take it to an absurd extreme: LZW compress your source code. Hey, it's less verbose! But that's not a net win. Instead, I think that there is an optimal value of terseness. More verbose than that, and you waste time finding the point. More terse than that, and you waste time decoding what's going on. Now, w…

I think we have different interpretations of what it means to be "verbose", which is why I instead directed my previous comment towards "clarity". Wiktionary gives the following definition of "verbose" [0]: > Abounding in words, containing more words than necessary; long-winded. My point is that adding words for the sake of adding words is bad, always. It's one thing to say "My code tends to be on the more verbose si…

> You should always be seeking to make your code as concise as possible while maintaining clarity.

Absolutely.

> It's that "while maintaining clarity" bit that's the tricky bit, really. On this, I think we agree.

Yes.

Re: Why I Prefer Functional Programming

#110
post #50

Earlier quoted context omitted.

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 fun…

You almost never use `new` in modern C++, and you would never use it as you suggest because it wouldn't compile, you would simply say: MyType x; C++ is nothing at all like Java.

Sorry, you'd need to use the MyType* x to use the `new` keyword; it's been awhile. It doesn't really deter from my point though; in order to heap-allocate something you have to use a pointer, and you end up doing something not that dissimilar from Java.

> C++ is nothing at all like Java.

Is that supposed to be a joke? Java was marketed specifically towards C++ engineers...

Post reply on HN