For sure, in some ways perhaps reverting to a low trust environment might improve quality in that it now forces harsher/more in depth reviews.
That however doesn't make the requirement less exhausting for people previously relying heavily on those markers to speed things up.
Will be very interesting to see how the industry standardizes around this. Right now it's a bit of the wild west. Maybe people in ten years will look back at this post and think "what do you mean you judged people based on the code itself that's ridiculous"
You said "hence the point its author is trying to make must be true" and "hence it must be modeling the world with high fidelity".
But it's more like "hence the author is likely competent and likely put in a reasonable effort."
When those assumptions hold, putting in a very deep review is less likely to pay off. Maybe you are right that people have been too complacent to begin with, I don't know, but I don't think you've framed it fairly.
And isn't dyslexic, and is a native speaker etc. Some will gain from this shift, some will lose.
The heuristic is "this submission doesn't even follow the basic laws of grammar, therefore I can safely assume incompetence and ignore it entirely."
You still have to do verification for what passes the heuristic, but it keeps 90% of the crap away.
When someone follows standard conventions it means that they A) have a baseline level of knowledge to know about them, and B) care to write the code in a clear and approachable way for others.
“unconventional” or “fancy” is in the eye of the beholder. Whose conventions are we talking about? Code is bad when it doesn't look the way you want it to? How convenient. I may find code hard to read because it's formatted “conventionally”, but I wouldn't be so entitled as to call it bad just because of that.
Literally not: a language defines its own conventions, they're not defined in terms of individual users/readers/maintainers subjective opinions.
> Whose conventions are we talking about?
The conventions defined by the language.
> Code is bad when it doesn't look the way you want it to?
No -- when it doesn't satisfy the conventions established by the language.
> I may find code hard to read because it's formatted “conventionally”,
If you did this then you'd be wrong, and that'd be a problem with your personal evaluation process/criteria, that you would need to fix.
Where are these mythical languages? I think the word you're looking for is syntax, which is entirely different. Conventions are how code is structured and expected to be read. Very few languages actually enforce or even suggest conventions, hence the many style guides. It's a standout feature of Go to have a format style, and people still don't agree with it.
And it's kinda moot when you can always override conventions. It's more accurate to say a team decides on the conventions of a language.
If every rando hire goes in and has a completely different style and formatting -- and then other people come in and rewrite parts in their own style -- code rapidly goes to shit.
It doesn't matter what the style is, as long as there is one and it's enforced.
What you're saying is reasonable, but that's not what they said at all. They said there's one way to write cleanly and that's "Standard conventions", whatever that means. Yes, conventions so standard that I've read 10 conflicting books on what they are.
There is no agreed upon definition of "readable code". A team can have a style guide, which is great to follow, but that is just formalizing the personal preference of the people working on a project. It's not anymore divine than the opinion of a "rando."
While it's true that in principle it doesn't matter what style you choose as long as there is one, in practice languages are just communities of people, and every community develops norms and standards. More recent languages often just pick a style and bake it in.
This is a good thing, because again, code is read 1000x more times than it's written. It saves everyone time and effort to just develop a typical style.
And yeah, the code might run no matter how you indent it, but it's not correct, any more than you going to a restaurant and licking the plates.
Again, there's a couple examples of languages doing this, and everything else is a free for all.
> No, you misunderstood what they said.
Agree to disagree. Nothing in that comment talks about the conventions of a language, only the conventions of code. Again, I don't disagree with what you say, but the person you replied to was in a completely different argument.
That's the core of the issue. It's time to say goodbye to heuristics like "the blog post is written in eloquent, grammatical English, hence the point its author is trying to make must be true" or "the code is idiomatic and following all code styles, hence it must be modeling the world with high fidelity".
Maybe that's not the worst thing in the world. I feel like it often made people complacent.