4 ms·

One of the challenges I’ve found with OOP is that’s really easy (encouraged!) to use a lot of “anti-functional” patterns. A functional style is not the only wa

One of the challenges I’ve found with OOP is that’s really easy (encouraged!) to use a lot of “anti-functional” patterns. A functional style is not the only way to write programs, but it’s often much easier to reason about behavior when you’re not chasing side effects. And OO implementations often have a LOT of side effects.

krapp 8y ago
>And OO implementations often have a LOT of side effects. If you're worried about side effects and want pure functional programming... Arc is not the language for you.
- dan-robertson 8y ago
  I think pure functional programming is often worse than a looser style which one often wants. This is sometimes described as functional core, imperative shell. The idea is to try to keep state in values (rather than global variables) and to update those values in a functional,typically immutable, maybe a sort of careful mutable way. Then on the outside there is some global state of things that are treated in an imperative way, eg setting up loggin, or a global variable for “the state of the world”, or reading user inputs, processing, and outputting. IO is something that Haskell has to make a big deal about because it is lazy and “pure.” One can think of it a bit like async in JavaScript: (most) IO things are async and so an async function is one that does IO, just like any function returning IO a in Haskell. I think in most programs structured with a functional core, having IO in the core will typically mean having logging or debug printing which I think is not really bad and not worthy of eg polluting type signatures everywhere. Most meaningful IO should go in the outside, topmost bits of the program because that’s where it belongs (rather than because your language makes it so painful that you don’t want it any other way). I suppose my point is that I don’t think “pure functional programming” is something one should want throughout a language.
  - pdimitar 8y ago
    > I suppose my point is that I don’t think “pure functional programming” is something one should want throughout a language. Yeah, same here. Haskell struck me as too strict and clunky to get basic stuff done. Its focus doesn't seem to be productivity. Hence I gravitated towards Elixir (and lately trying Clojure). It allows me to get stuff done in a small number of lines, is amazingly well documented and has powerful primitives. The pursuit of academic purity quickly turned me off of several languages, Haskell included.

krapp 8y ago

>And OO implementations often have a LOT of side effects. If you're worried about side effects and want pure functional programming... Arc is not the language for you.

dan-robertson 8y ago
I think pure functional programming is often worse than a looser style which one often wants. This is sometimes described as functional core, imperative shell. The idea is to try to keep state in values (rather than global variables) and to update those values in a functional,typically immutable, maybe a sort of careful mutable way. Then on the outside there is some global state of things that are treated in an imperative way, eg setting up loggin, or a global variable for “the state of the world”, or reading user inputs, processing, and outputting. IO is something that Haskell has to make a big deal about because it is lazy and “pure.” One can think of it a bit like async in JavaScript: (most) IO things are async and so an async function is one that does IO, just like any function returning IO a in Haskell. I think in most programs structured with a functional core, having IO in the core will typically mean having logging or debug printing which I think is not really bad and not worthy of eg polluting type signatures everywhere. Most meaningful IO should go in the outside, topmost bits of the program because that’s where it belongs (rather than because your language makes it so painful that you don’t want it any other way). I suppose my point is that I don’t think “pure functional programming” is something one should want throughout a language.
- pdimitar 8y ago
  > I suppose my point is that I don’t think “pure functional programming” is something one should want throughout a language. Yeah, same here. Haskell struck me as too strict and clunky to get basic stuff done. Its focus doesn't seem to be productivity. Hence I gravitated towards Elixir (and lately trying Clojure). It allows me to get stuff done in a small number of lines, is amazingly well documented and has powerful primitives. The pursuit of academic purity quickly turned me off of several languages, Haskell included.