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

“Mostly functional” programming does not work

queue.acm.org

Post reply on HN
Print view View original

51–58 of 58 posts

Re: “Mostly functional” programming does not work

#51

Post by rprospero »

stinos wrote: post #14
btmorex wrote: post #5

To play devil's advocate for a minute: Nearly all useful, reusable software today is written in a mostly or entirely imperative language. This is despite the fact that functional programming has been around for at least 20-30 years. So, my basic question is, if functional programming is so much better, why isn't more software written in a functional language? Or put another way, why are there so many blog posts promo…

After reading the article I tend to agree. Just this excerpt seems to confirm: Pure functional programming is programming with mathematical functions. ... Calling a function with the same arguments will return the same result every time. That leaves a whole lot of other functions, the non-mathematical ones, the real-life ones where you read files or I/O or user input out of the "Pure" definition, if I understand it c…

You can do a pure function that reads files or does IO. Heraclitus solved the algorithm millenia ago. You just need to include the right parameters.

Instead of

    readFile(file_name)
You just do

    readFile(file_name,complete_description_of_the_universe)
If you change the value of complete_description_of_the_universe, then you've changed the input to your function, and of course you're going to get a different result back.

Granted, a full complete_description_of_the_universe is rather space consuming. I don't even think it would fit on a floppy. Maybe a Zip drive?

Thankfully, you don't need the COMPLETE description. You only need the parts that your computer can access. There's no reason to store the amount of gas in the bowels of every elephant in India, unless you actually have an elephant gas sensor. So our function is really

    readFile(file_name,complete_description_of_everything_the_computer_measure)
Of course, that still means that the second parameter contains the contents of every bit on the hard drive, since the GMR sensor can measure those bits. Some lousy manufacturers are now selling computers that don't even have enough memory to hold their entire hard drive contents. Thankfully, we can use another optimization.

Since, by definition, the computer can measure the value of complete_description_of_everything_the_computer_measure, there's no reason to store it in memory at all. We just measure it when it's needed. Granted, it's a little slow to read the hard drive, versus having the entire drive stored in memory, but premature optimization and all that.

It's still completely functional, though. We still pass the function two parameters. The first parameter is a set of bytes in memory with a EBCDIC representation of the name of the file. The second parameter is a physical computer that can perform the measurements. As long as you pass the exact same computer to the readFile function, you'll get the same result every time.

Same thing for writeFile. We pass in a physical computer and the function returns to us a new, physical computer that's similar to the one that we passed in, except that this computer has some different magnetic spin arrangements on its hard drive and its system clock is reading a different value.

Granted, carrying all of these physical computers around gets tiring, plus people start giving you guff about conservation of mass or whatever whenever you make a new computer. Thankfully, the functional compiler guys have found ways to optimize the code so that you can destroy the unneeded computers very rapidly. In fact, it's faster than the human eye can detect. Without careful measurement, you'd think that it was just one computer the whole time.

Re: “Mostly functional” programming does not work

#52

Post by pjmlp »

btmorex wrote: post #5

To play devil's advocate for a minute: Nearly all useful, reusable software today is written in a mostly or entirely imperative language. This is despite the fact that functional programming has been around for at least 20-30 years. So, my basic question is, if functional programming is so much better, why isn't more software written in a functional language? Or put another way, why are there so many blog posts promo…

It is called legacy.

For several reasons, the hardware required to run Lisp code was too expensive vs what was required to run C, Pascal, Algol and their descendants.

Business don't change programming languages, just because. Unless you are doing greefield projects, there is a whole eco-system from tooling, building, trainings, developers, legacy code that needs to be taken into consideration.

By the time computers were getting cheap enough to handle FP at reasonable price, the OOP finally managed to get into the industry at the enterprise level. As such it got the place that could have been taken by FP.

OOP goes back to Simula and Smalltalk, which happen to also be Lisp inspired.

As for not producing results, many train schedule systems run on Lisp.

http://www.siscog.pt/

Re: “Mostly functional” programming does not work

#53

Post by mathenk2 »

I must say that in all of my years, most every piece of source I've ever seen has been mostly [insert paradigm here]. OOP is "mostly" more times than not, same goes for FP. I would argue that "mostly" does work, and thankfully so, because nearly every service that you use throughout your day is a "mostly".

Re: “Mostly functional” programming does not work

#54

Post by sparkie »

rprospero wrote: post #51
stinos wrote: post #14

Earlier quoted context omitted.

After reading the article I tend to agree. Just this excerpt seems to confirm: Pure functional programming is programming with mathematical functions. ... Calling a function with the same arguments will return the same result every time. That leaves a whole lot of other functions, the non-mathematical ones, the real-life ones where you read files or I/O or user input out of the "Pure" definition, if I understand it c…

You can do a pure function that reads files or does IO. Heraclitus solved the algorithm millenia ago. You just need to include the right parameters. Instead of readFile(file_name) You just do readFile(file_name,complete_description_of_the_universe) If you change the value of complete_description_of_the_universe, then you've changed the input to your function, and of course you're going to get a different result back.…

In practice, you don't actually need to return a new universe at all, because of course, that would be quite costly. Instead, the runtime can modify the existing universe and return it with a new unique identity - the reason we can do IO and remain referentially transparent is because every time we perform a side-effect, we do so on a unique universe - there is no way to duplicate a universe.

Haskell actually models the real universe better than any other languages - in the real world, we have the concept of now - some state of the current universe until an event elapses, when we have a new now, and we have a concept of the past, but in fact, this past does not exist anywhere - it was transient - we can't go back and modify this old universe to cause a change in the future, unless we introduce theories of parallel universes. the only thing that ever exists is the now, as you might learn from a Buddhist.

A Haskell function which does IO is just an event which causes a change from an old now in the universe to a current now, and the old one, the past, no longer exists.

Re: “Mostly functional” programming does not work

#55

Post by [deleted] »

electronvolt wrote: post #18
btmorex wrote: post #5

To play devil's advocate for a minute: Nearly all useful, reusable software today is written in a mostly or entirely imperative language. This is despite the fact that functional programming has been around for at least 20-30 years. So, my basic question is, if functional programming is so much better, why isn't more software written in a functional language? Or put another way, why are there so many blog posts promo…

Functional programming has been around since the late 50s/early 60s, depending on what you count as the start of LISP as a programming language. In some ways the reason it isn't used a lot is for historic reasons as much as anything else. Functional programming, for a long time, was seen (often rightly so) as more computationally expensive than the same imperative code for most tasks. For a long time, that meant that…

[deleted]

Re: “Mostly functional” programming does not work

#56

Post by mbenjaminsmith »

I think the real failure of FP has been demonstrating its advantages in practical terms. While deferring impurity is admittedly interesting (if you care about the theoretical underpinnings of programming at all) what do I gain as a programmer?

I'll try to illustrate my point:

In programming we often have to do something more than once. In terms of mental complexity, I'd rank our options like so, from easy to hard:

Loop -> Recursion -> Fixed Point Iteration

We can do the same thing with all of them. Recursion in some cases can lead to a stack overflow and any fixed point iteration has the disadvantage of, well, being f-ing hard to understand.

A beginner can get a `while` or a `for` loop in seconds. They're very, very intuitive. Once you figure out solving problems in software often requires doing things repeatedly, loops open up a lot of power.

Recursion is more difficult once you throw in conditionals and return values. They're harder to reason about. Loops are simple. So why bother with recursion? I learned recursion because it exists and I love learning. Could I have written just as much software without it? Yes. Would it have been just as functionally correct, maintainable, easy to read? Yes.

I know very little about fixed point iteration. Why? Well, because I have loops and if I'm feeling jaunty, recursion.

Having said that, I recently came across this article about the Y combinator:

http://matt.might.net/articles/implementation-of-recursive-f...

I recommend that article for everyone. But the most important part is the section "Exploiting the Y combinator".

> This formulation still has exponential complexity, but we can change it to linear time just by changing the fixed-point combinator. The memoizing Y combinator, Ymem, keeps a cache of computed results, and returns the pre-computed result if available:

The author is talking about his algorithm for calculating Fibonacci numbers. While the naive recursive approach is limited due to its computation complexity, by caching intermediate results we can short-circuit the calculations made.

> The end result is that the 100th Fibonacci number is computed instantly, whereas the naive version (or the version using the ordinary Y combinator) would take well beyond the estimated lifetime of the universe.

I don't know enough about what's being done here to say that this optimization couldn't have been made with a loop (I believe Turing equivalence proves that it could have been) but at least I get to see some of the magic that fixed point iteration gives us.

Haskell, as a functional language, offers a lot (purity! type safety!) but the community hasn't really shown how these things are valuable. Type safety is great, but is Haskell materially better than Objective-C (my primary language) in that regard? Pure functions are trivial to test, but in a language with a reasonable amount of type safety, how many individual functions are getting tested anyway? Of course I can write pure functions in an imperative language and often do. And I can do so without painfully abstract concepts like the dreaded monad if I want to do something as pedestrian as generate a random number.

The reality is writing software for most people is about the platform they're targeting, available libraries, ease of use and techniques for dealing with long-term complexity. I have yet to find a reason to use Haskell even though I would love to -- more accurately, I have yet to find a situation where I could justify using Haskell.

Re: “Mostly functional” programming does not work

#57

Post by louthy »

"Computation is not just about functions, if computation was just about functions then quicksort and bubblesort would be the same because they're computing the same function. A computing device is something that goes through a sequence of states. What an assignment statement is doing is it is telling you "here is a new state". Functions alone don't solve the problems of programming because programs (on the whole) are non-deterministic; on the other hand, imperative programs are using assignment statements to compute functions, and that's silly."

That exact phrase was said to Erik Meijer by Leslie Lamport when Erik interviewed Leslie. [1]

It seems clear (if you take Leslie's word as gospel) that there is room for 'Mostly Functional'. That is, accept that your program goes through a series of states, but use pure functions to calculate those states.

However, as an imperative programmer who's found Haskell over the past few years (thanks, in a large part to Erik Meijer), I happen to think that Haskell has it just about right.

[1] http://channel9.msdn.com/Shows/Going+Deep/E2E-Erik-Meijer-an...

Re: “Mostly functional” programming does not work

#58

Post by mamcx »

btmorex wrote: post #5

To play devil's advocate for a minute: Nearly all useful, reusable software today is written in a mostly or entirely imperative language. This is despite the fact that functional programming has been around for at least 20-30 years. So, my basic question is, if functional programming is so much better, why isn't more software written in a functional language? Or put another way, why are there so many blog posts promo…

I get aware about functional language years after I learn to program. I think I lot of devs I know barely know it (in fact, because I'm dreaming in build a language, I get more info about).

Probably swift will be a significant cause of exposure for it.

However, I don't think a total functional language is the best, but a mix (like swift, julia).

Post reply on HN