Admitting That Functional Programming Can Be Awkward (2007) • Hacker News Board

Re: Admitting That Functional Programming Can Be Awkward (2007)

#111

Post by z3t4 » Sat, Oct 24, 2020, 7:16 PM UTC

shaan7 wrote: post #30

belval wrote: post #5

Earlier quoted context omitted.

I'd go one step further and say that most people should care little about language features when doing an actual production project, as there are aspects such as how proficient your team is in a given language and how easy it will be to maintain afterwards that are simply more important. That does not mean having a favorite paradigm or language is useless, of course I love Rust and I find functional programming elega…

> how proficient your team is in a given language and how easy it will be to maintain afterwards that are simply more important. That is a double-edged sword. On one hand it makes sense because it allows teams to be more productive. Otoh, it leads to this decade where it has become okay to create a desktop application using HTML/JS (while more performant tooling exist) simply because a lot of people happen to know HT…

Actually the programming languages and frameworks are chosen by the buisness owners which have very little dev experience.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#112

Post by swader999 » Sat, Oct 24, 2020, 7:19 PM UTC

dcolkitt wrote: post #86

shaan7 wrote: post #30

Earlier quoted context omitted.

> how proficient your team is in a given language and how easy it will be to maintain afterwards that are simply more important. That is a double-edged sword. On one hand it makes sense because it allows teams to be more productive. Otoh, it leads to this decade where it has become okay to create a desktop application using HTML/JS (while more performant tooling exist) simply because a lot of people happen to know HT…

I’d agree with this. In my experience, choosing a language/platform based on the teams experience instead of the best tool for the job is a siren song. It’s less pain upfront, but way more amortized pain over the life of the project. Start with good engineers who understand CS fundamentals. After a week or two of immersion, they’re passable in a new language. After a month or two, there’s basically no difference with…

In agreement and I'd add that I think it is a bit arrogant to assume a more junior programmer or a team of them can't learn better programming practices.

A good lead will demand good code and support it with mentoring, pairing and time to refactor.

It still doesn't give them license to do tech for the sake of tech. Every architectural choice and added complexity has to be justified by the value it brings.

But programming for the lowest common skill level on a team is generally a bad idea.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#113

Post by eyelidlessness » Sat, Oct 24, 2020, 7:20 PM UTC

andi999 wrote: post #55

eyelidlessness wrote: post #45

Honestly I think this conclusion comes more from lack of familiarity with how people solve similar problems with FP than anything. For example, in the author’s followup post: All you have to do is pass the world state to each function and return a new state. True, yes, but...yuck. It can be clunky in a language with single-assignment. And what is this really gaining you over C? I mean, if you stop there, sure that’s…

I dont understand this. This has the same disadvantages as global variables: every function (that has the state) can change it.

The point is that you start with your program as a function of the entire state tree, but as you break down the problem into smaller functions they only use or need the subset of the state they intend to “mutate”. In a dynamically typed language, doing this safely requires selecting a subset at the call site (at either the parameter or from the return value). In statically typed languages this is more easily expressed with interfaces(/types/protocols/contracts/whatever the language calls them) and you can still safely pass the full state if that’s more convenient.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#114

Post by flowerlad » Sat, Oct 24, 2020, 7:25 PM UTC

What is worse is when some developers maintain and mutate global state, write functions with side effects, and still think their code is "functional" because they aren't using any classes. A lot of JavaScript developers are moving to that camp because of React and Hooks.

More on that here: https://medium.com/weekly-webtips/dysfunctional-programming-...

Re: Admitting That Functional Programming Can Be Awkward (2007)

#115

Post by csb6 » Sat, Oct 24, 2020, 7:33 PM UTC

pizza234 wrote: post #109

jamil7 wrote: post #76

Earlier quoted context omitted.

> VSCode are written in JS and they have no performance issues VSCode is not performant, especially on startup and especially when compared to editors like vim or sublime text. I agree that the reason likely isn't language choice though it's the use of electron. I don't agree with you about software not needing to be performant either, I believe developers should strive to make their software run as efficiently as th…

> I believe developers should strive to make their software run as efficiently as they can. This is not realistic. Performance doesn't just happen. Within limited constraints, focusing on performance will necessarily imply less feature. Ultimately, it's about balance. Personally I find VSC's performance to be good, and at lot of other devs find it at least good enough (it's a widespread editor). I've actually switche…

> This is not realistic. Performance doesn't just happen. Within limited constraints, focusing on performance will necessarily imply less feature.

I don’t think this has to be the case. I’ve found that it’s not really that much harder to develop in a language like C++ compared to JS. You can develop the same feature set using better tools and end up with a more performant product (plus you get a typechecker). Performance is a feature, and if you use good tools and a language that enables efficiency without much effort, it doesn’t have to be a fixed cost added on to development.

Writing similar imperative code in C++ as you would in JS with no effort spent on optimizing is almost guaranteed to be much, much more efficient. I guess my point is that to some extent performance vs. more features is a false dichotomy.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#116

Post by z3t4 » Sat, Oct 24, 2020, 7:40 PM UTC

dcolkitt wrote: post #86

shaan7 wrote: post #30

Earlier quoted context omitted.

> how proficient your team is in a given language and how easy it will be to maintain afterwards that are simply more important. That is a double-edged sword. On one hand it makes sense because it allows teams to be more productive. Otoh, it leads to this decade where it has become okay to create a desktop application using HTML/JS (while more performant tooling exist) simply because a lot of people happen to know HT…

I’d agree with this. In my experience, choosing a language/platform based on the teams experience instead of the best tool for the job is a siren song. It’s less pain upfront, but way more amortized pain over the life of the project. Start with good engineers who understand CS fundamentals. After a week or two of immersion, they’re passable in a new language. After a month or two, there’s basically no difference with…

You might learn 95% in two months, but the last 5% might take decades. One fun thing is that the less you know the more productive you are. So a good strategy is to leave before you learn how horrible your code is, don't stay longer then two years so you don't have to deal with maintainability, performance, scaleability, security, etc.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#117

Post by pmarreck » Sat, Oct 24, 2020, 7:45 PM UTC

He thinks passing around the world state as a functional immutable data structure is “gross”, but modifying the same state as a global from anywhere in the program... isn’t?

Re: Admitting That Functional Programming Can Be Awkward (2007)

#118

Post by regulation_d » Sat, Oct 24, 2020, 7:53 PM UTC

dehrmann wrote: post #26

voodootrucker wrote: post #9

I wrote an exercise once while I was teaching: "pure functional pacman". Really I did it to teach myself Redux, and it was a pretty fun way to learn. Totally agree with the article: sometimes functional is the right tool for the job, sometimes OOP. A more recent example: parsing USB descriptors in Rust. The parser would have been trivial and easy to understand if I could have multiple mutable references to nodes, but…

> sometimes OOP. I think OOP is taught somewhat wrong because people will dwell on contrived examples of inheritance when its real value as a paradigm is coupling state with functions. What we've learned from FP is immutability is easier to reason about, but when it isn't is when OOP shines because it gives you a sane way for managing state.

Interestingly, decoupling data and behavior is exactly what I like about FP.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#119

Post by tome » Sat, Oct 24, 2020, 7:53 PM UTC

nerdtime wrote: post #103

Functional programs tend to be more modular than imperative or OOP counter parts but nobody really knows why nor do they understand the cases where FP becomes less modular. FP is only modular when you use combinators. If you use closures then it's no longer modular. f x y = x + y g y = y * 2 w x = (f x) . g g and f are combinators and modular and w is the composition of both of those combinators. w = \x -> (\y -> (x…

Huh, what do you mean by "modular" that isn't satisfied by the closures?

Re: Admitting That Functional Programming Can Be Awkward (2007)

#120

Post by pyrale » Sat, Oct 24, 2020, 7:54 PM UTC

adwn wrote: post #102

pyrale wrote: post #92

Earlier quoted context omitted.

Several recent languages that came from the FP community recently tend to achieve this. This is the case of Agda, for instance, and I believe Idris also has totality checking.

Maybe you mean optional totality? As in, a function can be declared to be total and the compiler tries to prove it? A language cannot be Turing-complete if it completely forbids non-termination, there is no way around this. Or stated differently: If a language is Turing-complete, then there are programs that don't terminate. If a Turing-complete language only has functions which are total (i.e., which always terminat…

> A language cannot be Turing-complete if it completely forbids non-termination, there is no way around this.

I do acknowledge this. My point is that turing-completeness is not necessarily a desirable aspect of a language. You can check out Agda if you are interested in what can be done with a total language.

For some use-cases, like seting up a mainloop, you need an escape hatch because that mainloop is not going to be total. But not every program needs that. Conversely, a programming language that doesn't care about totality won't be able to sere other use-cases, such as building proven programs. My understanding is that it's much easier to build an escape hatch in total languages, than it is to retrofit non-total languages to prove programs.