Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Functional programming should be the future of software

spectrum.ieee.org

Post reply on HN
Print view View original

281–290 of 513 posts

Re: Functional programming should be the future of software

#281

Post by rosenjcb »

kstenerud wrote: post #57

I immediately distrust any article that makes sweeping claims about one-paradigm-to-rule-them-all. The reason why multiple paradigms exist is because here in the real world, the competing issues and constraints are never equal, and never the same. A big part of engineering is navigating all of the offerings, examining their trade-offs, and figuring out which ones fit best to the system being built in terms of constra…

We use Clojure at my work and it's basically functional Java with parens. No snottiness or evangelism needed. The fact that I don't have to write Java OOP boilerplate is a big enough advantage to me. Even if you just write it like Python or JS, it's still leagues better.

Re: Functional programming should be the future of software

#283

Post by DonaldPShimoda »

AnimalMuppet wrote: post #232
packetlost wrote: post #187

Earlier quoted context omitted.

> One of the big reasons why FP languages have so little penetration is because the advocacy usually feels like someone trying to talk you into a religion. Eh, I doubt it. I've encountered a few Haskell snobs in my time, but most people that I know who use FP do so completely silently and will discuss the merits and (and challenges) with you freely. I think the real issues with FP are lack of good tooling, package ma…

"A monad is just a monoid in the category of endofunctors". Anyone who says that - or anything anywhere close to it - is gatekeeping, no matter how true the statement is. And it's not just the statement. It seems to me (from my outside perspective) that category theory is often used in a gatekeeping way. In contrast, take SQL. How much of the mathematical theory of relations do you need to know to be able to write SQ…

> "A monad is just a monoid in the category of endofunctors". Anyone who says that - or anything anywhere close to it - is gatekeeping, no matter how true the statement is.

The original attribution of this line about monads comes from the (intentionally) comedic article "A Brief, Incomplete, and Mostly Wrong History of Programming Languages", published by James Iry in 2009: http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m...

It is not a stance I have ever seen taken up in a serious manner by anybody in the FP community, and I work in PL academia (the region of the community from which I would expect to see the most snobbery). Please stop misrepresenting people based on a misunderstood joke.

There are people in the FP community who gatekeep and take on a snobbish tone — with that I do not disagree. However, their prevalence is generally overstated; it's a vocal minority situation. Most people I know or have talked to are very welcoming.

Re: Functional programming should be the future of software

#285

Post by sk0g »

karmakaze wrote: post #140
christophilus wrote: post #83

Earlier quoted context omitted.

Last time I used F# on Linux, the REPL was a mess and mostly unusable. Compilation takes forever. You have to edit an fsproj rather than inferring modules from the file system structure like most modern languages. It’s a great language— maybe my favorite, but the tooling stinks if you’re not using VS. I’m not switching to Windows, so that leaves me in limbo.

PSA: Visual Studio for Mac[0]. I know you're on Linux but for others. [0] https://visualstudio.microsoft.com/vs/mac

And just for clarity, it's not proper Visual Studio, but rather an updated MonoDevelop. Was missing quite a lot of functionality (for Unity/C#) compared to VS, so I used Rider instead.

Re: Functional programming should be the future of software

#286

Post by taeric »

BoiledCabbage wrote: post #270
taeric wrote: post #251

I find this an amusing take. I'd more fully accept "declarative should be the future of software." In that, at large, I'd rather larger chunks of the software I am responsible for to be declarations of intent, if at all possible. That said, the rubber still hits the road somewhere, such that the abstraction should be tailored to fit the domain, if you can. As a fun challenge, look at the definition of pretty much any…

> Really, anything from the book Turtle Geometry would have a challenging time in a lot of functional languages. https://github.com/sergv/turtle-geometry Is an implementation of the book Turtle Geometry in Scheme. A Lisp dialect. > Which is not that most functional languages are bad. Just they don't usually even try to abstract over the graphical. I hate that folks see how well the abstract over functions and assume…

Yeah, that isn't surprising, in that the book even mentions using LISP. However, this is a touch of a goal post shift with what folks typically mean by modern functional programming. (Which, to be fair, was always far more nebulous than folks admitted.)

Specifically, though, this is my point. The turtle geometry abstraction is very imperative, by nature. It is still declarative, at a high level. But it is not functional. Despite that, it can be implemented in one of the classic functional languages. (Though, lisp's origins are far more imperative than you would think.)

Re: Functional programming should be the future of software

#287

Post by feoren »

wnolens wrote: post #246
commandlinefan wrote: post #213

Earlier quoted context omitted.

> A lot of languages have functional features but are not “purely” functional. That was my first thought. I work mostly in Java because that's what they pay me to do, but I've almost never worked with a Java programmer who could actually write Java code using the OO features that the language is based around. When I see their Scala code... it's mostly var, rarely val, because it's easy to think about.

Whenever I see "interesting" object modeling beyond very basic inheritance, I groan. I've never experienced it being worth the hassle (templates, factories, etc..). But my code is flush with collection.stream().filter().map().collect() etc. I was initially critical of it in code reviews (coming from C), but have been totally converted.

Templates (I assume you mean Generics, if we're talking Java?) aren't worth the hassle, but your code is flush with .filter() and .map()? Which rely entirely on generics to provide any typing support at all? You should learn to embrace generics; they're absolutely critical for the code you just said you write, and more. And they are most certainly not going away.

Re: Functional programming should be the future of software

#288

Post by feoren »

throwaway1492 wrote: post #41
dmitriid wrote: post #13

Earlier quoted context omitted.

To quote "Stop Writing Dead Programs" [1]: "If what you care about is systems that are highly fault tolerant, you should be using something like Erlang over something like Haskell because the facilities Erlang provides are more likely to give you working programs." [1] https://www.youtube.com/watch?v=8Ab3ArE8W3s

That quote is absurd because the vast majority of applications on the planet are not written in Erlang and work just fine. Working and fault tolerance are in no way related. Being generous the majority of applications with very high uptime are also not written in Erlang.

> the vast majority of applications on the planet are not written in Erlang and work just fine

The vast majority of applications on the planet are bug-ridden, fragile, over-budget, under-thought, mark-missing, user-hostile garbage. They most certainly do not "work just fine."

Re: Functional programming should be the future of software

#289

Post by sk0g »

Rochus wrote: post #274
aryehof wrote: post #257

I'm reminded of the following quote by the co-author of SICP - Gerry Sussman... "Remember a real engineer doesn't want just a religion about how to solve a problem, like object-oriented or functional or imperative or logic programming. This piece of the problem wants to be a functional program, this piece of the program wants to be imperative, this piece wants to be object-oriented, and guess what, this piece wants t…

A refreshingly pragmatic position for an academic. Where did you get that quote?

From a quick google, likely from a talk on Youtube. Matching section timestamped - https://youtu.be/O3tVctB_VSU?t=2346

Re: Functional programming should be the future of software

#290

Post by SkyMarshal »

pfraze wrote: post #215
pessimizer wrote: post #117

Earlier quoted context omitted.

This is just an appeal to the law of averages. I don't believe that you're actually considering ada, cobol and forth for new projects. > One of the big reasons why FP languages have so little penetration is because the advocacy usually feels like someone trying to talk you into a religion. This is never really a reason for anything, it's a personal attack on people who advocate the thing that you don't want to do. FP…

I was once at a distributed systems meetup where a member of the audience interrupted the talk to give an extemporaneous presentation on why we should all be using Haskell. FP advocates have a reputation for being zealous and pretentious. The only question is whether they’re right to be.

An anecdote of one person with bad manners shouldn't be representative of the whole.

I'd estimate there are three kinds of FP advocates:

1) People (like me) who have experienced personal pain in building or maintaining complex systems in imperative or other paradigms, and are genuinely astounded and relieved when we learn how Haskell and other FP languages can mitigate or eliminate that pain. They tend to advocate FP as a solution to specific problems they've personally encountered.

2) PLT academics who are just generally fascinated with building a mathematical programming language that can elegantly express the most advanced notions in math and logic.

3) People who like to feel superior and rudely interrupt presentations to expound on monads and endofunctors and the like.

Try to focus on and/or associate with #1 and #2 and ignore #3.

Post reply on HN