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-


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?


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-


 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?


 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