Linked by Thom Holwerda on Mon 3rd Sep 2012 20:46 UTC, submitted by MOS6510
Thread beginning with comment 533837
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/20/13 11:29 UTC
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
Linked by Thom Holwerda on 04/18/13 11:21 UTC
Linked by Thom Holwerda on 04/16/13 9:29 UTC
More Features »
Sponsored Links



Member since:
2010-03-11
A better solution is to group styles into different languages.
That way you have clear definitions of what features to expect. If you have two devs who say "I know X", it means you can be reasonably sure that they can check each other's work.
Additionally, say we have a section of code that should be pure (functional.) We can do that in C++, but there's no guarantee that someone won't come by and make it impure. If we instead require a pure language, then this issue never comes up. The restrictions of each language give you guarantees about the characteristics of the code, making it easier to reason about.
If you have every feature available all the time, then the code quickly and easily becomes more complicated than it has any right to be. You have to manually restrain yourself with C++; you simply don't have to do that with simpler languages.
Now, I'll admit that cross-talk between languages is currently kind of a pain. Most languages really only interface well with C... and even then not necessarily well. So maybe it makes sense to use C++, for now, but that doesn't mean that C++ isn't an issue.