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

381–390 of 513 posts

Re: Functional programming should be the future of software

#381

Post by the_af »

tsimionescu wrote: post #376
the_af wrote: post #298

Earlier quoted context omitted.

It's funny because the community knows some people too deep in the rabbit hole come across that way, but because the community acknowledges this is a hilarious assertion that would alienate newcomers -- if said with a straight face -- then it cannot be gatekeeping. Gatekeeping would be if the community said this with a straight face and everyone got impatient when you just "don't get it". > I've seem the claim that y…

Well, try understanding the Haskell docs around Applicative, Functor or Monad without understanding at least basic category theory - not to mention the heavy use of notation/operators in place of traditional programming idioms (named functions). Here [0] is an example: > This module describes a structure intermediate between a functor and a monad (technically, a strong lax monoidal functor). Compared with monads, thi…

Counterpoint: I learned about Applicative, Functor and Monad by reading docs and tutorials, and I haven't the faintest idea about category theory.

These are the building blocks of Haskell. You learn them as you go, just as you learn what a "method" is when learning OOP. You don't need to know category theory.

Re: Functional programming should be the future of software

#382

Post by leidenfrost »

BlargMcLarg wrote: post #353
bbarn wrote: post #310

Earlier quoted context omitted.

.net, and C# especially are absolutely fantastic tools for programming. The problem is just that they are embraced by large companies and that is where crappy engineers tend to congregate, in my experience. The bigger the company the easier it is to get lost in the crowd. I enjoy functional programming, but I'm a wizard with C# and .net, and I can pull a much higher salary continuing to focus there. I can write my ow…

It's also laziness and controversy. Unit testing is something aggressively pushed in many of these places, but then they continue to litter side effects, long flows, loads of complex objects, void methods, and more which inherently make it more difficult to test. FP guidelines help a lot of these cases, and you don't need to understand monoids, monads or any of that to grasp the concept of simple functions with clear…

Before learning FP I used to ask myself: "Assuming that by tomorrow my memory gets erased and my IQ diminishes by 50 points, will I understand this code?".

That's why I try to juggle the least amount of variables as possible at the same time, while trying to have my code to read like a cooking recipe or a very simple literature. From that, FP feels almost natural.

Even more so, I think that most software bugs and spaghetti code is made by people that were too confident on themselves. They thought they could handle a lot of random unrelated variables floating around all the time, while having their functions do a lot of random algorithms at the same time.

And yes, they could handle it. The first time. But, in the long run, most people forget, or they leave and another person ends up having to maintain it, and that super brief-and-clever code became an unmaintainable mess.

Re: Functional programming should be the future of software

#383

Post by tsimionescu »

aranchelk wrote: post #300
gjulianm wrote: post #245

Earlier quoted context omitted.

> there are more FP languages that are not as pure as Haskell I mean, that's precisely the point I'm making, that IO doesn't fit into the FP paradigm and that languages that make IO easier necessarily deviate from it. And once you bring non-FP concepts into an FP language, most people will reasonably question why do that instead of the easier way, which is bringing FP concepts into imperative languages.

Pure functional languages model IO with monads, which are very much functional (function composition within a context) and IMO easy to use. This ease of use is probably why JS adopted the pattern with native promises -- async/await. They fit well into otherwise imperative code and people seem to to like them.

Pure functional languages can very well have normal IO. It's Haskell's lazyness that mostly forced it to use monads for IO, for better or for worse. In a pure FP language with strict evaluation semantics, IO can easily be implemented as a pure function foo -> (World, Input) -> (World, Output).

Re: Functional programming should be the future of software

#384

Post by hither_shores »

AnimalMuppet wrote: post #358
hither_shores wrote: post #333

Earlier quoted context omitted.

In most situations, you use persistent data structures where you only have to copy the modified leaves. If you really need your type to be backed by a contiguous block of memory, you batch updates (stencils, SIMD, etc.)

But if you modify the leaf, don't you also have to modify the branch node that points to the leaf, so that it points to the new one? And every node from there to the root?

Yes, you (or rather, core library developers) need to pick a data structure appropriate to your access patterns: linked lists for iteration, search trees for concatenation, finger trees for random access, and so on. But you should be doing this anyway for clarity, even if you face no performance constraints.

Re: Functional programming should be the future of software

#385

Post by initplus »

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…

Honestly Haskell's tooling is really surprisingly good these days. It works fine cross platform, there is a single "blessed" path without too many options to spend time agonizing over.

Today the Haskell example is just `cabal install --only-dependencies && cabal build`.

Re: Functional programming should be the future of software

#386

Post by deviantbit »

ParetoOptimal wrote: post #192
deviantbit wrote: post #126

I believe functional programming is interesting, and fun. But it is not going to replace the world. My background has spanned from working on AAA games, to simulations for the DoE, to owning my own business developing embedded products, and graduate school (yes, I went back as a gray haired, and did that late). I fell in love with Lisp many years ago on a TI Explorer. Functional languages are inherently difficult to…

> In fact, I challenge you to develop a first-person shooter in Haskell (Have fun). https://hackage.haskell.org/package/frag > There are many types of applications where functional languages are perfect, but there are more that it would be a disaster. Can you give an example or two of an application in a functional language would be a disaster? > To make broad sweeping claims, such as this article, just encourages un…

frag-1.1.2 failed during the building phase. The exception was: ExitFailure 1

Go fix that for us.

``Can you give an example or two of an application in a functional language would be a disaster?``

Sure, code that tests its self. Not happening. Which means, most embedded applications where fault tolerance is a must. If you don't know what caused the error, well, lets here your ignorant response. Explain how you trap those problems in a functional language, and do it as simple as you can, say in C, or Pascal.

``opposing viewpoint to the popular "right tool for the job"``

So you advocate a hammer for screw. Got it. You're exactly the kinda of person I won't hire. You're so bent on proving you're right, you ignore the right tool for the right job.

Re: Functional programming should be the future of software

#387

Post by mpweiher »

leidenfrost wrote: post #370
mpweiher wrote: post #342

Earlier quoted context omitted.

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

imho the whole thing about FP it's not about a objectively superior way of coding, but a way of coding that's better suited to the current high level, highly distributed world. There are A LOT of developers, a lot of custom made software and a lot of web applications. And unless you really need performance, most web services are an ideal use case for FP practices. Even if you do it in plain Javascript. Some people ar…

> imho the whole thing about FP it's not about a objectively superior way of coding,

OK.

> a way of coding that's better suited to the current high level, highly distributed world.

But is it objectively better suited? One might even say "superior"? ;-)

Also, I actually believe FP is actually quite ill-suited to the high-level and particularly the highly distributed world.

Re: Functional programming should be the future of software

#388

Post by tsimionescu »

the_af wrote: post #381
tsimionescu wrote: post #376

Earlier quoted context omitted.

Well, try understanding the Haskell docs around Applicative, Functor or Monad without understanding at least basic category theory - not to mention the heavy use of notation/operators in place of traditional programming idioms (named functions). Here [0] is an example: > This module describes a structure intermediate between a functor and a monad (technically, a strong lax monoidal functor). Compared with monads, thi…

Counterpoint: I learned about Applicative, Functor and Monad by reading docs and tutorials, and I haven't the faintest idea about category theory. These are the building blocks of Haskell. You learn them as you go, just as you learn what a "method" is when learning OOP. You don't need to know category theory.

Learning what Applicative, Functor and Monad are is category theory. It's like saying "you can learn how to do unions, intersections, and differences on collections of unique objects without understanding set theory".

Re: Functional programming should be the future of software

#389

Post by tsimionescu »

BlargMcLarg wrote: post #360
tsimionescu wrote: post #357

Earlier quoted context omitted.

> The other part is FP's a bit of a mind fuck if you're used to procedural programming It's not "if you're used to procedural programming" - FP is simply hard for people to reason about. You can often very intuitively reason about imperative programs, while FP always requires putting your abstract thinker cap on. Look at any non-software person describing describing how to do something and see how often that sounds l…

Eh, it really depends. Some people find trees easier to navigate through recursion than iteration, same for lists and graphs. Some do better using decomposition on a list to get a combined value or create permutations than doing it through iteration and indexing. FP commonly becomes problematic when things are far more trivial to do stateful than stateless, with side-effects than without, and more. FP usually shines…

Sure, there are contexts where the functional approach is actually more natural - especially already highly abstract contexts. I actually like to use certain functional paradigms in my day to day programming (or did, before switching to Go). I just dislike the claim that imperative code is simply more familiar and not more natural/intuitive (in general).

Re: Functional programming should be the future of software

#390

Post by naasking »

tsimionescu wrote: post #368
naasking wrote: post #328

Earlier quoted context omitted.

> 1. Immutability is non-intuitive. If I were to hand a regular person a book, and ask him how he would list all the page's numbers where the word cheese appears, he would probably say something like this: 'I would read through the book, keeping a scrap of paper at hand. Whenever I saw the word cheese, I would write down the page number' This is an imperative algorithm. No, that's a purely functional algorithm. Note…

> No, that's a purely functional algorithm. Note how he's just adding numbers to the end of a list and emphatically not mutating the existing items in any way. They are clearly mutating the piece of paper to add new numbers to it. There is no linked list in sight. They are also flipping the pages of the book in order, another imperative paradigm. The closest you could come to a pure FP algorithm expressed in physical…

> They are clearly mutating the piece of paper to add new numbers to it.

No, they are simply adding a new record for the word occurrence. If the paper runs out, they grab another sheet and continue. This is clearly an append-only ledger, just like that used in accounting. These are both immutable abstractions.

The fact that this is happening on a single sheet of paper is merely an optimization, it's not a property of the underlying algorithm they're employing. The post-it equivalent you describe is simply a less space efficient version of exactly the same algorithm. You're basically saying that tail call elimination makes FP no longer FP.

> There is no linked list in sight.

What do linked lists have to do with anything? You don't think that FP or immutable programming have to use lists do you?

> They are also flipping the pages of the book in order, another imperative paradigm.

Traversing an immutable sequence in order is now an imperative algorithm? Since when?

What's really happening here is that you've already assumed that physical reality and people's intuitions are imperative, regardless of the contortions required.

This example of counting words and the general ledger are perfect examples: it's absolutely crystal clear that all of the recorded entries are immutable and that this log of entries is append-only, which is a characteristic property of FP and immutable abstractions, and yet you have to contort your thinking into looking at the paper itself as some mutable state that's essential to the process in order to call this an imperative process.

Post reply on HN