Sean Kelly wrote:

> Kind of an aside, but in C++ I always declare methods that override parent methods "virtual" even though the virtual label is inherited.

And I do that too, for exactly the same reasons.

Thought I'd return the courtesy to you, Farmer:

"Farmer" wrote .
> Just repeated this paragraph because it's so rare to read such musings, here.

Likewise re your comments

> > Arguing that the "override" should not be required because one doesn't wish to type in the word is like saying you don't wish to type in the "class" or "struct" keyword.
>
> How about preparing a proposal 'implicit class and struct declaration'? I bet, it gets plenty supporters but very few (if any) detractors. After all, OO-folks must write *so many* class declarations.

Don't follow you here, I'm afraid.

> > Another vague detraction is that of  "snow blindness". I think that clearly identifying those methods that override from those that don't is effective in helping either/or stand out against the background; regardless of whether your classes mostly/typically override or not. However, this is hardly an argument against something that's guaranteed to reduce the subsequent maintenance and debugging costs. So let's talk about that.
> >
> > The overriding (heh heh) financial cost of any long-lived software project is typically borne long after the initial release has been shipped. It's the cycle of updates, bug fixes, "enhancements" and so on that really suck up the dollars.
>
> But what about all those short-lived software: software projects that get canceled before they are finished or software that is abandoned shortly
after
> their initial release? The overriding number of projects belong to this category. And the more effort is put upfront (e.g. into maintainability)
the
> more likely the project is going to be canceled.

What you're partly talking about here is unrealistic scheduling which, unfortunately, seems the bane of the software industry. Regardless; we're talking about typing in perhaps a handful of additional keywords per class: I can't imagine you mean to say that will make or break a project? Surely some stronger compilation checks would not hinder such ventures?

> > We're not talking about some dorm
> > project that goes out to a few buddies and is then dropped after a month
> > or two. We're talking projects involving potentially hundreds of
> > man-years. Anything, and I really do mean *anything*, that a computer
> > language can do to reduce the element of 'surprise' during that
> > long-drawn-out-phase is a huge boon in terms of overall productivity and
> > in terms of hard currency.
>
> You really do mean *anything*?
> Wow, that's uncompromising, but real real-world computer languages put
your
> considerations into the 'nice to have' basket at best.

OK, fair enough. I meant anything that is accepted by the programming community. If adding such features restricts expression, then the language will die from lack of attention. That's not what we're talking about here: explicit use of "override" does not restrict expression in D at all. In return for a few measly additional characters you get more robustness. Plain and simple. Both long and short term.

> > This latter part is what gets the attention
> > of management. If the use of a language can reduce the bottom-line over
> > time, then it gets a great big pat on the back. DbC is one such notion
> > embraced by Walter; a stricter application of the override keyword would
> > be another. You start adding up all these little features, and pretty
> > soon you have something that the commercial development sector will
> > start to take notice of (purely from a bottom-line perspective).
>
> Probably, management doesn't care much for the maintenance phase of
software
> projects, since successful managers have moved to new projects, before
that
> stage is reached. Consider, how Java took management by storm. Although,
Java
> promotes several programming practices that a prone to bite maintainers,
and
> dropped some of C++'s features to improve maintainability.

Yes, those managers who wear Crampons to work. Regardless; someone pays the maintenance bills, and who do you think takes responsibility for commercial software after yon clambering manager has moved on to another pinnacle? They would certainly appreciate development features that help make their task smoother and less frustrating. Yes? There again, it's not just about maintenance as you rightly point out :

> I believe that the DbC thing isn't really about maintainability in first
> place, it's about cranking out reasonably bug-free code *fast*:
> If I crank out code with no other help than compile-time type-checking, I
> loose much time fixing all my bugs with a debugger. Writting full-blown
test-
> cases with 100% test-coverage is a time trap, too. But D's integrated DbC feature might reduce the time to write prototype-quality code, since it catches a fair amount of bugs, but requires only a modest time to write
and
> maintain.

Good point. I didn't claim that DbC or stricter overrides were purely about maintainability. Rather, I noted "If the use of a language can reduce the bottom-line over time, then it gets a great big pat on the back". Stricter overrides would absolutely help out in the short term also, in a vein similar to DbC. The problems induced by a misguided, mistyped, or "I just didn't know" method signature are just as difficult to track down as anything that DbC could help with. If someone likes DbC, I can't imagine why they wouldn't like stricter overrides. As you point out, DbC catches a fair amount of bugs but requires only modest investment. Surely the benefits of stricter overrides require only the most minimal investment one could hope for?

> Unfortunately, it's always those belonging to the minority that are considered as fools no matter how foolish the majority (of developers)
acts.

Right. Those were frustrated and inappropriate comments on my part ... should never have written them.

In article <cdmvs9$4l4$1@digitaldaemon.com>, Juanjo =?ISO-8859-15?Q?=C1lvarez?= says...
>
>Sean Kelly wrote:
>
>> Kind of an aside, but in C++ I always declare methods that override parent methods "virtual" even though the virtual label is inherited.
>
>And I do that too, for exactly the same reasons.

When i learned C++ i thought that the virtual was in the wrong place. Why do i have to guess if a method will be overriden? What i wanted was an "override" keyword. And i guess i still think that way... (Well, i understand that some things are not designed to be overriden, so i am less annoyed now).

The same thought crossed my mind when i learned virtual base classes in C++. Why do i have to design classes to be (multiply) inherited together (instead of correcting the "diamond" only when it happens)? Maybe it's an implementation issue?

First, I realize some "mis-communication": My last post isn't really about
the topic 'mandatory override keyword', and some of my comments are cynic
(beware!).
You are trying to focus the discussion back on topic, but I'm unwilling to
follow you: Matthew already said *everything* that is to say about your
proposal in his first post. So I won't add *anything*.

But I also had the impression your post wasn't restricted about 'override',
either:
<quote>
Anything, and I really do mean *anything*, that a computer language can do
to reduce the element of 'surprise' during that long-drawn-out-phase is a
huge boon in terms of overall productivity and in terms of hard currency.
</quote>
You must be thinking about more than just the 'override' keyword. After
all, the mandatory override keyword, per se, won't generate such great
financial benefits (only minor ones) for commercial projects.
One has to add much more bug-prevention features, to get the huge boon
you'are speaking about. I recommend, reading the 'C# Language Specification',
if you haven't already done so. There are quite some 'features' in there.
Yes, C# has the override keyword, and it is mandatory, of course.


More comments embedded.

> Yes, those managers who wear Crampons to work. Regardless; someone pays the maintenance bills, and who do you think takes responsibility for commercial software after yon clambering manager has moved on to another pinnacle? [...]

I think, that usually *nobody* takes the responsibility for the financial loss. But I know who has to deal with all the messed code, it's always _me_ and other unfortunate individuals.


> Good point. I didn't claim that DbC or stricter overrides were purely about maintainability. Rather, I noted "If the use of a language can reduce the bottom-line over time, then it gets a great big pat on the back". Stricter overrides would absolutely help out in the short term also, in a vein similar to DbC. The problems induced by a misguided, mistyped, or "I just didn't know" method signature are just as difficult to track down as anything that DbC could help with.

Sorry, you've never made such claims about DbC, I've shamelessly put words in your mouth.

<cynic mode again>
I refrain to comment about your estimation about the short term value of
stricter overrides. Just keep on arguing about short term productivity of
stricter overrides, this way, we might get them!
</>


> If someone likes
> DbC, I can't imagine why they wouldn't like stricter overrides.

Because DbC is completely optional, but stricter overrides aren't.


Farmer.

Please forgive the subject title: was being a tad cynical myself.

So; more off topic musings. But really, actually, surreptitiously, on topic;

I thought a little about that "laziness" comment, and realized that the cause is likely to be something else. I'm sure many people on this NG have heard the hoary old line about how software design and construction is somehow "a thin line between art and science". This is a truly wonderful spin! What it apparently implies is that software is somehow mystical: dark shrouded science mixed with creative spices from distant shores, plus some old-fashioned voodoo thrown in for good measure ...

That is just so much BS :-) Sure, sometimes solutions for problems seem to appear from nowhere, or you wake up in the middle of the night with the "perfect answer" in your mind. If you can regularly do that regarding software design, you can do it for any other profession; and more power to you. No; the spin in that line is about a lack of discipline. You don't need to be disciplined to be good at something, but you do need some of it to be /consistently/ good. Creative people generally don't like such shackles. After all, it gets in the way of the creative juices right? In fact, for certain "creative" people I know or have met, almost anything that smacks of discipline gets the finger <g>

It's interesting that the software industry often employs people in powerful positions (less so at the very top) who have absolutely zero self-control. Most of us can probably recount a story about some totally out-of-control, schizophrenic sociopath who makes life truly miserable for coworkers, but whom the board-of-directors either tolerate or bow down to (there seemed to be barrowloads of 'em around in the dot-com heyday). That begs the question: isn't it predominantly a level of discipline that separates the consummate professional from the rank amateur?

I'm tempted to suggest that this creative-versus-disciplined notion plays a significant part in why so much software truly stinks today in terms of reliability. And yet the general consumer seems to take it for granted that their "computing tool" should sometimes require rebooting several times a day. Great marketing. Go figure.

Anyway; the point is that I may have mistaken total laziness for a total lack of discipline. I mean, wouldn't those who view the term "strictness" as a perceived impingement (upon personal creativity) cry out in the loudest terms possible? Perhaps the phrase "stricter application of override" is just inviting trouble based purely upon the choice of words? After all, there is no shackle presented there; no hindrance to language expression.

Perhaps if anyone has to walk that "thin line between art and science" it might be computer language designers ... I mean there has to be a good measure of hard-algorithmic science present, yet somehow taking into account the vagaries of a particular audience section who might just balk at any perception of inhibition. Nasty job. That aside; we all know there's both black-magic and voodoo inside a compiler ...

How about that Walter? Would you prefer to see "less looseness" with respect to override, but are concerned it might upset too many?

:-)

Just a few thoughts. Of course, I could be just wildly wrong on all counts. Back to the cave ...

I've struggled to keep up with the arguments of either you or Farmer; frankly you've both seemed to be more polemic than point, and I really can't divine a definitive position for either of you.

That being said, I think that the issue of language strictness is secondary to the issue of professionalism of the practitioner. If a language is strict, it's easier to write most things well, but far harder to step outside of the constraints when you need to. This is one of the reasons why I suspect C++ has a *very* long future; we see already that there are several ways in which D's eschewal of the preprocessor is causing headaches for many of us. (Note: that's just an example. I don't seek to start a pre-processor argument, and I don't intend to participate in one.)

For my part, the professionalism and the training/experience of the practitioner is far more important. If someone doesn't care about maintainability, their code will not be maintainable. (In fact, it will be shit, and they are the kind of person that should be selling ice-creams on street corners rather than taking part in the most complex activity of man.)

I believe there are a wealth of studies (referenced in "Facts and Fallacies", "The Art Of UNIX Programming" and many other books - you should check for yourselves, given my track record in remembering what book gives what wisdom) that demonstrate that the quality of the software depends on the quality of the programmer up to 10 times more than it does on the language being used.

Not sure what all this means wrt your debate, but at least it lets me spout off like a moaning old git.



"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:cdpui8$1cjq$1@digitaldaemon.com...
> Please forgive the subject title: was being a tad cynical myself.
>
> So; more off topic musings. But really, actually, surreptitiously, on topic;
>
> I thought a little about that "laziness" comment, and realized that the cause is likely to be something else. I'm sure many people on this NG have heard the hoary old line about how software design and construction is somehow "a thin line between art and science". This is a truly wonderful spin! What it apparently implies is that software is somehow mystical: dark shrouded science mixed with creative spices from distant shores, plus some old-fashioned voodoo thrown in for good measure ...
>
> That is just so much BS :-) Sure, sometimes solutions for problems seem to appear from nowhere, or you wake up in the middle of the night with the "perfect answer" in your mind. If you can regularly do that regarding software design, you can do it for any other profession; and more power to you. No; the spin in that line is about a lack of discipline. You don't need to be disciplined to be good at something, but you do need some of it to be /consistently/ good. Creative people generally don't like such shackles. After all, it gets in the way of the creative juices right? In fact, for certain "creative" people I know or have met, almost anything that smacks of discipline gets the finger <g>
>
> It's interesting that the software industry often employs people in powerful positions (less so at the very top) who have absolutely zero self-control. Most of us can probably recount a story about some totally out-of-control, schizophrenic sociopath who makes life truly miserable for coworkers, but whom the board-of-directors either tolerate or bow down to (there seemed to be barrowloads of 'em around in the dot-com heyday). That begs the question: isn't it predominantly a level of discipline that separates the consummate professional from the rank amateur?
>
> I'm tempted to suggest that this creative-versus-disciplined notion plays a significant part in why so much software truly stinks today in terms of reliability. And yet the general consumer seems to take it for granted that their "computing tool" should sometimes require rebooting several times a day. Great marketing. Go figure.
>
> Anyway; the point is that I may have mistaken total laziness for a total lack of discipline. I mean, wouldn't those who view the term "strictness" as a perceived impingement (upon personal creativity) cry out in the loudest terms possible? Perhaps the phrase "stricter application of override" is just inviting trouble based purely upon the choice of words? After all, there is no shackle presented there; no hindrance to language expression.
>
> Perhaps if anyone has to walk that "thin line between art and science" it might be computer language designers ... I mean there has to be a good measure of hard-algorithmic science present, yet somehow taking into account the vagaries of a particular audience section who might just balk at any perception of inhibition. Nasty job. That aside; we all know there's both black-magic and voodoo inside a compiler ...
>
> How about that Walter? Would you prefer to see "less looseness" with respect to override, but are concerned it might upset too many?
>
> :-)
>
> Just a few thoughts. Of course, I could be just wildly wrong on all counts. Back to the cave ...
>
>

Matthew wrote:
> 
> I believe there are a wealth of studies (referenced in "Facts and Fallacies", "The Art Of UNIX Programming" and many
> other books - you should check for yourselves, given my track record in remembering what book gives what wisdom) that
> demonstrate that the quality of the software depends on the quality of the programmer up to 10 times more than it does
> on the language being used.

An excellent book I ran across a few months ago is "Large Scale C++ Software Design."  Reading it really drove home the difference between software engineering and programming.  I must say I'm glad that the dot com boom is over and folks who self-taught themselves to write code by reading "Javascript for Dummies" have mostly moved on to greener pastures.  I got trapped in a contracting job with one such fellow and it was an experience I hope never to repeat.

> Not sure what all this means wrt your debate, but at least it lets me spout off like a moaning old git.

Sometimes that's reason enough it itself :)


Sean

"Matthew" wrote ..

"That being said, I think that the issue of language strictness is secondary to the issue of professionalism of the practitioner. If a language is strict, it's easier to write most things well, but far harder to step outside of the constraints when you need to."

Couldn't agree more, but that's not the point being made re "override" (and I think you know that). Just to be clear for others: the "constraints" you imply one would wish to step beyond could only be bugs in this case. That's not what most sentient developer would refer to as "strict" WRT your above assertion ~ therein lurks a source of unwarranted anxiety.

"Not sure what all this means wrt your debate, but at least it lets me spout off like a moaning old git"

Hey! I thought that was my job today?

I didn't notice there was further debate (actually I failed miserably to comprehend what Farmer's position and point was). This was my personal time for spouting off like a moaning old git, so stop interrupting and get your own thread. Seriously though:  if there were a salient point to these latter musings, then it would have to be a cone of your ice-cream perspective, topped with dollop of lamentful sauce.

- Kris

"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:cdq690$1h8i$1@digitaldaemon.com...
> "Matthew" wrote ..
>
> "That being said, I think that the issue of language strictness is secondary to the issue of professionalism of the practitioner. If a language is strict, it's easier to write most things well, but far harder to step outside of the constraints when you need to."
>
> Couldn't agree more, but that's not the point being made re "override" (and I think you know that). Just to be clear for others: the "constraints" you imply one would wish to step beyond could only be bugs in this case. That's not what most sentient developer would refer to as "strict" WRT your above assertion ~ therein lurks a source of unwarranted anxiety.

Sorry, mate. I think I must have put my dumb head on. I'm really not getting you. I'll leave this one unread, I think, and try again in a few days. ;)

> "Not sure what all this means wrt your debate, but at least it lets me spout off like a moaning old git"
>
> Hey! I thought that was my job today?
>
> I didn't notice there was further debate (actually I failed miserably to comprehend what Farmer's position and point was). This was my personal time for spouting off like a moaning old git, so stop interrupting and get your own thread. Seriously though:  if there were a salient point to these latter musings, then it would have to be a cone of your ice-cream perspective, topped with dollop of lamentful sauce.

Ok.

"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cdq986$1i74$1@digitaldaemon.com...
> Sorry, mate. I think I must have put my dumb head on. I'm really not
getting you. I'll leave this one unread, I think,
> and try again in a few days. ;)

And perhaps I have my dumb ass on  ... not a pretty sight