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

> 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

> 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

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

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

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

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

Walter wrote:

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

<VBG>

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

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