Live data from Hacker News

“Mostly functional” programming does not work

queue.acm.org

151–160 of 205 posts

Re: “Mostly functional” programming does not work

#151
post #149

Earlier quoted context omitted.

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

Right, it's "exactly the same thing" under the hood. It's different in the roles it serves. Your elaboration is appreciated!

Re: “Mostly functional” programming does not work

#152
post #127
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…

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 believe Haskell has deeper industry adoption than Clojure does right now. You just don't see it a lot because haskell people aren't as focused on evangelism.

Re: “Mostly functional” programming does not work

#153

Earlier quoted context omitted.

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…

Haskell's community is a bit more thoughtful and less prone to self-promotion. That combined with the fact that you're not a Haskeller, you're not familiar with what they've built. Another issue is that Haskell is somewhat weighted towards finance and they're a bunch that tends to be somewhat proprietary about their IP. Some exceptions (Ermine) exist. Some notable projects that come to mind include git-annex and Pars…

[deleted]

Re: “Mostly functional” programming does not work

#154
post #27

Earlier quoted context omitted.

I'm an experienced Clojure user with work done on the job and in open source. If you're a Clojure user, it's very likely you've used a library I've worked on or made. Don't bother. Go straight to Haskell and just Haskell. No excuses, no compromises, no mental backflips to justify not learning something new. Learn Haskell properly and then see for yourself why "hybrids" are a waste of time. Hybridized approaches are l…

While I agree hybrids are in general a bad idea, some good hybrids exist. But they are extremely hard to get right. For example, Oz/Mozart: http://www.sm.luth.se/csee/courses/timber/reading/VanRoy.pdf http://www.epsa.org/forms/uploadFiles/3B6300000000.filename....

I would be much more inclined to read those papers if you gave a short reason as to why you think it got some things right, where others have failed.

Re: “Mostly functional” programming does not work

#155

Earlier quoted context omitted.

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

There is an element of truth to this. It is also how we get things like Heartbleed.

So, library code and critical infrastructure would fall outside of the "vast majority of cases". :)

And again, the question there is "Did Heartbleed keep people from getting value out of OpenSSL?". The answer is no, even if the value provided wasn't as advertised. It was more useful to have something--anything!--than nothing.

Re: “Mostly functional” programming does not work

#156

Earlier quoted context omitted.

"That combined with the fact that you're not a Haskeller, you're not familiar with what they've built." On the other hand, I don't have to be a php'r to know facebook was built in that language or a C++ programmer to know what google has done with it. The negative-nancy is Timothy Baldridge, an employee of Rich Hickey's company Cognitect. By personally attacking a critic of your claims, you're only making your case w…

> personally attacking Personal attack? What personal attack? Are you reading the same comment I am? He identified someone. If identification amounts to a personal attack, then that would seem to indicate severe problems with the image of the person being identified!

"The negative-nancy is Timothy Baldridge, an employee of Rich Hickey's company Cognitect. Cognitect is "the" Clojure company and represents the inner-clique."

Apart from the juvenile "negative-nancy", there's also the clear implication of ascribing untoward motives based on the person's identity.

Re: “Mostly functional” programming does not work

#157

Earlier quoted context omitted.

I'm an experienced Clojure user with work done on the job and in open source. If you're a Clojure user, it's very likely you've used a library I've worked on or made. Don't bother. Go straight to Haskell and just Haskell. No excuses, no compromises, no mental backflips to justify not learning something new. Learn Haskell properly and then see for yourself why "hybrids" are a waste of time. Hybridized approaches are l…

> Learn Haskell properly and then see for yourself why "hybrids" are a waste of time. /rant Getting tired of puritans. You people are selling functional programming on the basis of "ideology", not merits. Can the following be done in Haskell ? * A Real Operating System. * GPU programming. * Embedded programming. * If you can do all the above, can you replace Verilog ? * Financial Programming. Ocaml is one of the "hyb…

For GPU programming - Haskell is a quite good option for running [parts of] your heavy computations on the GPU instead of the CPU, and the language features directly help with that.

And Verilog is quite well entrenched, but if/when it's going to be replaced by something else, currently it seems that it will most likely be a Haskell derivative, something similar to Bluespec perhaps.

But can you clarify your point ? The cause of the rant seems to be for the "hybrids are a waste of time" line, however, most of the examples you provide are things that are currently done by, say, C/C++ but not by the hybrid languages.

Are you claiming that the hybrid languages are (or will be) much more widely used for developing 'A Real Operating System', embedded programming or mass-market games?

Re: “Mostly functional” programming does not work

#158
post #153

Earlier quoted context omitted.

Haskell's community is a bit more thoughtful and less prone to self-promotion. That combined with the fact that you're not a Haskeller, you're not familiar with what they've built. Another issue is that Haskell is somewhat weighted towards finance and they're a bunch that tends to be somewhat proprietary about their IP. Some exceptions (Ermine) exist. Some notable projects that come to mind include git-annex and Pars…

[deleted]

Please stop this—all of you.

Programming language flamewar is off-topic and inappropriate for HN. The personal attacks are beyond the pale.

Re: “Mostly functional” programming does not work

#159

Earlier quoted context omitted.

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.

Actually, the really nice thing is that the live editor is easy to build on top of the programming model! Once the pieces work a bit better, I'll try to put this on codeplex (though WPF/windows only...).

Re: “Mostly functional” programming does not work

#160
post #143

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.

Probably you mean the 'safe' package.
Post reply on HN