It’s obviously your right to do so. In a team setting that’s simply not an option however.
I feel like my original post has just fallen out of context here. I literally opened with “the practical value is clear”.
While I’m on team-formatter, the thing is they only enforce very, very minimal style (especially mix’s formatter). There are still a million different ways to much up style in a team setting that causes frustration beyond just “I don’t like this style.”
1 Like
I am with you but this is mostly Elixir-specific. It simply does not go far enough. Rust’s formatter is much more aggressive and I love it for that. (Though of course many don’t.)
My stance on formatters is: if you want to assist programmers then why don’t you go all the way? Why pull punches?
That’s why I like the Quokka formatter more. It’ll directly rewrite val |> do_stuff() to do_stuff(val). Frak your feelings, we have a team coding style and we deemed spending further time on this to be unproductive.
You can also configure it to sort keys in maps and struct definitions.
But yeah, my problem with Elixir’s default formatter is that it’s too meek. It should have more opinions and a handful of configurable knobs i.e. leave with that has whitespace alignment alone – it’s objectively easier to read that way.
1 Like
Definitely true, and the reason why team success often has a lot more to do with political/psychological dynamics than any technical issues, aesthetic or otherwise. It can seem sisyphean but it seems obvious to me that tools like credo help. Honestly have a hard time seeing another side to that in relation to a team setting.
Practically, one thing I’ve found really helpful is to try to get some consensus off the bat there is utility in drawing a line between style “preferences“ and “errors” even when it’s not pure from a theoretical pov. Then issues idenitfied as mere style go into a basket for potential credo rules, if we can’t get the computer to enforce it we just accept variation and ignore in PR reviews. Other things, like using some random acronym for a var, are legitimate targets for callouts even though they are also arguably only about readability.
1 Like
Let me know if I misunderstood you but this right here looks a bit pretentious. Or maybe you don’t work in teams and can afford this view?
While I have certainly found and used my own style towards a good amount of problems, it also has to be said that programming is mostly an objective science – one nobody can quite describe fully and formally just yet.
But let me not jump to assumptions. Can you give examples of artistic merit in programming? I am struggling with that.
To reiterate my stance, to me formatters are a fact of life, one I grew very fond of with time. I actually view this transition of mindset as a character development; letting go of something that looked like ego to me, so I can collaborate with people. I find it fascinating that it seems you’re going in the opposite direction. But I am certain I have misunderstood you and will appreciate elaboration.
1 Like
I agree with your thoughts on the rigid SQL and HTTP apps. Curious, what would you say would be a better or ideal way to build quality software? What has been forgotten?
For the record I think having a “coding style” is a great idea. And I would include many things in such a style guide that are impossible to lint because they require intelligence to make a judgement call as to whether something is in the spirit of the guide or not.
As an example, take a look at TigerBeetle’s style guide. There are some things on here that could be linted, but look at how many cannot be. There are literally entries labeled “this requires taste”!
This wasn’t directed to me specifically, but I think physical architectural is a classic example no? When a building just has the right proportions, but also is made with high quality components, it blends into its environment amplifying natural beauty instead of destroying it. The opposite of a mcmansion.
I feel the same way when I’m reading good code, vs reading the software equivalent of a mcmansion. The names express the intent instead of making me squint, modules have a pleasant size where I can grasp the context but am not overwhelmed by details…etc
I get the idea but I would be more interested in examples with code. I’ll start: I do my best to produce code that reads like English; like a story. Never have functions that are too long. Don’t mix concerns if you can help it. Isolate side effects to the maximum extent possible without resorting to various madnesses. Things like that.
But I would argue those are mostly quantifiable and don’t fall under “art”.
Started reading and already liking it but “this requires taste” makes me roll my eyes.
Well it’s not like I remember them, I wasn’t there! Keep in mind just because I can identify the fact that there’s a problem does not mean I know exactly what the problem is let alone what the solution is. I am definitely not claiming to have found the lost knowledge.
But I know something is wrong because software doesn’t work as well as it used to. To start, go back and read the original Apple Human Interface Guidelines for the Mac. The original Mac, from the 80s. Look at how much care they put into the user experience compared to the average webapp today, and ask yourself how we could have moved so much further backwards in 41 years. It really is just straight up depressing.
Here are a couple of principles that I have tried to embrace and which have (unsurprisingly) given me great trouble with existing tools:
-
The UI should instantly update to reflect complex underlying state without tearing. I tried to do this using LiveView, PubSub, and Postgres, and at this point I think I would say that I mostly failed. I made it pretty far, actually, but the “ugly hacks” slowly start to creep in and that obliterates velocity. I have come to recognize that I was simply abusing these tools; they were not made for this.
On the UI side, LiveView is actually quite decent but deep down post-hooks React’s design is more refined. This is not a difference you are going to perceive when working on “simpler” apps. The lack of composition for a number of key constructs (global
id) is problematic and the imperative APIs (JSandstream()) are poison.On the DB side things are worse. Postgres’s consistency guarantees are a clown fiesta to begin with before you try to graft incremental views onto them. I admire that ElectricSQL is trying, but honestly it might be easier to throw it away.
-
Impactful actions should be trivial to undo/redo.
Actually I got good results with LiveView here initially, as it is a legitimate stateful UI runtime. Forms and REST could never have gotten me that far. The problem is that the “backend” side of the undo/redo impl (command style) is glued to Ecto/Postgres.
SQL databases are just evil for this stuff. A proper undo/redo implementation requires a level of flexibility that is just not present.
There is more but look at how these two simple goals, which were met by desktop software 40 years ago, are enough to bring modern tooling to its knees. Form-based saas violates both of these so thoroughly and so deeply that there is no coming back.
Thankfully React’s design is simple and solid enough that I should have no trouble replicating it, so the frontend is easy. The database is… a bit harder, but I’m making real progress! A new stack will rise.
1 Like
How exactly do you quantify “too long” vs “too short”? 42? “too mixed” or “not mixed enough?”
Some of these things you can make quantifiable if you decide you don’t care that much, and just let credo enforce it. But others, mixing concerns I think is a good example, is going to be a matter of taste that nonetheless needs everyone to put care into and discuss with an open mind.
That’s why I said “mostly”. I can’t quite quantify them to formulae and recipes. Yet.
They are guidelines to strive towards. I wish I had more free time. Sigh.
I suppose I have a problem with the word “taste” in particular. Like @garrison said, we can see something is not quite right and we can make it better. But we can’t quite say what exactly is wrong. That however does not make it a matter of taste, IMO. It makes it an active area of research that is still ongoing.
There is a lot going on here, lol.
While unfortunately generally very unpopular, my answer is always pair programming.
For code style, when you’re writing code together all day long you just being to natural adopt the same style as your team-mates and you can hold each other accountable for things like random acronyms as variable.
As far as the topic developers stagnating which I haven’t commented on yet and won’t bother diving into, it completely eliminates the idea of “junior work,” which means you don’t have to stay away from patterns that “will be difficult to juniors or people new to the language to understand.” Grab a junior as a pair and work on something easy, then work on something really hard. Very, very quickly they will no longer be junior.
I think the lion’s share of my woes with Elixir would be solved if Elixir made it possible to mark functions as effectful, and calling those functions was only syntactically valid on their own line or at the very end of a pipeline. It’s a silly dream, though 
1 Like
I am ashamed to admit I did not like this for most of my career but started practicing it in the last 2-3 years and love it a lot. How stupid I was. But hey, character development!
As I keep developing as a programmer, this became my chief grief with all languages that don’t have it. I’ll start looking for ways to home-grow it in my projects.
1 Like
I certainly agree this is sort of an unfortunate example because the writing here is kind of, a bit much. But if you read the actual principles they follow you can see they are only really trying to enforce some only moderately strict rules, honestly, a lot of which can be quantified. I do agree with @garrison that it’s sad that the general state of development is so poor that having principles at all beyond mere formatting rules is something that is worth bragging about. Although I have my own ideas about the reason for that which have little or nothing to do with the opinions of individual developers or even teams.
1 Like
That’s why I like the article.
Or they are genius but are pretentious pricks. 
Having worked with both pretentious pricks and people who seem annoyed at even being asked to care, I’ll take the pretension every time (partially because being pretty pretentious myself I try to forgive it in others).
1 Like
False dichotomy, why not humble geniuses? 
But we started severely digressing. Sorry.
