I haven't followed Perl 6, and so any similarities are entirely coincidental. -Walter

Russell Bornschlegel wrote in message <3B81D17D.F9CCF518@estarcion.com>...
>Walter wrote:
>>
>> Russell Bornschlegel wrote in message
<3B81C8A0.4BC18B40@estarcion.com>...
>> >Well sure, a lazy compiler writer like you is gonna say that.
>>
>> The guy who invented a linkage for automatic valves for steam engines was the guy who's job was to run up and down a ladder opening and closing
valves
>> for each cycle of the piston.
>>
>> He jury rigged up a linkage and took to sleeping on the job <g>.
>
>Don't get me wrong, laziness is one of the three great programming virtues.
>
>Speaking of which, are you following the evolution of Perl 6 at all? One or two of the things you're leaning towards in D remind me of probable features for Perl 6, and I'm curious as to whether that's coincidental or intentional parallel evolution.
>
>The Perl 6 Apocalypses are at:
>
>http://perl.com/pub/au/Wall_Larry
>
>-RB

> Dont get me wrong, laziness is one of the three great programming

> virtues.



*laught* :-)

I just must comment that, even if it hasnt much to do with PERL 6.0.

Thats right. If D comes out right and is widely used in the future the people are going to demand (easy-use) stuff like:

Webserver-classes, Operativ-system-classes *giggle* , XML parsers, HTML-parsers, security-classes(DES, MD5,...), Secure socket layer, SMTP-classes, blah, ... just like in Java...

....or they (the companies) will discard it due to "cost-inefficent"
development.

Like:

Windows98 *win = new Windows98("Please_dont_crash_mode");

win -> start();

or

Webserver *myWebby = new Webserver(2893);

myWebby -> start();

*laught*

But who do you think do all that stuff that everyone uses?

Hmmmm... could it be someone like me??.. An hardworking moron... ;-)

People are truely mega-lazy but someone has to do the stuff behind it or should all wait until the next version of hype-XLT-mega-parser arrives? *evil laught*

regards

Johan Bryssling , Software engineer, Micronet

ps. I think the discussion of D are interesting and will follow it closely. You have lot of work ahead of you, even if you can link to C-libraries.

"Russell Bornschlegel" <kaleja@estarcion.com> wrote in message news:3B81D17D.F9CCF518@estarcion.com...
> Walter wrote:
> >
> > Russell Bornschlegel wrote in message
<3B81C8A0.4BC18B40@estarcion.com>...
> > >Well sure, a lazy compiler writer like you is gonna say that.
> >
> > The guy who invented a linkage for automatic valves for steam engines
was
> > the guy who's job was to run up and down a ladder opening and closing
valves
> > for each cycle of the piston.
> >
> > He jury rigged up a linkage and took to sleeping on the job <g>.
>
> Don't get me wrong, laziness is one of the three great programming virtues.
>
> Speaking of which, are you following the evolution of Perl 6 at all? One or two of the things you're leaning towards in D remind me of probable features for Perl 6, and I'm curious as to whether that's coincidental or intentional parallel evolution.
>
> The Perl 6 Apocalypses are at:
>
> http://perl.com/pub/au/Wall_Larry
>
> -RB

And it needs to be designed so that "reasonable" design changes can be made without having to redo the whole thing!  Nobody get anything at all complex right the first time.

Walter wrote:
> By jove, I think he's got it! -Walter
> 
> Russell Bornschlegel wrote in message <3B814024.902692D7@estarcion.com>...
> 
>>Well, I poked my nose into the thread in the Borland cppbuilder ng
>>that Jan mentioned, and saw a lot of flamage, and decided that I
>>didn't need to go there.
>>
>>However, some people seemed to be making the argument that making
>>language design decisions on the merits of ease of compilation was
>>a Bad Thing. I'm not so sure of this. Here are some points in favor:
>>
>>- A language that's simpler to implement is simpler to document and
>>to understand accurately. This has all sorts of cascade effects:
>>easy to teach and learn, less programmer time spent looking up
>>obscurities, etc.
>>
>>- A language that's simpler to implement is more likely to be
>>implemented correctly. A language that can be implemented by one
>>individual reduces the problems of miscommunication within the
>>development team. (Plus, if Walter remembers to take this ng with a
>>grain of salt, he can avoid "language committeisms".)
>>
>>- "This should be a smokin' fast compiler." Small, too.
>>
>>This isn't to say that any given feature should be left out because
>>it's "too hard", but my feeling is that an internally elegant
>>compiler will have beneficial effects on the outside. Anyone else
>>have pros or cons to offer?
>>
>>
>>-Russell B
>>
> 
>