• Matthew (133/176) Mar 12 2005 Oh really? cast(void*) is only ever going to appear in your cast idiom?
• Ben Hinkle (32/52) Mar 12 2005 I find Walter's posts to be much more reasonable that yours to be honest...
• Regan Heath (11/25) Mar 13 2005 I agree.
• Russ Lewis (16/24) Mar 12 2005 No, actually he's arguing that any serious source analysis on C++ will
• John Reimer (63/73) Mar 12 2005 It's probably not prudent of me to poke my nose into this thread, but I
• Kris (8/13) Mar 12 2005
• Regan Heath (4/24) Mar 13 2005 I'll join you.
• Walter (59/98) Mar 12 2005 Only? No. There will be some false positives, but they'll be mitigated b...
• Kris (19/24) Mar 12 2005 Now, Matthew does have a point here.
• Sean Kelly (5/28) Mar 12 2005 I agree. But it's easier to say that an idea makes sense than it is to ...
• Brad Anderson (11/22) Mar 12 2005 You are more than welcome to set up "moderator-only" forums at

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"Walter" <newshound digitalmars.com> wrote in message 
news:d0u3ht$1kj7$1 digitaldaemon.com...
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:d0tsll$1d22$1 digitaldaemon.com...
 However, you have not addressed the far less equivocal point that

     cast(X)cast(void*)y

 is manifestly less amenable to code analysis tools as

     static_cast(X)y

 If grep is the extent of it, perhaps. I think cast(void*) is eminently
 greppable;

Oh really? cast(void*) is only ever going to appear in your cast idiom?

 you'll get some false positives just like you will with grepping
 for static_cast.

Can you explain how one could get a false positive in grepping for 
static_cast?

 On the other hand, D is far more amenable to real code analysis tools
 because D is parseable at several levels without requiring a full 
 blown
 compiler to do it. Even if you are using a code analysis tool that 
 needs to
 do semantic analysis, it's just a lot easier to do with D than with 
 C++.
 Once you have that, it isn't hard at all to look for a double cast on 
 a
 class reference.

So you're suggesting that any serious source analysis on D will require 
writing an extension to the D compiler, or hook something onto the front 
end, or some such?

Interesting, then, that D is somehow more 'special' than other 
languages, such that people will be inclined to go to that (potentially 
daunting) effort, over and above the eminently effective searches with 
extant tools and techniques used for current languages. (Note, I can 
survive in large part on Visual Studio '98's Find-In-Files for C++!)

 If that still isn't enough, you can always write a template to do it, 
 and
 grep on the template name.


So to analyse an arbitrary set of source code, for which I may not have 
edit rights, for this particular facility I have to analyse it and then 
replace it with something more analysable?

(Then do I check in those changes? Release a patch? Whom do I consult?)





Sorry, Walter, but I just think that your reply is total bullshit. And I 
am dumbfounded as to why that is so. I think you've reached a dogmatic 
position (or, at best, a convincing impression of it) whereby you will 
truculently fight for any position that you've previously been allied 
to. Like a politician, where admission of mistakes is anathema to the 
creed. Truly, though I'm heartened at your recent actions and 
flexibility re warnings and $, your words in this forum seem to be 
getting increasingly bizarre and irrational. Personally, I find it 
incredibly disheartening. I've spent almost all of the last two weeks 
working on things related to D. I don't get paid for it. Neither do 
others, for their similarly large investments of time/effort/passion. 
And when we raise *real* concerns, from a position of wanting to improve 
the language for the *benefit of all*, you don't even have the courtesy 
to treat us with the respect of considered and well reasoned argument. 
All we get is (very low quality) propaganda.

I mean, Bobbing Bleeding Bob, it's like you've taken a trip on some 
weird drug that's locked your brain into a perspective that every 
potential user of D is a compiler writer. They're not!

Just let's look at your responses again:

- "cast(void*) is eminently greppable" - given that the point that I 
raised was that your 'idiom' did not lend itself to reasonable 
unambiguous automated source analysis, you're flat out wrong.

- "static_cast greps will give false positives" - other than if 
Machiavelli was to #define static_cast - which I've _never_ seen or 
heard of - this is patently false.

- "> On the other hand, D is far more amenable to real code analysis 
tools
 because D is parseable at several levels without requiring a full 
 blown
 compiler to do it. Even if you are using a code analysis tool that 
 needs to
 do semantic analysis, it's just a lot easier to do with D than with 
 C++.
 Once you have that, it isn't hard at all to look for a double cast on 
 a
 class reference." - the statement with about the least empathy for 
 normal (i.e. non-compiler / source tool writers users; and let's smell 
 some coffee for a moment and stipulate that this is going to be 95+% 
 of users) that you've come out with in some while. Let's look at a 
 practical example: What if I've gone to the effort of writing myself 
 such a tool which works, right now!, to do such a thing on Win32, but 
 I am at a friend's house, showing them the wonders of D on their Mac. 
 They've only got grep. Your argument is shot to shit, and that's 
 perhaps one less D convert.

- " If that still isn't enough, you can always write a template to do 
it, and grep on the template name." - preposterous circular argument, 
that shows a comtemptible disregard for the needs of writers of 
libraries and users of libraries.


<INTERMEZZO-1>
For anyone who thinks that I get my jollies having a go at Walter, or 
don't respect him, or what not, I'd invite you to consider the conundrum 
that has been puzzling me for the last couple of weeks. As I've said 
elsewhere, I very highly respect most of Walter's opinions on issues 
other than D. Even though Walter has a bias (since he's inventing D) 
against C++, and I have a bias towards it, I find a great many of the 
things he says even about C++ to be very valuable, even more so than 
some (perhaps more famous) experts who are more closely allied to C++ 
than either me or Walter. (The one exception that stands out is the 
issue of 'const', but that may be the exception that proves the rule.)

Given that I have such a high opinion of Walter's programming wit, I 
have been quite puzzled as to why his stance and attitudes on D are so 
frequently at odds with my own. Naturally, there are myriad 
possibilities. I may be subconsciously trying to scupper D. I might like 
the sound of my own voice too much. Maybe I feel that I can criticise D 
because there aren't quite the same number of scary smartarses in this 
ng as you'll find on C++ ngs, and I'm just a secret cowardy custard. 
etc. etc.

I've pondered all these things on my morning bike rides, and have 
seriously considered how it can be that I feel so closely in tune with 
Walter on non-D aspects and so out of tune with him on D. And the only 
explanation that stands up to my own (admittedly partial) reasoning is 
that Walter is not rational wrt D, as a consequence of it being his 
baby, and his having consequently greatly invested himself in it.
</INTERMEZZO-1>


I think D has huge potential. But if feels to me that your attitude of 
defensive-to-beyond-the-point-of-farce is the biggest single obstacle to 
progress - i.e. realisation of a viable 1.0 - at the moment. Either 
you're going to have to admit you're fallible and have made some errors, 
or people like me who are investing huge amounts of time into D are 
going to hit the point where we simply can't bear to bash ourselves on 
the head any longer.


<INTERMEZZO-2>
Let's get our feet back on planet earth and be honest for a moment: 
Everyone who knows anything about software engineering knows that the 
quality of the engineer is always more important than the quality of the 
language. Thus, if you make it too hard for good people to care about 
doing it in D, they'll move on and find something in which they can 
express themselves to an acceptable degree. As I've never tried to hide, 
I barely have anything I want to do for which C++ presents an obstacle 
to its expression. The same can doubtless be said of many/most others 
who are skilled in their particular primary language. Q: If I, with a 
very keen (intellectual _and_ commercial) interest in the success of D, 
consider it not fit for commercial use, how is it going to attract 
people who are far less invested in it? A: It isn't.
</INTERMEZZO-2>

The sad thing is, I reckon every seriously detracting wart/flaw (at 
least that I see) in D - apart from maybe the dynamic class / DLL stuff, 
which I've said before I'd be happy to have in post-1.0 - could be fixed 
in short order. Undoubtedly in less time than has been spent arguing the 
toss and venting frustrations over the past couple of months.



In my opinion we're at to the point where D is either going to have to 
get organised, or it's going to be dumped like a floundering beast. And 
that means the C-word: committee. I've around half a dozen issues that 
I'd like to prepare in the form of language change proposals (as PDFs), 
for serious and considered discussion. But I don't consider it a 
suitable risk/reward for the investment of my time when they're just 
going to be greeted by childish/uninformed input from the peanut gallery 
(which I can easily live with), and either ignored by you or subject to 
the propaganDa machine (which I can't).

I've set aside some months - effectively unpaid - to work with you and 
write the book on D. But I am not going to squander whatever standing I 
have in the 'community' as an author and a software engineer on 
documenting "a very promising language with some ridiculously bad and 
easily avoidable design decisions". Frankly, I'm not prepared to wear 
the embarassment. I acknowledge that we've not (yet) done the systematic 
criticism of the language that we discussed a few months ago, but I'm 
even pretty unwilling to risk the expenditure of time and embark on the 
necessary full and complete digestion of the D spec based on what, from 
your responses on the NG, appears to be an almost total unwillingness to 
admit the possibility of sub-optimal decisions and to explore/effect 
remedies.

Now, this may be seen as a whittering "I'm taking my bat home" spat. If 
it is, so be it. But it's not the case. I want D to succeed as much as 
_anyone_ involved in it - because it promises so much that may yet be 
fulfillable. But as much as I want it to succeed, I have very grave 
doubts that it will, and they're going to have to factor more and more 
into my decisions about how I spend my time.

I recommend that D lose the one-man-bandedness *forthwith*, and become a 
(small and manageable) suite of committees - Language, Phobos, Extension 
Libraries, Tools - over which _you_ preside, and over who's 
recommendations _you_ retain the last word, but to whom _you_ listen 
with a willing ear.


Matthew

"Ben Hinkle" <ben.hinkle gmail.com> writes:

 Sorry, Walter, but I just think that your reply is total bullshit. And I 
 am dumbfounded as to why that is so. I think you've reached a dogmatic 
 position (or, at best, a convincing impression of it) whereby you will 
 truculently fight for any position that you've previously been allied to. 
 Like a politician, where admission of mistakes is anathema to the creed. 
 Truly, though I'm heartened at your recent actions and flexibility re 
 warnings and $, your words in this forum seem to be getting increasingly 
 bizarre and irrational. Personally, I find it incredibly disheartening. 
 I've spent almost all of the last two weeks working on things related to 
 D. I don't get paid for it. Neither do others, for their similarly large 
 investments of time/effort/passion. And when we raise *real* concerns, 
 from a position of wanting to improve the language for the *benefit of 
 all*, you don't even have the courtesy to treat us with the respect of 
 considered and well reasoned argument. All we get is (very low quality) 
 propaganda.

I find Walter's posts to be much more reasonable that yours to be honest. 
Maybe that's just because I prefer his style of conversation. I think 
everyone should read this book called "Difficult Conversations" 
http://www.amazon.com/exec/obidos/ASIN/014028852X/103-2956879-9169443 that 
is basically about how to have a conversation instead of an argument. I 
learned about it through work but it applies to everyday life situations, 
too. One of the key points it makes is that difficult conversations go much 
more smoothly when you get to a common point of agreement and then go from 
there to find where the disagreement lies. Each side needs to understand the 
other side's point of view (and acknowledge it). Conversations are 
opportunites to learn. I find Walter's posts to be more reasonable because 
IMO he does this pretty well.

An earlier post about using a semi-standard or standard mechanism for 
proposing language changes or new features would help. Also trying to give a 
true balanced account about advantages and disadvantages in these proposals 
would help. It's very very tempting to just say how great one's idea is 
without looking at it from other angles.

 I recommend that D lose the one-man-bandedness *forthwith*, and become a 
 (small and manageable) suite of committees - Language, Phobos, Extension 
 Libraries, Tools - over which _you_ preside, and over who's 
 recommendations _you_ retain the last word, but to whom _you_ listen with 
 a willing ear.

Personally I think we should give the "standard proposal" system a shot 
first. Another good book I recently read is "The Wisdom of Crowds" 
http://www.amazon.com/exec/obidos/ASIN/0385503865/103-2956879-9169443. The 
point of that book is that in many situations a better result comes out of a 
large *diverse* group of people than one that comes out of a small group of 
experts. I see the length threads as something like this were we have been 
getting lots of ideas from all kinds of perspectives (C coders, Basic 
coders, Ruby coders, casual users, length proponents, length opponents etc) 
and I doubt a committee would have gotten all those views on the table. 
Design-by-crowd isn't always the right thing to do but I think D is best 
served by getting as many opinions as possible. Sure Walter will be the 
filter at the end and there is always the danger that he will ignore a 
"good" decision by the crowd but I think the chances of him ignoring a few 
"experts" is larger than the chances of him ignoring the newsgroup as a 
whole. 

"Regan Heath" <regan netwin.co.nz> writes:

On Sat, 12 Mar 2005 09:46:31 -0500, Ben Hinkle <ben.hinkle gmail.com>  
wrote:
 I think
 everyone should read this book called "Difficult Conversations"
 http://www.amazon.com/exec/obidos/ASIN/014028852X/103-2956879-9169443  
 that
 is basically about how to have a conversation instead of an argument. I
 learned about it through work but it applies to everyday life situations,
 too. One of the key points it makes is that difficult conversations go  
 much
 more smoothly when you get to a common point of agreement and then go  
 from
 there to find where the disagreement lies. Each side needs to understand  
 the
 other side's point of view (and acknowledge it). Conversations are
 opportunites to learn.

I agree.

Often posts on this NG start from a conclusion or idea. When people  
disagree with that conclusion it's typically because they disagree with  
the reasoning used to reach the conclusion. As such, in order to reach a  
consensus or find the point of difference you have to go back and start  
 from the initial premiss and explain the reasoning step by step. You will  
either convince them, or find the point of difference.

This is known as an "inductive argument".

Regan

Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

Matthew wrote:
 So you're suggesting that any serious source analysis on D will require 
 writing an extension to the D compiler, or hook something onto the front 
 end, or some such?

No, actually he's arguing that any serious source analysis on C++ will 
require that.  Source analysis for D will require much less.

 Interesting, then, that D is somehow more 'special' than other 
 languages, such that people will be inclined to go to that (potentially 
 daunting) effort, over and above the eminently effective searches with 
 extant tools and techniques used for current languages. (Note, I can 
 survive in large part on Visual Studio '98's Find-In-Files for C++!)

Find-In-Files will work in D, just as well as it does in C++.  Walter's 
point is that Find-In-Files and the like are ugly hacks which work 
around the inherent difficulty of parsing C++.  Walter's point is that 
it is *easier* to write a parser for D than it is in C++.  Thus, while 
C++ is stuck with Find-In-Files (or ugly hacks on compilers), D will 
have simple tools that do powerful things.



Speaking personally, Matthew, I really was glad when you joined the 
newsgroup.  Your comments were insightful and helpful.  I don't feel 
that way anymore.  You are a flamer.  You have adopted a "do it my way, 
or you're certain to fail" attitude, and frankly I'm tired of hearing 
it.  Calm down, take a deep breath (or a dozen) and get back to the 
helpful contributor that you used to be.

Russ

John Reimer <brk_6502 yahoo.com> writes:

Russ Lewis wrote:
 Matthew wrote:

<snip>

 
 Speaking personally, Matthew, I really was glad when you joined the 
 newsgroup.  Your comments were insightful and helpful.  I don't feel 
 that way anymore.  You are a flamer.  You have adopted a "do it my way, 
 or you're certain to fail" attitude, and frankly I'm tired of hearing 
 it.  Calm down, take a deep breath (or a dozen) and get back to the 
 helpful contributor that you used to be.
 
 Russ

It's probably not prudent of me to poke my nose into this thread, but I 
feel something should be mentioned here.

I'll start with a silly personal story; you can laugh.. . or, if it 
makes you feel better, roll your eyes a bit.  It goes something like this:

I live with an older brother.  I've lived with him the good portion of 
my life. We've gone to the same school, we've shared the same jobs, and 
we've followed the same "career" path; we've looked out for each other 
through thick and thin.  Most people that don't know us extremely well 
would assume that we've always got along famously.  For the most part, 
we now do, but it certainly hasn't always been that way.  Our 
personalities, you see, are almost exactly opposite.  It's taken 
training and discipline to get used to each other's habits, traits, and 
faults.

One thing that always annoyed me about my brother is that he would never 
realize how angry I was with him until I was near the point of 
"physically" demonstrating the fact to him.  Yelling rarely awakened him 
to the problem at hand.  He was oblivious and remained so in a 
disturbingly calm, undaunted manner.  Further he had a habit of making 
comments about my current condition, such as references to my "temper 
tantrum"; this, naturally, would only fuel the flames.  It used to be 
that yelling was not enough to awaken him to the seriousness of the 
problem.  Now, just a slightly raised voice seems to snap him into acute 
awareness... huge improvement to say the least! (and I've improved in 
anger management too! ;-) )

The point of my story is that some people need to be treated differently 
in order to get their attention (I'm not saying I condone yelling or 
harsh treatment).  Walter seems to be of a fairly "resilient" nature. 
He has often admitted to having thick skin.  It appears he isn't easily 
awakened to problems or acutely aware of what other people see as 
glaringly obvious.  This is where Matthew's personality comes in. 
Matthew is, I think, perfectly matched for Walter.  His diatribes 
(perhaps too strong of a word?), though harsh to many an observer, seem 
to be one of the few things that can pierce Walter's armor, causing him 
to "flinch" enough to re-evaluate his pre-conceived notions.  Without 
Matthew, D would not be where it has been today.

That said, I don't necessarily agree with Matthew's style of persuasive 
argument on this list.  I don't think he's been sensitive in his 
approach many times.  He has often used similar abusive style on those 
that lack the Walter's conditioning.  This has resulted in permanent 
damage and lost community members.  Not everybody can or should be 
treated the same way.

Furthermore, concerning your comment concerning the change in Matthew's 
respectability -- Matthew has not changed; he's always been this way on 
the D newsgroup, and I'm surprised that you don't notice that.  In fact, 
if he has changed, I think he's improved and is showing more humility 
than before.  Discussion is what this group is for, and that is what 
Matthew is here for.  As one Walter appears to respect highly and as the 
person Walter has chosen to co-write the first D language book, Matthew 
has full right to contribute his perspective to this newsgroup, perhaps 
more so than others, don't you think? Has such responsibility been 
invested in him undully?  Has he taken on more responsibility than has 
been proffered him?  No, I don't think so.  Just observe the level of 
involvement Walter has given him in many tasks, and you'll see where he 
stands.

That said, I do hope Matthew continues to tone down his habit of 
deprecation or at least learns to be more sensitive to variances in 
personality (very challenging task, by the way).  I think he's doing a 
great job, aside from several hiccups. ;-)

I might have overstepped an invisible boundary with this post.  If so I 
apologize and step back into the shadows once again.

- JJR

Kris <Kris_member pathlink.com> writes:

In article <d102u7$snn$1 digitaldaemon.com>, John Reimer says...
Russ Lewis wrote:
 Matthew wrote:

<snip>

It's probably not prudent of me to poke my nose into this thread, but I 
feel something should be mentioned here.

<snip>

Posts like this one of John's rarely get a response, for one reason or another.
Whether you support or deny the topic content is neither here nor there; rather;
this post reflects the kind of thoughtful, honest, open, balanced, and I suspect
deliberated, perspective that injects some oft-needed humanity into this NG.
Well said, John.

I'll be the first to stand up and start clapping.

"Regan Heath" <regan netwin.co.nz> writes:

On Sun, 13 Mar 2005 02:13:52 +0000 (UTC), Kris <Kris_member pathlink.com>  
wrote:
 In article <d102u7$snn$1 digitaldaemon.com>, John Reimer says...
 Russ Lewis wrote:
 Matthew wrote:

 <snip>

 It's probably not prudent of me to poke my nose into this thread, but I
 feel something should be mentioned here.

 <snip>

 Posts like this one of John's rarely get a response, for one reason or  
 another.
 Whether you support or deny the topic content is neither here nor there;  
 rather;
 this post reflects the kind of thoughtful, honest, open, balanced, and I  
 suspect
 deliberated, perspective that injects some oft-needed humanity into this  
 NG.
 Well said, John.

 I'll be the first to stand up and start clapping.

I'll join you.

Regan

"Walter" <newshound digitalmars.com> writes:

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d0uifq$2a5o$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:d0u3ht$1kj7$1 digitaldaemon.com...
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:d0tsll$1d22$1 digitaldaemon.com...
 However, you have not addressed the far less equivocal point that
     cast(X)cast(void*)y
 is manifestly less amenable to code analysis tools as
     static_cast(X)y

 If grep is the extent of it, perhaps. I think cast(void*) is eminently
 greppable;

 Oh really? cast(void*) is only ever going to appear in your cast idiom?

Only? No. There will be some false positives, but they'll be mitigated by:
1) cast itself is a keyword and cast expressions are not that common
2) cast(void*) is even far less common, as many of the C++ uses it is put to
are not relevant in D. For example, a pointer to arbitrary data would more
likely be a void[] in D, not a void*.
3) If you're a more sophisticated grep user, it's little trouble to use a
regexp to look for a cast preceding the cast(void*).
4) I regularly use grep as a (primitive) code analysis tool, and don't think
it's a big deal to redirect the output to a file and go through it, visually
disgarding a few irrelvancies.

 you'll get some false positives just like you will with grepping
 for static_cast.

 Can you explain how one could get a false positive in grepping for
 static_cast?

Yes. static_cast is used for more things than just downcasting without a
check. Since types in C++ have a tendency to be layers of typedefs, just
grepping for static_cast in arbitrary C++ code finds all the static_casts,
but then you've got to examine each one and figure out what the types are to
determine if it is a downcast or not. I'd say the latter is not trivial. The
double cast through void*, however, is a pretty strong clue that it's a
downcast.

 On the other hand, D is far more amenable to real code analysis tools
 because D is parseable at several levels without requiring a full
 blown
 compiler to do it. Even if you are using a code analysis tool that
 needs to
 do semantic analysis, it's just a lot easier to do with D than with
 C++.
 Once you have that, it isn't hard at all to look for a double cast on
 a
 class reference.

 So you're suggesting that any serious source analysis on D will require
 writing an extension to the D compiler, or hook something onto the front
 end, or some such?

Serious code analysis tools *do* require some ability to lex and parse. D
makes it particularly easy for tools that only need to parse, because D can
be parsed without needing a full compiler to back it up. Doing a complete
and correct lexer/parser for D is under 10,000 lines of code, and a complete
working example usable as a guide comes with the compiler. Doing it for C++
is 100 times harder (and that's being generous) because C++ cannot be parsed
without writing a full blown front end.

Of course, one can make approximate C++ code parsing tools with much less
effort, and people do write such tools. They're an endless support problem
for the vendor, though, because they simply don't do the language 100%. I've
never seen a syntax highlighter for C++ that couldn't be easilly tricked
into making a hash of it.

Do you ever wonder why, after 20 years of development of C++ tools, we're
both still using grep as our serious source code analysis tool? Why are the
tools for Java so much better?

 Interesting, then, that D is somehow more 'special' than other
 languages, such that people will be inclined to go to that (potentially
 daunting) effort, over and above the eminently effective searches with
 extant tools and techniques used for current languages. (Note, I can
 survive in large part on Visual Studio '98's Find-In-Files for C++!)


code <g>. (Both use C-style casting syntax.) Both do a runtime check on the
cast for downcasting, as does D. D offers a way to escape the runtime check

D is out of step with current language design thinking. It's superior to the

it does offer an escape for more advanced programmers who need efficiency.

 If that still isn't enough, you can always write a template to do it,
 and
 grep on the template name.

 So to analyse an arbitrary set of source code, for which I may not have
 edit rights, for this particular facility I have to analyse it and then
 replace it with something more analysable?

That's the case with C++'s support for C-style casts. Those (as we've
discussed in the past) are not greppable in any reasonable way, and are not
findable without applying a real C++ compiler front end to it. If you are
given some arbitrary piece of C++ code, there's no way you can guarantee it
isn't doing downcasting C-style casts using grep or really any tool other
than DMC++. So, you're *already* relying on C++ programmers sticking to the
convention of using static_cast rather than C-style casts.

I suggest that the double cast idiom in D is:
1) only marginally less greppable than static_cast
2) once found, is easier to determine if it is doing a suspicious downcast
or not
3) isn't going to be confused with a cast between floats and integers
4) there are no worries about overlooked C-style casts
5) can't be obfuscated away with stupid preprocessor macros (yes, I know no
programmer in their right mind would do that, but the fact it is possible is
what gives C++ source code analyzers fits)
6) taking it to the next level beyond grep is nowhere near as difficult as
it is with C++

Kris <Kris_member pathlink.com> writes:

In article <d0uifq$2a5o$1 digitaldaemon.com>, Matthew says...
<snip>
I recommend that D lose the one-man-bandedness *forthwith*, and become a 
(small and manageable) suite of committees - Language, Phobos, Extension 
Libraries, Tools - over which _you_ preside, and over who's 
recommendations _you_ retain the last word, but to whom _you_ listen 
with a willing ear.


Now, Matthew does have a point here. 

An NG does not represent an ideal place to get convergence on any given topic
(take a look at /. for glittering examples :-) 

On the other hand, committees can perhaps be viewed as being a bit elitist, and
possibly being a little narrow-minded.

But there /is/ a problem here. The sheer quantity of recent "$ or length"
postings do identify a growing number of participants, and while the perspective
did seem to finally converge upon one approach (rather unusual in itself), who
picks up the ball from that point? 

Anyone who says "Walter", has not been here long enough ~ there's far too many
damn balls for one person to hold onto :)

An intermediary group would make a lot of sense and, if it happened, would be a
good exercise in collaboration. There's no reason why topics wouldn't continue
to be bantered about in the manner they are now, so everyone would still get
their say.

I'll second that call for a (non-closed) 'committee'.

- Kris

Sean Kelly <sean f4.ca> writes:

In article <d108s4$115d$1 digitaldaemon.com>, Kris says...
In article <d0uifq$2a5o$1 digitaldaemon.com>, Matthew says...
<snip>
I recommend that D lose the one-man-bandedness *forthwith*, and become a 
(small and manageable) suite of committees - Language, Phobos, Extension 
Libraries, Tools - over which _you_ preside, and over who's 
recommendations _you_ retain the last word, but to whom _you_ listen 
with a willing ear.

Now, Matthew does have a point here. 

An NG does not represent an ideal place to get convergence on any given topic
(take a look at /. for glittering examples :-) 

On the other hand, committees can perhaps be viewed as being a bit elitist, and
possibly being a little narrow-minded.

But there /is/ a problem here. The sheer quantity of recent "$ or length"
postings do identify a growing number of participants, and while the perspective
did seem to finally converge upon one approach (rather unusual in itself), who
picks up the ball from that point? 

Anyone who says "Walter", has not been here long enough ~ there's far too many
damn balls for one person to hold onto :)

An intermediary group would make a lot of sense and, if it happened, would be a
good exercise in collaboration. There's no reason why topics wouldn't continue
to be bantered about in the manner they are now, so everyone would still get
their say.

I'll second that call for a (non-closed) 'committee'.

I agree.  But it's easier to say that an idea makes sense than it is to execute
it.  For this to work, there almost has to be some structure just to keep people
involved.


Sean

Brad Anderson <brad dsource.dot.org> writes:

Sean Kelly wrote:
I'll second that call for a (non-closed) 'committee'.

 
 
 I agree.  But it's easier to say that an idea makes sense than it is to execute
 it.  For this to work, there almost has to be some structure just to keep
people
 involved.
 
 
 Sean
 

You are more than welcome to set up "moderator-only" forums at 
dsource.org so the topics can remain focused, and the initial post in a 
topic could be a PEP-like description with discussion in the following 
posts.

If you want to keep it non-closed, then make it a public or 
registered-users-only forum but diligently moderate it...

I can set up a separate area of the forums for these 
committees/proposals, or I could even set up another main area of the 
site (top tab) with a dedicated instance of phpBB.

BA