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

141–150 of 205 posts

Re: “Mostly functional” programming does not work

#141

Post by abecedarius »

PaulAJ wrote: post #56
Amadiro wrote: post #18

Earlier quoted context omitted.

And just what makes you think making a purely functional language 'lambdacious' will not a few years later result in a book 'Industrial strength lambdacious'? You're falling for the trap of thinking that pursuing a theoretically pure discipline will result in a language with less flaws; in reality, even theoretically pure concepts have issues and can be superior and inferior to other theoretical concepts/constructs […

Quote: "You call 'Aversion to Extremes' a cognitive bias [... but] the more extreme a language pursues a theoretical concepts, the less used it typically ends up being in practice." Yes, people use languages with solid theoretical foundations less because they perceive them to be extreme. That was my point. Quote: "I can't imagine [... any measure that] makes these 'purity-oriented' languages appear to "work better i…

Erlang is an uncompromisingly pure implementation of the actor model

It's not. To pick just the first issue I remember, PIDs are forgeable. (I spent a day once trying to survey what you'd have to do to capability-tame Erlang, and it looked like a lot of work. The Erlang developers did not wear a hair-shirt.)

Re: “Mostly functional” programming does not work

#142

Post by copergi »

_halgari wrote: post #83
coolsunglasses wrote: post #71

Earlier quoted context omitted.

I've used a lot of languages, including Clojure and Scala. I'm saying any time spent learning Clojure when Haskell exists is a waste of time and a half-step. Everybody who hasn't should be learning Haskell, regardless of background. Teaching somebody Haskell is faster than explaining why the 1,001 dumb things mainstream languages do are dumb. I don't want to waste my time explaining why null values are dropdead stupi…

I find it funny to hear such grandiose claims about a language that can has yet to create a major killer project. That's why I can never bring myself to write Haskell. Show me the Storm, OTP, Datomic, Netflix, Whatsapp, etc. written in Haskell and perhaps I'll have a reason to change my mind. But until then all I see is C#, Scala, Erlang and Clojure shipping awesome products and the Haskell guys sitting in the corner…

You are making your bias WAY too obvious by including a bunch of niche software with tiny to nonexistent userbases as "major killer project"s just because they happen to be written in clojure. Why is one of the official clojure guys so interested in spreading FUD about haskell anyways? Haskell people have largely positive things to say about clojure. Shouldn't you be more focused on spreading FUD about scala?

Re: “Mostly functional” programming does not work

#143

Post by Dewie »

GregBuchholz wrote: post #123
dllthomas wrote: post #103

Earlier quoted context omitted.

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.

We just don't want to forget that exceptions and termination are effects, and that Haskell isn't perfectly pure... a,b::Integer a = div 1 0 b = sum [1..]

If you want to avoid partial functions, I guess you would use Safe Haskell.

Re: “Mostly functional” programming does not work

#144

Post by dllthomas »

Dewie wrote: post #143
GregBuchholz wrote: post #123

Earlier quoted context omitted.

We just don't want to forget that exceptions and termination are effects, and that Haskell isn't perfectly pure... a,b::Integer a = div 1 0 b = sum [1..]

If you want to avoid partial functions, I guess you would use Safe Haskell.

AFAIK, Safe Haskell doesn't do that. Am I missing something?

Re: “Mostly functional” programming does not work

#145

Post by paulajohnson »

angersock wrote: post #118
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.

"Its not about beauty, its about buggy software." In the vast majority of cases, it's about delivering customer value --whether through good, buggy, or nonexistent software. A buggy language used to make buggy software beats a perfect solution every time if it gets you paid. EDIT: Downvote all you'd like; in the vast majority of cases the pain point of a customer getting solved is what matters, not how we solve it.

I can have it done next week if it doesn't have to work.

And of course this is a false dichotomy anyway.

Re: “Mostly functional” programming does not work

#146

Post by mike_hearn »

seanmcdirmid wrote: post #15
skrebbel wrote: post #13

Earlier quoted context omitted.

Woah, want! Glitch looks really cool. How real is it? Are there plans to make it real? Everybody, really, if you have time and would like a look into the future, read chapter 2 of the paper seanmcdirmid posted (and co-wrote).

I want to make it real; I'm working on some interesting ways of improving performance right now. It is kind of a climb though, I have no idea when/if this would ever reach production, but it's almost a brand new world if we can make this work.

Do you have any plans to release the code you have so far? Seems it'd be a fairly big effort to catch up with where you got to so far, especially the live editor.

Re: “Mostly functional” programming does not work

#147

Post by adrianm »

_delirium wrote: post #138
_pmf_ wrote: post #127

Earlier quoted context omitted.

I agree. Part of the reason Clojure sees production use and Haskell does not leave its academic closet very often is that the former makes interaction with the non-functional parts of a system painless.

I don't regularly use either one, but I was under the impression that the situation is rather the reverse: Clojure is quite popular among hobbyists but doesn't get a lot of serious industry usage (perhaps excepting some stuff in the web space, which I don't really follow), while Haskell has a bunch of industry users. I see ads for Haskell jobs pretty often, anyway, while I'm not sure I've ever seen a Clojure job ad o…

My experience has been in the reverse, which just goes to show you how bad anecdotal evidence is at proving any point. Without any hard data, it's impossible to say for certain. All I know is that there is definitely enough demand for Clojure work that I didn't have to search for any leads when I left my last job; I already had four promising prospects to choose from that either emailed me directly or messaged me on Linkedin within the previous month.

Re: “Mostly functional” programming does not work

#148

Post by [deleted] »

angersock wrote: post #118
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.

"Its not about beauty, its about buggy software." In the vast majority of cases, it's about delivering customer value --whether through good, buggy, or nonexistent software. A buggy language used to make buggy software beats a perfect solution every time if it gets you paid. EDIT: Downvote all you'd like; in the vast majority of cases the pain point of a customer getting solved is what matters, not how we solve it.

[deleted]

Re: “Mostly functional” programming does not work

#149

Post by swift »

dllthomas wrote: post #101
TheCoelacanth wrote: post #98

Earlier quoted context omitted.

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

Ptr is exactly the same thing as a C pointer. Critically, if you have a Ptr to some value, that Ptr could become invalid if the value gets moved by the garbage collector, just like a C pointer would. That's why you'd never use Ptr except in FFI code, to access memory that isn't managed by Haskell's GC. (If you need to pass a pointer to a Haskell value to code written in another language, you'd use a StablePtr, which pins the value in the Haskell heap.)

In idiomatic Haskell, if you need something like a pointer you have several choices. If you're writing parallel code your best bet is STM. If you're writing code in IO, you can use an IORef. If you don't want that restriction, you can use an STRef.

(I'm aware that you probably know all this, but other people reading the thread might not.)

Re: “Mostly functional” programming does not work

#150

Post by marcosdumay »

carlsborg wrote: post #129
marcosdumay wrote: post #115

Earlier quoted context omitted.

Just to cite a few quick examples. If you have a mutable object anywhere in your codebase, the compiler can not reuse calculated values, ignore unneeded code, or map a set of independent output sequences[1] at your source code into highly interleaved single threaded asynchronous output, like Haskell's green threads do. [1] I'm yet to see an imperative language (and "mostly functional" is imperative) that has the conc…

Thats interesting. I wonder if anyone has done a performance study to measure and compare the speed up offered by the functional approach for some standard workload.

Well, it's hard to define "some standard workload", and obviously you can always write something in C that performs at least as well as any program in Haskell. What's important is comparing how hard it's to write and maintain both programs.
Post reply on HN