News for hackers. Stuff that matters.
Re:Bringing Clojure programming to Enterprise (2021) by thunky on Thursday April 02, 2026 @09:40AM (#47614353)
What I meant by that is the metaprogramming capabilities that often get cited for allowing devs to create their own domain specific "mini languages". To me that's a "creative" way to write code because the end result could be wildly different depending on who's doing the writing. And creativity invites over-engineering, over-abstraction, and hidden costs. That's what I meant by the "opposite of boring".
Re:Bringing Clojure programming to Enterprise (2021) by hatefulheart on Thursday April 02, 2026 @09:50AM (#47614487)
I read comments like these in bewilderment.

Have you worked for a company that hasn’t created its own, as you put it “mini language”?

Have you worked for a company that doesn’t indulge in over engineering, over abstraction and hidden cost?

Do you actually do programming for a job at all?

Re:Bringing Clojure programming to Enterprise (2021) by thunky on Thursday April 02, 2026 @10:06AM (#47614694)
speaking of bewilderment, i'm not sure at all what you're getting at here.

because programmers suck we should make tools that make it easier for them to suck?

Re:Bringing Clojure programming to Enterprise (2021) by tines on Thursday April 02, 2026 @11:54AM (#47616164)
We should make it easier for them to suck less. It's like providing free needles. Druggies gonna drug, might as well help them drug safely :)
Re:Bringing Clojure programming to Enterprise (2021) by whateveracct on Friday April 03, 2026 @06:51AM (#47625192)
what a low trust attitude

wouldn't want to work at a place with those kind of values

Re:Bringing Clojure programming to Enterprise (2021) by dgb23 on Thursday April 02, 2026 @11:06AM (#47615474)
You linked me to this comment from another one and I have to agree with this sentiment.

Creating these mini DSLs is something that requires a lot of thought and good design. There is a danger here as you pointed out sharply.

But I have some caveats and counter examples:

I would say the danger is greater when using macros and far less dangerous when using data DSLs. The Clojure community has been moving towards the latter since a while.

There are some _very good_ examples of (data-) DSLs provided by libraries, such as hiccup (and derived libraries), reitit, malli, honeysql, core match, spec and the datalog flavor of Clojure come to mind immediately (there are more that I forget).

In many cases they can even improve performance, because they can optimize what you put into them behind the scenes.

Re:Bringing Clojure programming to Enterprise (2021) by midnight_eclair on Thursday April 02, 2026 @12:15PM (#47616430)
so many similar conversations happening, it's refreshing xD

https://news.ycombinator.com/item?id=47587386

Re:Bringing Clojure programming to Enterprise (2021) by michaelsbradley on Thursday April 02, 2026 @09:50AM (#47614479)
In practice, though, most developers don’t do that.

There’s a rule of thumb: write a macro as a last resort.

It’s not hard to stick to it. In general, you can go a long, long way with HOFs, transducers, and standard macros before a hand-rolled macro would serve you better.

Re:Bringing Clojure programming to Enterprise (2021) by kaliszad on Friday April 03, 2026 @05:48AM (#47624793)
It also allows you to write stuff like Rama, Specter (@nathanmarz) and to wrap stuff that you do often to avoid boilerplate.