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

161–170 of 205 posts

Re: “Mostly functional” programming does not work

#161

Post by doxydexydroxide »

lomnakkus wrote: post #6
seanmcdirmid wrote: post #3

Debugging a functional program is so difficult (data flow debuggers don't really exist) that equational reasoning is necessary because you want be able to fix your code otherwise. But really, mixing list comprehensions with effects is really a bad idea, and we C# programmers have no trouble avoiding it. There are ways to tame side effects without going monads, which don't really fix the complexity problem anyways (it…

Are there any practical systems that are usable today that implement "managed time"? (I haven't read the paper yet(!), but I just thought I'd ask to shorten the turnaround time.) Btw, are you familiar with David Barbour's Reactive Demand Programming and if so, what are your thoughts on it?

Yes there are.

Glitch is an approximation to Backus's "Applicative State Transition Systems". see:Backus:"Can programming be liberated from the von Neumann style?" www.thocp.net/biographies/papers/backus_turingaward_lecture.pdf

Since 1980, I have applied ASTS in the development of Hard Real Time Avionics Systems Software for Military & Commercial Aircraft and Spacecraft.

I have licensed this code exclusively to Aerospace companies over the years.

It has proven its value in the development of verifiable software.

For reasons that Backus states, the approach is not easy to comprehend nor apply, and requires very specialized tools (data flow debugger & proof system).

The tool is known as "Synthesis" in the Aerospace Industry.

Re: “Mostly functional” programming does not work

#162

Post by nextos »

MrBuddyCasino wrote: post #154
nextos wrote: post #27

Earlier quoted context omitted.

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.

Just have a look at the comments about the CTM book in c2, and the links to LtU:

http://c2.com/cgi/wiki?ConceptsTechniquesAndModelsOfComputer...

Re: “Mostly functional” programming does not work

#163

Post by muhuk »

tethis wrote: post #50
Kutta wrote: post #35

I disagree with some of the sentiment expressed in the article; mostly functional programming works much better than profoundly non-functional code, and more functional programming usually delivers marginal benefits. The fact that effects can be used to simulate other effects does not imply that programmers would typically try doing that. In fact, programming style is more often shaped by trivial inconveniences (ofte…

And it's important to note with Scala, a big part of its complexity comes from the practical philosophy of its creators: purity is sacrificed in order to actually make it work on the JVM the way we want it to . I used to work with Java on the server-side, but I'm programming almost entirely in Scala now (I'm at a small shop where I was lucky enough to convince the boss to let me give it a go on a project last year) a…

How do you manage nesting from callbacks and matches and such? Inlining short functions like _ + _ is fine, but how do you organize more advanced operations?

(I'm just constantly looking for ways to make my scala code more accessible.)

Re: “Mostly functional” programming does not work

#164

Post by the_af »

spullara wrote: post #131

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

Erik addresses this in the article. What he calls "mostly functional" isn't FP with some carefully used escape mechanism, but imperative languages adding FP features here and there. He argues that the benefits of true FP get negated in hybrid languages.

Re: “Mostly functional” programming does not work

#165

Post by the_af »

ruricolist wrote: post #125

Is this a satire? I mean this seems like a satire of the fact that the unfortunate framing of functional programming in terms of "purity" and "impurity" clouds a very abstract question with the intense instinctive reactions we have to questions of personal hygiene. Notwithstanding the fact that a programming language is "impure", you cannot catch anything from it. It cannot defile, pollute, or contaminate you. Nor is…

"Impure" doesn't have negative connotations in this context, and in fact "pure" and "impure" are common informal terms when discussing languages with or without control of side-effects.

Re: “Mostly functional” programming does not work

#166

Post by the_af »

maxiepoo wrote: post #135

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

Indeed, in last year's Reactive Programming course from Coursera, Erik's position was that one shouldn't be too fundamentalist about programming languages, and instead pick whatever works from each language.

He seems to be having a bit of fun with us all. That said, I respect a people that can change their minds.

Re: “Mostly functional” programming does not work

#167

Post by coolsunglasses »

bobfunk wrote: post #134
coolsunglasses wrote: post #105

Earlier quoted context omitted.

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

You could even load it up in a REPL and generate the JSON to see what stuff looks like.

Re: “Mostly functional” programming does not work

#168

Post by coolsunglasses »

cynicalkane wrote: post #116
coolsunglasses wrote: post #19

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…

I find your rant slightly insulting, off-topic, and lacks substantial information. "Learn Haskell because I say so." Why? No. But let me do something you didn't do, which is to actually explain my position. Hybrid languages afford a flexibility and power not available to language puritans. It's very nice to have things first-class DSLs that don't rely on slow monad stacks, heterogeneous lists that don't rely on exist…

A Clojure and Erlang user I got started learning recently was able to get to Applicatives in a single afternoon.

You can easily, easily spend more time debating it - learning nothing - than you would just checking it out for yourself.

If you were banging your head against the wall, you were suffering from bad pedagogy, not a bad language.

I went through the same experience! I know exactly what you're talking about, but you don't know what you're missing!

So lets stop debating and instead focus on fixing the pedagogy. You won't regret it.

Try this course: http://www.seas.upenn.edu/~cis194/lectures.html

Ping me via my email if you need help.

Re: “Mostly functional” programming does not work

#169

Post by coolsunglasses »

caughtexception wrote: post #119
cynicalkane wrote: post #116

Earlier quoted context omitted.

I find your rant slightly insulting, off-topic, and lacks substantial information. "Learn Haskell because I say so." Why? No. But let me do something you didn't do, which is to actually explain my position. Hybrid languages afford a flexibility and power not available to language puritans. It's very nice to have things first-class DSLs that don't rely on slow monad stacks, heterogeneous lists that don't rely on exist…

I am fed up with these "pure" people. They have hijacked every sane discussion about programming into a condescending -- "Do you have monads and typeclasses ?". It's absolutely unhealthy. State is not Evil. Languages like clojure, scheme take imperative features and give it more beautiful abstractions. In what profession, do you find people complaining about the very foundations and thinking it's cool ? It's like Mus…

>State is not Evil.

I agree!

You're mistaken if you think Haskell users don't take advantage of state or side effects. They do, you just don't understand the difference.

Try this course:

http://www.seas.upenn.edu/~cis194/lectures.html

Then see LYAH's section on the State monad:

http://learnyouahaskell.com/for-a-few-monads-more

Then reflect on ST:

http://www.haskell.org/haskellwiki/Monad/ST

Then this example using mutable variables and closures:

http://bitemyapp.com/posts/2014-03-25-when-nested-io-actions...

Side-effecting closures mutating variables!

It's not "no state or side effects".

It's about making state and side effects typed and explicit so they can be properly composed and manipulated.

Re: “Mostly functional” programming does not work

#170

Post by cynicalkane »

coolsunglasses wrote: post #168
cynicalkane wrote: post #116

Earlier quoted context omitted.

I find your rant slightly insulting, off-topic, and lacks substantial information. "Learn Haskell because I say so." Why? No. But let me do something you didn't do, which is to actually explain my position. Hybrid languages afford a flexibility and power not available to language puritans. It's very nice to have things first-class DSLs that don't rely on slow monad stacks, heterogeneous lists that don't rely on exist…

A Clojure and Erlang user I got started learning recently was able to get to Applicatives in a single afternoon. You can easily, easily spend more time debating it - learning nothing - than you would just checking it out for yourself. If you were banging your head against the wall, you were suffering from bad pedagogy, not a bad language. I went through the same experience! I know exactly what you're talking about, b…

Ah, the Haskell assumption that people who dislike Haskell's way of doing things just don't get it.

Why are you talking to me about Applicatives? Applicatives are easy. I'm not complaining about what the type system can do. I'm complaining about what it can't do. And it can't do a lot. For instance, it can't "safely" twiddle a bit in a vector without resorting to a compiler trick involving uninstantiable existentially typed monads. It can't produce DSLs that live outside the type straitjacket, so you get really complicated stuff, like the kudzu-like system of the Lens library, full of existential types and higher-rank types and restrictions, that still is not actually typesafe. And so on. I'm repeating myself already.

Monads and weird compiler extensions are not the same as a language that respects the programmer who wants to do something unusual. This is what I'm saying. Don't tell me about applicatives as a response. It's not a response, and it's insulting.

Post reply on HN