Perspective is everything. It sounds like you have been more fortunate than I, when it comes to developers I have interacted with. I think it’s important to look at things holistically even when explicit examples are given, especially when we’re talking about opinions. It’s not black and white, but there are people out there that will go out of their way to avoid acknowledging their own inabilities, maybe out of fear of being judged or wrong. To me programming is like writing a book, if the book is written in Spanish and a reader doesn’t speak it, they might find it incomprehensible due to lack of abilities. It’s really that simple to me.
Schultzer
sodapopcan
As much as I love it, in my experience aesthetics have been taken to extremes in Elixir in code I’ve had to work to the point where it makes me sad. The biggest (but not only) culprit would be the pipe operator, so I don’t really blame folks from other languages for being extremely skeptical.
4
garrison
Exactly. This is why I dislike code formatters; the practical value is clear (“avoid syntax bikeshedding on teams”), but the cultural cost is enormous. To format your code is to give in to the idea that writing code is a mindless, industrial activity with no affordance for artistic merit.
One thing I appreciate about LLMs is that they provide great clarity here: if you think about code this way, why are you writing code at all? Anyone with this mentality is about to be displaced.
The thing is, you have to factor out the skill issue.
Take the common dichotomy of “Clean Code” (that’s a proper noun) versus “Data-oriented Design”. This is often framed as a matter of aesthetics, where the former group prefers “beautiful” code and the latter is somehow sacrificing that for performance. But in reality the loudest voices on the DoD side are indie game developers, i.e. a group with more artistic integrity and merit than basically anyone else writing software. Naturally these are people who are going to care deeply about performance and beauty because that’s what it takes.
The difference between the “Clean Code” and DoD people is that, broadly speaking, the latter group understands how computers work and the former does not. This is not a matter of artistic merit but rather a pure skill difference. I mean, just look at the demoscene; who has more artistic merit or skill than that?
Someone who writes code that does not work well, regardless of how it looks, is simply not a good programmer.
4
sodapopcan
garrison
Hah, it was a bit of a Rorschach statement.
If your approach to programming is to mindlessly produce enterprise slop, you’re about to be out of a job because Claude can produce slop way faster than you.
So you can either lean into this and become a 10x vibecoder with 10 parallel agents churning out bottom of the barrel mediocrity, or you can reject the premise that decent software should or even can be produced industrially and focus your energy on building novel solutions.
This is what I mean when I say LLMs bring clarity. Before, there was a dichotomy between those who care about the quality of software and those who were focused on delivering immediate utility at the expense of that quality.
But now that the latter group is literally indistinguishable from a GPU this argument is much easier to win! 
1
sodapopcan
Much clearer 
and I really like this.
I have too many thoughts to respond coherently, heh. This is the path I’ve been taking, though. While I’m a mere web developer, I still care deeply about my craft and am very much a journey programmer, probably to my detriment. The way I see it, and this is by no means my own revelation (ugh, I really wanted to use em dashes here but I guess I can’t anymore), is that if LLMs are going to get to the point where they are so good anyone can use them easily, I’ll just wait until and in the meantime, continue to enjoy writing code. I’ve heard Claude is now prompting your when you start a project to help you prompt it back properly which is steps toward removing that whole “You just don’t know how to prompt it, bro” trope.
As for formatters, I like them. I don’t particularly think they ruin the artistry of writing code, maybe because it happened to largely match my style anyway, and it leaves a lot of stuff alone that matters to me. A big one would be that it doesn’t go an force everything on one line if it can. The same can’t be said for the heex formatter, unforumately.
Elixir just has too many ways to be “cute” and it’s starting to really get to me 
I am all for code as art, even on team-owned projects to a point. But if you are going to write business code like _why the lucky stiff inspired code then I’m going to have words for you. The formatter, and even Credo, can’t help much with this.
1
tfwright
Sure, there’s a whole lot of open space between “my code is performance art, you wouldn’t get it bro“ and “humanity is just a rounding error.“ The point I’ve been trying to make here (and everywhere if I’m being honest) is that if we try to eliminate the ambiguity from questions like these we lose by default. Even the question of “formatters”, is this really that black and white? I doubt there are people out there that enjoy manually removing empty whitespace from their code, or consider it a point of pride in their craft to leave it there. Rather than “do we care about readability?” Or, “do we care about performance,” I think we should be asking “what counts as readable code in this project“ and “what kind of performance do we care about?“ And expect and celebrate different answers to those questions in a code golf exercise vs an ecommerce application vs an experimental database
edit and the most important part: the fact that there are different answers these questions doesn’t mean we can no longer judge if this is a good ecommerce application, a better application than this other one, even if they both “work” and the latter has better performance metrics!
2
garrison
Well that’s the irony, isn’t it? If you actually like what the formatter produces, invoking the formatter is a form of artistic expression for you. And I cannot possibly have a problem with that
Andy Warhol managed to get away with painting cans of soup!
I am just not convinced this is a “language” thing. Like, you know the C code that prints a spinning donut formatted as a donut? You can do this stuff in literally any language.
If someone is writing unmaintainable code it’s just a skill issue. Usually the root cause is not spending enough time having to maintain their own work, which is the only way to learn.
1
sodapopcan
I don’t disagree with either of you but also there are a few different topics going on here. I don’t think talking about this stuff is a waste of time at all and I hate that many people do.
Really I’m just salty about how people (ab)use the pipe operator, really 
I fault Elixir only because people are just so in love with it.
1
tfwright
pipe operator is a good low stakes case study! Default credo has, I think pretty decent rules around pipe usage. For instance, I do agree single pipes are “abuse.” x |> foo() is not as readable/pretty/clear as foo(x). But I also agree (with most of the community I think) that
x
|> foo()
|> bar()
|> baz()
is much better than alternatives with parens or intermediate vars. So where’s the line? Not something I think we care about really. Somewhere in between. Write the credo rule and move on, otherwise, yeah, you’re probably bike-shedding.
Where it gets more interesting is something like use with Ecto’s binding aliases. I have recently worked with someone who absolutely detested
Foo
|> from(as: :my_foo)
|> where(...)
...
even though technically that is in line with our project standards. But I have to agree it’s awkward, and doesn’t express very well. But I really didn’t want to give up the credo rule about starting with a raw value. It’s not that credo is right or wrong here, I would argue from trying a bit too hard to adhere to SQL syntax at the cost of expressiveness in Elixir and better would be
Foo
|> as(:my_foo)
|> where(...)
Or there are other directions you could take it. I’m sure some people think stuff like this is a waste of time. But my view is little things like this add up in the same way that small amounts of tech debt add up, and it’s just as important to take a min and see if you can make simple and easy improvements to your names to make your API pleasant to use and read.
1