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

421–430 of 513 posts

Re: Functional programming should be the future of software

#421

Post by deterministic »

Show us the commercially successful wonderfull code you wrote using functional programming and you will be 1000x more convincing than anything you claim in an article or religious face-to-face debate.

For example, there are hundreds of glowing articles written about Lisp, making all kinds of amazing claims about the superiority of the language and the superior intelligent of people using it. However very little commercially successful software is written in Lisp. Making those claims laughable and not convincing at all.

Less talking more walking!

Re: Functional programming should be the future of software

#422

Post by imbnwa »

kstenerud wrote: post #318
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…

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…

OMG you just reminded me of waiting outside some 101 class on day one typing on my laptop and this guy asks me what OS I'm running. When I told him "Ubuntu", he snickers and says "Talk to me when you're done playing with a toy"

Re: Functional programming should be the future of software

#423

Post by Karrot_Kream »

alanwreath wrote: post #292
AnimalMuppet wrote: post #256

Earlier quoted context omitted.

But why should FP be the basis for understanding? Let's say I run a CS department. And let's say that I've accepted that what my department is really doing is jobs training for software engineers. Well, what are their jobs going to be, imperative or functional? For most of them, for most of their careers, the jobs are going to be imperative. Why should we start with FP? You could say "FP is better", but then we're ba…

It’s about rope. Imperative languages generally give you a lot of flexibility (for x or y) and, therefore, rope to hang yourself. I don’t believe that starting students here, from a pedagogical perspective, is a good strategy. FP languages/paradigms, on the other hand, are all about restrictions(immutability, side effects, etc), and thus less rope. Less places to hang yourself, so to speak. Also, even though, as you’…

This rope only matters for production oriented systems. Most programmers are doing quotidian processing tasks. Manipulating CSVs, processing data to get statistics on, plotting points on maps, maybe writing a simple automation. Almost every software engineering class I read about when I was a graduate student teaching undergrad classes spent time discussing the pitfalls of the "rope of mutability" and explicitly discussed the idea of immutability to make this kind of programming safer. I agree with another poster that it's just much easier to teach general programming skills and thinking procedurally. I do think that programmers have to unlearn some of this when writing production-grade software, but most programmers will never write anything like that.

Re: Functional programming should be the future of software

#424

Post by bob1029 »

I'd strongly recommend checking this paper out:

Out of the Tar Pit - http://curtclifton.net/papers/MoseleyMarks06a.pdf

I agree that functional programming is part of the future. I believe that the relational model is the other part. In this space, imperative programming exists primarily to bootstrap a given FRP domain.

We've built a functional-relational programming approach on top of SQLite using this paper as inspiration. Been using this kind of stuff in production for ~3 years now.

Remember - Your user/application defined functions in SQL do not need to be pure. You can expose your entire domain to SQL and build complete applications there, with the domain data & relational model serving as first-class citizens. With special SQL functions like "exec_sql()" and storing your business rule scripts in the very same database, you can build elegant systems that can be 100% encapsulated within a single .db file.

Re: Functional programming should be the future of software

#425

Post by Karrot_Kream »

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…

I think FP suffers from what I call the "ideological gruel" problem. A lot of niche ideology-oriented communities with very strong opinions tend to ignore usability issues not necessarily because it's a theory/practice dichotomy, but that the highly ideologically excited community ignores the problems because they're so positively motivated by the ideology. So even if you're eating gruel, if the gruel is produced by an ideology you identify strongly with, the identification alone is enough to make the gruel taste better than mere gruel. A lot of folks that use FP are willing to overlook the myriad of rough edges around tooling because they're so excited to work with FP that they often get used to the tooling. Rust made tooling UX an explicit focus of the project which is why it was able to escape the "ideological gruel" curse.

Additionally most prominent FP projects are old. Both Haskell and Ocaml date from a time when UX expectations around language tooling were much lower (think C++.) The inertia around the projects never cared much for UX anyway so now in 2022 when languages like Rust and Go have raised the floor of expectation for PL tooling, Haskell and Ocaml struggle to keep up.

Re: Functional programming should be the future of software

#426

Post by TexanFeller »

packetlost wrote: post #239
AnimalMuppet wrote: post #232

Earlier quoted context omitted.

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

SQL is intrinsically tied to set theory and borrows a ton of terminology and logic from set theory. Whether you understand that it's from mathematics or not doesn't really matter. You are using set theory and it's terminology regardless. I've only really ever seen monoids referred to in Haskell. If you actually read my comment, Haskell is not all FP (no PL is). It's not even a significant portion of FP. So just don't…

SQL tables are not actually sets at all since you can insert duplicate rows! In practice they usually are though.

Re: Functional programming should be the future of software

#427

Post by Iwan-Zotow »

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

> the ++ operator only acts on integer types

no, I believe it works on pointer types and enums as well

Re: Functional programming should be the future of software

#428

Post by blep_ »

z9znz wrote: post #400
blep_ wrote: post #345

Earlier quoted context omitted.

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

It's not about being afraid to define a struct/record (rigid type). It's about being afraid of being stuck with something that doesn't meet your needs later or elsewhere, if only by a little bit. That Range type is great until you have cases where you want variations on a Range, such as a MeasuredRange (same start and end, but with a new field called step_cost). Original functions which take a Range can't cope with t…

re Haskell: I just looked at a few arbitrary files in arbitrary Haskell projects on Github, and I retract that part. I was either thinking of another language, or had seen a lot of bad Haskell code before that I cannot find now.

----

Isn't this just the nullability thing again that most people have decided was a bad idea, but with a different name? Instead of two ints, now your function takes two maybe-ints and crashes at runtime if they're not there.

I do think the thing you're asking for (interfaces but for fields instead of functions) is a missing feature in most languages. I understand why it's there, but it's still annoying.

The most well-known language I can think of that explicitly supports it in an otherwise static type system is TypeScript, where a type can be "object containing non-nullable ints called start and end, but with no constraints on other fields that may be there"[0]. It's technically a hash map at runtime, but it's a compile-time type-checked hash map.

In other languages, you could bodge it with a bunch of Java-esque getX/setX functions. I don't blame people for not doing so.

[0] https://www.typescriptlang.org/docs/handbook/2/objects.html

Re: Functional programming should be the future of software

#429

Post by DonaldPShimoda »

momentoftop wrote: post #392
DonaldPShimoda wrote: post #283

Earlier quoted context omitted.

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

That article went round the Edinburgh mailing list when it was published, and Phil Wadler, who got monads into Haskell, replied saying something like "I didn't know this. Does anyone have the proof?" The actual quote that monads are monoids in the category of endofunctors comes from MacLane, and is intended for mathematicians.

I'm honestly not sure the MacLane reference applies here.

Although the abstract phrasing can be traced to him, the particular use of "just" in the parent comment's quote tells me they're specifically thinking of the (deliberately condescending) version from the Iry post, especially since that's the version that gets memed throughout the FP community. After all, that particular phrasing is meant to convey a sense of "this is obvious and you are stupid if you don't understand it immediately", which is a far cry from the MacLane version (since that one is, as you said, intended for mathematicians).

But I probably ought to have included the full provenance regardless; thank you for bringing it up!

Re: Functional programming should be the future of software

#430

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

Hey, wait a minute, ++ is defined for floats.

It might be a bad idea to use it in many cases (since there are values for which the result is just rounded back to the original value), but it works!

Post reply on HN