Polishing D - suggestions and comments

[Unknown W. Brackets]

Yes, of course.... but that's what specialization is all about!  I may 
know a thing or two about the web, but I could never begin to write a 
programming language.  Closest I can get is a low-end scripting 
language.  Growing a project is all about getting people with good 
skills together.

To add user comments to the site, the Ddoc-generated files could be 
output to template files (read: no differently), which might then be 
used by a system which would interpolate those with user-comments.

There's no reason you would need to change your process.  There's no 
reason the documentation has to be dynamic any differently than it 
already is (Ddoc is a part of D, after all, and a good one at that.)

Vandalism can be handled by moderators.  Likely, with a situation like 
this, comments would not become public until they were approved.  Also, 
with the right server- and client-side coding, spam can be minimized. 
It really would only take maybe three people checking each once a day 
and that would probably be well-sufficient for the time being.

I am by no means suggesting you need to throw everything out the window 
and start doing things some strange way.  After all, I wouldn't do that. 
  But a little interactivity can go a long way.

-[Unknown]


Walter Bright wrote:
> I'm sure it is easy for someone who has done a lot of this stuff. But 
> it's all new to me.
> 
> Right now, the pages are all generated from Ddoc source files according 
> to macros. Redoing the macros and style sheets would transform the site 
> without needing to rewrite any of the content.
> 
> Putting user content on there is another problem, though, because 
> someone would have to regularly cull the spam and vandalism from it.
> 
> The "archives" pages are all generated by a custom D program that reads 
> the newsgroup files and generates the corresponding html page.
> 
> Unknown W. Brackets wrote:
>> Speaking as a professional at what you're talking about, there's not a 
>> chance it would.
>>
>> I will say that the company I work for would ask no less than $40k to 
>> do a site like digitalmars.com/d, but that's still only 400 hours of 
>> work (give or take.)  After that you're normally talking about it 
>> reading a database, files or protocols from other softwares, or even 
>> flat files for those who like that.... and that is something anyone 
>> can do.
>>
>> Even if it did require a part time, or even full time, position in 
>> itself - if that's what D needs, why is that a problem?  I can 
>> guarantee you that you'll find enough volunteers if you're worried 
>> about cost.
>>
>> If you're worried about efficiency, I've worked on stuff that've gone 
>> on ABC's website etc., and I can promise you this is a solved problem 
>> as well.  Sure, it has to be done right, but this is true of anything.
>>
>> Just my opinion.
>>
>> -[Unknown]
>>
>>
>> Walter Bright wrote:
>>> Unknown W. Brackets Wrote:
>>>> As a side note, I work for a web company, and we use PHP primarily
>>>> - which language I do like.  But it would be cool to see D eat its
>>>> own dogfood here, and host the website on its own, lightweight
>>>> webserver with D-coded dynamic pages.  This wouldn't be hard to
>>>> write at all, and would really show the versatility of D (as well
>>>> as efficiency, assuming it handled load well.)  Maybe not
>>>> practically the best, though.
>>>
>>> The web pages are all static. Not that they have to be, but doing a 
>>> dynamically generated site the size of digitalmars.com would probably 
>>> be a full time job in itself.