For anyone else unfortunate enough to try using Commons Daemon - looks like prunsrv only recognises static methods, even though the Daemon interface methods aren't static. Ended up defining the interface myself with (:gen-class (:methods ...)); the documentation also gives the wrong arities for all functions, so this has just been a whole mess of trial and error.

the profiler operates on java code with a jvm agent

are you asking for profiling clojure apps or any kind of app?

specifically clojure apps. I am trying to figure out what would be the most convenient way to use it as profiling instrumentation tool in production. I guess that the intent was to sue it as a project dependency so it can run a small http server interface that can start/stop profiling and later serve the svg files for the flame graph. what do you think?

You mean 'server sent events'?

this feature https://caniuse.com/#feat=eventsource ?

Yep. Basically it's just a long-lived HTTP request where you consume the body line for line

I don’t think this is you thinking in OOP. When I interact with external services, I often put them behind a protocol, both to isolate the calls, and to allow me to stub or mock them out during testing.

However, be careful about overengineering. One of the benefits of protocols is that you can replace functions with protocol methods without changing any of the calling code. So you can always replace a set of functions with a protocol later.

Clojure embraces abstractions and polymorphism. OOP has it's own mechanisms to provide those, and that's these concrete mechanism that are often criticized, and not the concepts

If you are in a scenario where you have two+ of something that can be abstracted cleanly behind a Protocol, go for it.

That said, do you expect that you will actually actively use two+ of those things in practice?

Cause if not, just write your functions and keep refactoring them as you try out new DBs until you find the one you like.

The danger of an abstraction is that it comes with a higher burden. You need to find an abstraction that fits all DBs equally well. And that can be hard. For one DB, you might realize that they just don't fit the abstraction as well as you thought, or they support things that would require a different interface and means of interaction, which your Protocol might not be able to mold itself too.

Thx for tips and comments. What about state? Shove it inside a namespace atom then write public functions that derefs it is the general idea? Or is there any other recommendations for encapsulation?

There's many different strategies for handling state. But generally encapsulation of data isn't encouraged.

In general you want state to be immutable. So don't use an atom. Your namespace just shouldn't hold any state at all

Every single function simply takes as input whatever it needs, and returns as output the result

Yep, I’m pretty sure Clojure explicitly rejects encapsulation in the official rationale.

Let the user of your namespaces choose how to manage state if there are any

What sort of application are you making, @UFHB0T69M? If you have a database and a text editor, it sounds like it might be a webapp?

An example would be. If you would have had a class with fields x, y, z. And your methods would use those fields. Well now just add to each method an argument for x, y and z and the user of the class should simply provide these and make sure to carry them along from one call to the next. In this case the class being a namespace, but devoid of state.

In doing so, state will be pushed to the top layer. And the top layer can choose how to manage it. That could be done by putting it all in a map inside an atom. Or it could be done by capturing it inside closures. Or by carrying it through passes of a recursion. Or putting it inside agents, or refs, etc.

If you have things that are more like entities. Those can be modeled as a map or record. So your functions instead of taking an x, y, z, could take a map of x, y, z, and return that.

@U0BKWMG5B yeah its actully a web-extension note taking app. Requires interop with npm pkgs etc. But I dont want to be specific, used just for example. @didibus thx for the explanation, so if you were to write some funcs that, say requires a connection or any stateful thing, your all func would take that as param thus state management pushed to upper level?

The exception to this rule are constants. Those can be in your namespace if you want as top level defs, as long as they are read only. Though sometimes it's nice to take those in as well, so in tests and all you can override them easily.

Ya, pretty much.

There’s a common pattern where the application’s state is stored in a single atom, and functions are written that take in a state and an event, and return a new state.

(f state event) -> state'

This can then be applied to an atom with (swap! state-atom f event)

Yep I am familiar with that kind of architecture by elm reframe redux etc..

Just didnt see much that kind of things on the "backend"

Ya, that's one good and proven pattern. Just be sure when people say you pass state, they mean the immutable structure inside the atom, and not the atom itself

On the backend, ask yourself if you can't just be stateless instead

Your state being managed by your DB

Just what I was about to say 🙂. The only state I ever tend to keep are caches, and even then that’s rare.

You can even start by just creating a new connection to the DB on every request.

And deal with improving the performance of that once you get to that being an issue

Thats the one thing that concerns me about all this, yeah early optimization is blabla right but making it second class like this, might isnt it hard to untangle when it accumalates. Idk if all these passing, recreating(new structs share common parts tho) can be optmized away via JIT

Which like @U0BKWMG5B said, it just really all amounts to caching.

Well, if you did it right, everything that would need to be cached will live at the top most layer.

So its trivial to refactor that part to have some caching in place.

Performance in FP is often a caching issue. Imperative languages tend to complect this - you modify in place, or you hang onto data instead of recalculating it. But essentially they’re all different mechanisms for caching results, just somewhat obscured.

I wouldn't say to start without caching anything at all from the start if you weren't learning Clojure. Eventually, you discover your preferred mean for organizing components at the top layer. Some people use a component framework like Component, integrant, mount, etc. Some people just use defs. Others might use delays and atoms. Some might use closures, higher-order-functions, memoization, etc.

But without knowing these, you'll be confused and distracted. I mean, my opinion off course.

You might find caching your connections for example is an okay thing and gives you a bit more performance. But maybe putting a shared proxy cache instead is even better for performance!

I think I’d go straight for a connection pool like HikariCP rather than trying to cache connections bespoke. Just to nitpick 🙂

I'd love to read you guys articles about design comparasion of a generic programmer and a clojure programmer (said clj since not all func. langs have the same tools) on an real_world_tm app parts.

It depends. If everytime your app does a read or write it is a whole new query. Then a connection cache aka a pool might be better. But if your app is read heavy and most reads tend to be duplicate requests, then a request cache could be better. Etc.

thx again

Caches are hard though. That's why I recommend not starting with them. Get a grasp on everything else first. What's the famous quote? The hardest thing in computer science are caches and names?

In OOP, every object is a cache 😝 no wonder it's so darn hard

That’s an interesting way of thinking about it. I’ll have to remember that one.

The “every object is a cache” I mean.

😏thx

And it gets even more complicated fast. People start having object caches as well. And suddenly many things are sharing mutable objects with one another believing that they have a new fresh copy, when they don't. Those bugs have always been some of the hardest to debug

> What's the famous quote? The hardest thing in computer science are caches and names? n OOP, every object is a cache 😝 no wonder it's so darn hard Smooth.