4 ms·

This attitude is fine for personal projects, but it does not scale when working with other people. Even in a two person project, one person using a language fe

This attitude is fine for personal projects, but it does not scale when working with other people. Even in a two person project, one person using a language feature will inadvertently force the other person to learn how that feature works. And they will not even know if the feature was appropriate to use until they have learned it. With this small amount of reasoning we are back to the tired old argument of "Which is better? Ease of expression or ease or learning?"

bachmeier 8y ago
> This attitude is fine for personal projects, but it does not scale when working with other people. Even if true, so what? "Personal projects" don't count? But honestly, this is one of the worst programming language arguments there is. Any feature can be misused. There has to be discipline - full stop. Restricting the language is not the answer because that just leads to worse code, not better. Decades of C code demonstrates that lack of features does not translate into good programming practice.
- dgellow 8y ago
  C has clearly other issues than just a lack of features.
  - btschaegg 8y ago
    You could very well argue, however, that many of the issues with C are symptoms of a lack of some specific features. To work around that, you need just as much discipline (to avoid, for example, buffer overflows) as you would need not to misuse the features that aren't there. That's more or less the reason I too don't find "multiple people projects may have problems with discipline" to be a good argument for anything. That's a culture issue and pretty much orthogonal to any technical factor of your environment, including the choice of programming language.
BurningFrog 8y ago
You're assuming the multi person project has no coding standards. Then again, you are perhaps making a decent argument for using simple languages in multi person projects!
Volt 8y ago
Are you not doing code reviews in your organisation?
piano 8y ago
> This attitude is fine for personal projects, but it does not scale when working with other people. True, but the same is true of Go, which may be surprising to people. Despite its claims, Go didn't solve this problem. One reason is that larger projects typically start to invent their own abstractions on top of the base language and Go is no exception here, in fact, what with its lack of some common abstractions, built-in support for code generation, frequent use of external add-ons (like go vet etc.), Go very much encourages this. And so you're going to have to learn specifics of larger projects just like with "complex" languages. The solution to this problem is meticulous and somewhat restricted code style standard, but that's a solution that works with "complex" languages just as well, in fact, I'd argue that even better. The other reason is that the Go language is not just the Go language. That is, what with the lack of abstractions for error handling, code re-use, etc., people end up following a bunch of conventions, styles, patterns and using external tools (like the already mentioned go vet). And so in effect the language becomes "the base" + "lore". This is of course true of any language. With Go and early Java, for example, this becomes more pronounced, since the base part is very small, larger parts need to be taken care of by the "lore". This is why Design Patterns become so popular in the Java world. And this why it's not good to have the base part too small, which is the problem of Go. Of course, the other extreme is equally bad - that is, when the base part is too large, which is the problem of C++, where now "lore" has to take care of deprecating/removing language features. I feel like the authors of Go decided to do the opposite of what C++ does and thought that since C++ is horrendous, doing the opposite would yield a great result. But unfortunatelly that's not the way things work. You can't just negate someone's bad approach and expect great results.

bachmeier 8y ago

> This attitude is fine for personal projects, but it does not scale when working with other people. Even if true, so what? "Personal projects" don't count? But honestly, this is one of the worst programming language arguments there is. Any feature can be misused. There has to be discipline - full stop. Restricting the language is not the answer because that just leads to worse code, not better. Decades of C code demonstrates that lack of features does not translate into good programming practice.

dgellow 8y ago
C has clearly other issues than just a lack of features.
- btschaegg 8y ago
  You could very well argue, however, that many of the issues with C are symptoms of a lack of some specific features. To work around that, you need just as much discipline (to avoid, for example, buffer overflows) as you would need not to misuse the features that aren't there. That's more or less the reason I too don't find "multiple people projects may have problems with discipline" to be a good argument for anything. That's a culture issue and pretty much orthogonal to any technical factor of your environment, including the choice of programming language.

BurningFrog 8y ago

You're assuming the multi person project has no coding standards. Then again, you are perhaps making a decent argument for using simple languages in multi person projects!

Volt 8y ago

Are you not doing code reviews in your organisation?

piano 8y ago

> This attitude is fine for personal projects, but it does not scale when working with other people. True, but the same is true of Go, which may be surprising to people. Despite its claims, Go didn't solve this problem. One reason is that larger projects typically start to invent their own abstractions on top of the base language and Go is no exception here, in fact, what with its lack of some common abstractions, built-in support for code generation, frequent use of external add-ons (like go vet etc.), Go very much encourages this. And so you're going to have to learn specifics of larger projects just like with "complex" languages. The solution to this problem is meticulous and somewhat restricted code style standard, but that's a solution that works with "complex" languages just as well, in fact, I'd argue that even better. The other reason is that the Go language is not just the Go language. That is, what with the lack of abstractions for error handling, code re-use, etc., people end up following a bunch of conventions, styles, patterns and using external tools (like the already mentioned go vet). And so in effect the language becomes "the base" + "lore". This is of course true of any language. With Go and early Java, for example, this becomes more pronounced, since the base part is very small, larger parts need to be taken care of by the "lore". This is why Design Patterns become so popular in the Java world. And this why it's not good to have the base part too small, which is the problem of Go. Of course, the other extreme is equally bad - that is, when the base part is too large, which is the problem of C++, where now "lore" has to take care of deprecating/removing language features. I feel like the authors of Go decided to do the opposite of what C++ does and thought that since C++ is horrendous, doing the opposite would yield a great result. But unfortunatelly that's not the way things work. You can't just negate someone's bad approach and expect great results.