Tell me you've never picked up a piece of clojure code and gone, WTF does this do? What are these global channels for? Why is the whole application constantly updating a top level full-application-state atom? Why are we blocking indefinitely with some magical invisible state hidden in a closure as we iterate over a collection of objects to process?
If you have a beautiful clojure code base, it's fantastic...
But, ideally, you just learn to . . . not do that
How do you fix a bad code base when the functions aren't pure (global injections, global channels), or are 'pure' only in the sense the input is the entire application state, including non-pure objects like a database handle? Or your functions are non-deterministic due to some kind producer/consumer race condition?
I get it; don't do that.
...but what do you do when it's too late, and someone has already made those bad decisions?
Where are the debugging tools to help you figure out what's going on, and the refactoring tools to help isolate code units and replace them?
I mean, sure, you could argue that's an issue in any language, but all I can say is that I've used a lot of other languages, and the only other similar experience I've had was working with perl.
> What are these global channels for? Why is the whole application constantly updating a top level full-application-state atom? Why are we blocking indefinitely with some magical invisible state hidden in a closure as we iterate over a collection of objects to process?
I think something that would help the Clojure community improve, especially with regard to introducing Clojure to a team is to ask why this kind of thing doesn't happen in Python.
I know Python doesn't come with atoms, but you could certainly stick the whole application state in a global variable. You wouldn't though if you're a working programmer with a modicum of experience on your first Python project. Do people just see some new idioms and forget everything they already knew about programming?
Python does have closures, and you certainly could write one that blocks due to some hidden state or does something stupid involving multithreading. This isn't seen as a problem with the language though; it's seen as a sign that the person who did it might need to work more closely with someone more experienced or that the team needs better code reviews.
I suppose. When you update and depend on a global atom your functions aren't pure, at all, in any sense.
Why are you even using FP at that point?
Global application state should be represented in a single root storage; the application data store (ie. database), and the interactions with it should be controlled and sanitised.
If you have a thousand little places across your code base updating and reading from the database, that's horrible code too, in java or in clojure...
Modern UI frameworks are carefully controlled access and update to the display state for a UI; they happen in a controlled and orderly manner specifically to prevent the chaos you get otherwise; if not, you're doing it wrong.
(notice, you don't just reach out and update atoms directly by hand; there's nothing wrong with having a global application state; that's a good thing, but directly interacting with it is not)
You were closer to it the first time: it's usually a mistake to stick your whole application state in something resembling a god object. The client-side of a single-page application might be an exception under some circumstances when the language provides sane tools for dealing with it.
Tell me you've never picked up a piece of clojure code and gone, WTF does this do? What are these global channels for? Why is the whole application constantly updating a top level full-application-state atom? Why are we blocking indefinitely with some magical invisible state hidden in a closure as we iterate over a collection of objects to process?
If you have a beautiful clojure code base, it's fantastic...
How do you fix a bad code base when the functions aren't pure (global injections, global channels), or are 'pure' only in the sense the input is the entire application state, including non-pure objects like a database handle? Or your functions are non-deterministic due to some kind producer/consumer race condition?I get it; don't do that.
...but what do you do when it's too late, and someone has already made those bad decisions?
Where are the debugging tools to help you figure out what's going on, and the refactoring tools to help isolate code units and replace them?
I mean, sure, you could argue that's an issue in any language, but all I can say is that I've used a lot of other languages, and the only other similar experience I've had was working with perl.