Not sure I am following, but from what I can tell we do disagree that there is any particular problem with “yelling” about readability, vs “yelling” about anything else, like performance or what have you. “it depends” does not make it a weak argument, because when it comes to assessment everything depends on goals, constraints and other things, so we should avoid invoking some sort of mythical purely objective POV that makes some arguments strong or weak in advance without some sort of consideration.
In an effort to be more on topic I do think it would be a good think if Elixir had more influence on other languages for precisely this reason, because it shows a lot more attention to the aesthetics of code. I am happy to see that coming through in the discussions around the development of the typing system. This seems to me to be a big part of the influence of Ruby. Matz, and the community generally, famously prized “developer happiness” and I think it’s sort of a shame this somewhat became bogged down in a “performance vs productivity” debate for some reason (coughDHHcoughcough). I have no desire to transform into an emotionless robot when I am writing code and I really wish “this code makes me sad when I read it” would at least be given some of the weight in reviews as “this code is not performant“ when it’s really not always true that the latter is somehow automatically more important. In my experience a lot of disagreements around code quality are hampered by pretensions of objectivity when the reality is more “this is just the way I like to do it“
So yeah let’s not yell (“average” developers are certainly not the only ones guilty of this) but let’s consider arguments even when they appear to be just a matter of opinion. “Is this enough abstraction” is fundamentally a subjective question and I’m tempted to say it’s the most generalized form of any assessment of software quality
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.
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.
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.
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!
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.
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!
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.
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.
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.
Don’t get me wrong, I also love the pipe operator, it’s just that many people love to get creative turning everything they can into a “pipeline.” It’s maddening as “looks cool” but doesn’t help with readability or debugging. I’ve also run into several instances over the years where it makes changing code really hard because all the code was tailored to work with pipes that didn’t lend well to changing steps in between (at least not in a sensible way).
I’ve said this a lot in the past but the small surface area of Elixir is very expressive where the constructs you use can communicate a lot about the code (“the medium is the message” if you will). For example, if I see with I think, “multiple side effects.” If I see a pipline, I think “effect-free data transformation that always comes out the other side.” I’ve found that whenever you find a pipe naturally breaking, it’s almost always means that it’s a good place to break it and assign it to a variable. This is especially true when see folks adding comments as to what the data looks likes like at this point.
There are a whole bunch of other things along these lines. Like piping into elem when you know its length is never better than pattern matching, I consider then and tap mostly evil (they are useful for debugging albeit pretty much just useful for debugging nasty pipelines), and don’t me started on |> Kenerl.+.
I do agree it gets murky with the raw value thing and “no single pipe.” For me it comes down to taste and it’s hard to describe and I don’t get too hung up about. For instance I also don’t like x |> Foo(), though in a changeset I will often do:
foo
|> cast(attrs, [:bar, :baz])
because there is often going to be more coming and makes for nicer diffs. I dunno, again, it’s more to taste and doesn’t really hinder readability/changeability in any meaningful way.
Of course it all comes down to taste, but I’ve come across a lot of production code that is full of “pipelines” that contains multiple different data-structures and multiple side-effects. It’s in these extreme, and unfortunately common, cases I say “to heck with your art” (or just type “LGTM” and hit “Approve”).
I hope that this is true. It’s not clear to me how things will play out. I imagine people on the other side of the argument would say precisely the opposite — the artistry way will be displaced moving forward (if it hasn’t been already). After all, this line of thinking happens to align nicely with the capitalist motive.
Interestingly, the guy who coined the “vibecoding” term doesn’t actually vibe code but rather liberally uses tab autocomplete, which I guess would be more in the vein of industrial with perhaps a bit more involvement and opportunity for artistry than pure mindlessness though seems easy to drift towards the latter.
As an aside, I also find it interesting that the most prominent voices in this community seem to champion the industrial way. I suppose with the belief that LLM slop is good enough as is and will only get better from here. Regardless, it all feels a bit prisoner’s dilemma. Among programmers, I wonder who is thinking of the 2nd and 3rd order implications of this path and what those pursuing it are ultimately hoping for — probably worthy of an entire separate discussion.
If this happens, is there any point anymore? Maybe if you’re solo-preneuring (or own equity) or coding as a hobby. This would drive the value of programmers to zero. The point of leverage shifts almost entirely to marketing and sales activities rather than a technical solution that can be copied ad infinitum. I thought that perhaps software quality could be a differentiating factor but I can’t say I’m confident in that hypothesis. Hopefully it bears out. The world deserves better software.
I didn’t mean this, I mean insofar as getting agents to do something useful without “prompting skills” being a bottleneck (or even a thing). I personally don’t see how humans aren’t going to be needed to vet the output for the foreseeable future, but who knows.
And this is the entirety of my point. None of this pipe abuse stuff has anything to do with pipes. If we removed pipes from the language those people would find something else to screw up, because their value function is fundamentally misaligned.
The only way to learn what is maintainable is to practice, i.e. to spend time maintaining your code.
This is exactly why I don’t like this stuff. The attributes that make code “good” or “maintainable” are enormously complex and subtle. Like with any trade, the ability to do this properly is downstream of many years of deliberate practice.
I will not allow a computer to tell me what to do.
Oh for sure, it’s just I’ve never quite witnessed the same degree of “syntax fever” before, so I get extra grumpy But I also haven’t used too many languages professionally. Ultimately, is what it is
Quality software has already become enormously rare, and the principles and techniques used to develop it have already been largely forgotten. It’s astonishing how quickly that happened.
Most web devs have no idea how to build anything other than rigid forms and rigid SQL tables duct-taped together with GET and POST. Getting past that its actually really hard because there are essentially no resources to learn from. And all of the tooling is built for these patterns, too.
Even tools which were carefully and deliberately designed to climb out of this hole, like React, are mostly just abused by people who don’t know what to do with them. Like, if you build a React SPA that hits a RESTful API tied to a bunch of rigid Postgres tables, what was the point?
But the thing about LLMs right now is that they don’t seem to be generalizing to anywhere near human intelligence. They can write code but they’re still mirroring the training set. And because “good apps” are practically extinct there’s nothing to be gained from this.
I am fairly confident than in the consumer space quality will win over time.
And they have every right to champion what they believe in. It’s our job to push back and provide another perspective.
Surely you are not suggesting that starting a pipe with a raw value is some "forgotten lore” key to writing good software that we’re losing because we use credo.
Look, when I work on my own stuff, I also let myself be more creative with how I am using and organizing code. I strongly believe that helps me improve my skills (especially when it’s not just another crud app). But the reality of working on teams is that we have to focus on the conversations that are the most productive. The computer is not telling me what to do, I am working with a team that collectively decided to let the computer handle that decision so that we can discuss more important architectural decisions. And none of that has anything to do with LLMs, where it is precisely the creative decisions that have been handed over.
I found squabbling over syntax unproductive the very first time I encountered it and this has not changed for over 20 years.
As @tfwright very adequately points out, at one one point it’s best to leave any conflicts behind and just focus on what truly matters. That would be the data and architecture.
I find arguments over craftmanship / being an artisan / having a creative freedom by getting ourselves liberated from the tyranny of a tool, a bit facetious and pretentious. We are here to get work done for money. If I could only code as a hobby then my views would likely be different but that’s not my reality.
And yeah LLMs are barely relevant here. They simply exposed the triviality of a lot of shovel-ware commercial programming.
The only thing I can agree with @garrison here is that writing quality software is indeed looking like it’s disappearing quickly. But it will make a comeback with a bang. I, like many of my kind, am simply waiting for the LLM hype wave to subside a bit. There will be metric tons of slop to fix. And many will start appreciating good quality and will pay even better for it.
The only question is how long will that take. Some societal shifts move with the speed of a glacier.
No, I think you are blending my last two replies (on two different topics) together. My reply to @jam was baking in a lot of context from previous discussions that I know he is aware of.
Hey, I get it. I acknowledged this when I brought up formatters.
Keep in mind that nowhere in my reply did I tell you what you should be doing. I don’t care what you do. If you’re happy, keep doing it. It doesn’t affect me.
I was only using your commentary on Credo to elaborate upon my own feelings.
I am not interested in defending these practices, but my impression is that vibecoders would strongly disagree with you here. They believe they are retaining creative control (by prompting) and that the code itself is immaterial.
This was not the point I was trying to make, though. I actually just do not like linters and code formatters lol.
and I really like this.
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 
I fault Elixir only because people are just so in love with it.
