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

151–160 of 163 posts

Re: Why I Prefer Functional Programming

#151

Post by AtlasBarfed »

fortran77 wrote: post #70
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…

Maybe we just need to have more math training for people who want to become Computer Programmers.

That's kind of another aspect of the social-IQ divide.

Programming is very democratic and blue collar as white collar jobs go: you can get stuff done without a lot of formal education (OR the formal certification of (ahem) REAL engineering professions).

So either you ivory tower and sniff at the lower classes and use FP and higher tools, or you "get stuff done" actually making tools (like the dude who make the OSX package management getting stiffarmed by google).

The old CS vs no CS divide actually fissures quite dramatically in alignment with FP vs no FP.

Re: Why I Prefer Functional Programming

#152

Post by andolanra »

newen wrote: post #113
andolanra wrote: post #30

Earlier quoted context omitted.

I think this is a question that's orthogonal to OOP-versus-functional-programming, but is rather about programming style. Haskell programmers like being terse, but there's also nothing stopping you from writing Haskell like this: alignCenter :: [String] -> [String] alignCenter lines = let maxLineLength = maximum (map length lines) in [ leftPadding ++ line | line You could have verbose and easy-to-read functional code…

Honestly...how is that more readable? It's more verbose sure but the first example is much more readable and straightforward. Here, you have to remember Haskell's list comprehension syntax and you have to scan up and down a few times to keep track of the variables.

> …you have to remember Haskell's list comprehension syntax…

I get the point you're trying to make, but this feels like a huge stretch. Haskell's list comprehension syntax is straightforward and in many cases a terse and useful way of implementing complex functionality. You'll find multiple uses of it in the base libraries; notably, catMaybes is implemented in terms of list comprehension:

    catMaybes :: [Maybe a] -> [a]
    catMaybes ls = [x | Just x
I'm all for reducing cognitive load, but Haskell has such a sparse syntax and this specific feature is so useful (and honestly, so consistent with the rest of Haskell's syntax) that arguing it's some kind of unnecessary cognitive burden feels ridiculous to me.

Re: Why I Prefer Functional Programming

#153

Post by hinkley »

roywiggins wrote: post #49
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…

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

That's a cool trick but I'd like an operator with more pixels for that behavior.

When I used to track new languages, I ran into one where the . was implicit. You could change a member of an object from a single value to an array and it would iterate over all of the values. So you could do an information architecture that was 1:1 and change to 1:many later and things would still work.

Re: Why I Prefer Functional Programming

#154

Post by [deleted] »

robocat wrote: post #79
jimbokun wrote: post #53

Earlier quoted context omitted.

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

[deleted]

Re: Why I Prefer Functional Programming

#155

Post by lolinder »

willtim wrote: post #123
lolinder wrote: post #116

Earlier quoted context omitted.

And x86 assembler is perfectly capable of expressing pure functions. Such algorithms are still expressed using subroutines, subroutines that save and restore all state to its start state. The question isn't whether a language can express an algorithm, Church and Turing already proved that. The question is whether the language can do so scalably. We want to see nontrivial examples of FP applied to messy, side-effect-l…

Depends on what you mean by "scalable". Given that Haskell can track the use of effects and mutable state in its type system, might suggest that it allows such techniques to scale beyond a language that does not. Haskell also has syntactic and compiler support for imperative code, no encoding is necessary, so I don't think your analogy of writing FP in assembly is fair. Writing imperative code in Haskell is much the…

I'm not saying that Haskell is as bad at imperative as assembly is at functional, just that being able to accomplish all tasks in a single-paradigm language does not constitute proof that the language is suitable for all tasks.

I love FP concepts, and I've enjoyed my experiments with Haskell. What I object to is that FP advocates don't push FP as a valuable addition to a larger toolbox, they push it as a single paradigm to rule them all. For daily work, I prefer a multi-paradigm language that allows me to choose a programming model that matches the domain well.

(FWIW, I have the same problem with OOP advocates who try to squeeze everything into a class. Some things are better modeled as pure functions.)

Re: Why I Prefer Functional Programming

#156

Post by zelphirkalt »

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.

I almost fully agree. A professional programmer, how can such a person not know about stuff like map, filter and reduce? It can only happen, when they never cared to learn programming languages, paradigms or concepts of various kinds. This would betray an attitude of not continuing to learn. Even, if they have not come into contact with other programming concepts, how can any professional not have heard anything about map-reduce stuff at some point somewhere? Seems very unlikely to happen without learning-resistance or disinterest towards learning or informing oneself.

However, I would exclude junior software developers from this, as they might have just come from university, where they might not have learned about this at all, depending on the university. Still computer programming is then what they do as "profession", so we would have to count them as "professionals".

Re: Why I Prefer Functional Programming

#157

Post by n4r9 »

rienbdj wrote: post #115
0xcoffee wrote: post #92

Earlier quoted context omitted.

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…

Sadly C# is still missing a few important ML features that making functional programming more difficult than in a true ML.

It would be interesting if you could mention which feature/s you think it most sorely lacks. Some of the recent syntax additions have made it really easy to write concise functional code. I don't even use curly braces much anymore. What about f#?

Re: Why I Prefer Functional Programming

#158

Post by newen »

andolanra wrote: post #152
newen wrote: post #113

Earlier quoted context omitted.

Honestly...how is that more readable? It's more verbose sure but the first example is much more readable and straightforward. Here, you have to remember Haskell's list comprehension syntax and you have to scan up and down a few times to keep track of the variables.

> …you have to remember Haskell's list comprehension syntax… I get the point you're trying to make, but this feels like a huge stretch. Haskell's list comprehension syntax is straightforward and in many cases a terse and useful way of implementing complex functionality. You'll find multiple uses of it in the base libraries; notably, catMaybes is implemented in terms of list comprehension: catMaybes :: [Maybe a] -> [a…

Yeah I mostly agree but I mentioned it because I spent some time trying to figure how how the leftPadding variable in the let block can be referenced outside the let block. It's been a couple of years since I've used Haskell.

Re: Why I Prefer Functional Programming

#159

Post by itsbruce »

n4r9 wrote: post #145
apta wrote: post #112

Earlier quoted context omitted.

> I find Go-lang a reasonable crossover where you could do a lot of FP in it When people talk about FP, they usually include things like pattern matching and generics, none of which golang has. Not to mention it actively prohibits chaining functions that return errors because of the botched way it decided to handle errors as a product type instead of the correct way as sum type. golang is a very imperative language w…

tbh if you have the ability to easily treat functions as first class citizens in a language then it's fair enough to say you can code functionally in it. I think the attitude "X is inherently a functional language" is being replaced by the idea that there are clusters of language properties with labels like "functional" or "object-oriented" or "array-based" or whatever, and that a language may overlap with bits of va…

There's more to the admittedly fuzzy-edged concept of functional programming than function application.

I'd agree with you that the feature list is more important than a vaguer title. That's something Robet Harper talks about: http://www.cambridgeblog.org/2017/05/what-if-anything-is-a-p...

But the selection of features has limited value if the selection isn't coherent and the features don't compose. Within both FP and OOP there are languages whose design choices represent coherent choices with synergy... and ones that don't.

Go's feature set doesn't provide that coherence and synergy for functional abstractions. Frankly, it's an awkward obstacle in that direction. Beyond that, its feature set is deliberately designed to place arbitrary limits on abstraction.

Re: Why I Prefer Functional Programming

#160

Post by willtim »

lolinder wrote: post #155
willtim wrote: post #123

Earlier quoted context omitted.

Depends on what you mean by "scalable". Given that Haskell can track the use of effects and mutable state in its type system, might suggest that it allows such techniques to scale beyond a language that does not. Haskell also has syntactic and compiler support for imperative code, no encoding is necessary, so I don't think your analogy of writing FP in assembly is fair. Writing imperative code in Haskell is much the…

I'm not saying that Haskell is as bad at imperative as assembly is at functional, just that being able to accomplish all tasks in a single-paradigm language does not constitute proof that the language is suitable for all tasks. I love FP concepts, and I've enjoyed my experiments with Haskell. What I object to is that FP advocates don't push FP as a valuable addition to a larger toolbox, they push it as a single parad…

I don't think modern Haskell is a single paradigm language. As I said above, it has good support for imperative programming and lots of imperative code has been written in Haskell. Even the GHC compiler is full of imperative code and uses algorithms with mutation where it makes sense (e.g. unification).
Post reply on HN