• Tim Matthews (2/2) Oct 11 2009 Don't know if it has already been posted:
• Walter Bright (2/6) Oct 11 2009 I gotta get some new duds :-)
• Jeremie Pelletier (8/15) Oct 11 2009 Funny how you mention the 'for(...); dosomething();' problem in C
• bearophile (8/11) Oct 11 2009 No posted yet, thank you.
• Tim Matthews (9/16) Oct 12 2009 I wouldn't want the language to be too different though. Maybe a subset
• bearophile (5/6) Oct 12 2009 I agree.

Tim Matthews <tim.matthews7 gmail.com> writes:

Don't know if it has already been posted:

http://www.simple-talk.com/opinion/geek-of-the-week/walter-bright-geek-of-the-week/

Walter Bright <newshound1 digitalmars.com> writes:

Tim Matthews wrote:
 Don't know if it has already been posted:
 
 http://www.simple-talk.com/opinion/geek-of-the-week/walter-brig
t-geek-of-the-week/ 
 

I gotta get some new duds :-)

Jeremie Pelletier <jeremiep gmail.com> writes:

Walter Bright wrote:
 Tim Matthews wrote:
 Don't know if it has already been posted:

 http://www.simple-talk.com/opinion/geek-of-the-week/walter-brig
t-geek-of-the-week/ 

 
 I gotta get some new duds :-)

Funny how you mention the 'for(...); dosomething();' problem in C 
because I just came across this on the daily wtf:

How to prevent for-loops from boundary overrun?

     for (int i=0;i<max; i++) {
      ...
     } while(0);

You can add that to the list of mistakes D prevents :)

bearophile <bearophileHUGS lycos.com> writes:

Tim Matthews:
 Don't know if it has already been posted:
 http://www.simple-talk.com/opinion/geek-of-the-week/walter-bright-geek-of-the-week/

No posted yet, thank you.
The text is very good, and it puts both D and Walter in a wonderful light. The
nicest interview to Walter I've seen so far. I'll let some friends of mine read
this text!

Just a note:
What are the application areas that D targets? WB: In short, any application
that would otherwise use C or C++ would be suitable for D.<

That may become true in future, but it can't be true now. If I buy an Arduino,
or a little 16 bit CPU that has to go inside a cheap microwave oven, I usually
have to program it in C, Forth (or worse). I can't use D for that. Currently D
is not fit for the world of small real-time CPUs. And embedded CPUs are very
common, for every desktop (and handheld) CPU produced, 10 or 100 small CPUs for
embedded purposes are produced.

But there are possible ways to make D fitter for those purposes. For example it
may be designed a "lightD", a subset of D (that has no built-in AAs, that uses
no GC, etc), and adds several tricks/constructs useful when your available RAM
is 1200 bytes long and your available ROM (well, flash, or a different slower
kind of RAM) is 30000 bytes. In such situations a compiler is even asked to
produce not just the faster or shorter binary, but sometimes even the less
energy consuming one! (think about a -Oe compilation flag, beside the -O and
the -Os). Or maybe D will never fit for such purposes. 

Bye,
bearophile

Tim Matthews <tim.matthews7 gmail.com> writes:

bearophile wrote:

 Just a note:
 What are the application areas that D targets? WB: In short, any application
that would otherwise use C or C++ would be suitable for D.<

 
 That may become true in future, but it can't be true now. If I buy an Arduino,
or a little 16 bit CPU that has to go inside a cheap microwave oven, I usually
have to program it in C, Forth (or worse). I can't use D for that. Currently D
is not fit for the world of small real-time CPUs. And embedded CPUs are very
common, for every desktop (and handheld) CPU produced, 10 or 100 small CPUs for
embedded purposes are produced.
 
 But there are possible ways to make D fitter for those purposes. For example
it may be designed a "lightD", a subset of D (that has no built-in AAs, that
uses no GC, etc), and adds several tricks/constructs useful when your available
RAM is 1200 bytes long and your available ROM (well, flash, or a different
slower kind of RAM) is 30000 bytes. In such situations a compiler is even asked
to produce not just the faster or shorter binary, but sometimes even the less
energy consuming one! (think about a -Oe compilation flag, beside the -O and
the -Os). Or maybe D will never fit for such purposes. 
 

I wouldn't want the language to be too different though. Maybe a subset 
runtime (with gc off by default) + std lib though (subset of existing 
and not really a third choice of library). Call just about anything in 
tango and you get an allocation, no explicit delete and an assumption 
that the GC will take care of it eventually.

Aswell as the embedded, regular operating systems are a big area of 
C/C++. This should be an easier fit for D but all D kernel/os projects 
have probably been abandoned.

bearophile <bearophileHUGS lycos.com> writes:

Tim Matthews:

 I wouldn't want the language to be too different though.

I agree.
But it will take some work to have a D compiler able to produce uncompressed
binaries 2500 bytes long that at runtime use 500 bytes of RAM to do something
useful :-)

Bye,
bearophile