Live data from Hacker News

“Mostly functional” programming does not work

queue.acm.org

171–180 of 205 posts

Re: “Mostly functional” programming does not work

#171
post #26

Earlier quoted context omitted.

How about Clojure, which is a Lisp-like language with objects? Explicitly, you have protocols and multimethods; implicitly, almost everything under the hood is done with Java interfaces (and you can make new first-class datatypes by implementing the interfaces, though this is mildly discouraged). I cannot recall anyone complaining about the OO clashing with the functional patterns. There's also O'Haskell, and in regu…

and in regular Haskell you can get something like polymorphism (implemented under the hood with actual polymorphism) with forall-qualified datatypes. Huh? Haskell's polymorphism capabilities are more expressive and more expansive than most other languages'. Higher-kinded polymorphism, a mainstay in Haskell, is pretty rare to find almost anywhere else.

I meant dynamic polymorphism, which is different from parametric polymorphism.

Re: “Mostly functional” programming does not work

#172
post #81

Earlier quoted context omitted.

It is possible that Erik has a better (or more cynical) idea of the "average programmer" than you or I might. I'm of the opinion that so long it makes sense and has an elegance to it, then it's fine. If "average" programmers can't handle it, they can use another language or something.

I can't substantiate this, but my sense is that the generation of general-purpose, non-academic programming languages C++ lowered the barrier to writing software in the industrial context (think VB.Net, etc.). This can be seen as a good thing in these business contexts, but for those who are driven to be deeper and more concise in their problem solving, and are interested in solving more challenging problems, are onl…

He no longer works for Microsoft

Re: “Mostly functional” programming does not work

#173
post #163
post #50

Earlier quoted context omitted.

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

He's probably referring to for-comprehensions.

Re: “Mostly functional” programming does not work

#174

Earlier quoted context omitted.

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

You don't appear to be here to share ideas or learn, so lets get concrete rather than posture.

When you say "uninstantiable existentially typed monads" you're showing off your knowledge and being verbose when you actually mean "ST". There's no actual problem here, you're using big words to seem impressive despite the fact that by being obscure you're condescending to them and to me. ST works the way it does so you can't accidentally leak mutable references. There's nothing particularly limiting about it beyond that. ST is like a generic transients that works for any data type instead of the blessed ones.

You don't need to care that ST is existentially typed in order to use it at all. That's like complaining about how difficult it is to weld steel so you live in a mud hut instead. Division of labor applies here because abstractions and types work in Haskell.

There's nothing wrong with twiddling bits in Haskell. I do it all the time. You're complaining that the type system won't let you lie to your users and say a side effect is

    a -> ()
    -- instead of
    a -> IO ()
I happen to think knowing which functions are pure and which are actions is a plus.

"Can't produce DSLs that live outside the type straitjacket" What? You can build a DSL on hash-maps and symbols in Haskell the same as Clojure users do. Haskell users don't do that because it sucks. ADTs and free monads are nicer.

Name-dropping lens as if it's a negative to Haskell is nuts. You're not obligated to use lens if you're still learning Haskell, but finding it difficult to use is a sign you miscalculated your knowledge.

The foundational building block of writing one's first lens is scrubbing out the (fmap . fmap) pattern, which is a use-case even Clojurians can relate to. There's no "there" there to complain about.

Your library 'clearley' would be easier to understand if it had types.

Have you considered a book like Joy of Clojure? http://www.manning.com/fogus2/ I found the first edition of Joy of Clojure improved and clarified my Clojure. Also, back off the defprotocol/defrecord in Clojure until your design is cleaner and more firmed up.

You're not here to be learn or share anything so I'm backing out of the conversation. Provided some clarity on the obtusity before parting.

tl;dr nonsense, intentionally obscure appeals to things that are "too complicated" which are comparable to refusing to drive a car you couldn't build yourself.

You can learn how to build the car later after you understand why it was engineered that way.

Re: “Mostly functional” programming does not work

#175
post #97

I am going to take the apparently unique position here (after 90 comments) that Erik is correct, at least about pure functional programming (the more modern sense of "functional" rather than the older one that is "merely" about first-class function objects). The value of pure functional programming comes from creating programs out of very mathematically-small pieces... a function of Int -> Int can only do so many thi…

Now that I've read your post, I'd say that impurity is much more similar to "goto" than with object orientation. A language with "goto" is not structured. It does not matter how often it's used, or how similar the rest of the language is to a structured one. The same is true for side effects. (Funny thing that the most used language has both.)

Donald Knuth uses GOTO. It is perfectly safe if kept within a function: invoke a function, jump around like crazy inside it, exit to caller with return value. No problem.

Re: “Mostly functional” programming does not work

#176

Earlier quoted context omitted.

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

[deleted]

Re: “Mostly functional” programming does not work

#177

Earlier quoted context omitted.

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

Not really. What Backus is advocating is applicative-style programming (what we know as FP today); what Glitch is advocating is anything but! Some of the code looks similar (indeed, we are inspired by FRP and earlier reactive languages like Esterel), but Glitch keeps everything in the world of explicit control flow rather than bury everything in data flow.

Re: “Mostly functional” programming does not work

#178
post #97

I am going to take the apparently unique position here (after 90 comments) that Erik is correct, at least about pure functional programming (the more modern sense of "functional" rather than the older one that is "merely" about first-class function objects). The value of pure functional programming comes from creating programs out of very mathematically-small pieces... a function of Int -> Int can only do so many thi…

Now that I've read your post, I'd say that impurity is much more similar to "goto" than with object orientation. A language with "goto" is not structured. It does not matter how often it's used, or how similar the rest of the language is to a structured one. The same is true for side effects. (Funny thing that the most used language has both.)

If code is structured or not is not really a property of a language, every function call is effectively a "goto" although with more convenient syntax. If your functions are partitioned in a strange way, you can just as easily produce spaghetti code. Same with nested if statements. You can write well structured code in Fortran 77 for example, even though most standard control structures involve a goto. Absence of a goto statement is neither necessary nor sufficient for enforcing structured code. One real advantage is perhaps that the compiler has more invariants to work with.

Re: “Mostly functional” programming does not work

#179
post #143

Earlier quoted context omitted.

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?

You're probably right. I can't find any mention of enforcing total functions.

Re: “Mostly functional” programming does not work

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

That's a very plausible explanation.
Post reply on HN