Trucchi: Also some stuff in JS makes it tough to avoid

Khalil: Dekok: my use case is a GUI widget. It can be driven by React at a higher level, but the widget itself is mutable. Because it’s GUI.

Trucchi: Without crazy verbosity and too much copying

Cully: Trucchi: yeah, but there’s always mutation in every computer program at some level. the point of avoiding mutability is to fence it off so your program doesn’t deal with it

Slightam: Trucchi: IO itself can’t be immutable, yeah. The only thing you can do is write a description of how IO should be performed and feed it to an interpreter. Kmett’s machines do this, and they’re awesome.

Klepfer: Like, you can even write your own debugger in user land

Rohrscheib: Dekok: with GUI it’s preferable not to have to rebuild my DOM, browser, computer, office, house, city, country, continent, planet, solar system, galaxy, universe, dimension, glarba***e, and so on, when I want to change something.

Sowders: I have 2 files. 1 defines var a = 1; the other file uses it. but it gets ‘a not defined’ error. but only when run from a different server. what is going on there?

Hofheimer: Profsimm: that’s a very weak argument.

Rolson: I might be missing nuances, but that’s always how i ***umed haskell’s IO worked

Trucchi: Who is this Kmett and will they let me borrow one of their machines?

Scelba: Dekok: what’s the stronger counterargument

Trucchi: That’s. pretty much what react is there to abstract away for you though

Traxson: You define a system that describes how IO is handled and hand if off to something that actually runs ‘main’

Henneberry: Profsimm: you haven’t stated your problem, so it’s not possible to suggest any approach that is contextually valid. The only thing I can suggest is “this is a good idea in general, but it might not be the best thing for you,” which in this case is “try to keep things declarative and pure where possible”

Wylam: Ah Dekok little OT on the argument but I found this message really interesting https://www.reddit.com/r/Clojure/comments/3h4qdk/what_are_clojurians_critiques_of_haskell/cu4qfw4

Trucks: J201: yes that’s how it works. It preserves the semantics of Haskell, but also it makes no sense, because in the world of Haskell you wouldn’t build something that does nothing and then p*** it to something that gives you nothing back.

Jeffress: J201: as good a description as any

Brancanto: J201: in short it’s a hack, but some people can stay on their high horse due to it.

Cohagan: It reminded my a blog post of Harper on this topic

Sabot: Hannibal_Smith: yeah, that’s also the case for Purr. And Purr is an untyped language.

Forbush: Though currently the Task module exposes the equivalent of “unsafePerformIO”, which is not ideal

Cornick: Dekok: a panel, no, I’ll make it simpler. A button. In a browser. In the DOM. You create it, then it fires events when it’s clicked, you can read/set its label, make it disabled, enabled and so on

Perciballi: Dekok: is the use case more clear now

Grignon: Profsimm: that’s still not a problem. If it were, my suggestion would still be relevant.

Trucchi: Ultimately, the dom IS IO, and yes, it’s mutated. The idea is to abstract away the interface so it can be manipulated by simpler, purer methods

Trucchi: Which means nothing in one function will get changed out from under it by another function with a side effect

Trucchi: At least, you can minimize that

Kirkpatric: Dekok: you’re not offering a solution, you’re just saying “that’s still not a problem”. What am I to do with your answer?

Gorneault: J201: it used to work exactly like that. New implementations are kiiiiiiinda different. You can reason about it like that, and it’ll be mostly correct, but the way it works under the hood is not like that anymore, because it needs to be fastaaaa

Nuccitelli: Dekok: I’m asking what’s 2+2 you say “it’s not math”

Jeffress: Profsimm: explain the actual problem instead of an obscure simplification of it