www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Time to get committeed, or get off. [WAS Re: Writing C in D]

reply "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
Mar 12 2005
next sibling parent reply "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.
Mar 12 2005
parent "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
Mar 13 2005
prev sibling next sibling parent reply 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
Mar 12 2005
parent reply 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
Mar 12 2005
parent reply 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.

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.
Mar 12 2005
parent "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.

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
Mar 13 2005
prev sibling next sibling parent "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

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.

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.

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++!)

I challenge you to use grep to find cast expressions in C# and Java source 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 with the double cast idiom; Java and C# do not. So, no, I do not agree that D is out of step with current language design thinking. It's superior to the Java and C# method in that it *is* greppable, and it's superior in the way 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.

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++
Mar 12 2005
prev sibling parent reply 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
Mar 12 2005
parent reply 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
Mar 12 2005
parent 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
Mar 12 2005