www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Geek of the week

reply 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/
Oct 11 2009
next sibling parent reply 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 :-)
Oct 11 2009
parent 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 :)
Oct 11 2009
prev sibling parent reply 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
Oct 11 2009
parent reply 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.
Oct 12 2009
parent 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
Oct 12 2009