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
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 lar
"Walter Bright" wrote in message
news:h3g51a$2e3...@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 engin
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 nam
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 b
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
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 danger
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
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, yo
Walter Bright wrote:
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.
It's not about language design , what I have to say is more about
complex software systems in general. f.i. we are de
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
== Quote from Walter Bright (newshou...@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 experienc
"Sean Kelly" wrote in message
news:h3ntqk$qm...@digitalmars.com...
> == Quote from Walter Bright (newshou...@digitalmars.com)'s article
>> Here's certainly a different take on language design:
>> http://blog.objectmentor.com/articles/2009/07/13/ending-the-er
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
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,
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 const
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
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 im
18 matches
Mail list logo
