[ my public key: https://keybase.io/epgui; my proof: https://keybase.io/epgui/sigs/y564TgN5chSlzKFy-9SIa9Lpqeo22kBECpmXwEVwMJ8 ]
- You can property test most code.
- Am I the only one who, rather than being impressed, is recoiling in horror?
- I’m a senior engineer on a staff track, I am proud to ask “dumb” questions all the time, and I don’t want to work somewhere where I don’t feel safe pursuing knowledge openly and candidly.
- It’s very unpleasant to read. I did find the article useful nonetheless.
- I don’t see how this should take more than a few minutes of css work.
- There’s a nugget of an idea in there, even if I disagree with most of it.
But code doesn’t only need to be understood for maintenance purposes: code is documentation for business processes. It’s a thing that needs to be understandable and explainable by humans anytime the business process is important.
LLMs can never / should never replace verifiability, liability, or value judgment.
- At that point you may as well just do the work yourself.
- you could say that about anything…
- A lot of things that are “standard English” are not obvious, and not everyone has English as a first language.
- Of course teaching FP ideas to traditional-javascript devs is going to be tricky, but that’s less a React complexity problem as it is a familiarity problem.
If everyone came from a purescript/fp background the story would be different.
- It took me a minute to figure out if they were talking about a biosafety problem or a labour safety problem. Maybe that’s just me.
- Not to diminish the severity of the situation, but I believe this is a figure of speech… In case that wasn’t clear.
- Presumably the commenter read the article and is expressing his disagreement with the article’s second sentence.
- > Simplicity (explicitly control when things update)
I’m not saying this is wrong, but it’s a very very weird notion of simplicity. It reminds me a bit of how C++ engineers argue that for loops are simpler than comprehensions.
- See also “begging the question”.
- There are languages much better suited for DSLs though.
- There are some programming language journals that people like to dismiss as “academic”. But “academic” is what I value here.
- > However, it will take 10x the time to write, be less flexible, and harder to understand.
Not in my experience: only in the usual ramp-up period in the first few months.
- This article feels like someone is defending their language. And that doesn’t bother me, but I don’t value that.
I don’t care about what’s popular or what feels most familiar. What I want is a dispassionate discussion of how different language features impact code quality, and I think you can only find that in more abstract discussions. The kind that turns people off with its talk of monads and applicatives.
I wonder what that might mean!