If writing good, maintainable code requires knowing/using a large number of rules and best practices that aren't part of the language (and whose absence are actually considered to be a virtue of the language), that seems like a flaw in the language itself.
Yes, you can write bad code in any language. That doesn't mean that languages don't have an impact on the ease of writing good and correct code.
If you think that the existence of style guides are a flaw in their respective languages, then I'm going to (as non-condescendingly as I can via text) suggest that you may not be a very mature developer yet.
Style guides and best practices exist for every commonly used language, and not because of flaws in the languages themselves, but because unless there is literally only one way to do things, a dozen developers will come up with a dozen ways of solving a problem.
There's a difference between style guides offering a well-lit path to follow, and a language having a large number of possible expressions that are off limits in practice because they lead to bad code. The former marks out a path, the latter indicates a minefield. When the language's design actually facilitates the creation of bad code, not just by offering the possibility of dangerously ambiguous expressions, but by touting that possibility as a plus, that's a flaw.
Maybe accepting that flaw is worth it because the expressiveness of the language makes it a net plus; doesn't mean it's not a weakness or flaw or a point to be cautious about.
I do apologize - I didn't mean to be perjorative. I meant to communicate that I've heard the sentiment ("why does it let me shoot myself in the foot? It shouldn't let me do that!") espoused by many, many new developers, and it's an attitude that I've seen many people grow out of.
Coffeescript is a very flexible language. Its flexibility lets you do bad things with it, but the flipside of that attribute is that you can do very good things with it. I don't think that it's either "a path or a minefield"; I think those are two sides of the same coin. Optional parentheses and whitespace delimiting can reduce visual clutter, but if you abuse them and reduce it too far, you increase cognitive load on the person that has to read and maintain the code.
The more stringent the language, the less guidance you need in the form of style guides and community standards, but that's simply because the language itself imposes those standards on you as a byproduct of disallowing flexibility. It's absolutely something to be cautious about, but it doesn't make the language inherently flawed.
Syntax flexibility is not a virtue. Creating restrictive rules about what I can do to an object or how functions work ties my hands when I try to do tricky things, but syntax only limits my artistic urges to do esoteric code layout.
The C style syntax situation with optional if brackets is almost universally considered a flaw:
if (foo)
st1();
st2();
This is not the flexibility to do hard things. It does not save a lot of typing or make some other common construct less cluttered. It is just a defect in the grammar that it's too late to fix.
It sounds like Coffeescript has more of these flaws.
I don't consider the optional braces in C-if a flaw. I use them for early return often, eg
if (somethingBad)
return NULL;
restOfBody();
And I find that the braces are often just unnecessary visual noise. Of course, there is always the issue of people adding extra statements, but I haven't found that to be a problem in practice. YMMV though
The trick to avoiding the problem of extra statements is to only skip the braces if it all fits on one line:
if (somethingBad) return NULL;
That's a clear visual indicator that the braces have been skipped, but it's basically impossible to look at the next line and not know that it's NOT part of the conditional. Also, if you're having trouble fitting it all on one line, it's a good cue that you're not in a situation where skipping the braces is safe.
I think there ought to be a distinction between semantic flexibility and syntactic flexibility, though. They may be correlated but it's not always clear cut. Lisp is an example of a syntactically inflexible (s-expressions or walk) but semantically rich language (macros).
My own opinion is that syntactic flexibility does have value (e.g. Haskell). I think it's also vastly overrated relative to that value; syntax is incredibly easy to bikeshed. Semantics require you to know something about the languages at issue.
That said, my opinion is that this kind of syntactic flexibility offers dubious value if the trade-off includes not just obviously broken programs but also subtly broken ones with errors which are difficult to spot. Newbie errors are part of the learning curve, but these seem like mistakes even experienced people can make.
> Its flexibility lets you do bad things with it, but the flipside of that attribute is that you can do very good things with it.
The problem is that there is a local maxima in the flexibility cost-benefit curve. After you reach that maxima additional flexibility degrades your experience.
But surely for a language that is almost purely designed to make syntactic improvements, the designer could have taken a stronger stance on syntax. I wish he could have at least decided on semicolons. The beauty of Python is that it is actually hard to write unclear code that does what you think it does. I'd love to see a PEP-8 for CoffeeScript or some kind fo built in linter.
Not saying that they don't exist, but I've literally never seen a python style guide (other than "don't mix tabs and spaces", which is part of the language now), never seen someone make a commit just to fix code formatting in python (something that happens quite often with every other language I use professionally), and never had any trouble working on other people's python.
Yes, you can write bad code in any language. That doesn't mean that languages don't have an impact on the ease of writing good and correct code.