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


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


 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


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

The guy who invented a linkage for automatic valves for steam engines


 the guy who's job was to run up and down a ladder opening and closing


 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