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

101–110 of 205 posts

Re: “Mostly functional” programming does not work

#101

Post by dllthomas »

TheCoelacanth wrote: post #98
PaulAJ wrote: post #77

Earlier quoted context omitted.

For instance, in Haskell a value is a value. If I have a value of type Integer then it definitely exists; if I want to say that it might not exist then I use the type "Maybe Integer", which expresses that idea precisely. Same goes for a value of type Employee; if I might or might not have an Employee (for instance, if the lookup function doesn't find someone with that employee number) then I have to use Maybe Employe…

> in Haskell a value is a value The same is true of C++. Values and references in C++ can't be null. Pointers can be null, but that's a lower-level feature that doesn't have an equivalent in idiomatic Haskell.

"Ptr a" is an equivalent, in many senses. It's quite true that use is far less in idiomatic Haskell, especially as you're restricted to IO when operating on them.

Re: “Mostly functional” programming does not work

#102

Post by ky3 »

brudgers wrote: post #31
ky3 wrote: post #20

Earlier quoted context omitted.

> Scheme is not a pure functional language I think OP wittily conflates 2 senses of pure. Scheme is purely functional in the sense that it's _only_ functional, as opposed to a hybrid like Scala, as OP points out. But it's not purely functional in the sense of Haskell, that famous flagship of effect-less programming. Here 'pure' is contrasted against _effectful_ functions.

In Scheme, everything is an expression and because of macros and mutability not all expressions are functions in any sense beyond that by which we commonly use 'function' as a synonym for 'programming procedure'. What Scheme doesn't have is a symantics that distinguishes between statements and expressions.

Good point about the macros and mutability.

There's FP vs imperative and then there's FP vs OOP. Scala is the FP-OOP hybrid and Scheme is the FP-imperative hybrid.

These are vast simplifications but useful to start a conversation with. Thanks!

Re: “Mostly functional” programming does not work

#103

Post by dllthomas »

GregBuchholz wrote: post #91
PaulAJ wrote: post #77

Earlier quoted context omitted.

For instance, in Haskell a value is a value. If I have a value of type Integer then it definitely exists; if I want to say that it might not exist then I use the type "Maybe Integer", which expresses that idea precisely. Same goes for a value of type Employee; if I might or might not have an Employee (for instance, if the lookup function doesn't find someone with that employee number) then I have to use Maybe Employe…

>For instance, in Haskell a value is a value. If I have a value of type Integer then it definitely exists; x,y::Integer x = x + 1 y = undefined

That's an important point, but since you can't test for undefined-ness it's not quite the same thing as carrying around something that's actually a Maybe Int but just hopes you'll check before implicitly using fromJust everywhere.

Re: “Mostly functional” programming does not work

#104

Post by gnuvince »

GregBuchholz wrote: post #91
PaulAJ wrote: post #77

Earlier quoted context omitted.

For instance, in Haskell a value is a value. If I have a value of type Integer then it definitely exists; if I want to say that it might not exist then I use the type "Maybe Integer", which expresses that idea precisely. Same goes for a value of type Employee; if I might or might not have an Employee (for instance, if the lookup function doesn't find someone with that employee number) then I have to use Maybe Employe…

>For instance, in Haskell a value is a value. If I have a value of type Integer then it definitely exists; x,y::Integer x = x + 1 y = undefined

`undefined` is used as a placeholder for yet to be written code; since you cannot do anything meaningful with it, it is never used in practice.

Re: “Mostly functional” programming does not work

#105

Post by coolsunglasses »

dorfsmay wrote: post #95
coolsunglasses wrote: post #72

Earlier quoted context omitted.

I've written an Elasticsearch client in Haskell just so I can port a project from Clojure. I'm moving everything over that I can. Some legacy Clojure at work I'll have to leave alone for now, but going forward it's Haskell wherever I can.

Have you found any drawback so far? What is your take on the "you have to write clever, complicated code to make haskell work" (1). I've read that a lot of the code use for the language shootout is far from idiomatic haskell, but just plain clever, in order to get decent performance... (1): http://jxyzabc.blogspot.ca/2009/03/haskell-vs-ocaml-or-ravin...

>"you have to write clever, complicated code to make haskell work"

Haha, no. I write pretty dumb Haskell myself. The author might've tripped into a library beyond their faculties. Also possible, they might've tried to make something "practical" before they really knew what they were doing. I made this mistake in the past myself.

The library I've been working on makes my boring Haskell obvious: https://github.com/bitemyapp/bloodhound/

I even tweeted a sample of my code making fun of how "stupid-simple" my Haskell is :)

I might refine the code later, but for now I'd rather KISS until I'm prepared to firm up the design.

You can get down a rabbit-hole with Haskell if you want, but the same is equally true of Clojure/Scala/C++/Ruby/Python/Perl.

Even then, the rabbit-hole at least has typed hand-rails.

Negatives?

Uhhh, missing libraries (which I am working to help remedy)

You develop a "nose" for libraries for which you aren't the audience. It's not a big or unavoidable negative, but there are definitely libraries on Hackage made to prove a point rather than for use in production. These libraries are easy to identify. Some of them are prefixed acme-*

The primary negative that matters is simply that Haskell is deeply unfamiliar to most working programmers, so while it's 100% worth it, the road to Haskell isn't as well-trodden or smooth as it would be going between Python Ruby.

I'm working to remedy this as well. I've been teaching Haskell for the last ~6 months.

Re: “Mostly functional” programming does not work

#106

Post by saryant »

eranation wrote: post #89

Just an observation, Erik was one of the lecturers in the coursera course "Introduction to reactive programming" co taught by Martin Odersky, creator of Scala. Erik was teaching reactive extensions to Scala (a port based of his work at Microsoft). Course is highly recommended by the way.

He's also a keynote speaker at this year's Scala Days conference.

Re: “Mostly functional” programming does not work

#107

Post by [deleted] »

coldtea wrote: post #73
PaulAJ wrote: post #45

Earlier quoted context omitted.

Yes, that is what I meant. Thanks for the clarification, although I think the term "beauty contest" trivialises the issue. Its not about beauty, its about buggy software.

Well, most of the software I depend upon everyday, and is almost rock-solid is written in C++. So not sure where you are getting at.

[deleted]

Re: “Mostly functional” programming does not work

#108

Post by [deleted] »

jerf wrote: post #97

I am going to take the apparently unique position here (after 90 comments) that Erik is correct, at least about pure functional programming (the more modern sense of "functional" rather than the older one that is "merely" about first-class function objects). The value of pure functional programming comes from creating programs out of very mathematically-small pieces... a function of Int -> Int can only do so many thi…

[deleted]

Re: “Mostly functional” programming does not work

#109

Post by nightski »

dorfsmay wrote: post #95
coolsunglasses wrote: post #72

Earlier quoted context omitted.

I've written an Elasticsearch client in Haskell just so I can port a project from Clojure. I'm moving everything over that I can. Some legacy Clojure at work I'll have to leave alone for now, but going forward it's Haskell wherever I can.

Have you found any drawback so far? What is your take on the "you have to write clever, complicated code to make haskell work" (1). I've read that a lot of the code use for the language shootout is far from idiomatic haskell, but just plain clever, in order to get decent performance... (1): http://jxyzabc.blogspot.ca/2009/03/haskell-vs-ocaml-or-ravin...

The general approach for functional programming is to make some thing right (provably correct), and then transform it into something performant. There are books (pearls of functional programming) that elaborate on this technique. The thing is, the series of transformations retains the correctness of the original implementation.

In reality this isn't necessary very often. It is important to understand persistent data structures, how they differ from imperative ones, and which to use in different situations. However with a good understanding of the fundamentals (just as in imperative code) you'll be writing idiomatic performant functional code fairly easily.

Re: “Mostly functional” programming does not work

#110

Post by shasta »

yason wrote: post #54

I think that "Mostly functional" is actually the sweet spot. Going to any extreme makes some things horribly difficult and going to another does the same for other things. So, optimally, multiple paradigms coexist in the single codebase, applied where they're most useful. Functional programming with as many immutable bits as possible is definitely a good start. I generally do that for whatever problem I'm solving: I…

> So, optimally, multiple paradigms coexist in the single codebase, applied where they're most useful.

If you count a pure (e.g. monadic) encoding of another paradigm in this, then you're not disagreeing with Erik. If you don't, then I think you're wrong about where the sweet spot is.

Post reply on HN