Walter Bright Wrote: > Here's certainly a different take on language design: > > http://blog.objectmentor.com/articles/2009/07/13/ending-the-era-of-patronizing-language-design > > I'm not convinced. All my engineering experience supports the idea that > the larger the project and the more people are involved in it, the > better off you are with isolation between modules and better enforcement > of interfaces. > > Simply relying on programmers being responsible isn't good enough when > you've got a high risk application. > > What are your experiences?
I agree that relying on other programmers' "good will" or "responsibility" or whatever name you want to give it is a dangerous way to approach a project. However, the author seemed to me to be advocating more of a D language approach to the world -- give the programmer the tools he needs. I enjoy the low-level, "unsafe" capabilities in D. But only because they are fenced in with lots of warnings and "here be dragons" sorts of comments. I don't think the strong emphasis on type, thread and const safety is misguided -- compiler ensured safety isn't confining, but liberating. I don't have to worry that I (or the other guy) meant one thing but did another. But when I do intend to subvert some safety feature I want to be reminded that I'm skating on thin ice. In my experience, problems with independent development of software and relying on fixed interfaces most often arise either because someone chose to disregard or "improve" the interface, or (more usually) the interface was not specific enough, and allowed for more than one (incompatible) solution. I guess a third kind of problem was the part of the team that did their development without any particular regard for the interface and then, when time was short, lobbied for drastic changes so they wouldn't have to re-implement their software to actually comply. The existence of the interface wasn't the issue. The better defined and more rigidly enforced it was, the better the result. And yes, I've been involved with projects where the interfaces were poorly defined that still succeeded, but only because there were the independent types who went and actually talked with the designers on the other side of the interface and established a de facto standard. So I object to being "patronized", but I'd rather have something explained to me slowly than to move forward rapidly based on inaccurate assumptions. In the words of President Reagan: "Trust, but verify." Paul
