www.digitalmars.com         C & C++   DMDScript  

D - Lazy compiler writers

reply Russell Bornschlegel <kaleja estarcion.com> writes:
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
Aug 20 2001
next sibling parent Jan Knepper <jan smartsoft.cc> writes:
 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.


I don't either... If you want the STL stuff:
news://news.digitalmars.com/c++.stl/


 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.


Agreed!


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


Have you ever compared the compile time of Digital Mars C++ with ANY
other??? <g>
D is gonna be scary!!!
I am sure that programmers are going to wonder if the compiler actually
did something!!!
Kinda the feeling that it compiled BEFORE you hit the <Enter> key! <g>


 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?


It has many pro's just as VB has many pro's because of which it is
widely used. Except it's a lot better than VB! <g>
The con's are partially those that VB also has... I guess.

Jan
Aug 20 2001
prev sibling next sibling parent reply Axel Kittenberger <axel dtone.org> writes:
 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:
 


Well in my eyes this aren't new news. I think this again the old Pascal vs 
C conflict in disquise. Wirth beside Pascal father of a set of programming 
languages always had the strict ideal to keep the language simple as it can 
be. He used to define an absolut minimum set of language constructs with 
which you can do anything with, altough some tasks require more steps at it 
would have been in another language. While other languages which where 
designed by comitee's and standard instutues where created by compromise on 
a lot of different interests, and are blown of features and valid language 
structure.

Pascal was also designed with the compiler in mind. An avarage Pascal 
compiler compiles 10 times faster as an avarage C compiler, and this only 
counts ~source lines/sec. And doesn't even count the include files C 
compilers spend again and again and again time on. I don't want to know how 
often my "stdio.h" was parsed in sum :o) while Pascal was far more 
effective in this regard. 

I used to write VC++ application and on my old Pentium 100 a first build 
(or complete rebuild) of an average sized application could take up nearly 
15 minutes. Was always a good time to get coffee and to chit-chat a little. 
When I wrote a ~equantly sized Delphi I hit the first time on "compile", 
stood up to get coffee, and even before I was completly standing the mean 
compiler made already <PING> build complete. So pascal is coffee unfriendly 
:o)

However compilers have different ends you can concentrate on, but as sad it 
may sound, compile time is in common a low priority. Most people will 
sacrifice compiletime for runtime, for ease of use, for mature warnings, 
for having them write less (characters), for beeing more standard conform, 
etc.

- Axel
Aug 20 2001
parent reply "Walter" <walter digitalmars.com> writes:
The difficulty with Pascal is it's designed as a teaching language, not a
production one.

Axel Kittenberger wrote in message <9lrlos$10k1$1 digitaldaemon.com>...

 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:


Well in my eyes this aren't new news. I think this again the old Pascal vs
C conflict in disquise. Wirth beside Pascal father of a set of programming
languages always had the strict ideal to keep the language simple as it can
be. He used to define an absolut minimum set of language constructs with
which you can do anything with, altough some tasks require more steps at it
would have been in another language. While other languages which where
designed by comitee's and standard instutues where created by compromise on
a lot of different interests, and are blown of features and valid language
structure.

Pascal was also designed with the compiler in mind. An avarage Pascal
compiler compiles 10 times faster as an avarage C compiler, and this only
counts ~source lines/sec. And doesn't even count the include files C
compilers spend again and again and again time on. I don't want to know how
often my "stdio.h" was parsed in sum :o) while Pascal was far more
effective in this regard.

I used to write VC++ application and on my old Pentium 100 a first build
(or complete rebuild) of an average sized application could take up nearly
15 minutes. Was always a good time to get coffee and to chit-chat a little.
When I wrote a ~equantly sized Delphi I hit the first time on "compile",
stood up to get coffee, and even before I was completly standing the mean
compiler made already <PING> build complete. So pascal is coffee unfriendly
:o)

However compilers have different ends you can concentrate on, but as sad it
may sound, compile time is in common a low priority. Most people will
sacrifice compiletime for runtime, for ease of use, for mature warnings,
for having them write less (characters), for beeing more standard conform,
etc.

- Axel
Aug 20 2001
parent Jan Knepper <jan smartsoft.cc> writes:
Walter wrote:


 The difficulty with Pascal is it's designed as a teaching language, not a
 production one.


Yeah... I seem to remember they thought me that Pascal was designed to fit into
a PSD....
Jan
Aug 20 2001
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
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
Aug 20 2001
next sibling parent reply Russell Bornschlegel <kaleja estarcion.com> writes:
Walter wrote:

 
 By jove, I think he's got it! -Walter
 


Well sure, a lazy compiler writer like you is gonna say that.

/me cracks whip

Get back to work!

-RB
Aug 20 2001
parent reply "Walter" <walter digitalmars.com> writes:
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>.
Aug 20 2001
parent reply Russell Bornschlegel <kaleja estarcion.com> writes:
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
Aug 20 2001
next sibling parent "Walter" <walter digitalmars.com> writes:
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
Aug 20 2001
prev sibling parent "Johan Bryssling" <johan.bryssling micronet.se> writes:
 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
Aug 21 2001
prev sibling next sibling parent Jan Knepper <jan smartsoft.cc> writes:
Walter wrote:


 By jove, I think he's got it! -Walter


<VBG>
Aug 20 2001
prev sibling parent Charles Hixson <charleshixsn earthlink.net> writes:
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
Aug 21 2001