[davidthewatson]

It's worth noting that the pattern you describe here is an emergent property of programming languages that changes with the era:

http://www.paulgraham.com/pypar.html

Sadly, the culture of programming language choice in commercial contexts has changed a lot in twenty years, but you can replace python with rust or elixir because programming language choice is a good proxy to understanding insight, intuition, and intelligence.

I like python, but if the broad preference mattered, we'd all be running J2EE apps today. My reasons for choosing python around Y2K were as philosophical then as they are now.

Where your argument goes awry is that what matters is how the programming language catalyzes better interdisciplinary team communication. Code tells a story that, the easier it is to read, the clearer the story gets, and that pays unforeseen dividends in development, deployment, debugging, and distribution.

Computer optimization is straightforward by comparison to scaling human commercial endeavors.

“Programs are meant to be read by humans and only incidentally for computers to execute.”

― Donald Knuth

[iterateoften]

Where your argument goes awry is that this discussion is about Elixir. The points you make I did not see happening in the Elixir community so I left even though I was a staunch advocate for years.

Programs are meant to be read by humans. Which is why Python and the bunch are so widely popular across foreign contexts.

Elixir is hard in that context because it introduces a lot of paradigms.

I have had Elixir teams but there is a big big big difference between someone who has done a Phoenix tutorial and someone who understands supervisor trees and genservers.

There are much better languages than Elixir for communicating intention in programs in a way that a junior dev can come in and understand. Especially if you are working with engineers in foreign countries with language barriers.

[weatherlight]

> I have had Elixir teams but there is a big big big difference between someone who has done a Phoenix tutorial and someone who understands supervisor trees and genservers.

Most of the "scary" parts of the BEAM aren't surfaced when using Phoenix. I don't think you are being terribly honest here. Working with Elixir/Phoenix is no more difficult from a academic aspect than working in Python/Django or gasp JS/Typscript/(Front-end framework du jour.)

> There are much better languages than Elixir for communicating intention in programs in a way that a junior dev can come in and understand. Especially if you are working with engineers in foreign countries with language barriers.

If you say something like Go or Python. I'm going to scream, lol. It's just isn't true. Phoenix was voted the most loved web framework in stack overflow's 2022 survey, Elixir was voted second most love language after Rust. A large percentage of the survey takers only had 1-3 years of experience.

[davidthewatson]

Good point. I can relate.

I worked in Ruby on Rails and our particular culture of Rails was not the purity that DHH encourages, but a kind of hipster collection of things like Cucumber, where the intent diverges from reality. That is, we understood the design intent of the DSL barrier-lowering interdisciplinary facade to non-technical people writing tests.

However, that is not what happened in reality. What happened in reality is that only techs wrote Cucumber tests and they struggled mightily with abstractions that had good intent, but bad ROI, given their misapplication.

The constant cacophony of unforeseeable DSL interactions was that team's annoyingly persistent foot-gun postmortem.