"Completely functional" obviously doesn't work as there would be no side effects aside from your computer getting warm. Every functional language has escape mechanisms that allow you to see what the program is doing. "Mostly functional" is as close as you can get to functional.
“Mostly functional” programming does not work
131–140 of 205 posts
Re: “Mostly functional” programming does not work
#132I would just like to point out that the author seems to be confusing Pure-Functional-Lazy with just Functional. I absolutely agree that if you buy into Lazy programming, you have to buy into entirely Pure Functional as well. However, many languages and frameworks have demonstrated a high degree of success mixing in functional paradigms (mostly centered around collections) I would like to refer people to the concept o…
He isn't confusing the terms, he's just using the correct one. Functional programming is about programming with functions - "Purely functional" is redundant. It should be obvious that Functional means functions, and "function" has fairly precise meaning which predates computation, and certainly didn't include anything about side-effects. Languages which don't use functions are not functional - they would be best desc…
> Functional programming is about programming with functions
Actually I think the etymology of "functional programming" comes for programming with functions as first-class objects. So a "functional programming language" is one that supports higher-order functions.
> It should be obvious that Functional means functions, and "function" has fairly precise meaning which predates computation, and certainly didn't include anything about side-effects.
It also doesn't say anything about non-termination. If you want to program with mathematical functions I suggest you use something other than Haskell (e.g. Coq, Agda).
Re: “Mostly functional” programming does not work
#133I would just like to point out that the author seems to be confusing Pure-Functional-Lazy with just Functional. I absolutely agree that if you buy into Lazy programming, you have to buy into entirely Pure Functional as well. However, many languages and frameworks have demonstrated a high degree of success mixing in functional paradigms (mostly centered around collections) I would like to refer people to the concept o…
He isn't confusing the terms, he's just using the correct one. Functional programming is about programming with functions - "Purely functional" is redundant. It should be obvious that Functional means functions, and "function" has fairly precise meaning which predates computation, and certainly didn't include anything about side-effects. Languages which don't use functions are not functional - they would be best desc…
I disagree that '"Purely functional" is redundant'. You can have a functional language that still uses mutable state. Lisps are a good example. Pure functional implies no mutable state. Pure functional is the only way to safely achieve laziness. Which seems to be the author's thesis.
Re: “Mostly functional” programming does not work
#134Earlier quoted context omitted.
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/bite…
The source for Bloodhound really is clean and simple. I might actually just use the Types.hs file as a my goto reference for the ElasticSearch query format next time I need to write some of those!
Re: “Mostly functional” programming does not work
#135I just don't get Erik Meijer, though I think he's quite entertaining. He seems to enjoy taking the other side wherever he is.
Here's a talk I was at a couple years ago where he makes fun of the ideas he's presenting in this article: http://www.youtube.com/watch?v=a-RAltgH8tw . Key quote: "obsession with monads is a medical condition".
Re: “Mostly functional” programming does not work
#136Earlier 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.
There is an element of truth to this. It is also how we get things like Heartbleed.
Re: “Mostly functional” programming does not work
#137Earlier 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…
"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!
Re: “Mostly functional” programming does not work
#138I 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 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 outside of HN threads.
Re: “Mostly functional” programming does not work
#139Earlier 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…
There are a number of toy operating systems written in Haskell. There are not very many "real operating systems" being written in any language, because it is a tremendous undertaking for uncertain value in a space that already has significant players with platform-effect lock in. I don't see why building a "real OS" in Haskell would be much harder than building a "real OS" in other languages, though.
I don't know anything about the state of GPU programming in Haskell, so I'm not going to speak to that.
Regarding embedded, GHC can target some quasi-embedded platforms these days, but it's also possible to write embedded programs in (pardon the overloading) an embedded DSL that can compile to C. Check out the Atom library.
I've heard about some people doing hardware synthesis involving (again) embedded DSLs in Haskell - I don't really know the state of it, but IIRC Conal Elliot gave a talk on some related stuff at one of the Bay Area Haskell meetups.
Jane Street is doing a lot of O'Caml stuff, and that's awesome, but there's definitely a lot of Haskell in finance these days as well (I've seen several job postings, and heard some chatter generally). I don't know which is better represented, or how it compares to other stuff - most big finance places don't talk about what they're doing inside.
Oh, and Haskellers actually type "Arrow" when they're working with a particular generalization of functions. When they're actually working with functions, they type ->.
Re: “Mostly functional” programming does not work
#140Earlier 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..]
Certainly the case.