Clojurians Log v2

Moaning

Morning!

Morgen!

Morning

Morning

mogge

Morning

I was thinking these days about the gulf that separates beginner programmers, usually being focused to “making things happen” and to, well, more experienced ones that, well, don’t.

"Can I do this?" "Can I do this elegantly?" "Can I do this efficiently?" "Can I not do this?"

I still remember the rush of excitement that Django provided: you could do “full stack” in one go (for me that was a first), and it seems every tech iteration provides the same rush to newcomers.

The code base I’m migrating from seems to have caught the Node and Websockets fever and you can almost feel the excitement of the first devs that managed to go full circle...

The same people also rode out that high and then got another high trying to rewrite to go, Postgres and gRPC.

(Thanks for coming to my rant)

They had a great allergy on actually writing “business specific” code. So naturally they tried to write machinery instead, and then failed...

"Don't mistake motion for progress"

(yes, I'm decided to comment only by quotes)

So I’m writing all that stuff because I was trying to figure out if I can phrase my “instincts” in a way that makes sense for others. I think Zach Tellman has something about this in his book.

So these days I’m usually thinking about “the domain” and trying to write code that resembles it. This could be tiny named functions that return snippets of SQL/mongo queries or our graphql API that is domain oriented (vs database oriented)

(Waiting for another quote @val_waeselynck !)

"To solve a problem, you have to let it dissolve into a rising tide of general theory"

OK, that one didn't work out that well

I blame the various tutorials that always aim at showing how the tech is put together, naturally using the simplest of domains, which gives people false confidence, because they leave thinking that making the machine dance is the job. Whereas it’s only the most basic requirement...

Yeah we do have a problem that having a good grasp of each mechanical part does not mean we have a good grasp of how they should come together into a sensible whole

And that's a misconception that typically plagues the discussions of "which technology is easiest"

Like, assembly language is quite easy, in the sense that it's very easy to picture what each individual instruction does

Much more so than the building blocks of Clojure programs for example

This does not change the fact that it's easier to program advanced logic in Clojure

Well I guess that's already addressed in Greenspun's 10th rule, should have quoted that maybe

Unfortunately, I think you can only cure that addiction of instant gratification through self-inflicted spaghetti code

Well, actually @orestis, maybe there's another way: actually achieving the right abstraction, where all the mechanical aspects become invisible, can provide another intense form of gratification, an "epiphany". Maybe that's something to encourage, a desirable reward to promote so that people strive for "pure-domain" code.

Yeah I was thinking about the ways to learn this: there’s the luck of landing in a team that got this right (to some extent), or the struggle of having to clean up the mess :)

Domain- driven design does try to go into this a bit but I remember a lot of noise about OO...

Yes, unfortunately most of what I've seen of DDD at conferences was working around the limitations of class-based languages

There does seem to be some Clojure-specific content though, e.g: https://www.infoq.com/presentations/DDD-Clojure/

(haven't seen it, don't know if it's good)

Anyway, you might not need to go all the way to DDD to teach that lesson - even SICP makes this sort of point

Still haven’t read SICP :(

I agree, DDD is deeply rooted in OO language for its tactical aspect not for the strategic ones (Ubiquituous Language, Bounded Context, Context map, etc.) where the real innovation and value was, and that part is language agnostic. For instance the Value Object building blocks has a lot of “functional” characteristics (immutability, etc.) and is simply a…Value. The Entity/Aggregate ones deals with lifecycle that is not tied to the language but more with identity, persistence, etc.