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

341–350 of 513 posts

Re: Functional programming should be the future of software

#341

Post by moffkalast »

pessimizer wrote: post #117
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…

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 don't believe that you're actually considering ada, cobol and forth for new projects.

I'm not considering Erlang either.

Re: Functional programming should be the future of software

#342

Post by mpweiher »

SkyMarshal wrote: post #290
pfraze wrote: post #215

Earlier quoted context omitted.

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…

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

It is so incredibly widespread, it's not just "an anecdote of one person".

The entry-level courses at TU-Berlin where I studied had just been taken over by FP disciples when I started studying, and it was crazy. "Let me tell you about our Lord and Saviour Functional Programming, Hallelujah".

And of course the reality didn't come close to matching the advertising.

And it never does.

Another nice example was in a lecture by SPJ on parallel Haskell, where he says "This can only be done in a functional language.". Audience member: "We've been doing exactly this in HPC for decades. In FORTRAN". Instead of conceding or apologising for the gaffe, SPJ doubles down with something along the lines of "well, then what you are using is an FPL". Jeez. Oh, and when it comes to the results he reveals that the overhead is so high that you need 7-8 cores running full tilt to be equivalent to a single core C program. Jeez.

In general, there is also the widespread phenomenon I call "functional appropriation", where a similarity is noted between some aspect of FP and some other mechanism or paradigm or some such, and then the claim is made that this obviously means that the other mechanism/paradigm is just thinly veiled FP.

Newsflash: let me tell you about Turing machines. Or NAND gates...

For example FRP, "Functional Reactive Programming". Which is really just dataflow, and badly packaged dataflow at that. Or the React people's claim that the core concept or React is that the UI is a "pure function" of the model. Well, it turns out it is not. Not a pure function at all. And not really a function either. Just a mapping. And any UI had better be some sort of mapping of the model, or it's hard to see how it would qualify as a UI.

I could go on (and on, and on, and on...) but I'll stop now.

Re: Functional programming should be the future of software

#343

Post by moffkalast »

NaturalPhallacy wrote: post #315
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…

Basically the antithesis of the "silver bullet". That is, there is no silver bullet.

A silver bullet may be able to elegantly kill the werewolf, but throw enough depleted uranium his way and the problem should go away soon enough.

I suppose that's an analogy for object oriented design or something.

Re: Functional programming should be the future of software

#344

Post by thosakwe »

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…

Another reason is that imperative languages have a lot of business inertia around them. It's expensive to rewrite existing code or switch to a new language, and most businesses can't justify this cost.

I love functional programming, but I doubt most companies that sell CRUD apps care about it.

Re: Functional programming should be the future of software

#345

Post by blep_ »

z9znz wrote: post #319

At the last two places I worked, I gradually led my teams from traditional OOP Ruby or Python behaviors to at least partially functional (if you'll pardon the pun). The immediate value I was able to demonstrate was in testing. Three basic (not too scary) principles can get you a long way: 1. push mutations and side effects as far toward the edges as possible (rather than embedded in every method/procedure) 2. strive…

> prefer simple built-in data structures (primarily hashes) over custom objects

I've found this is actually one of my biggest problems with functional code as currently written: people seem afraid to just declare a struct/record, in lots of cases where it's obviously the right thing.

If everything is a hash, you've just made all arguments optional and now you've invented a bad type system inside your good type system.

If everything is a tuple (more common in my experience, from reading Haskell), now you know (int, int) is actually a pair of ints, but you've thrown away variable names and nominal typing: is it a 2D vector, a pair of indices into an array, or something else entirely?

Defining custom types is the elegant solution to this: you have `struct range { start: int, end: int }` and now your functions can take a range and everything is great.

Re: Functional programming should be the future of software

#346

Post by BlargMcLarg »

rowanG077 wrote: post #332
kstenerud wrote: post #318

Earlier quoted context omitted.

Addendum after watching this thread blow up: What's interesting to notice about this thread is how many messages are just oozing with smug superiority and disdain for anyone who doesn't share their knowledge. Yes, some are from genuinely humble and even-handed FP practicioners, but when we look at people who are vocal about FP, this small example shows around 90% of them in the gatekeeper camp. And the punchline is I…

Do you have actual, recent, examples of this? I keep reading the same attitude you have here, but I have never seen it first hand.

Git, Vim and general GUI come to mind, specifically on this site. There is always someone berating individuals for not using shortcuts, not using the console instead of a visual tool, using an IDE, etc. Specifically using Git with a GUI primarily is a great way to get flak from several subreddits, too.

NB: This is not an invitation for discussion on the pros and cons, to berate either preference, or gatekeep.

Re: Functional programming should be the future of software

#347

Post by zamalek »

pera wrote: post #71
zamalek wrote: post #24

Functional programming won't succeed until the tooling problem is fixed. 'Tsoding' said it best: "developers are great at making tooling, but suck at making programming languages. Mathematicians are great at making programming languages, but suck at making tooling." This is why Rust is such a success story in my opinion: it is heavily influenced by FP, but developers are responsible for the tooling. Anecdotally, the…

That's interesting, I often find the tooling one of the best things that FP languages offer. In OCaml for instance I found Dune to be fantastic and extremely intuitive. Another very good experience I had was with Elixir and Hex. In Haskell I personally think that there are indeed quite a few things that could be improved around build system and packaging, but overall it's not really that bad once you learn the quirks…

It would the OCaml community a great service if you wrote up a beginner's tutorial on working with Dune.

Re: Functional programming should be the future of software

#348

Post by bee_rider »

xdavidliu wrote: post #302
bee_rider wrote: post #202

Earlier quoted context omitted.

C/C++ is just 1 in the limit, right?

two things wrong with your statement: - the ++ operator only acts on integer types, not floats or doubles, so there is no limit to speak of here - the expression "C++" has value equal to C before incrementing, hence the expression "C/C++" is just one for positive C, even when C is small

So, luckily my mistakes cancel out -- C/C++ = 1 always, so it must also in the limit. Once we figure out how to define limit.

Re: Functional programming should be the future of software

#349

Post by softwarebeware »

tikhonj wrote: post #309
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…

> 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. That's exactly what worked for OOP—have we collectively forgotten just how hard OOP was pushed everywhere 15–20 years ago? Way more aggressive than any FP advocacy I've seen, and I've seen a lot. When I was learning to program every single book and tutorial pushed…

And yet today we only have partially-OOP languages being mostly used in procedural ways.

Re: Functional programming should be the future of software

#350

Post by swyx »

sk0g wrote: post #289
Rochus wrote: post #274

Earlier quoted context omitted.

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

isn't it amazing in this day and age we can just google a 7 year old quote and basically pull up the actual video of it instantly and send it around timestamped?

some days technology sucks, but other days its a wonder it works as well as it does

Post reply on HN