This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (72)
- # aleph (8)
- # announcements (21)
- # beginners (43)
- # calva (10)
- # cider (2)
- # clj-new (2)
- # cljdoc (12)
- # cljsrn (3)
- # clojure (9)
- # clojure-android (1)
- # clojure-europe (38)
- # clojure-norway (2)
- # clojure-romania (1)
- # clojure-uk (2)
- # clojurescript (58)
- # cursive (8)
- # datomic (29)
- # depstar (2)
- # fulcro (3)
- # java (20)
- # leiningen (11)
- # luminus (2)
- # off-topic (13)
- # sci (1)
- # shadow-cljs (3)
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.
They had a great allergy on actually writing “business specific” code. So naturally they tried to write machinery instead, and then failed...
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)
"To solve a problem, you have to let it dissolve into a rising tide of general theory"
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
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
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.
There does seem to be some Clojure-specific content though, e.g: https://www.infoq.com/presentations/DDD-Clojure/
Anyway, you might not need to go all the way to DDD to teach that lesson - even SICP makes this sort of point