"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:cdqa5c$1iig$1@digitaldaemon.com...
> "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

Euch! That's conjuring all kinds of nasty images. Please desist!

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. 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.)
> 

The preprocessor thing kind of peaks my interest in the sense of why it would be giving problems.  Having worked without one for so long it makes me think why one would want the preprocessor.  In my knowlege, the only reasons for the precompiler are:

1) protect from double include.  Fixed by "import"

2) Override implementation of method.  That's evil, and a source of
   maintenance hell (so is it the system printf I'm using or the one in
   another library?).  Simple, don't do it.

3) Define constants or magic numbers.  Fixed by "const" or "final"

4) Conditional compilation.  Fixed by "version"

4) Define "macros".  Thought was that templated functions could solve
   this, but perhaps there might be a need for a language supported
   macro language?

What other possible need would there be for the preprocessor?  (A
well versed Java programmer asks.)  The only time I was tempted to have
one for Java, the "version" keyword in D would have solved my problem.

"Berin Loritsch" <bloritsch@d-haven.org> wrote in message news:cdr427$1usb$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. 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.)
> >
>
> The preprocessor thing kind of peaks my interest in the sense of why it would be giving problems.  Having worked without one for so long it makes me think why one would want the preprocessor.  In my knowlege, the only reasons for the precompiler are:
>
> 1) protect from double include.  Fixed by "import"
>
> 2) Override implementation of method.  That's evil, and a source of
>     maintenance hell (so is it the system printf I'm using or the one in
>     another library?).  Simple, don't do it.
>
> 3) Define constants or magic numbers.  Fixed by "const" or "final"
>
> 4) Conditional compilation.  Fixed by "version"
>
> 4) Define "macros".  Thought was that templated functions could solve
>     this, but perhaps there might be a need for a language supported
>     macro language?
>
> What other possible need would there be for the preprocessor?  (A
> well versed Java programmer asks.)  The only time I was tempted to have
> one for Java, the "version" keyword in D would have solved my problem.

I did say: "I don't seek to start a pre-processor argument, and I don't intend to participate in one", but I'm not surprised that I was not believed.

The most recent problem this has caused is while trying to get some Doxygen documentation for DTL, in order to release it in a format that stands a chance of being understood. Since Doxygen can use the preprocessor, and D uses version statements, whole swathes of the DTL code is skipped. I can think of no simple way to resolve this problem.

And that's my final word on the subject, since there's precisely 0% chance of the preprocessor being added! :-)

Matthew wrote:

<snip/>

> I did say: "I don't seek to start a pre-processor argument, and I don't intend to participate in one", but I'm not
> surprised that I was not believed.

sorry, it was not my intention to make you a liar.  :(

> 
> The most recent problem this has caused is while trying to get some Doxygen documentation for DTL, in order to release
> it in a format that stands a chance of being understood. Since Doxygen can use the preprocessor, and D uses version
> statements, whole swathes of the DTL code is skipped. I can think of no simple way to resolve this problem.
> 
> And that's my final word on the subject, since there's precisely 0% chance of the preprocessor being added! :-)

I see.  It's not so much preprocessor as another tool used for documentation purposes?  I assume Doxygen is generating more output than  is actually represented in the compiled D code?

Maybe there is a need for the euiv. to JavaDoc--that understands the D language and only outputs the comments necessary for the compiled unit?

"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in news:cdq690$1h8i$1@digitaldaemon.com:


> I didn't notice there was further debate (actually I failed miserably to comprehend what Farmer's position and point was).
[snip]

I agree. And admittedly, it's my fault that there wasn't a debate. Because I deliberately try to not reveal my position on the 'strict override' matter.

BTW, I think my posts read quite like the typical unmaintainable (code) mess:
- intentions remain completely mysterious to everyone
- only the one who wrote it, understands it
- after three days, even the one who wrote it, doesn't understand it
- the one who wrote it, has written it in a language that he doesn't
understand ;-)



Farmer.

"Farmer" wrote ..
> "Kris"  wrote
>
> > I didn't notice there was further debate (actually I failed miserably to comprehend what Farmer's position and point was).
> [snip]
>
> I agree. And admittedly, it's my fault that there wasn't a debate. Because
I
> deliberately try to not reveal my position on the 'strict override'
matter.
>
> BTW, I think my posts read quite like the typical unmaintainable (code)
mess:
> - intentions remain completely mysterious to everyone
> - only the one who wrote it, understands it
> - after three days, even the one who wrote it, doesn't understand it
> - the one who wrote it, has written it in a language that he doesn't
> understand ;-)

That's cool Farmer. In the spirit of comradery (and a tip of the hat to James McComb) I repost my earlier drivel, but in a more understandable form:

 I dought some little about dat "laziness" comment, and realized dat de
cause be likesly t'be sump'n else. I'm sho' man many sucka's on dis NG gots
heard da damn ho'y old line about how software design and construcshun is
somehow "a din line between art and science". Dis be a truly wonderful spin!
Right on! Whut it apparently implies be dat software be somehow mah'stical,
dig dis: dark shrouded science mixed wid creative spices fum distant sho'es,
plus some old-fashioned voodoo drown in fo' baaaad measho' man ... Dat be
plum so much BS :-) Sho' man, sometimes solushuns fo' problems seem to
appear fum nowhere, o' ya' wake down in de middle uh de night wid de
"puh'fect answer" in yo' mind. If ya' kin regularly do dat regardin'
software design, ya' kin do it fo' any oda' profession; and mo'e powa' to
ya'. No; de spin in dat line be about some lack uh discipline. You's duzn't
need to be disciplined t'be baaaad at sump'n, but ya' do need some uh it
t'be /consistently/ baaaad. Creative sucka's generally duzn't likes such
shackles. Afta' all, it digs in de way uh de creative juices right? In fact,
fo' certain "creative" sucka's ah' know o' gots met, mos' nuthin dat smacks
of discipline digs de fin'a' It's interestin' dat da damn software industry
often employs sucka's in powerful posishuns (less so's at da damn very top)
who gots absolutely zero self-control. Most uh us kin probably recount some
sto'y about some totally out-of-control, schizophrenic sociopad who makes
life truly miserable fo' cowo'kers, but whom de bo'd-of-directo's eida'
tolerate o' bow waaay down t'(dere seemed to be barrowloads uh 'em around in
de dot-com heyday). Dat begs de quesshun: ain't it predominantly some level
uh discipline dat separates de consummate professional fum de rank beginna'?
I'm tempted t'suggest dat dis creative-versus-disciplined noshun plays a
significant part in why so's much software truly stinks today in terms of
reliability. Slap mah fro! And yet da damn general consuma' seems t'snatch
it fo' granted dat deir "computin' tool" should sometimes require rebootin'
several times a day. Slap mah fro! Great marketin'. Go figure. Anyway; de
point be dat ah' may gots missnatchn total laziness fo' some total lack uh
discipline. ah' mean, wouldn't dose who view de term "strictness" as a
puh'ceived impin'ement (upon sucka'al creativity) cry out in de loudest
terms possible? Perhaps de phrase "stricta' applicashun uh override" is plum
invitin' trouble based purely downon de choice uh wo'ds? Afta' all, dere be
no shackle presented dere; no hindrance t'language 'espression. 'S coo',
bro. Perhaps if any sucka gots'ta walk dat "din line between art and
science" it might be clunker language designers ... ah' mean dere gots'ta be
some baaaad measho' man uh hard-algo'idmic science present, yet somehow
takin' into account de vagaries uh a particular audience secshun who might
plum balk at any puh'cepshun uh inhibishun. Nasty job. Co' got d' beat! Dat
aside; we all know dere's bod black-magic and voodoo inside some compila'
... How about dat Walter? Would ya' prefa' to see "less looseness" wid
respect to override, but is concerned it might downset too many? Just some
few doughts. Of course, ah' could be plum wildly wrong on all counts.
Back t'de cave ...

On Sat, 24 Jul 2004 00:19:57 +1000, Matthew <admin.hat@stlsoft.dot.org> wrote:

> "Berin Loritsch" <bloritsch@d-haven.org> wrote in message news:cdr427$1usb$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. 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.)
>> >
>>
>> The preprocessor thing kind of peaks my interest in the sense of why it
>> would be giving problems.  Having worked without one for so long it
>> makes me think why one would want the preprocessor.  In my knowlege, the
>> only reasons for the precompiler are:
>>
>> 1) protect from double include.  Fixed by "import"
>>
>> 2) Override implementation of method.  That's evil, and a source of
>>     maintenance hell (so is it the system printf I'm using or the one in
>>     another library?).  Simple, don't do it.
>>
>> 3) Define constants or magic numbers.  Fixed by "const" or "final"
>>
>> 4) Conditional compilation.  Fixed by "version"
>>
>> 4) Define "macros".  Thought was that templated functions could solve
>>     this, but perhaps there might be a need for a language supported
>>     macro language?
>>
>> What other possible need would there be for the preprocessor?  (A
>> well versed Java programmer asks.)  The only time I was tempted to have
>> one for Java, the "version" keyword in D would have solved my problem.
>
> I did say: "I don't seek to start a pre-processor argument, and I don't intend to participate in one", but I'm not
> surprised that I was not believed.
>
> The most recent problem this has caused is while trying to get some Doxygen documentation for DTL, in order to release
> it in a format that stands a chance of being understood. Since Doxygen can use the preprocessor, and D uses version
> statements, whole swathes of the DTL code is skipped. I can think of no simple way to resolve this problem.
>
> And that's my final word on the subject, since there's precisely 0% chance of the preprocessor being added! :-)

Hooray for that.

I wonder how long it would take a sufficiently motivated/talented person to write a documentation tool in D, for D...

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/