www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Patronizing Language Design?

reply Walter Bright <newshound1 digitalmars.com> writes:
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?
Jul 13 2009
next sibling parent Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:
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
Jul 13 2009
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:h3g51a$2e3r$1 digitalmars.com...
 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've always considered myself a highly responsible coder. But I still make mistakes. Hell, the best programmers in the world make mistakes. The article seems to assume that safety features are for irresponsible coders. That's nonsense. There's always a way to get into some sort of trouble (even if it's just creating a pile of unmaintainable code), and irresponsible coders are going find it, because they're the ones who think they don't make mistakes. What makes a responsible coder responsible is *admitting* that they're infallible and responsibly using the appropriate tools to catch or prevent any possible mishaps. Irresponsibility is skating along the edge of a cliff because "It's ok! I'm a responsible person!" Responsibility is making sure there's a f*^&* fence first. "You can program safe, secure, high quality applications in dynamically typed languages. People do it all the time..." Yea, I'm sure they do. And there are a hell of a lot of people who ride motorcycles at 75+ mph without a helmet on a regular basis, never get into a single accident and live long productive lives. Doesn't mean it isn't stupid. The whole article seems screwy anyway: The author seems to be under the impression that whenever a particular feature is missing from a language, like metaprogramming or reflection, that it must be because it was deemed unsafe. Straw-man, anyone? Also, maybe I'm wrong, but doesn't Ruby (and Python for that matter) lack direct memory access/management, reinterpret casts, etc? If so, then so much for the claim that those languages are all about throwing away safety nets and trusting the programmer. In fact, so much for the whole idea of placing all responsibility on the programmer because (unless I'm mistaken) *even those* supposedly "trust-the-programmer" languages know perfectly well not to truly trust the programmer.
Jul 13 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:h3ga75$2n4m$1 digitalmars.com...
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:h3g51a$2e3r$1 digitalmars.com...
 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?

(rant)

Of course, then again, something like Java *is* patronizing in a very bad way. Like other people have said, let me do what I want, but if I'm doing something questionable, make sure I'm at least aware of it.
Jul 13 2009
parent BCS <none anon.com> writes:
Hello Nick,

 let me do what I want, but if
 I'm doing something questionable, make sure I'm at least aware of it.

Bingo! The only language you /can't/ write bugs in is HQ9+ http://esolangs.org/wiki/HQ9_Plus Just about any time you stop me from doing something because you think it's a bug, you will make something else (that is not a bug) harder.
Jul 13 2009
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Mon, Jul 13, 2009 at 05:50:25PM -0400, Nick Sabalausky wrote:
 Also, maybe I'm wrong, but doesn't Ruby (and Python for that matter) lack 
 direct memory access/management, reinterpret casts, etc? 

They don't even have goto, surely because they think people would abuse it. -- Adam D. Ruppe http://arsdnet.net
Jul 13 2009
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 What are your experiences?<

Michael Feathers is talking about Ruby; in the Python community there's even a say about this subject: "We are all consenting adults". It means that you usually don't need private class attributes, you can just put an underscore (or even two, for name mangling) before the name of class attributes that are private, it means "don't mess with those, or do it at your own risk". Usually this is enough. Michael Feathers says something quite important here:
The additional price is a decreased sense of responsibility and ownership.<

Human behavior isn't set in stone, it changes and adapts itself to the situation. Even intelligence changes according to the ambient. So if you put a programmer in an anonymous box inside a noisy Open Space, then you give such programmer a very precise list of things to program plus a bondage&discipline language like Java, such programmer will behave in certain ways. If you give such programmer some responsibilities, some space to learn and try things in a more flexible language, you will see a different behavior. Probably you will see the first programmer be less intelligent than the second one. Such psychological things are important, and often ignored. Bye, bearophile
Jul 13 2009
prev sibling next sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
Walter Bright wrote:
 What are your experiences?

Not all safety features are patronizing. Safety features allow the compiler to partially check the correctness of the program. Patronizing safety features prevent the programmer from doing their job. Having no way to specify const data is dangerous. Having no way to cast away 'const' is patronizing. -- Rainer Deyke - rainerd eldwood.com
Jul 13 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Rainer Deyke wrote:
 Not all safety features are patronizing.  Safety features allow the
 compiler to partially check the correctness of the program.  Patronizing
 safety features prevent the programmer from doing their job.
 
 Having no way to specify const data is dangerous.  Having no way to cast
  away 'const' is patronizing.

I think that's a sensible way to put it.
Jul 13 2009
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Reminds me of this from Bartosz' site:

"If you're a fan of object-oriented programming, you might find this 
quotation from the MFC's official Guidelines for Writing Class Library 
Extensions pretty amusing.

    Limit the Use of "Private" in Your Classes. It is important that your 
users be able to use your MFC-friendly classes in ways that you might not 
have originally intended. By keeping the majority of member functions, data 
members, and operators public, you allow for flexibility in their use. In 
MFC, even functions declared in the //Implementation section of a class are 
usually public or protected. " 

http://www.relisoft.com/resource/libs.html
Jul 13 2009
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Here's certainly a different take on language design:
 http://blog.objectmentor.com/articles/2009/07/13/ending-the-era-of-patronizing-language-

 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?

The same as yours. As project complexity and team size increase, modularity and isolation become increasingly important. Varying design style between team members alone can substantially affect the comprehensibility of the design, not to mention varying skill levels and plain old workplace problems. The more the design can be statically constrained by the design tools (programming language and toolchain, in this case), the less chance there is for such problems to occur. I'd be interested in hearing whether there are any genuinely large projects out there that are written in dynamic languages, and whether maintainability is an issue with them. Are bugs easy to find? etc.
Jul 16 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Sean Kelly" <sean invisibleduck.org> wrote in message 
news:h3ntqk$qmv$1 digitalmars.com...
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Here's certainly a different take on language design:
 http://blog.objectmentor.com/articles/2009/07/13/ending-the-era-of-patronizing-language-

 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?

The same as yours. As project complexity and team size increase, modularity and isolation become increasingly important. Varying design style between team members alone can substantially affect the comprehensibility of the design, not to mention varying skill levels and plain old workplace problems. The more the design can be statically constrained by the design tools (programming language and toolchain, in this case), the less chance there is for such problems to occur. I'd be interested in hearing whether there are any genuinely large projects out there that are written in dynamic languages, and whether maintainability is an issue with them. Are bugs easy to find? etc.

I recently worked on a upgrading a small Python/Django/Apache/Linux webapp from an older version of Django to a newer one. While there's a lot about using Django that's really nifty, I found debugging to be an absolute pain, even for that small app. For instance, a lot of times when something was changed (though not always), the only indication was some obscure error that only pointed to a symptom. Plus, I would typically get no indication of certain errors until that particular section of code was actually executed (In these regards, it reminded me very much of the pains of dealing with PHP or Classic ASP.) There were a few other issues too. However, in all fairness, it was my first experience with both Django and mod_python, and I'm not exactly an expert with Python, Apache or Linux (although I am familiar with them and have used them before), so that may have been a factor in making things worse than they normally would be. FWIW, A couple of the problems I would probably have to attribute to unfamiliarity are: - Temporary test code and temporary commenting-out accidentally screwing up the allmighty indentations (resulting in weird errors that didn't remotely seem to indicate an indentation problem) - Certain objects apperently persisting even after changing the code, resulting in a number of incrediby bizarre errors such as a complaint that line X was calling non-existant function Y even when there was absolutely *no* reference to function Y on that line or any other (Ended up working around these sorts of issues by obsessively restarting apache after most changes, even though some changes *did* seem to work fine without restarting anything). Here's another thought on this recent "non-patronizing language" push: AIUI, One of the design ideals behind C's type system was exactly the same as these newer languages: to trust the programmer to "be an adult" and always know what they're doing. Well that didn't quite work out did it? Even the *experts* who make the C std lib *still* messed up and planted the seeds for thousands of buffer overflow errors/exploits. And then there's the troubles C coders have to deal with even today as a result of being trusted to not accidentally do a destructive implicit cast. The way I see it, these newer "non-patronizing" languages are walking down the exact same road which can only lead to the same old result: rediscovery of the need to *not* place blind trust in the programmer.
Jul 16 2009
parent reply BCS <ao pathlink.com> writes:
Reply to Nick,

 Here's another thought on this recent "non-patronizing language" push:
 AIUI, One of the design ideals behind C's type system was exactly the
 same as these newer languages: to trust the programmer to "be an
 adult" and always know what they're doing. Well that didn't quite work
 out did it? Even the *experts* who make the C std lib *still* messed
 up and planted the seeds for thousands of buffer overflow
 errors/exploits. And then there's the troubles C coders have to deal
 with even today as a result of being trusted to not accidentally do a
 destructive implicit cast. The way I see it, these newer
 "non-patronizing" languages are walking down the exact same road which
 can only lead to the same old result: rediscovery of the need to *not*
 place blind trust in the programmer.

I think (and it would seem Walter does as well) the answer here is to trust the programer, but only when they ask to be trusted. Make it so they have to explicitly do something (like do a cast) to get out of the safe feature set. Then try and set up social construct to prevent them, when possible, from needing to do the unsafe thing.
Jul 16 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:
 I think (and it would seem Walter does as well) the answer here is to 
 trust the programer, but only when they ask to be trusted. Make it so 
 they have to explicitly do something (like do a cast) to get out of the 
 safe feature set. Then try and set up social construct to prevent them, 
 when possible, from needing to do the unsafe thing.

Essentially, correct. My preference is to try to make the easy way the safe and correct way, and the cowboy approach to be possible, but require deliberate effort to employ, and there to be clear indications in the code that a cowboy approach is being used. For example (back to aircraft!), dust covers and other things that are handy to stick on the aircraft while on the ground, but would screw things up while in flight, have long red streamers attached. This makes it easy & quick to scan for any (literally) red flags before takeoff.
Jul 16 2009
parent reply Don <nospam nospam.com> writes:
Walter Bright wrote:
 BCS wrote:
 I think (and it would seem Walter does as well) the answer here is to 
 trust the programer, but only when they ask to be trusted. Make it so 
 they have to explicitly do something (like do a cast) to get out of 
 the safe feature set. Then try and set up social construct to prevent 
 them, when possible, from needing to do the unsafe thing.

Essentially, correct. My preference is to try to make the easy way the safe and correct way, and the cowboy approach to be possible, but require deliberate effort to employ, and there to be clear indications in the code that a cowboy approach is being used. For example (back to aircraft!), dust covers and other things that are handy to stick on the aircraft while on the ground, but would screw things up while in flight, have long red streamers attached. This makes it easy & quick to scan for any (literally) red flags before takeoff.

We still have a problem with casting, I think. There are still too many places where it is required. Most of the time they are pretty harmless, but unfortunately cast() can also be used to do some really nasty stuff. eg, int a = cast(int)b; If b is 'uint', that's fine. But if b is immutable, or an object, that's a disgusting bit of code. And you can't whether it's harmless or a capital offence without looking at the definition of b. Another example of long-distance coupling.
Jul 20 2009
next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Don, el 20 de julio a las 11:24 me escribiste:
 Walter Bright wrote:
For example (back to aircraft!), dust covers and other things that are handy to 
stick on the aircraft while on the ground, but would screw things up while in 
flight, have long red streamers attached. This makes it easy & quick to scan 
for any (literally) red flags before takeoff.

We still have a problem with casting, I think. There are still too many places where it is required. Most of the time they are pretty harmless, but unfortunately cast() can also be used to do some really nasty stuff. eg, int a = cast(int)b; If b is 'uint', that's fine. But if b is immutable, or an object, that's a disgusting bit of code. And you can't whether it's harmless or a capital offence without looking at the definition of b. Another example of long-distance coupling.

I was thinking the same the other day. I think common conversions should be handled by library functions, not casts. Specially conversions where there is more work than telling the compiler to interpret the bits in another way. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Home, home again. I like to be here when I can. When I come home cold and tired It's good to warm my bones beside the fire.
Jul 20 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:
 We still have a problem with casting, I think. There are still too many 
 places where it is required. Most of the time they are pretty harmless, 
 but unfortunately cast() can also be used to do some really nasty stuff.
 eg,
 int a = cast(int)b;
 If b is 'uint', that's fine. But if b is immutable, or an object, that's 
 a disgusting bit of code. And you can't whether it's harmless or a 
 capital offence without looking at the definition of b. Another example 
 of long-distance coupling.

I know.
Jul 20 2009