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.
“Mostly functional” programming does not work
171–180 of 205 posts
Re: “Mostly functional” programming does not work
#172Earlier 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…
Re: “Mostly functional” programming does not work
#173Earlier 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.)
Re: “Mostly functional” programming does not work
#174Earlier 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…
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
#175I 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.)
Re: “Mostly functional” programming does not work
#176Earlier 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.
Re: “Mostly functional” programming does not work
#177Earlier 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…
Re: “Mostly functional” programming does not work
#178I 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.)
Re: “Mostly functional” programming does not work
#179Re: “Mostly functional” programming does not work
#180Earlier 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.