undefined | Better HN

0 pointsmpweiher11y ago0 comments

Hmm...didn't realize this was (or could be) a serious question.

Anything with state comes to mind. The text field I am typing this into, for example. I type on my keyboard and the state of the text field changes, and after I hit "reply", the state of the page changes with a comment appended. Before/after.

Yes, you can implement this by creating a completely new page containing the concatenation of the old page with the comment, but externally (when you visit the URL), the state of that page has changed. So if you choose to implement the problem in a functional style, you have to bridge that gap somehow between that style and the problem at hand.

Any sort of document processing done on computers in Word, Excel (regarding the document itself, not the one way dataflow constraint program inside), OpenOffice, PowerPoint, Pages, Keynote, Quark XPress, InDesign, Photoshop, Illustrator etc. People use these programs to change the state of documents. That is the purpose of these programs.

Anything that interacts with the world, for example the user interface.

Or Wikipedia. Pages change, sometimes because there is new information, sometimes because something in the world has changed. Or most any other web site.

Really, the world (a) has (a lot of) state and (b) that state is changing incessantly. It is not (a) stateless or (b) immutable.

But don't take it from me: "In the end, any program must manipulate state. If it doesn't, there is no point in running it. You hit go and the box gets hotter" - Simon Peyton-Jones. https://www.youtube.com/watch?v=iSmkqocn0oQ&t=3m20s

0 comments

tome11y ago

Thank you for the food for thought.

nbevans11y ago

It's pretty rubbish food he just gave you there. This is why F# has the mutable keyword. If you are so desperate to use it, that is. Most good programmers try to avoid it.

It's funny that this guy claims fitting the problem to suit FP is a bad thing. But fitting the problem to suit OOP is seemingly a good thing. There is no difference really. All problems have to be made to fit your tooling and practices in same way. The difference is how much squashing is required and the two or three second decision it takes to select the right tool. Only performance optimisations really warrant falling back to mutation of state, other than IO of course. The default should always be immutable. Don't let some brain dead OOP-only troll deter you from seeing the light.

He is speaking is riddles, like pseudo academics love to. Seriously, he is suggesting you can't have an editable text box on a GUI, written in a language like Scala, F# or OCaml? What a moron. (This link will prove particularly embarrassing to a certain person here: http://www.scala-lang.org/api/2.10.2/index.html#scala.swing....) He is arguing an argument that doesn't even exist here, but one that only exists in his own head.

Pure FP, much like pure OOP, is utter shit and painful. The sweet spot is reached by mixing the two and using a multi-paradigm language, ala F#, Scala, OCaml, etc.

j / k navigate · click thread line to collapse