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…
“Mostly functional” programming does not work
151–160 of 205 posts
Re: “Mostly functional” programming does not work
#152I 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.
Re: “Mostly functional” programming does not work
#153Earlier 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…
Re: “Mostly functional” programming does not work
#154Earlier 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....
Re: “Mostly functional” programming does not work
#155Earlier 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.
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
#156Earlier 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!
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
#157Earlier 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…
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
#158Earlier 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]
Programming language flamewar is off-topic and inappropriate for HN. The personal attacks are beyond the pale.
Re: “Mostly functional” programming does not work
#159Earlier 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.
Re: “Mostly functional” programming does not work
#160Earlier 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.