clojure-europe 2022-10-27

There’s an issue that I see once in a while while programming. Some file or some thing is generated, and you have the final result. Great! But now you want to remove or change the generation, and you didn’t own it to begin with. And the final result does not tell you where it came from. With that little nugget of information, you’d be able to start pulling the thread to changing the implementation, but without it, you don’t know where the thread is. I think the first time I was annoyed by something like this was in env vars for my terminal, which can come from a bunch of different places. Another is files for some terminal programs that I wanted to remove, where doing so manually was impossible, since I had no overview of the related folders and files scattered on my file system. Can anyone relate?

Dimitar Uzunov09:10:19

I can. ENV variables are global state, they have their uses but they are often abused IMHO. It started with Heroku using them a lot and then the 12 factor methodology endorsing them. I think their use should restricted to things like bootstrapping a configuration process but not actually storing much configuration

Dimitar Uzunov09:10:07

I’ve had this experience with this library: https://www.npmjs.com/package/rc#standards Check out how many ways a configuration can be discovered and loaded; it is very important that a team chooses a clear convention and sticks to it strictly, if possible

reefersleep11:10:18

Interesting library! Yeah, I agree.

reefersleep11:10:32

I’ve come to long for obvious, easily discoverable code more and more as I’ve grown more experienced as a Clojure programmer 😄

slipset12:10:08

I’ve been pondering this in terms of source code as well. If we take the Java example:

List l = new ArrayList()

This is considered Best Practice(TM) since you’re now programming against the interface and not the implementation, and you’re free to swap out implementation with some other list implementation. All good. Problem we’re seeing is akin to

Ifoo foo = new SomeFooImpl()

where both IFoo and SomeFooImpl are types owned by the app your’re building. Somewhere down the code you’ll see:

foo.bar()

And it’s hard to know which implementation of bar you’re actually talking about. Likewise, if you’re in SomeFooImpl and you want to know where it’s implementation of bar is used, it’s also hard. So in this case, we’ve started being very explicit and programming against the implementation rather than the interface like:

SomeFooImpl foo = SomeFooImpl()

Whenever we’re not in need of the polymorphism that going through an interface/protocol provides.

slipset12:10:54

You could argue that this also goes against loose coupling, but while loose coupling is great when you want to evolve software, it’s really sucky when you want to figure out how/why software works

reefersleep08:10:32

Seems reasonable to choose a specific implementation from the get-go. I You can always change your mind and make it general later, I guess 🙂

reefersleep08:10:12

Yeah, all “looseness” makes for more difficult reading.

reefersleep09:10:11

I experience it once in a while in my Clojure work project as well. I love generating stuff from data, but sometimes it becomes unclear where the data resides, and even where the generation resides.

reefersleep09:10:24

I’ve been thinking that maybe, for some use cases, it’d be nice to include for example a little “generation report” in a comment block in a generated file, if at all possible. For easier future discovery.

lemontea14:10:53

some tools have adopted and implemented that already, if my memory’s correct

reefersleep14:10:19

I’d love to see an example, if you ever come across it again 🙂

lemontea14:10:17

sadly, I OOM’ed (hence the backlog)

lemontea14:10:42

my computer’s also constantly OOM >_<

lemontea14:10:11

(I do rmb that it’s just a simple “This is a generated file. Do not edit as it will be overwritten” comment on top. Maybe some that also add a line indicating which tool generated it + where the responsible source file is located at)

👌 1

reefersleep09:10:09

I tend to do a lot of code archaeology in my day job 🙂

ordnungswidrig13:10:09

> I love generating stuff from data, but sometimes it becomes unclear where the data resides, and even where the generation resides. metdata ftw.

simongray13:10:21

yeah, metadata is where it's at

thomas14:10:51

yeah, but how do we describe the meta data :thinking_face:

Ben Sless14:10:31

replied to a thread:Morning. Tired today as I was up late for the F years webinar yesterday.

F to pay respect?

Adam Helins15:10:37

Good afternoon

🌲 2

2022-10-27

Channels