7 ms·

Happy user of typescript here. imo, pure FP is just like pure OO: it's just not very good. Why constraint ourselves? The world is not pure, our programs don't b

Happy user of typescript here. imo, pure FP is just like pure OO: it's just not very good. Why constraint ourselves? The world is not pure, our programs don't become ANY better because of the IO monad (Task in Elm); Let's stop wankering or at least, just do it for the math and the research value but let's not kid ourselves it's very useful.

daxfohl 10y ago
Yeah, being a math person I jumped on the pure FP bandwagon full time for four years. But my experience has been that in anything but pet projects, it gets to the point of replacing impurity with incompatible layers of abstractions to create the illusion of some minimal level of allowed impurity and awkward buggy glue code in hopes to hold everything together. Working with an illusion of impurity on top of purity isn't any better than working with impurity directly. Or in Greenspun's Tenth Rule Of Programming terms: Any sufficiently complicated Haskell/PureScript program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a Python VM trying to share state with an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a JS VM trying to communicate with an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a .Net VM. Anyway I like typescript now too.
- bfung 10y ago
  "...in Greenspun's Tenth Rule Of Programming terms...slow implementation of half of a .Net VM"... ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.[1] So we're back to FP... =P 1. https://en.wikipedia.org/wiki/Greenspun's_tenth_rule https://en.wikipedia.org/wiki/Greenspun's_tenth_rule
rubber_duck 10y ago
Agree somewhat - I like the balance something like clojure and F# strike, immutability and high level abstractions by default but interoperability with OO and imperative code as needed - if they fit your problem domain they can be a huge productivity boost - typescript still has that C#/Java style verbosity when doing data manipulation and all the pitfalls of shared mutable state + all the pitfalls of insane JS semantics.
- boubiyeah 10y ago
  I do not have a single 'this' pointer in my programs. Not a single class/prototype. Imo, that leaves: Bad/no pattern matching support, many operators create statements and not expressions (e.g if/else) but they can be extracted to functions. Also, relative path imports. This is nuts. But you can use root imports with webpack+TS and the problem is solved. mutable objects/arrays is annoying. But we have the convention of never doing it, and it's been working for a long time. (https://github.com/AlexGalays/immupdate https://github.com/AlexGalays/immupdate) Granted, I would prefer immutable by default for sure. Do you have other insane JS semantics in mind? And yeah, F# looks brillant. Just wished it was not a .NET thing. Fable could interest me but it's just like bucklescript/reasonml: there is no momentum, no community, no libs. It would be a big leap of faith to heavily invest in it as an individual. I generally like the FP approach with imperative escape hatches. Need more performance? Some code is actually more elegant in imperative form? Go for it. F# can do it, scala can do it too (unfortunately with some crappy java compatibility concerns to deal with)
  - mamcx 10y ago
    > Just wished it was not a .NET thing Then what? OCalm is the other possibility, but the appeal of a larger ecosystem and easier mobile target by xamarin is what put me into F#.
  - allover 10y ago
    I actually think momentum behind Reason/Bucklescript is going to start building, possibly spurred on by React people. Saw this tweet recently [1] re: React bindings to Reason at Facebook. (Neat demo and interesting replies to the tweet). >> Early preview of @reasonml bindings to ReactJS. Compiles to regular JS so interop/debugging is easy. Haven't been this excited since React! [1] https://twitter.com/jordwalke/status/814091172540858368 https://twitter.com/jordwalke/status/814091172540858368
deleted 10y ago
[deleted]
runT1ME 10y ago
pure FP is just like pure OO As someone who did OO for ten years and is doing FP full time, this statement is absurd. Why constraint ourselves? You are not constrained in any way by FP, you just have to make everything explicit so programs are easier to read and reason about. There's nothing I can't do in a pure FP language. The world is not pure, The world is not a touring machine either, does this argument have more substance or is it just an offhanded comment...? our programs don't become ANY better because of the IO monad Do you actually have any experience with functional programming? Non rhetorical...it's such an odd thing to say. Programs absolutely become better when you encapsulate IO in a monadic context. The entire point is to demarcate what functions interact with the world and which don't. This makes testing easier, reading code easier, composition easier. What functional language do you have experience with that would lead you to these bizzare conclusions? :)
- allover 10y ago
  > The entire point is to demarcate what functions interact with the world and which don't. This makes testing easier, reading code easier, composition easier. This is 1. a tradeoff , 2. subjective. Words like 'bizarre' aren't really necessary, and come off as feigned surprise (passive aggressive). You think a function being easier to test (without reaching for extra tools like mocking libraries, presumably), justifies needing to write and understand 'monads' in order to interact with the real world. Another programmer finds myObject.doExplicitThingToWorld() far more expressive and easy to understand and is very familiar with the mocking tools/practices they need to test that. As for composition ... well composhmishion. It's so rare you can actually compose your business logic/app-code (beyond the original use-case you wrote the thing for, which you might well have chosen to write in a 'compositional' way). It's neat for frameworks and libraries to create composable stuff but it just doesn't come up as often as we'd all like to hope in our day-to-day code in my experience. And if you really want to compose something OO absolutely has ways to do it. (So composition is not the big win over OO some FP fans make it out to be IMO).
  - boubiyeah 10y ago
    Agreed. I've used many nice libs using various monads, applicative builders, functors, yada yada under the hood; It can make the libs more pleasant to use for an end user for sure. But telling people that you should write EVERYTHING using this style because it's "objectively" superior strikes me as being almost religious. Surely, you don't need IO monads to write, say, an API server.
purescript 10y ago
You don't need to constrain yourself. AltJS allows users to mix and match different languages for different problems. Use a pure functional language where it makes sense for you, and don't where it doesn't.
- boubiyeah 10y ago
  In theory yes. In practice, just one ecosystem can be a big investment. Knowledge sharing, build tooling, libraries, be it third-party or yours. At least that's my experience building a lot of single page apps. That could be seen as a weakness of SPAs. With fully separated pages, it's easier to mix technologies.
retrogradeorbit 10y ago
> The world is not pure TL;DR: The 'impurity' of the world is an illusion created by our brains. I have a physics degree and I completely disagree. The world IS pure. Think of it like this: Time is the successive application of a pure function that takes the old universe as an argument and returns the new universe. All science models the real world like this. This is the foundation of mathematics. Nowhere in physics or maths do we mutate anything. Even quantum applies this perspective. This is what leads to the many worlds interpretation of quantum. What's actually going on is your brain is such a powerful illusion machine that it has convinced 'you' that the world is composed of 'objects' that 'change'. This is entirely inside your brain. It is a side effect of the perception process inside your brain. It does not mean the real world is actually composed of 'objects' that 'change'. This illusion is so strong that we then go on to model the real world inside computers with 'objects' that 'change'. This is a mistake that leads to no end of problems. Once you realise the world is immutable, and that the process of time is a function, and that what we see as time is actually a succession of immutable 'universe-values', you then start modelling your problems like this. And then you realise what a better fit FP is for modelling the real world. And then you realise why science models the world using mathematics... that is functions and values... which are immutable. When I argue this with OO developers I ask them "Is the real world mutable, or immutable?" When they answer mutable, I then ask them to go back to last Tuesday and change their lotto numbers. They can't. It's almost as if the past.... is immutable! And the present becomes the past the very moment it comes into being. And the future is unknown. The present also cant be changed. We can affect the future by using our muscles to apply 'forces' to the 'universe-value' thereby changing the way the time-function of the universe returns the new-universe value (the future), but we cannot reach in and alter any of these immutable values directly, not the past, the present, or the future.
- cousin_it 10y ago
  The world might be pure behind the scenes, but it stubbornly presents an imperative interface, and refuses to present a pure one where old values would stay accessible forever. That has major implications for computing.
- deleted 10y ago
  [deleted]

daxfohl 10y ago

Yeah, being a math person I jumped on the pure FP bandwagon full time for four years. But my experience has been that in anything but pet projects, it gets to the point of replacing impurity with incompatible layers of abstractions to create the illusion of some minimal level of allowed impurity and awkward buggy glue code in hopes to hold everything together. Working with an illusion of impurity on top of purity isn't any better than working with impurity directly. Or in Greenspun's Tenth Rule Of Programming terms: Any sufficiently complicated Haskell/PureScript program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a Python VM trying to share state with an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a JS VM trying to communicate with an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a .Net VM. Anyway I like typescript now too.

bfung 10y ago
"...in Greenspun's Tenth Rule Of Programming terms...slow implementation of half of a .Net VM"... ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.[1] So we're back to FP... =P 1. https://en.wikipedia.org/wiki/Greenspun's_tenth_rule https://en.wikipedia.org/wiki/Greenspun's_tenth_rule

rubber_duck 10y ago

Agree somewhat - I like the balance something like clojure and F# strike, immutability and high level abstractions by default but interoperability with OO and imperative code as needed - if they fit your problem domain they can be a huge productivity boost - typescript still has that C#/Java style verbosity when doing data manipulation and all the pitfalls of shared mutable state + all the pitfalls of insane JS semantics.

boubiyeah 10y ago
I do not have a single 'this' pointer in my programs. Not a single class/prototype. Imo, that leaves: Bad/no pattern matching support, many operators create statements and not expressions (e.g if/else) but they can be extracted to functions. Also, relative path imports. This is nuts. But you can use root imports with webpack+TS and the problem is solved. mutable objects/arrays is annoying. But we have the convention of never doing it, and it's been working for a long time. (https://github.com/AlexGalays/immupdate https://github.com/AlexGalays/immupdate) Granted, I would prefer immutable by default for sure. Do you have other insane JS semantics in mind? And yeah, F# looks brillant. Just wished it was not a .NET thing. Fable could interest me but it's just like bucklescript/reasonml: there is no momentum, no community, no libs. It would be a big leap of faith to heavily invest in it as an individual. I generally like the FP approach with imperative escape hatches. Need more performance? Some code is actually more elegant in imperative form? Go for it. F# can do it, scala can do it too (unfortunately with some crappy java compatibility concerns to deal with)
- mamcx 10y ago
  > Just wished it was not a .NET thing Then what? OCalm is the other possibility, but the appeal of a larger ecosystem and easier mobile target by xamarin is what put me into F#.
- allover 10y ago
  I actually think momentum behind Reason/Bucklescript is going to start building, possibly spurred on by React people. Saw this tweet recently [1] re: React bindings to Reason at Facebook. (Neat demo and interesting replies to the tweet). >> Early preview of @reasonml bindings to ReactJS. Compiles to regular JS so interop/debugging is easy. Haven't been this excited since React! [1] https://twitter.com/jordwalke/status/814091172540858368 https://twitter.com/jordwalke/status/814091172540858368

deleted 10y ago

[deleted]

runT1ME 10y ago

pure FP is just like pure OO As someone who did OO for ten years and is doing FP full time, this statement is absurd. Why constraint ourselves? You are not constrained in any way by FP, you just have to make everything explicit so programs are easier to read and reason about. There's nothing I can't do in a pure FP language. The world is not pure, The world is not a touring machine either, does this argument have more substance or is it just an offhanded comment...? our programs don't become ANY better because of the IO monad Do you actually have any experience with functional programming? Non rhetorical...it's such an odd thing to say. Programs absolutely become better when you encapsulate IO in a monadic context. The entire point is to demarcate what functions interact with the world and which don't. This makes testing easier, reading code easier, composition easier. What functional language do you have experience with that would lead you to these bizzare conclusions? :)

allover 10y ago
> The entire point is to demarcate what functions interact with the world and which don't. This makes testing easier, reading code easier, composition easier. This is 1. a tradeoff , 2. subjective. Words like 'bizarre' aren't really necessary, and come off as feigned surprise (passive aggressive). You think a function being easier to test (without reaching for extra tools like mocking libraries, presumably), justifies needing to write and understand 'monads' in order to interact with the real world. Another programmer finds myObject.doExplicitThingToWorld() far more expressive and easy to understand and is very familiar with the mocking tools/practices they need to test that. As for composition ... well composhmishion. It's so rare you can actually compose your business logic/app-code (beyond the original use-case you wrote the thing for, which you might well have chosen to write in a 'compositional' way). It's neat for frameworks and libraries to create composable stuff but it just doesn't come up as often as we'd all like to hope in our day-to-day code in my experience. And if you really want to compose something OO absolutely has ways to do it. (So composition is not the big win over OO some FP fans make it out to be IMO).
- boubiyeah 10y ago
  Agreed. I've used many nice libs using various monads, applicative builders, functors, yada yada under the hood; It can make the libs more pleasant to use for an end user for sure. But telling people that you should write EVERYTHING using this style because it's "objectively" superior strikes me as being almost religious. Surely, you don't need IO monads to write, say, an API server.

purescript 10y ago

You don't need to constrain yourself. AltJS allows users to mix and match different languages for different problems. Use a pure functional language where it makes sense for you, and don't where it doesn't.

boubiyeah 10y ago
In theory yes. In practice, just one ecosystem can be a big investment. Knowledge sharing, build tooling, libraries, be it third-party or yours. At least that's my experience building a lot of single page apps. That could be seen as a weakness of SPAs. With fully separated pages, it's easier to mix technologies.

retrogradeorbit 10y ago

> The world is not pure TL;DR: The 'impurity' of the world is an illusion created by our brains. I have a physics degree and I completely disagree. The world IS pure. Think of it like this: Time is the successive application of a pure function that takes the old universe as an argument and returns the new universe. All science models the real world like this. This is the foundation of mathematics. Nowhere in physics or maths do we mutate anything. Even quantum applies this perspective. This is what leads to the many worlds interpretation of quantum. What's actually going on is your brain is such a powerful illusion machine that it has convinced 'you' that the world is composed of 'objects' that 'change'. This is entirely inside your brain. It is a side effect of the perception process inside your brain. It does not mean the real world is actually composed of 'objects' that 'change'. This illusion is so strong that we then go on to model the real world inside computers with 'objects' that 'change'. This is a mistake that leads to no end of problems. Once you realise the world is immutable, and that the process of time is a function, and that what we see as time is actually a succession of immutable 'universe-values', you then start modelling your problems like this. And then you realise what a better fit FP is for modelling the real world. And then you realise why science models the world using mathematics... that is functions and values... which are immutable. When I argue this with OO developers I ask them "Is the real world mutable, or immutable?" When they answer mutable, I then ask them to go back to last Tuesday and change their lotto numbers. They can't. It's almost as if the past.... is immutable! And the present becomes the past the very moment it comes into being. And the future is unknown. The present also cant be changed. We can affect the future by using our muscles to apply 'forces' to the 'universe-value' thereby changing the way the time-function of the universe returns the new-universe value (the future), but we cannot reach in and alter any of these immutable values directly, not the past, the present, or the future.

cousin_it 10y ago
The world might be pure behind the scenes, but it stubbornly presents an imperative interface, and refuses to present a pure one where old values would stay accessible forever. That has major implications for computing.
deleted 10y ago
[deleted]