On Fri, Sep 21, 2018 at 10:53:39AM +0000, Vladimir Panteleev via Digitalmars-d wrote: > On Friday, 21 September 2018 at 07:58:16 UTC, mate wrote: > > Different sensibilities on where to put restrictions clearly lead to > > different designs. I am not sure myself what is best. > > The more people you have on your team, the more you appreciate the > restrictions. If you are working on a personal project alone, you are > in control and have full knowledge of the entire codebase, so > restrictions are a hindrance. When you are collaborating with someone > you know only by name from across the globe, being able to reason what > their code might or may not do is considerably helpful.
+100. Many things I could get away with in my own personal projects, I wouldn't do in a team project (which is basically *any* non-trivial project these days). Unrestricted freedom to do whatever you want greatly reduces the ability to reason about the code, which is why these days structured programming constructs like if/else, while-loops, functions, etc., are preferred over unrestricted goto's, even though they are technically "more restrictive". The challenge is in finding the balance between restriction and not hampering the programmer's ability to express what he wants without jumping through hoops (Java's verbosity comes to mind... although, to be fair, given your typical "enterprise" development environment, this is not necessarily a bad thing, since it forces even bad code to conform to a certain predictable structure, which makes it easier to rewrite said bad code :-P when one of your coworkers turns out to be a cowboy programmer). Not an easy balance to strike, which is why designing a successful programming language is so hard. T -- Unix is my IDE. -- Justin Whear