www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D-

reply "Tim Krimm" <twkrimm yahoo.com> writes:
We have C and C++

How about D- and D?

D- would be the have a similar use as today's C compilers.

===========================
Why create this language?
===========================

Well I would love to have a D compiler that supports 
microcontrollers.
The ones that have say 32 K of RAM and 64K of FLASH.
A language that is targeted for embedded and/or low resource 
environments.
It would be nice to have a modern language for low resource 
environments.

A potential way to implement this language is to use the DMD 
frontend,
then flag the unsupported features of D,
Next create a backend, like "C front" that outputs C code instead 
of assembler.


===========================
What do I envision with D-,
D-- or Dm or what ever you want to call it.
===========================

This language would basically be D without the garbage collection.
For example there would be structures but no classes.
There would be regular arrays but no dynamic arrays.
Code that is mostly equivalent to C, but you would still have 
structures with functions and overloading support,
and other features like templates etc.

I think you get the idea.

What are your thoughts?
Feb 10 2012
next sibling parent reply Zachary Lund <admin computerquip.com> writes:
On 02/10/2012 01:02 PM, Tim Krimm wrote:

 We have C and C++

 How about D- and D?

 D- would be the have a similar use as today's C compilers.

 ===========================
 Why create this language?
 ===========================

 Well I would love to have a D compiler that supports microcontrollers.
 The ones that have say 32 K of RAM and 64K of FLASH.
 A language that is targeted for embedded and/or low resource environments.
 It would be nice to have a modern language for low resource environments.

 A potential way to implement this language is to use the DMD frontend,
 then flag the unsupported features of D,
 Next create a backend, like "C front" that outputs C code instead of
 assembler.


 ===========================
 What do I envision with D-,
 D-- or Dm or what ever you want to call it.
 ===========================

 This language would basically be D without the garbage collection.
 For example there would be structures but no classes.
 There would be regular arrays but no dynamic arrays.
 Code that is mostly equivalent to C, but you would still have structures
 with functions and overloading support,
 and other features like templates etc.

 I think you get the idea.

 What are your thoughts?


I would love this as well. I *think* you wouldn't have to recreate the 
language, just recreate the runtime. You can currently use D and can 
completely avoid the use of the GC by just using static functions. From 
what I understand, dynamic arrays are also controlled and provided 
through the runtime. You can also export C symbols if you wanted to.
Feb 10 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-02-10 20:23, Zachary Lund wrote:

 On 02/10/2012 01:02 PM, Tim Krimm wrote:

 We have C and C++

 How about D- and D?

 D- would be the have a similar use as today's C compilers.

 ===========================
 Why create this language?
 ===========================

 Well I would love to have a D compiler that supports microcontrollers.
 The ones that have say 32 K of RAM and 64K of FLASH.
 A language that is targeted for embedded and/or low resource
 environments.
 It would be nice to have a modern language for low resource environments.

 A potential way to implement this language is to use the DMD frontend,
 then flag the unsupported features of D,
 Next create a backend, like "C front" that outputs C code instead of
 assembler.


 ===========================
 What do I envision with D-,
 D-- or Dm or what ever you want to call it.
 ===========================

 This language would basically be D without the garbage collection.
 For example there would be structures but no classes.
 There would be regular arrays but no dynamic arrays.
 Code that is mostly equivalent to C, but you would still have structures
 with functions and overloading support,
 and other features like templates etc.

 I think you get the idea.

 What are your thoughts?


 I would love this as well. I *think* you wouldn't have to recreate the
 language, just recreate the runtime. You can currently use D and can
 completely avoid the use of the GC by just using static functions. From
 what I understand, dynamic arrays are also controlled and provided
 through the runtime. You can also export C symbols if you wanted to.


No need to restrict yourself yo static functions. Functions in structs 
are not virtual and doesn't require the GC.

-- 
/Jacob Carlborg
Feb 11 2012
parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Jacob Carlborg wrote:

 On 2012-02-10 20:23, Zachary Lund wrote:

 On 02/10/2012 01:02 PM, Tim Krimm wrote:

 This language would basically be D without the garbage collection.
 For example there would be structures but no classes.
 There would be regular arrays but no dynamic arrays.
 Code that is mostly equivalent to C, but you would still have structures
 with functions and overloading support,
 and other features like templates etc.

 I think you get the idea.

 What are your thoughts?


 I would love this as well. I *think* you wouldn't have to recreate the
 language, just recreate the runtime. You can currently use D and can
 completely avoid the use of the GC by just using static functions. From
 what I understand, dynamic arrays are also controlled and provided
 through the runtime. You can also export C symbols if you wanted to.


 No need to restrict yourself yo static functions. Functions in structs
 are not virtual and doesn't require the GC.


Virtual functions don't require the GC either.
Feb 11 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-02-11 18:40, Piotr Szturmaj wrote:

 Jacob Carlborg wrote:

 On 2012-02-10 20:23, Zachary Lund wrote:

 On 02/10/2012 01:02 PM, Tim Krimm wrote:

 This language would basically be D without the garbage collection.
 For example there would be structures but no classes.
 There would be regular arrays but no dynamic arrays.
 Code that is mostly equivalent to C, but you would still have
 structures
 with functions and overloading support,
 and other features like templates etc.

 I think you get the idea.

 What are your thoughts?


 I would love this as well. I *think* you wouldn't have to recreate the
 language, just recreate the runtime. You can currently use D and can
 completely avoid the use of the GC by just using static functions. From
 what I understand, dynamic arrays are also controlled and provided
 through the runtime. You can also export C symbols if you wanted to.


 No need to restrict yourself yo static functions. Functions in structs
 are not virtual and doesn't require the GC.


 Virtual functions don't require the GC either.


No they don't, but the will add other overhead.

-- 
/Jacob Carlborg
Feb 11 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/10/12 11:02 AM, Tim Krimm wrote:

 We have C and C++

 How about D- and D?


No please.

Andrei
Feb 10 2012
parent reply "Tim Krimm" <twkrimm yahoo.com> writes:
On Friday, 10 February 2012 at 20:21:53 UTC, Andrei Alexandrescu 
wrote:

 On 2/10/12 11:02 AM, Tim Krimm wrote:

 We have C and C++

 How about D- and D?


 No please.

 Andrei


Please elaborate.
Feb 10 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/10/12 12:54 PM, Tim Krimm wrote:

 On Friday, 10 February 2012 at 20:21:53 UTC, Andrei Alexandrescu wrote:

 On 2/10/12 11:02 AM, Tim Krimm wrote:

 We have C and C++

 How about D- and D?


 No please.

 Andrei


 Please elaborate.


The last thing we need is balkanization of the community. You are of 
course free to initiate such a project but if you care about D it would 
be great to apply your talent in a different direction.

Thanks,

Andrei
Feb 10 2012
next sibling parent reply "Tim Krimm" <twkrimm yahoo.com> writes:
On Friday, 10 February 2012 at 21:04:26 UTC, Andrei Alexandrescu 
wrote:

 On 2/10/12 12:54 PM, Tim Krimm wrote:

 On Friday, 10 February 2012 at 20:21:53 UTC, Andrei 
 Alexandrescu wrote:

 On 2/10/12 11:02 AM, Tim Krimm wrote:

 We have C and C++

 How about D- and D?


 No please.

 Andrei


 Please elaborate.


 The last thing we need is balkanization of the community. You 
 are of course free to initiate such a project but if you care 
 about D it would be great to apply your talent in a different 
 direction.

 Thanks,

 Andrei


It seems like D would catch on faster if it could be used more 
places,
but at the same time I do understand your concern about the 
language fragmentation that could occur. That is a major, major 
issue.

D is superior to C and C++ but
D is fighting an up hill battle when it comes to market share.
Unfortunately, I guess for now, I am stuck using the C/C++ tools 
that are available for all of the different microcontrollers out 
there.
Feb 10 2012
parent maarten van damme <maartenvd1994 gmail.com> writes:
I would love to be able to use D on memory limited devices like arduino but
creating a whole new language would certainly add up to the confusion for
many new potential users (they can't deal with two standard library's, let
alone two language named nearly the same)
if one were to do such project I would certainly hope he'd keep nearly
everything the same and only strip out what's really necessary.
Feb 10 2012
prev sibling next sibling parent reply "Tim Krimm" <twkrimm yahoo.com> writes:
On Friday, 10 February 2012 at 21:04:26 UTC, Andrei Alexandrescu 
wrote:

 On 2/10/12 12:54 PM, Tim Krimm wrote:

 On Friday, 10 February 2012 at 20:21:53 UTC, Andrei 
 Alexandrescu wrote:

 On 2/10/12 11:02 AM, Tim Krimm wrote:

 We have C and C++

 How about D- and D?


 No please.

 Andrei


 Please elaborate.


 The last thing we need is balkanization of the community. You 
 are of course free to initiate such a project but if you care 
 about D it would be great to apply your talent in a different 
 direction.

 Thanks,

 Andrei


Can we minimize the fragmentation issues by handling this with a 
flag in the front end of the compiler, similar to the way we 
handle "The SafeD Subset".
Feb 10 2012
parent "Nick Sabalausky" <a a.a> writes:
"Tim Krimm" <twkrimm yahoo.com> wrote in message 
news:kwweecfnvetseprndtjw dfeed.kimsufi.thecybershadow.net...

 On Friday, 10 February 2012 at 21:04:26 UTC, Andrei Alexandrescu wrote:

 On 2/10/12 12:54 PM, Tim Krimm wrote:

 On Friday, 10 February 2012 at 20:21:53 UTC, Andrei Alexandrescu wrote:

 On 2/10/12 11:02 AM, Tim Krimm wrote:

 We have C and C++

 How about D- and D?


 No please.

 Andrei


 Please elaborate.


 The last thing we need is balkanization of the community. You are of 
 course free to initiate such a project but if you care about D it would 
 be great to apply your talent in a different direction.

 Thanks,

 Andrei


 Can we minimize the fragmentation issues by handling this with a flag in 
 the front end of the compiler, similar to the way we handle "The SafeD 
 Subset".


VOTE++!!!!
Feb 11 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Feb 10, 2012 at 01:04:26PM -0800, Andrei Alexandrescu wrote:

 On 2/10/12 12:54 PM, Tim Krimm wrote:

On Friday, 10 February 2012 at 20:21:53 UTC, Andrei Alexandrescu wrote:

On 2/10/12 11:02 AM, Tim Krimm wrote:

We have C and C++

How about D- and D?


No please.

Andrei


Please elaborate.


 
 The last thing we need is balkanization of the community. You are of
 course free to initiate such a project but if you care about D it
 would be great to apply your talent in a different direction.


[...]

Perhaps one solution is to simply have the compiler recognize all valid
D constructs, but to give an error when it sees a construct not
supported by the target platform. For example:

	input.d(123): Error: dynamic arrays not supported by target
	platform.

This way, we don't cause fragmentation of D, and at the same time users
will know which constructs should be avoided due to target platform
limitations.


T

-- 
Never trust an operating system you don't have source for! -- Martin Schulze
Feb 10 2012
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, February 10, 2012 13:54:49 H. S. Teoh wrote:

 Perhaps one solution is to simply have the compiler recognize all valid
 D constructs, but to give an error when it sees a construct not
 supported by the target platform. For example:
 
 input.d(123): Error: dynamic arrays not supported by target
 platform.
 
 This way, we don't cause fragmentation of D, and at the same time users
 will know which constructs should be avoided due to target platform
 limitations.


I think that the only switch even vaguely like that which has any chance of 
making it into the compiler is one which makes any constructs which use the GC 
illegal. And no one has been able to get Walter to even put _that_ in yet.

For the most part, I'd argue that if you don't want to use all of D's 
features, then just don't use them all. The only major issue that I'm aware of 
is if you want to avoid the GC entirely (either for performance reasons or 
paranoia), you're probably going to have to forgoe using a lot of Phobos.

- Jonathan M Davis
Feb 10 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-02-10 23:06, Jonathan M Davis wrote:

 On Friday, February 10, 2012 13:54:49 H. S. Teoh wrote:

 Perhaps one solution is to simply have the compiler recognize all valid
 D constructs, but to give an error when it sees a construct not
 supported by the target platform. For example:

 input.d(123): Error: dynamic arrays not supported by target
 platform.

 This way, we don't cause fragmentation of D, and at the same time users
 will know which constructs should be avoided due to target platform
 limitations.


 I think that the only switch even vaguely like that which has any chance of
 making it into the compiler is one which makes any constructs which use the GC
 illegal. And no one has been able to get Walter to even put _that_ in yet.

 For the most part, I'd argue that if you don't want to use all of D's
 features, then just don't use them all. The only major issue that I'm aware of
 is if you want to avoid the GC entirely (either for performance reasons or
 paranoia), you're probably going to have to forgoe using a lot of Phobos.

 - Jonathan M Davis


It's possible to remove the GC and you'll get linker errors when the GC 
is used. This is a hack but it works today.

-- 
/Jacob Carlborg
Feb 11 2012
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:jh40oq$26p0$1 digitalmars.com...

 On 2/10/12 12:54 PM, Tim Krimm wrote:

 On Friday, 10 February 2012 at 20:21:53 UTC, Andrei Alexandrescu wrote:

 On 2/10/12 11:02 AM, Tim Krimm wrote:

 We have C and C++

 How about D- and D?


 No please.

 Andrei


 Please elaborate.


 The last thing we need is balkanization of the community. You are of 
 course free to initiate such a project but if you care about D it would be 
 great to apply your talent in a different direction.


I absolutely agree: We've learned a very hard lession from the 
community-fragmenting failure that was known as SafeD.
Feb 11 2012
next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:jh40oq$26p0$1 digitalmars.com...

 On 2/10/12 12:54 PM, Tim Krimm wrote:

 On Friday, 10 February 2012 at 20:21:53 UTC, Andrei Alexandrescu wrote:

 On 2/10/12 11:02 AM, Tim Krimm wrote:

 We have C and C++

 How about D- and D?


 No please.

 Andrei


 Please elaborate.


 The last thing we need is balkanization of the community. You are of
 course free to initiate such a project but if you care about D it would be
 great to apply your talent in a different direction.


 I absolutely agree: We've learned a very hard lession from the
 community-fragmenting failure that was known as SafeD.


So now SafeD is only thing of the past?
Feb 11 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/11/2012 06:43 PM, Piotr Szturmaj wrote:

 Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org> wrote in message
 news:jh40oq$26p0$1 digitalmars.com...

 On 2/10/12 12:54 PM, Tim Krimm wrote:

 On Friday, 10 February 2012 at 20:21:53 UTC, Andrei Alexandrescu wrote:

 On 2/10/12 11:02 AM, Tim Krimm wrote:

 We have C and C++

 How about D- and D?


 No please.

 Andrei


 Please elaborate.


 The last thing we need is balkanization of the community. You are of
 course free to initiate such a project but if you care about D it
 would be
 great to apply your talent in a different direction.


 I absolutely agree: We've learned a very hard lession from the
 community-fragmenting failure that was known as SafeD.


 So now SafeD is only thing of the past?


Nick was quite obviously being sarcastic. ;)
Feb 11 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/11/12 12:28 PM, Timon Gehr wrote:

 Nick was quite obviously being sarcastic. ;)


oops...

Andrei
Feb 11 2012
parent "Tim Krimm" <twkrimm yahoo.com> writes:
On Saturday, 11 February 2012 at 18:53:13 UTC, Andrei 
Alexandrescu wrote:

 On 2/11/12 12:28 PM, Timon Gehr wrote:

 Nick was quite obviously being sarcastic. ;)


 oops...

 Andrei


I am sorry Andrei, I think I stirred up a rats nest with this D- 
or EmbeddedD stuff.
Feb 11 2012
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/11/12 8:48 AM, Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:jh40oq$26p0$1 digitalmars.com...

 On 2/10/12 12:54 PM, Tim Krimm wrote:

 On Friday, 10 February 2012 at 20:21:53 UTC, Andrei Alexandrescu wrote:

 On 2/10/12 11:02 AM, Tim Krimm wrote:

 We have C and C++

 How about D- and D?


 No please.

 Andrei


 Please elaborate.


 The last thing we need is balkanization of the community. You are of
 course free to initiate such a project but if you care about D it would be
 great to apply your talent in a different direction.


 I absolutely agree: We've learned a very hard lession from the
 community-fragmenting failure that was known as SafeD.


Not sure what you mean there. As far as I can tell SafeD did not fail 
and there was no community fragmentation at any point because of it.

Andrei
Feb 11 2012
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Feb 11, 2012 at 11:55:07AM -0600, Andrei Alexandrescu wrote:

 On 2/11/12 8:48 AM, Nick Sabalausky wrote:


[...]

I absolutely agree: We've learned a very hard lession from the
community-fragmenting failure that was known as SafeD.


 
 Not sure what you mean there. As far as I can tell SafeD did not fail
 and there was no community fragmentation at any point because of it.


[...]

AFAIK, SafeD is just incompletely implemented, right? But it exists and
it will be done one day.


T

-- 
Жил-был король когда-то, при нём блоха жила.
Feb 11 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/11/12 12:07 PM, H. S. Teoh wrote:

 On Sat, Feb 11, 2012 at 11:55:07AM -0600, Andrei Alexandrescu wrote:

 On 2/11/12 8:48 AM, Nick Sabalausky wrote:


 [...]

 I absolutely agree: We've learned a very hard lession from the
 community-fragmenting failure that was known as SafeD.


 Not sure what you mean there. As far as I can tell SafeD did not fail
 and there was no community fragmentation at any point because of it.


 [...]

 AFAIK, SafeD is just incompletely implemented, right? But it exists and
 it will be done one day.


That is correct. A nicer way to put it is  safe needs more work.

Andrei
Feb 11 2012
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 11.02.2012 19:50, schrieb Andrei Alexandrescu:

 On 2/11/12 12:07 PM, H. S. Teoh wrote:

 On Sat, Feb 11, 2012 at 11:55:07AM -0600, Andrei Alexandrescu wrote:

 On 2/11/12 8:48 AM, Nick Sabalausky wrote:


 [...]

 I absolutely agree: We've learned a very hard lession from the
 community-fragmenting failure that was known as SafeD.


 Not sure what you mean there. As far as I can tell SafeD did not fail
 and there was no community fragmentation at any point because of it.


 [...]

 AFAIK, SafeD is just incompletely implemented, right? But it exists and
 it will be done one day.


 That is correct. A nicer way to put it is  safe needs more work.

 Andrei


Andrei, what would be needed to improve it? Just submitting patches to
existing open issues or is some kind of redesign also needed?

--
Paulo
Feb 12 2012
prev sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:jh6daf$1vq7$1 digitalmars.com...

 On 2/11/12 12:07 PM, H. S. Teoh wrote:

 On Sat, Feb 11, 2012 at 11:55:07AM -0600, Andrei Alexandrescu wrote:

 On 2/11/12 8:48 AM, Nick Sabalausky wrote:


 [...]

 I absolutely agree: We've learned a very hard lession from the
 community-fragmenting failure that was known as SafeD.


 Not sure what you mean there. As far as I can tell SafeD did not fail
 and there was no community fragmentation at any point because of it.


 [...]

 AFAIK, SafeD is just incompletely implemented, right? But it exists and
 it will be done one day.


 That is correct. A nicer way to put it is  safe needs more work.

 Andrei


I don't know why people keep saying this.  Most of safeD is implemented as 
of about six months ago.
Feb 12 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/11/2012 06:55 PM, Andrei Alexandrescu wrote:

 On 2/11/12 8:48 AM, Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org> wrote in message
 news:jh40oq$26p0$1 digitalmars.com...

 On 2/10/12 12:54 PM, Tim Krimm wrote:

 On Friday, 10 February 2012 at 20:21:53 UTC, Andrei Alexandrescu wrote:

 On 2/10/12 11:02 AM, Tim Krimm wrote:

 We have C and C++

 How about D- and D?


 No please.

 Andrei


 Please elaborate.


 The last thing we need is balkanization of the community. You are of
 course free to initiate such a project but if you care about D it
 would be
 great to apply your talent in a different direction.


 I absolutely agree: We've learned a very hard lession from the
 community-fragmenting failure that was known as SafeD.


 Not sure what you mean there. As far as I can tell SafeD did not fail
 and there was no community fragmentation at any point because of it.

 Andrei


He was setting up an analogy between SafeD and 'EmbedD' in a satirical 
attempt to ridicule non-uniform treatment of the concepts.
Feb 11 2012
prev sibling next sibling parent Norbert Nemec <Norbert Nemec-online.de> writes:
On 10.02.2012 22:04, Andrei Alexandrescu wrote:

 On 2/10/12 12:54 PM, Tim Krimm wrote:

 On Friday, 10 February 2012 at 20:21:53 UTC, Andrei Alexandrescu wrote:

 On 2/10/12 11:02 AM, Tim Krimm wrote:

 We have C and C++

 How about D- and D?


 No please.

 Andrei


 Please elaborate.


 The last thing we need is balkanization of the community. You are of
 course free to initiate such a project but if you care about D it would
 be great to apply your talent in a different direction.


In my understanding, balkanization would begin only if D- would stop 
being a pure subset of D

"Safe D" is already one kind of subset that you can use for a large 
class of real-world problems. Maybe, the new concept could be 
communicated as "Embedded D" in a very similar way, prohibiting certain 
language features by a compiler switch and making sure that a meaningful 
subset of the runtime library can still be used.

In fact, the concept of such a restricted subset of D could be quite 
useful for hard real-time code that has been discussed on this list 
recently. Perhaps the requirements are slightly different, but why not 
expand the concept of restricting D for various purposes? (real-time, 
embedded systems, memory-safe programming, maybe others will come up too?)
Feb 12 2012
prev sibling parent reply Zach the Mystic <reachzachatgooglesmailservice dot.com> writes:
On 2/10/12 4:04 PM, Andrei Alexandrescu wrote:

 The last thing we need is balkanization of the community. You are of
 course free to initiate such a project but if you care about D it would
 be great to apply your talent in a different direction.


I think this might be going a little bit too far. In other posts on this 
thread, is has been clearly shown that D isn't afraid run with a design 
even though the implementation may be quite a ways into the future. As 
you yourself said, " safe needs more work".

The reason I'm saying this is because I don't think that a subset of D 
which is good for tiny devices breaks the language itself. And it would 
also showcase D's versatility. In other words, the community may 
actually *gain* followers when people using other languages start to 
think to themselves, "You know, I can't do that in my language, not even 
in principle. That's pretty cool."
Feb 13 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/13/12 10:45 AM, Zach the Mystic wrote:

 On 2/10/12 4:04 PM, Andrei Alexandrescu wrote:

 The last thing we need is balkanization of the community. You are of
 course free to initiate such a project but if you care about D it would
 be great to apply your talent in a different direction.


 I think this might be going a little bit too far. In other posts on this
 thread, is has been clearly shown that D isn't afraid run with a design
 even though the implementation may be quite a ways into the future. As
 you yourself said, " safe needs more work".

 The reason I'm saying this is because I don't think that a subset of D
 which is good for tiny devices breaks the language itself. And it would
 also showcase D's versatility. In other words, the community may
 actually *gain* followers when people using other languages start to
 think to themselves, "You know, I can't do that in my language, not even
 in principle. That's pretty cool."


I just find it difficult to imagine things that way. Tiny devices are 
confined to small programs by definition, and at that magnitude the 
field is quite leveled; for a 3K-lines program, C is just fine and many 
of D's (and other languages') advantages are at best minor.

Andrei
Feb 13 2012
parent reply Zach the Mystic <reachzachatgooglesmailservice dot.com> writes:
On 2/13/12 11:54 AM, Andrei Alexandrescu wrote:

 I just find it difficult to imagine things that way. Tiny devices are
 confined to small programs by definition, and at that magnitude the
 field is quite leveled; for a 3K-lines program, C is just fine and many
 of D's (and other languages') advantages are at best minor.

 Andrei


 From a practical standpoint, you are correct, and I won't argue.

But from an idealistic standpoint, D stands as one of the few languages 
(the only language?) which really has a finger in every pie.

So we seek a compromise answer. How to manage D's current limited 
manpower effectively while still holding true to a few ideals. Ideals do 
matter, and in that sense they are, ironically, practical, because they 
motivate people.
Feb 13 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/13/12 11:46 AM, Zach the Mystic wrote:

 On 2/13/12 11:54 AM, Andrei Alexandrescu wrote:

 I just find it difficult to imagine things that way. Tiny devices are
 confined to small programs by definition, and at that magnitude the
 field is quite leveled; for a 3K-lines program, C is just fine and many
 of D's (and other languages') advantages are at best minor.

 Andrei


  From a practical standpoint, you are correct, and I won't argue.

 But from an idealistic standpoint, D stands as one of the few languages
 (the only language?) which really has a finger in every pie.

 So we seek a compromise answer. How to manage D's current limited
 manpower effectively while still holding true to a few ideals. Ideals do
 matter, and in that sense they are, ironically, practical, because they
 motivate people.


Agreed. There are two issues I see here in my opinion. First, putting 
some of our manpower in a small subset of D for tiny embedded systems is 
a misplaced investment because it would make a small impact at best. 
Second, coming up with another D-derived brand is a bad marketing move. 
We've been hurt for too long a time by D1/D2. With that in mind, if 
working on D for small embedded systems is what you like, I encourage 
you to go down that path and see what you discover.

Andrei
Feb 13 2012
next sibling parent Zach the Mystic <reachzachatgooglesmailservice dot.com> writes:
On 2/13/12 1:17 PM, Andrei Alexandrescu wrote:

 Agreed. There are two issues I see here in my opinion. First, putting
 some of our manpower in a small subset of D for tiny embedded systems is
 a misplaced investment because it would make a small impact at best.
 Second, coming up with another D-derived brand is a bad marketing move.
 We've been hurt for too long a time by D1/D2. With that in mind, if
 working on D for small embedded systems is what you like, I encourage
 you to go down that path and see what you discover.

 Andrei


Once again, you're correct. I have little to add to this, except to say 
that when I first read the topic I was rather excited, and I read on 
hoping to see a discussion of what exactly would be involved in 
stripping out a chunk of D that it might produce extremely small 
programs. I wonder if my desire to read these threads for educational 
purposes is at odds with their other functions, such as internal debates 
about where the language should be headed.

I don't know what to say about the D1/D2 debacle. It seems like D's 
extraordinary dedication to "getting it right" has had some unfortunate 
side effects. Perhaps it's possible to interpret D's past as a sort of 
"nekyia" on D's way to a more glorious future:

http://en.wikipedia.org/wiki/Nekyia
Feb 13 2012
prev sibling parent reply Don <nospam nospam.com> writes:
On 13.02.2012 19:17, Andrei Alexandrescu wrote:

 Second, coming up with another D-derived brand is a bad marketing move.
 We've been hurt for too long a time by D1/D2.


Andrei, can I ask you to please never mention D1 again? You seem to have 
_fundamental_ misconceptions about it. It's obvious that D1 was 
exceedingly poorly explained, to the extent that even you didn't 
understand it, and you've spread your misunderstandings everywhere.
And THAT has been a marketing disaster.

To try to set the record straight:

The D language has been developed continuously since the beginning.
"D1" is a stability snapshot of DMD 1.015.
"D2" is the continued development of D after 1.015.

There was no change in the rate of language development before the 
stability snapshot (ie, what went into D1) vs after the stability 
snapshot (what has gone into D2). There was no decision "1.015 is a good 
enough language, let's stabilize on this". It was essentially a freezing 
of the language development at a largely arbitrary point, for purposes 
of stability. Most importantly, note that "D1" was not planned. It's not 
a language that anyone wanted. It's just a snapshot.
And it was successful - 75% of the open bugs are D2-only.

Any mention of D1 as if it were the "first attempt" of the D language is 
offensive, and wrong.

Here's the original announcement of D1:
http://www.digitalmars.com/d/archives/digitalmars/D/announce/Stick_a_fork_in_it_8521.html
Feb 15 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/15/12 4:40 PM, Don wrote:

 On 13.02.2012 19:17, Andrei Alexandrescu wrote:

 Second, coming up with another D-derived brand is a bad marketing move.
 We've been hurt for too long a time by D1/D2.


 Andrei, can I ask you to please never mention D1 again? You seem to have
 _fundamental_ misconceptions about it. It's obvious that D1 was
 exceedingly poorly explained, to the extent that even you didn't
 understand it, and you've spread your misunderstandings everywhere.
 And THAT has been a marketing disaster.

 To try to set the record straight:

 The D language has been developed continuously since the beginning.
 "D1" is a stability snapshot of DMD 1.015.
 "D2" is the continued development of D after 1.015.

 There was no change in the rate of language development before the
 stability snapshot (ie, what went into D1) vs after the stability
 snapshot (what has gone into D2). There was no decision "1.015 is a good
 enough language, let's stabilize on this". It was essentially a freezing
 of the language development at a largely arbitrary point, for purposes
 of stability. Most importantly, note that "D1" was not planned. It's not
 a language that anyone wanted. It's just a snapshot.
 And it was successful - 75% of the open bugs are D2-only.

 Any mention of D1 as if it were the "first attempt" of the D language is
 offensive, and wrong.

 Here's the original announcement of D1:
 http://www.digitalmars.com/d/archives/digitalmars/D/announce/Stick_a_fork_in_it_8521.html


All of this is in agreement with my understanding of the situation, so I 
fail to see where my fundamental misconceptions would be. Is it possible 
that your perception of my view of D1 is inaccurate? As a simple 
starting point, note that none of the above contradicts, either directly 
or indirectly, my assertion.


Thanks,

Andrei
Feb 15 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Feb 10, 2012 at 08:02:52PM +0100, Tim Krimm wrote:

 We have C and C++
 
 How about D- and D?


[...]

Great, just what I need: a D- in programming!

:-P


T

-- 
PNP = Plug 'N' Pray
Feb 10 2012
prev sibling next sibling parent "Jesse Phillips" <jessekphillips+D gmail.com> writes:
On Friday, 10 February 2012 at 19:02:54 UTC, Tim Krimm wrote:

 We have C and C++

 How about D- and D?


There has been discussion of having a compiler switch that flags 
use of the GC. I'm pretty sure Walter agreed it would be good to 
have. So someone needs to create a pull request so he can pull it 
in.

Then a runtime and standard library could be created for the 
needed device/purpose.
Feb 10 2012
prev sibling next sibling parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 10.02.2012, 20:02 Uhr, schrieb Tim Krimm <twkrimm yahoo.com>:


 What are your thoughts?


There is no way you get a D application into 64K. The language is not  
powerful enough. Only C can achieve that.
Feb 10 2012
next sibling parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
 What are your thoughts?


 There is no way you get a D application into 64K. The language 
 is not powerful enough. Only C can achieve that.


I'll need to agree. Porting D to a smaller memory space and with 
cramped features in all of this is not going to be good no matter 
how you look at it. I'm sure it's similar to comparing using perl 
in something with only 64k of memory, one must ask where you can 
put the interpreter, decoding and working with the source text, 
and many other things, not to mention even if you pulled it off, 
the speed penalty.

With only 64k, you aren't going to need anything extremely 
complex or elaborate.
You MIGHT get away with exporting D code to using C symbols, but 
you'll likely be stuck working with structs, no library support, 
no heap, no memory management, and fixed-sized arrays. I doubt 
you'd need templates, or any of the higher functions. All 
structures and types must be basic or known statically at compile 
time. Unlikely for lambdas to be used, and a score of other 
features.

This is all just speculation, but I think you get the picture. If 
you make a subset of D, it would most likely be named Mini-D. But 
at that point you've got an enhanced C without going C++.
Feb 10 2012
next sibling parent reply "Tim Krimm" <twkrimm yahoo.com> writes:
 If you make a subset of D, it would most likely be named 
 Mini-D. But at that point you've got an enhanced C without 
 going C++.


Yes and that probably would be better than what I have now.

Going back and forth programming in C/C++ today,
and then switching back to D tomorrow.

Let me see if I remember again,
classes and structures are almost the same in C++
but different in D.

Well I did the assignment A=B, if I change A will it also change 
B,
or is B a copy of A.
Is A a class or a structure that is an important distinction in D.

Today, Oh crap I forgot the #include
Tomorrow, Oh crap I forgot the import

Oh crap what was that syntax for initializing the class variables 
again.
Feb 10 2012
next sibling parent Xinok <xinok live.com> writes:
On 2/10/2012 8:13 PM, Tim Krimm wrote:

 If you make a subset of D, it would most likely be named Mini-D. But
 at that point you've got an enhanced C without going C++.


 Yes and that probably would be better than what I have now.

 Going back and forth programming in C/C++ today,
 and then switching back to D tomorrow.

 Let me see if I remember again,
 classes and structures are almost the same in C++
 but different in D.

 Well I did the assignment A=B, if I change A will it also change B,
 or is B a copy of A.
 Is A a class or a structure that is an important distinction in D.

 Today, Oh crap I forgot the #include
 Tomorrow, Oh crap I forgot the import

 Oh crap what was that syntax for initializing the class variables again.


That hardly seems like a good enough reason to create a second language. 
The community has enough to work on from the standard library to 
squashing bugs to writing literature and much more.

I think a more practical idea would be to write a utility which 
translates a subset of D's features to equivalent C code.
Feb 10 2012
prev sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
On Saturday, 11 February 2012 at 02:13:19 UTC, Tim Krimm wrote:

 If you make a subset of D, it would most likely be named 
 Mini-D. But at that point you've got an enhanced C without 
 going C++.


 Yes and that probably would be better than what I have now.

 Going back and forth programming in C/C++ today,
 and then switching back to D tomorrow.

 Let me see if I remember again,
 classes and structures are almost the same in C++
 but different in D.

 Well I did the assignment A=B, if I change A will it also 
 change B,
 or is B a copy of A.
 Is A a class or a structure that is an important distinction in 
 D.

 Today, Oh crap I forgot the #include
 Tomorrow, Oh crap I forgot the import

 Oh crap what was that syntax for initializing the class 
 variables again.


"I'm incompetent so I want to fork the language"
Feb 10 2012
prev sibling next sibling parent reply "Tim Krimm" <twkrimm yahoo.com> writes:
On Saturday, 11 February 2012 at 01:46:26 UTC, Era Scarecrow 
wrote:

 What are your thoughts?


 There is no way you get a D application into 64K. The language 
 is not powerful enough. Only C can achieve that.


 I'll need to agree. Porting D to a smaller memory space and 
 with cramped features in all of this is not going to be good no 
 matter how you look at it. I'm sure it's similar to comparing 
 using perl in something with only 64k of memory, one must ask 
 where you can put the interpreter, decoding and working with 
 the source text, and many other things, not to mention even if 
 you pulled it off, the speed penalty.

 With only 64k, you aren't going to need anything extremely 
 complex or elaborate.
 You MIGHT get away with exporting D code to using C symbols, 
 but you'll likely be stuck working with structs, no library 
 support, no heap, no memory management, and fixed-sized arrays. 
 I doubt you'd need templates, or any of the higher functions. 
 All structures and types must be basic or known statically at 
 compile time. Unlikely for lambdas to be used, and a score of 
 other features.

 This is all just speculation, but I think you get the picture. 
 If you make a subset of D, it would most likely be named 
 Mini-D. But at that point you've got an enhanced C without 
 going C++.


Also computer chips are becoming more powerful every day.
I think we will soon be needing better tools.


example: Microchip PIC32MX795F512L
32 bit MIPS architecture
512K flash, 128K RAM
priced less than $10
Feb 10 2012
parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
 This is all just speculation, but I think you get the picture. 
 If you make a subset of D, it would most likely be named 
 Mini-D. But at that point you've got an enhanced C without 
 going C++.


 Also computer chips are becoming more powerful every day.
 I think we will soon be needing better tools.


 example: Microchip PIC32MX795F512L
 32 bit MIPS architecture
 512K flash, 128K RAM
 priced less than $10




Interesting and curious. I've wondered if you could string a 
hundred such processors onto a board and have it work properly at 
a fast speed, but obviously there's issues with that. (No need to 
explain the problems)

Just think though; What if they had this back when they were 
still making atari800 PCs? Since the Atari was only at about 
3Mhz, then this would be supped up, on steroids, crack, and maybe 
a few other illegal drugs as well :P

Now if only I had the expertise... then I might make one just for 
the hell of it.
Feb 10 2012
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Era Scarecrow" <rtcvb32 yahoo.com> wrote in message 
news:jzavmzbmjoyujhqyfvhp dfeed.kimsufi.thecybershadow.net...

 What are your thoughts?


 There is no way you get a D application into 64K. The language is not 
 powerful enough. Only C can achieve that.


 I'll need to agree. Porting D to a smaller memory space and with cramped 
 features in all of this is not going to be good no matter how you look at 
 it. I'm sure it's similar to comparing using perl in something with only 
 64k of memory, one must ask where you can put the interpreter, decoding 
 and working with the source text, and many other things, not to mention 
 even if you pulled it off, the speed penalty.

 With only 64k, you aren't going to need anything extremely complex or 
 elaborate.
 You MIGHT get away with exporting D code to using C symbols, but you'll 
 likely be stuck working with structs, no library support, no heap, no 
 memory management, and fixed-sized arrays. I doubt you'd need templates, 
 or any of the higher functions. All structures and types must be basic or 
 known statically at compile time. Unlikely for lambdas to be used, and a 
 score of other features.

 This is all just speculation, but I think you get the picture. If you make 
 a subset of D, it would most likely be named Mini-D. But at that point 
 you've got an enhanced C without going C++.


That would *still* be a very notable improvement over C. Hell, if you ask 
me, a proper module system alone is one of the killer features of D over C. 
Header files? Seriously? Fuck that shit. What the hell is this, 1970? And 
then there's other things that are *at the very least* icing on the cake: 
Faster compilation, slicing, better safety, metaprogramming (esp CTFE) that 
whups C's ass and makes it much less less tempting to do things at runtime 
that don't need to be done at runtime. That's all just off the top of my 
head.

I find it an absolute enigma that anyone would even consider that wouldn't 
be worthwhile. Ok, so it wouldn't add *all* of D's features...so the fuck 
what? The ones it would add would be more than enough to beat the shit out 
of C.

And like I've said before, why should we be focusing so exclusivly on 
desktop/web developers who *already* have five billion fucking languages to 
choose from, when we're already in the extremely unique position of actually 
having some potential to provide an alternative to areas that *don't* have 
many (or any) language choices available.
Feb 11 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-02-11 15:36, Nick Sabalausky wrote:

 "Era Scarecrow"<rtcvb32 yahoo.com>  wrote in message
 news:jzavmzbmjoyujhqyfvhp dfeed.kimsufi.thecybershadow.net...

 What are your thoughts?


 There is no way you get a D application into 64K. The language is not
 powerful enough. Only C can achieve that.


 I'll need to agree. Porting D to a smaller memory space and with cramped
 features in all of this is not going to be good no matter how you look at
 it. I'm sure it's similar to comparing using perl in something with only
 64k of memory, one must ask where you can put the interpreter, decoding
 and working with the source text, and many other things, not to mention
 even if you pulled it off, the speed penalty.

 With only 64k, you aren't going to need anything extremely complex or
 elaborate.
 You MIGHT get away with exporting D code to using C symbols, but you'll
 likely be stuck working with structs, no library support, no heap, no
 memory management, and fixed-sized arrays. I doubt you'd need templates,
 or any of the higher functions. All structures and types must be basic or
 known statically at compile time. Unlikely for lambdas to be used, and a
 score of other features.

 This is all just speculation, but I think you get the picture. If you make
 a subset of D, it would most likely be named Mini-D. But at that point
 you've got an enhanced C without going C++.


 That would *still* be a very notable improvement over C. Hell, if you ask
 me, a proper module system alone is one of the killer features of D over C.
 Header files? Seriously? Fuck that shit. What the hell is this, 1970? And
 then there's other things that are *at the very least* icing on the cake:
 Faster compilation, slicing, better safety, metaprogramming (esp CTFE) that
 whups C's ass and makes it much less less tempting to do things at runtime
 that don't need to be done at runtime. That's all just off the top of my
 head.


I think slicing is quite difficult without a GC. Not the actual slicing 
but freeing the memory.

-- 
/Jacob Carlborg
Feb 11 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:jh63p2$17li$1 digitalmars.com...

 On 2012-02-11 15:36, Nick Sabalausky wrote:

 "Era Scarecrow"<rtcvb32 yahoo.com>  wrote in message
 news:jzavmzbmjoyujhqyfvhp dfeed.kimsufi.thecybershadow.net...

 What are your thoughts?


 There is no way you get a D application into 64K. The language is not
 powerful enough. Only C can achieve that.


 I'll need to agree. Porting D to a smaller memory space and with cramped
 features in all of this is not going to be good no matter how you look 
 at
 it. I'm sure it's similar to comparing using perl in something with only
 64k of memory, one must ask where you can put the interpreter, decoding
 and working with the source text, and many other things, not to mention
 even if you pulled it off, the speed penalty.

 With only 64k, you aren't going to need anything extremely complex or
 elaborate.
 You MIGHT get away with exporting D code to using C symbols, but you'll
 likely be stuck working with structs, no library support, no heap, no
 memory management, and fixed-sized arrays. I doubt you'd need templates,
 or any of the higher functions. All structures and types must be basic 
 or
 known statically at compile time. Unlikely for lambdas to be used, and a
 score of other features.

 This is all just speculation, but I think you get the picture. If you 
 make
 a subset of D, it would most likely be named Mini-D. But at that point
 you've got an enhanced C without going C++.


 That would *still* be a very notable improvement over C. Hell, if you ask
 me, a proper module system alone is one of the killer features of D over 
 C.
 Header files? Seriously? Fuck that shit. What the hell is this, 1970? And
 then there's other things that are *at the very least* icing on the cake:
 Faster compilation, slicing, better safety, metaprogramming (esp CTFE) 
 that
 whups C's ass and makes it much less less tempting to do things at 
 runtime
 that don't need to be done at runtime. That's all just off the top of my
 head.


 I think slicing is quite difficult without a GC. Not the actual slicing 
 but freeing the memory.


Those are orthogonal concerns. Just because you're taking a slice doesn't 
mean you aren't still using the rest. And if you're not using the rest, then 
the problem just reduces to the classic old "GC vs manual" issue.
Feb 11 2012
prev sibling parent reply "q66" <quaker66 gmail.com> writes:
On Saturday, 11 February 2012 at 16:08:02 UTC, Jacob Carlborg 
wrote:

 On 2012-02-11 15:36, Nick Sabalausky wrote:

 "Era Scarecrow"<rtcvb32 yahoo.com>  wrote in message
 news:jzavmzbmjoyujhqyfvhp dfeed.kimsufi.thecybershadow.net...

 What are your thoughts?


 There is no way you get a D application into 64K. The 
 language is not
 powerful enough. Only C can achieve that.


 I'll need to agree. Porting D to a smaller memory space and 
 with cramped
 features in all of this is not going to be good no matter how 
 you look at
 it. I'm sure it's similar to comparing using perl in 
 something with only
 64k of memory, one must ask where you can put the 
 interpreter, decoding
 and working with the source text, and many other things, not 
 to mention
 even if you pulled it off, the speed penalty.

 With only 64k, you aren't going to need anything extremely 
 complex or
 elaborate.
 You MIGHT get away with exporting D code to using C symbols, 
 but you'll
 likely be stuck working with structs, no library support, no 
 heap, no
 memory management, and fixed-sized arrays. I doubt you'd need 
 templates,
 or any of the higher functions. All structures and types must 
 be basic or
 known statically at compile time. Unlikely for lambdas to be 
 used, and a
 score of other features.

 This is all just speculation, but I think you get the 
 picture. If you make
 a subset of D, it would most likely be named Mini-D. But at 
 that point
 you've got an enhanced C without going C++.


 That would *still* be a very notable improvement over C. Hell, 
 if you ask
 me, a proper module system alone is one of the killer features 
 of D over C.
 Header files? Seriously? Fuck that shit. What the hell is 
 this, 1970? And
 then there's other things that are *at the very least* icing 
 on the cake:
 Faster compilation, slicing, better safety, metaprogramming 
 (esp CTFE) that
 whups C's ass and makes it much less less tempting to do 
 things at runtime
 that don't need to be done at runtime. That's all just off the 
 top of my
 head.


 I think slicing is quite difficult without a GC. Not the actual 
 slicing but freeing the memory.


What's so difficult on that? Slices do not require the GC, you 
allocate once, slice many times, deallocate once.
Feb 11 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, February 11, 2012 19:00:51 q66 wrote:

 What's so difficult on that? Slices do not require the GC, you
 allocate once, slice many times, deallocate once.


With dynamic arrays, the GC owns the memory, and _all_ dynamic arrays are 
slices. _None_ of them own their own memory. The GC keeps track of whether you 
have any slices for a particular memory block and deals with freeing up wth 
the block if you don't. However, if you allocate a dynamic array without the 
GC, then all of a sudden, it effectively owns its own memory, so the semantics 
of dealing with arrays and memories changes drastically. What happens when you 
slice it? Which one owns the memory? What happens when you try and do stuff 
like popFront on an array? All of a sudden, you have memory which is no longer 
referenced. It's been leaked.

If you have a very careful scheme for handling memory, you _can_ slice arrays 
without a GC, but you have to worry about all the bookkeeping of keeping track 
of the originally allocated memory and how many slices reference it so that 
you can free it when appropriate.

Also, you can't concatenate to arrays at all, because that requires the GC.

So, you're dealing with a mine field if you try and use D's array capabilities 
without a GC. Yes, you _can_ use some of them if you're _very_ careful, but 
I'd seriously advise just sticking to using arrays like you would in C except 
for the fact that arrays know their length.

- Jonathan M Davis
Feb 11 2012
next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Jonathan M Davis wrote:

 On Saturday, February 11, 2012 19:00:51 q66 wrote:

 What's so difficult on that? Slices do not require the GC, you
 allocate once, slice many times, deallocate once.


 With dynamic arrays, the GC owns the memory, and _all_ dynamic arrays are
 slices. _None_ of them own their own memory. The GC keeps track of whether you
 have any slices for a particular memory block and deals with freeing up wth
 the block if you don't. However, if you allocate a dynamic array without the
 GC, then all of a sudden, it effectively owns its own memory, so the semantics
 of dealing with arrays and memories changes drastically. What happens when you
 slice it? Which one owns the memory? What happens when you try and do stuff
 like popFront on an array? All of a sudden, you have memory which is no longer
 referenced. It's been leaked.

 If you have a very careful scheme for handling memory, you _can_ slice arrays
 without a GC, but you have to worry about all the bookkeeping of keeping track
 of the originally allocated memory and how many slices reference it so that
 you can free it when appropriate.

 Also, you can't concatenate to arrays at all, because that requires the GC.

 So, you're dealing with a mine field if you try and use D's array capabilities
 without a GC. Yes, you _can_ use some of them if you're _very_ careful, but
 I'd seriously advise just sticking to using arrays like you would in C except
 for the fact that arrays know their length.


Delphi has dynamic arrays and appendable strings without a GC. In Delphi 
pointers and objects are managed manually, but arrays and strings are 
managed automatically (ref counted with Copy-On-Write). Take a look at 
http://www.codexterity.com/delphistrings.htm. Maybe some Delphi 
solutions may be used in NoGcD?
Feb 11 2012
parent "Zachary Lund" <admin computerquip.com> writes:
On Saturday, 11 February 2012 at 19:21:49 UTC, Piotr Szturmaj 
wrote:

 Jonathan M Davis wrote:

 On Saturday, February 11, 2012 19:00:51 q66 wrote:

 What's so difficult on that? Slices do not require the GC, you
 allocate once, slice many times, deallocate once.


 With dynamic arrays, the GC owns the memory, and _all_ dynamic 
 arrays are
 slices. _None_ of them own their own memory. The GC keeps 
 track of whether you
 have any slices for a particular memory block and deals with 
 freeing up wth
 the block if you don't. However, if you allocate a dynamic 
 array without the
 GC, then all of a sudden, it effectively owns its own memory, 
 so the semantics
 of dealing with arrays and memories changes drastically. What 
 happens when you
 slice it? Which one owns the memory? What happens when you try 
 and do stuff
 like popFront on an array? All of a sudden, you have memory 
 which is no longer
 referenced. It's been leaked.

 If you have a very careful scheme for handling memory, you 
 _can_ slice arrays
 without a GC, but you have to worry about all the bookkeeping 
 of keeping track
 of the originally allocated memory and how many slices 
 reference it so that
 you can free it when appropriate.

 Also, you can't concatenate to arrays at all, because that 
 requires the GC.

 So, you're dealing with a mine field if you try and use D's 
 array capabilities
 without a GC. Yes, you _can_ use some of them if you're _very_ 
 careful, but
 I'd seriously advise just sticking to using arrays like you 
 would in C except
 for the fact that arrays know their length.


 Delphi has dynamic arrays and appendable strings without a GC. 
 In Delphi pointers and objects are managed manually, but arrays 
 and strings are managed automatically (ref counted with 
 Copy-On-Write). Take a look at 
 http://www.codexterity.com/delphistrings.htm. Maybe some Delphi 
 solutions may be used in NoGcD?


It's possible that we just create our own dynamic array similar 
to that of std::vector from C++ except using cleaner syntax 
available in D. I'd really rather not do that though since it 
feels redundant.
Feb 11 2012
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.242.1328986002.20196.digitalmars-d puremagic.com...

 On Saturday, February 11, 2012 19:00:51 q66 wrote:

 What's so difficult on that? Slices do not require the GC, you
 allocate once, slice many times, deallocate once.


 With dynamic arrays, the GC owns the memory, and _all_ dynamic arrays are
 slices.


But not all slices are slices of dynamic arrays.


 _None_ of them own their own memory. The GC keeps track of whether you
 have any slices for a particular memory block and deals with freeing up 
 wth
 the block if you don't. However, if you allocate a dynamic array without 
 the
 GC, then all of a sudden, it effectively owns its own memory, so the 
 semantics
 of dealing with arrays and memories changes drastically. What happens when 
 you
 slice it? Which one owns the memory? What happens when you try and do 
 stuff
 like popFront on an array? All of a sudden, you have memory which is no 
 longer
 referenced. It's been leaked.

 If you have a very careful scheme for handling memory, you _can_ slice 
 arrays
 without a GC, but you have to worry about all the bookkeeping of keeping 
 track
 of the originally allocated memory and how many slices reference it so 
 that
 you can free it when appropriate.


Yea, manual memory management is hard and you have to be careful. That's 
true slices or not.


 Also, you can't concatenate to arrays at all, because that requires the 
 GC.


That's true (at least without providing some way to provide an alternate 
concatenation allocator). But nobody said that all D features would be 
usable.


 So, you're dealing with a mine field if you try and use D's array 
 capabilities
 without a GC. Yes, you _can_ use some of them if you're _very_ careful, 
 but
 I'd seriously advise just sticking to using arrays like you would in C 
 except
 for the fact that arrays know their length.


Arrays knowing their own length *is* a notable improvement over C.
Feb 11 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, February 11, 2012 18:01:05 Nick Sabalausky wrote:

 But not all slices are slices of dynamic arrays.


But all slices are still dynamic arrays, even if they refer to a static array. 
They just have a capacity of 0, so any appending will result in them being 
reallocated. And slicing static arrays is one of those things that you 
generally have to be careful about precisely because they aren't managed by 
the GC and can go out of scope before their slices do.


 Yea, manual memory management is hard and you have to be careful. That's
 true slices or not.


Yes, but in this case, you're dealing with a language feature which is 
_designed_ to be managed by the GC. It's not designed for manual memory 
management at all. It's a completely different situation when you're dealing 
with user-defined types.


 Arrays knowing their own length *is* a notable improvement over C.


Indeed, but that's pretty much the only improvement that D makes to arrays 
which is safe to use without a GC without being _very_, _very_ careful.

- Jonathan M Davis
Feb 11 2012
parent reply "Zachary Lund" <admin computerquip.com> writes:
On Sunday, 12 February 2012 at 00:29:35 UTC, Jonathan M Davis 
wrote:

 On Saturday, February 11, 2012 18:01:05 Nick Sabalausky wrote:

 But not all slices are slices of dynamic arrays.


 But all slices are still dynamic arrays, even if they refer to 
 a static array. They just have a capacity of 0, so any 
 appending will result in them being reallocated. And slicing 
 static arrays is one of those things that you generally have to 
 be careful about precisely because they aren't managed by the 
 GC and can go out of scope before their slices do.


 Yea, manual memory management is hard and you have to be 
 careful. That's
 true slices or not.


 Yes, but in this case, you're dealing with a language feature 
 which is _designed_ to be managed by the GC. It's not designed 
 for manual memory management at all. It's a completely 
 different situation when you're dealing with user-defined types.


 Arrays knowing their own length *is* a notable improvement 
 over C.


 Indeed, but that's pretty much the only improvement that D 
 makes to arrays which is safe to use without a GC without being 
 _very_, _very_ careful.

 - Jonathan M Davis


Btw, I'm not very fluent in the inner workings of a garbage 
collector implementation but how does one go about concatenating 
to an array in a garbage collector as compared to manual memory 
management? I believe array concatenation can be done in 
std::vector with the insert() function just fine. Isn't it as 
simple as determining both array sizes and allocating enough 
memory for both arrays? I could be oversimplifying things...
Feb 11 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, February 12, 2012 01:40:50 Zachary Lund wrote:

 Btw, I'm not very fluent in the inner workings of a garbage
 collector implementation but how does one go about concatenating
 to an array in a garbage collector as compared to manual memory
 management? I believe array concatenation can be done in
 std::vector with the insert() function just fine. Isn't it as
 simple as determining both array sizes and allocating enough
 memory for both arrays? I could be oversimplifying things...


Read this:

http://www.dsource.org/projects/dcollections/wiki/ArrayArticle

Appending to vectors is very different from appending to dynamic arrays because 
dynamic arrays do _not_ own their own memory (the GC does) and not only could 
other slices refer the same memory (in which case, you can't just free that 
memory when an array gets reallocated due to running out of space to append 
to), but they could already refer to the memory one past the end of the array, 
making it so that it can't expand into that memory.

Slices change the entire equation. And the way slices are designed, they 
require the GC.

- Jonathan M Davis
Feb 11 2012
parent reply Zachary Lund <admin computerquip.com> writes:
On 02/11/2012 07:00 PM, Jonathan M Davis wrote:

 On Sunday, February 12, 2012 01:40:50 Zachary Lund wrote:

 Btw, I'm not very fluent in the inner workings of a garbage
 collector implementation but how does one go about concatenating
 to an array in a garbage collector as compared to manual memory
 management? I believe array concatenation can be done in
 std::vector with the insert() function just fine. Isn't it as
 simple as determining both array sizes and allocating enough
 memory for both arrays? I could be oversimplifying things...


 Read this:

 http://www.dsource.org/projects/dcollections/wiki/ArrayArticle

 Appending to vectors is very different from appending to dynamic arrays because
 dynamic arrays do _not_ own their own memory (the GC does) and not only could
 other slices refer the same memory (in which case, you can't just free that
 memory when an array gets reallocated due to running out of space to append
 to), but they could already refer to the memory one past the end of the array,
 making it so that it can't expand into that memory.

 Slices change the entire equation. And the way slices are designed, they
 require the GC.

 - Jonathan M Davis


Right but they use the same semantics and the information to do either 
seems to be present. I'm not sure why an abstraction between the two 
cannot be made.
Feb 13 2012
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, February 13, 2012 20:41:01 Zachary Lund wrote:

 On 02/11/2012 07:00 PM, Jonathan M Davis wrote:

 On Sunday, February 12, 2012 01:40:50 Zachary Lund wrote:

 Btw, I'm not very fluent in the inner workings of a garbage
 collector implementation but how does one go about concatenating
 to an array in a garbage collector as compared to manual memory
 management? I believe array concatenation can be done in
 std::vector with the insert() function just fine. Isn't it as
 simple as determining both array sizes and allocating enough
 memory for both arrays? I could be oversimplifying things...


 
 Read this:
 
 http://www.dsource.org/projects/dcollections/wiki/ArrayArticle
 
 Appending to vectors is very different from appending to dynamic arrays
 because dynamic arrays do _not_ own their own memory (the GC does) and
 not only could other slices refer the same memory (in which case, you
 can't just free that memory when an array gets reallocated due to running
 out of space to append to), but they could already refer to the memory
 one past the end of the array, making it so that it can't expand into
 that memory.
 
 Slices change the entire equation. And the way slices are designed, they
 require the GC.
 
 - Jonathan M Davis


 
 Right but they use the same semantics and the information to do either
 seems to be present. I'm not sure why an abstraction between the two
 cannot be made.


I'm not sure what you're saying. All dynamic arrays are slices and _none_ of 
them own their own memory. As such, you need a way to manage their memory. 
Vectors, on the other hand, own their memory and do not allow slicing at all.

- Jonathan M Davis
Feb 13 2012
prev sibling next sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 02/11/12 02:46, Era Scarecrow wrote:

 There is no way you get a D application into 64K. The language is not powerful
enough. Only C can achieve that.


 
 I'll need to agree. Porting D to a smaller memory space and with cramped
features in all of this is not going to be good no matter how you look at it.
I'm sure it's similar to comparing using perl in something with only 64k of
memory, one must ask where you can put the interpreter, decoding and working
with the source text, and many other things, not to mention even if you pulled
it off, the speed penalty.
 
 With only 64k, you aren't going to need anything extremely complex or
elaborate.
 You MIGHT get away with exporting D code to using C symbols, but you'll likely
be stuck working with structs, no library support, no heap, no memory
management, and fixed-sized arrays. I doubt you'd need templates, or any of the
higher functions. All structures and types must be basic or known statically at
compile time. Unlikely for lambdas to be used, and a score of other features.
 
 This is all just speculation, but I think you get the picture. If you make a
subset of D, it would most likely be named Mini-D. But at that point you've got
an enhanced C without going C++.
 


I assumed the poster you're replying to was not being serious.
There's absolutely no difference between the code generated from C and D,
unless you use a few D-only concepts; ignoring compiler issues.
Having several levels of modules and templates, that in the end emit
single CPU instructions is not only possible, it lets you write
completely generic code that's both safer and not less efficient than
writing the equivalent in assembler.
I can easily see D being acceptable for 8K projects, 64K would probably
allow for a mostly complete runtime.

The answer isn't to butcher the language, it's to fix the shortcomings.
So, for example: all array ops need to be lowered and mapped to D code
so that they can be intercepted. Then you can either disallow everything
not supported or allow some subset and fail for every other operation.
Slicing probably counts too, as you may want to disallow or limit its use.
(Intercepted) pseudo-GC allocation might even work for some cases, even
if i'm not sure that it would be very useful, w/o things like scoped args
and more compiler support.
"synchronized" needs to accept anything that implements opLock() and
opUnlock(). Not only does that let you change the locking primitives,
it also lets you use it for things like CLI/STI-type UP exclusion, 
since I doubt the 64K machine would be MP. "synchronized" is better
than RAII/scope because it gives the compiler more information; once
it knows that the code inside the critical region is much more expensive
to run, it can more aggressively move certain parts outside, keeping
the critical region as small as possible (think "immutable" accesses,
that are hidden under a layer of functions/templates).
Classes are probably not a good idea in such a small system, yes.
A compiler option to turn off the default TLS model would help too.
What did I miss?

artur
Feb 11 2012
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 11 February 2012 17:47, Artur Skawina <art.08.09 gmail.com> wrote:

 On 02/11/12 02:46, Era Scarecrow wrote:

 There is no way you get a D application into 64K. The language is not p=






owerful enough. Only C can achieve that.

 I'll need to agree. Porting D to a smaller memory space and with cramped=




 features in all of this is not going to be good no matter how you look at =
it. I'm sure it's similar to comparing using perl in something with only 64=
k of memory, one must ask where you can put the interpreter, decoding and w=
orking with the source text, and many other things, not to mention even if =
you pulled it off, the speed penalty.

 With only 64k, you aren't going to need anything extremely complex or el=




aborate.

 You MIGHT get away with exporting D code to using C symbols, but you'll =




likely be stuck working with structs, no library support, no heap, no memor=
y management, and fixed-sized arrays. I doubt you'd need templates, or any =
of the higher functions. All structures and types must be basic or known st=
atically at compile time. Unlikely for lambdas to be used, and a score of o=
ther features.

 This is all just speculation, but I think you get the picture. If you ma=




ke a subset of D, it would most likely be named Mini-D. But at that point y=
ou've got an enhanced C without going C++.


 I assumed the poster you're replying to was not being serious.
 There's absolutely no difference between the code generated from C and D,
 unless you use a few D-only concepts; ignoring compiler issues.
 Having several levels of modules and templates, that in the end emit
 single CPU instructions is not only possible, it lets you write
 completely generic code that's both safer and not less efficient than
 writing the equivalent in assembler.
 I can easily see D being acceptable for 8K projects, 64K would probably
 allow for a mostly complete runtime.



I'd imagine the general idea is, just how much of druntime can we
strip away and still have the compiler be happy with all it's implicit
library calls.  After that, then decide what we don't *need*, or could
do in an alternative way and achieve the same result (without loosing
safeness).  I'd imagine there's quite a few things that could be done
differently depending on whether the compiler is building with the
assumption the program is going to be free standing environment, or
will depend on some sort of runtime existing that we'll link to.  What
can't be done may most likely be an error.




--=20
Iain Buclaw

*(p < e ? p++ : p) =3D (c & 0x0f) + '0';



 Feb 11 2012



prev sibling  parent  "Tim Krimm" <twkrimm yahoo.com>  writes:


On Saturday, 11 February 2012 at 00:58:53 UTC, Marco Leise wrote:

 Am 10.02.2012, 20:02 Uhr, schrieb Tim Krimm <twkrimm yahoo.com>:


 What are your thoughts?


 There is no way you get a D application into 64K. The language 
 is not powerful enough. Only C can achieve that.


It seems to me that if you are only using the D constructs that 
are similar to C,
then you should probably be generating similar assembly code.

It also seems to me that if you are only using the D constructs 
that are similar to C,
then you could rather easily convert the D into equivalent C code.
Then you could use the existing C compiler to compile the code
for your Microchip, Ardinuo, Zilog, ARM, Intel, Propeller, etc.



 Feb 10 2012



prev sibling next sibling parent  bcs <bcs example.com>  writes:


On 02/10/2012 11:02 AM, Tim Krimm wrote:

 We have C and C++

 How about D- and D?

 D- would be the have a similar use as today's C compilers.

 ===========================
 Why create this language?
 ===========================

 Well I would love to have a D compiler that supports microcontrollers.
 The ones that have say 32 K of RAM and 64K of FLASH.
 A language that is targeted for embedded and/or low resource environments.
 It would be nice to have a modern language for low resource environments.

 A potential way to implement this language is to use the DMD frontend,
 then flag the unsupported features of D,
 Next create a backend, like "C front" that outputs C code instead of
 assembler.


 ===========================
 What do I envision with D-,
 D-- or Dm or what ever you want to call it.
 ===========================

 This language would basically be D without the garbage collection.
 For example there would be structures but no classes.
 There would be regular arrays but no dynamic arrays.
 Code that is mostly equivalent to C, but you would still have structures
 with functions and overloading support,
 and other features like templates etc.

 I think you get the idea.

 What are your thoughts?


If it's strict subset of D, then it could be done in a lint-esqu fashion 
by statical checking for anything not in the subset. I could see this as 
a patch to DMD that makes no modifications to the processing aside from 
adding extra errors. Any legal D- should be legal D and do exactly the 
same thing.



 Feb 10 2012



prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org>  writes:


Am 10.02.2012 20:02, schrieb Tim Krimm:

 We have C and C++

 How about D- and D?

 D- would be the have a similar use as today's C compilers.

 ===========================
 Why create this language?
 ===========================

 Well I would love to have a D compiler that supports microcontrollers.
 The ones that have say 32 K of RAM and 64K of FLASH.
 A language that is targeted for embedded and/or low resource environments.
 It would be nice to have a modern language for low resource environments.

 A potential way to implement this language is to use the DMD frontend,
 then flag the unsupported features of D,
 Next create a backend, like "C front" that outputs C code instead of
 assembler.


 ===========================
 What do I envision with D-,
 D-- or Dm or what ever you want to call it.
 ===========================

 This language would basically be D without the garbage collection.
 For example there would be structures but no classes.
 There would be regular arrays but no dynamic arrays.
 Code that is mostly equivalent to C, but you would still have structures
 with functions and overloading support,
 and other features like templates etc.

 I think you get the idea.

 What are your thoughts?



I don't see the point.

C++ was the last systems programming language without GC getting market 
share. I seriously doubt any new systems programming language without GC 
will ever suceed.

Specially since systems programming in MacOS X and Windows world is 
slowly meaning the use of reference counting or GC in the vendor 
supported systems programming languages. Objective-C in MacOS X supports
GC and Reference Counting (GC). C++ in Windows has the std::*ptr and 

used in context of Microsoft Research projects like Singularity.

So sum this up. If you need a languague without GC, C and C++ are quite 
good, have lots of tools and excellent compilers available.

Do you need a very simple C like language, but with GC and a few 
improvements, Go might be an option.

Do you need a language with GC, that is C++ done right and quite capable
for systems programming, pick D.

There is no need to D-.

--
Paulo



 Feb 11 2012



 next sibling parent reply "Nick Sabalausky" <a a.a>  writes:


"Paulo Pinto" <pjmlp progtools.org> wrote in message 
news:jh5aip$1qma$1 digitalmars.com...

 I don't see the point.

 C++ was the last systems programming language without GC getting market 
 share. I seriously doubt any new systems programming language without GC 
 will ever suceed.


You're looking at it backwards. The whole point is for places where you 
wouldn't want GC. Those people are currently limited to the rotting, 
antiquated C and...that's about it. Nobody said this "D-" would need to take 
over the world. It can still succeed in a niche, and that niche is the whole 
point here.


 Specially since systems programming in MacOS X and Windows world is


Nobody's talking about Mac and Windows here.


 So sum this up. If you need a languague without GC, C and C++ are quite 
 good,


That's laughable. C and C++ are convoluted anachronistic crap. The only 
reason anyone still uses them is because 99.99% of language designers feel 
the way you do, and as a reasult, C/C++ remain the *only* options for 
certain uses.


 have lots of tools and excellent compilers available.

 Do you need a very simple C like language, but with GC and a few 
 improvements, Go might be an option.


First of all, Issue 9 is shit. Secondly, we're talking systems/embedded 
here, and Issue 9 is nowhere remotely near the same planet. That's like 
suggesting Perl or PHP.


 Do you need a language with GC,


Not the scenario we're talking about.


 that is C++ done right and quite capable
 for systems programming, pick D.

 There is no need to D-.


Poppycock.



 Feb 11 2012



  parent reply Paulo Pinto <pjmlp progtools.org>  writes:


Am 11.02.2012 15:46, schrieb Nick Sabalausky:

 "Paulo Pinto"<pjmlp progtools.org>  wrote in message
 news:jh5aip$1qma$1 digitalmars.com...

 I don't see the point.

 C++ was the last systems programming language without GC getting market
 share. I seriously doubt any new systems programming language without GC
 will ever suceed.


 You're looking at it backwards. The whole point is for places where you
 wouldn't want GC. Those people are currently limited to the rotting,
 antiquated C and...that's about it. Nobody said this "D-" would need to take
 over the world. It can still succeed in a niche, and that niche is the whole
 point here.


 Specially since systems programming in MacOS X and Windows world is


 Nobody's talking about Mac and Windows here.


 So sum this up. If you need a languague without GC, C and C++ are quite
 good,


 That's laughable. C and C++ are convoluted anachronistic crap. The only
 reason anyone still uses them is because 99.99% of language designers feel
 the way you do, and as a reasult, C/C++ remain the *only* options for
 certain uses.



The reason being that if you remove the GC, then you end up with some 
kind of C, C++, Pascal or Ada flavour, because there is only so much you
can do without a GC.

So in the end you just get an already existing language, but with 
different syntax.

So it is not worth the effort designing such languages.

More to the point, research has proven that system programming languages 
with GC is possible, they have yet not become mainstream because for a 
systems programming language to become mainstream it has to be choosen 
from a major OS company.


Singularity version but open source.

--
Paulo



 Feb 12 2012



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Paulo Pinto" <pjmlp progtools.org> wrote in message 
news:jh7tvk$29sv$1 digitalmars.com...

 So in the end you just get an already existing language, but with 
 different syntax.

 So it is not worth the effort designing such languages.


Where are you getting the crazy idea that the GC is the only non-syntactic 
improvement D has vs C/C++?

Additionally, you keep implying that the syntactic improvements are 
unimportant, or at least insignificant. Rediculous. Even if the GC were the 
only non-syntactic improvement and all the other changes were syntax (which 
isn't even true anyway), the syntax alone would absolutely be a worthwhile 
improvement over C or C++.



 Feb 12 2012



  parent  Paulo Pinto <pjmlp progtools.org>  writes:


Am 12.02.2012 15:23, schrieb Nick Sabalausky:

 "Paulo Pinto"<pjmlp progtools.org>  wrote in message
 news:jh7tvk$29sv$1 digitalmars.com...

 So in the end you just get an already existing language, but with
 different syntax.

 So it is not worth the effort designing such languages.


 Where are you getting the crazy idea that the GC is the only non-syntactic
 improvement D has vs C/C++?

 Additionally, you keep implying that the syntactic improvements are
 unimportant, or at least insignificant. Rediculous. Even if the GC were the
 only non-syntactic improvement and all the other changes were syntax (which
 isn't even true anyway), the syntax alone would absolutely be a worthwhile
 improvement over C or C++.


Because I see it as a wasted effort that could be better spent in other 
areas D needs.

There already other languages with manual memory management like Ada or 
Pascal, which in my personal opinion have a much better syntax and 
module systems than C or C++.

--
Paulo



 Feb 13 2012



prev sibling  parent reply bcs <bcs example.com>  writes:


On 02/11/2012 12:58 AM, Paulo Pinto wrote:

 Am 10.02.2012 20:02, schrieb Tim Krimm:

 We have C and C++

 How about D- and D?

 D- would be the have a similar use as today's C compilers.

 ===========================
 Why create this language?
 ===========================

 Well I would love to have a D compiler that supports microcontrollers.
 The ones that have say 32 K of RAM and 64K of FLASH.
 A language that is targeted for embedded and/or low resource
 environments.
 It would be nice to have a modern language for low resource environments.

 A potential way to implement this language is to use the DMD frontend,
 then flag the unsupported features of D,
 Next create a backend, like "C front" that outputs C code instead of
 assembler.


 ===========================
 What do I envision with D-,
 D-- or Dm or what ever you want to call it.
 ===========================

 This language would basically be D without the garbage collection.
 For example there would be structures but no classes.
 There would be regular arrays but no dynamic arrays.
 Code that is mostly equivalent to C, but you would still have structures
 with functions and overloading support,
 and other features like templates etc.

 I think you get the idea.

 What are your thoughts?



 I don't see the point.

 C++ was the last systems programming language without GC getting market
 share. I seriously doubt any new systems programming language without GC
 will ever suceed.

 Specially since systems programming in MacOS X and Windows world is


Systems programming in the MacOS X and Windows world isn't real systems 
programming. The closest you get is kernel and driver work but even 
there you have most of an OS to work with. I think the kind of systems 
programming being considered is embedded work and/or things like BIOS work.


 slowly meaning the use of reference counting or GC in the vendor
 supported systems programming languages. Objective-C in MacOS X supports
 GC and Reference Counting (GC). C++ in Windows has the std::*ptr and

 used in context of Microsoft Research projects like Singularity.

 So sum this up. If you need a languague without GC, C and C++ are quite
 good, have lots of tools and excellent compilers available.

 Do you need a very simple C like language, but with GC and a few
 improvements, Go might be an option.

 Do you need a language with GC, that is C++ done right and quite capable
 for systems programming, pick D.

 There is no need to D-.

 --
 Paulo





 Feb 11 2012



  parent reply Paulo Pinto <pjmlp progtools.org>  writes:


Am 11.02.2012 18:00, schrieb bcs:

 On 02/11/2012 12:58 AM, Paulo Pinto wrote:

 Am 10.02.2012 20:02, schrieb Tim Krimm:

 We have C and C++

 How about D- and D?

 D- would be the have a similar use as today's C compilers.

 ===========================
 Why create this language?
 ===========================

 Well I would love to have a D compiler that supports microcontrollers.
 The ones that have say 32 K of RAM and 64K of FLASH.
 A language that is targeted for embedded and/or low resource
 environments.
 It would be nice to have a modern language for low resource
 environments.

 A potential way to implement this language is to use the DMD frontend,
 then flag the unsupported features of D,
 Next create a backend, like "C front" that outputs C code instead of
 assembler.


 ===========================
 What do I envision with D-,
 D-- or Dm or what ever you want to call it.
 ===========================

 This language would basically be D without the garbage collection.
 For example there would be structures but no classes.
 There would be regular arrays but no dynamic arrays.
 Code that is mostly equivalent to C, but you would still have structures
 with functions and overloading support,
 and other features like templates etc.

 I think you get the idea.

 What are your thoughts?



 I don't see the point.

 C++ was the last systems programming language without GC getting market
 share. I seriously doubt any new systems programming language without GC
 will ever suceed.

 Specially since systems programming in MacOS X and Windows world is


 Systems programming in the MacOS X and Windows world isn't real systems
 programming. The closest you get is kernel and driver work but even
 there you have most of an OS to work with. I think the kind of systems
 programming being considered is embedded work and/or things like BIOS work.



Systems programming is everything you need to get an OS up and running. 
At least it was so a few decades back when I attended computer science 
and informatics engineering course.

Regarding embedded and BIOS work, many systems being used today still 
required a custom C compiler without full ANSI C support, so how would
such systems support a D- implementation?

--
Paulo



 Feb 11 2012



  parent reply bcs <bcs example.com>  writes:


On 02/11/2012 09:19 AM, Paulo Pinto wrote:

 Am 11.02.2012 18:00, schrieb bcs:

 On 02/11/2012 12:58 AM, Paulo Pinto wrote:

 Specially since systems programming in MacOS X and Windows world is


 Systems programming in the MacOS X and Windows world isn't real systems
 programming. The closest you get is kernel and driver work but even
 there you have most of an OS to work with. I think the kind of systems
 programming being considered is embedded work and/or things like BIOS
 work.



 Systems programming is everything you need to get an OS up and running.
 At least it was so a few decades back when I attended computer science
 and informatics engineering course.


OK then there may be some people doing systems programming for MacOS X 
and Windows, but they all work for Apple and MS.


 Regarding embedded and BIOS work, many systems being used today still
 required a custom C compiler without full ANSI C support, so how would
 such systems support a D- implementation?

 --
 Paulo





 Feb 11 2012



  parent reply Paulo Pinto <pjmlp progtools.org>  writes:


Am 12.02.2012 03:03, schrieb bcs:

 On 02/11/2012 09:19 AM, Paulo Pinto wrote:

 Am 11.02.2012 18:00, schrieb bcs:

 On 02/11/2012 12:58 AM, Paulo Pinto wrote:

 Specially since systems programming in MacOS X and Windows world is


 Systems programming in the MacOS X and Windows world isn't real systems
 programming. The closest you get is kernel and driver work but even
 there you have most of an OS to work with. I think the kind of systems
 programming being considered is embedded work and/or things like BIOS
 work.



 Systems programming is everything you need to get an OS up and running.
 At least it was so a few decades back when I attended computer science
 and informatics engineering course.


 OK then there may be some people doing systems programming for MacOS X
 and Windows, but they all work for Apple and MS.


So do you mean everyone doing device driver development are also working
for them?

As well as all the companies writing services/daemons with low level 
protocols for optimal perfomance?



--
Paulo



 Feb 12 2012



  parent  bcs <bcs example.com>  writes:


On 02/12/2012 12:32 AM, Paulo Pinto wrote:

 Am 12.02.2012 03:03, schrieb bcs:

 On 02/11/2012 09:19 AM, Paulo Pinto wrote:

 Am 11.02.2012 18:00, schrieb bcs:

 On 02/11/2012 12:58 AM, Paulo Pinto wrote:

 Specially since systems programming in MacOS X and Windows world is


 Systems programming in the MacOS X and Windows world isn't real systems
 programming. The closest you get is kernel and driver work but even
 there you have most of an OS to work with. I think the kind of systems
 programming being considered is embedded work and/or things like BIOS
 work.



 Systems programming is everything you need to get an OS up and running.
 At least it was so a few decades back when I attended computer science
 and informatics engineering course.


 OK then there may be some people doing systems programming for MacOS X
 and Windows, but they all work for Apple and MS.


 So do you mean everyone doing device driver development are also working
 for them?


I've never worked on them but I seem to recall from somewhere that 
Windows drivers operate in an environment that has a lot of "supporting 
infrastructure".  Assuming that's not off in the weeds, I suspect the 
cases is not to different for OS-x.


 As well as all the companies writing services/daemons with low level
 protocols for optimal perfomance?


If you are working in user mode your claim to doing systems programming 
is weakened. The same goes if any part of your program can afford to use 
a GC.

I will grant that there is a lot of ground between that and the "very 
much not systems programming" type of work that goes into a things like 
web apps. However, I would assert that a formal D- sub-set/dialect would 
mostly be of use on the core kernel development and 
embedded-systems/micro-controllers end of things. Outside that, I 
suspect that >90% of the advantage can be had via a well selected style 
guide.



 Feb 14 2012



prev sibling  parent reply "Daniel Murphy" <yebblies nospamgmail.com>  writes:


This is actually probably not that difficult to do.

A C backend for dmd would be quite difficult to make - but if you strip out 
most of the complex features that make it to code generation (exceptions, 
garbage collected memory, tls, classes, array ops, threading, floating 
point, typeinfo, destructors, postblits etc) then the actual code generated 
doesn't need to be that complex.

This could be (well, it _should_ be, stuff like array ops currently happens 
in the frontend) implemented completely in the glue layer of the compiler, 
with everything not supported just stubbed out. 



 Feb 11 2012



  parent reply Paulo Pinto <pjmlp progtools.org>  writes:


Am 11.02.2012 16:32, schrieb Daniel Murphy:

 This is actually probably not that difficult to do.

 A C backend for dmd would be quite difficult to make - but if you strip out
 most of the complex features that make it to code generation (exceptions,
 garbage collected memory, tls, classes, array ops, threading, floating
 point, typeinfo, destructors, postblits etc) then the actual code generated
 doesn't need to be that complex.


If you remove all of that then how good would D- be in regard with 
existing languages being used for the same tasks?

For example, MikroEletronica sells C, Basic and Pascal compilers that 
target everything from a small PIC up to big ARMs.

http://www.mikroe.com/eng/products/view/754/mikropascal-pro-for-arm/

I can also get Ada for embedded systems programming, which was actually
one of Ada's design goals,
http://www.adacore.com/home/products/gnatpro/development_solutions/embedded/?gclid=CJ-7yNeImK4CFUGIDgodXT4CJQ

So what does D- bring to the table, besides fragmenting the community?

--
Paulo



 Feb 12 2012



  parent reply "Daniel Murphy" <yebblies nospamgmail.com>  writes:


"Paulo Pinto" <pjmlp progtools.org> wrote in message 
news:jh7v08$2chs$1 digitalmars.com...

 If you remove all of that then how good would D- be in regard with 
 existing languages being used for the same tasks?


You still have all of D's compile-time magic, which I miss every time I need 
to do embedded programming.  You still have the simple syntax improvement. 
I would love to be able to do away with the preprocessor and 
stupidly_long_method_names_because_of_no_overloading_or_method_syntax.



 So what does D- bring to the table, besides fragmenting the community?


No need to fork the lanugage - just add a couple of pragmas and a basic C 
backend. 



 Feb 12 2012



 next sibling parent reply Paulo Pinto <pjmlp progtools.org>  writes:


Am 12.02.2012 11:55, schrieb Daniel Murphy:

 "Paulo Pinto"<pjmlp progtools.org>  wrote in message
 news:jh7v08$2chs$1 digitalmars.com...

 If you remove all of that then how good would D- be in regard with
 existing languages being used for the same tasks?


 You still have all of D's compile-time magic, which I miss every time I need
 to do embedded programming.  You still have the simple syntax improvement.
 I would love to be able to do away with the preprocessor and
 stupidly_long_method_names_because_of_no_overloading_or_method_syntax.


Overloading is also possible with C++.

I know compile-time magic is messy (to say the least) with C++, still it 
is already there.


 So what does D- bring to the table, besides fragmenting the community?


 No need to fork the lanugage - just add a couple of pragmas and a basic C
 backend.


How basic would this C backend be? Specially taking into account it 
would be one extra backend to support and not all embedded processors 
are even able to support full ANSI C even on this day and age.

I am just playing a bit the devil's advocate here, as I think our 
industry suffers a lot from the "Worse is Better" principle, and as such
one really needs to think about ROI when proposing new solutions for
problems with existing solutions, even if they aren't the best ones.

--
Paulo



 Feb 12 2012



 next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com>  writes:


"Paulo Pinto" <pjmlp progtools.org> wrote in message 
news:jh87aj$2upa$1 digitalmars.com...

 Overloading is also possible with C++.

 I know compile-time magic is messy (to say the least) with C++, still it 
 is already there.


Having D able to work on embedded platforms isn't going to enable anything 
that wasn't possible, it will just make it easier and more pleasant.


 So what does D- bring to the table, besides fragmenting the community?


 No need to fork the lanugage - just add a couple of pragmas and a basic C
 backend.


 How basic would this C backend be? Specially taking into account it would 
 be one extra backend to support and not all embedded processors are even 
 able to support full ANSI C even on this day and age.


Honestly, I don't really know.  I've never written a C backend before.  I 
know the compiler already has code to print expressions and statements back 
out as D code, and this is not incredibly complex.  I don't know if it's 
possible to really keep it simple, but if it is...

The great thing about it only being a backend is that it benefits from all 
the work that goes into the frontend, and that is where most of the 
development is these days.  Not trying to support all D features means a lot 
of code can be directly mapped to C code - if you take out everything on my 
list, how much stuff in D is actually not supported by C?


 I am just playing a bit the devil's advocate here, as I think our industry 
 suffers a lot from the "Worse is Better" principle, and as such
 one really needs to think about ROI when proposing new solutions for
 problems with existing solutions, even if they aren't the best ones.


Yeah well, I'm not really discussing this as a solution to anything, just 
something interesting to try out.  Nobody sane would try to make something 
that works on every microprocessor out there, but if it was pluggable and 
open source, maybe people would rather be writing D than C?  I know I would, 
even for extremely low-level stuff. 



 Feb 12 2012



  parent reply "Daniel Murphy" <yebblies nospamgmail.com>  writes:


Turns out I can't help myself:

https://github.com/yebblies/dmd/tree/microd
(the makefile changes are win32 only, but aren't very compilcated)

It compiles the following into cryptic c full of mangled names just fine:

__gshared int global = 3;

int main()
{
    uint x;
    foreach(i; 0..20)
    {
        x += i;
    }
    return 0;
}

Doesn't seem that hard.  Dmd would need support for 8/16 bit pointers and a 
few other things, but I think most of the customization could be done with 
some well-defined macros and per-architecture header files.  Some features 
are implemented in wrong part of the compiler, and will cause problems. 



 Feb 12 2012



 next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com>  writes:


On 12 February 2012 17:45, Daniel Murphy <yebblies nospamgmail.com> wrote:

 Turns out I can't help myself:

 https://github.com/yebblies/dmd/tree/microd
 (the makefile changes are win32 only, but aren't very compilcated)

 It compiles the following into cryptic c full of mangled names just fine:

 __gshared int global =3D 3;

 int main()
 {
 =A0 =A0uint x;
 =A0 =A0foreach(i; 0..20)
 =A0 =A0{
 =A0 =A0 =A0 =A0x +=3D i;
 =A0 =A0}
 =A0 =A0return 0;
 }

 Doesn't seem that hard. =A0Dmd would need support for 8/16 bit pointers a=


nd a

 few other things, but I think most of the customization could be done wit=


h

 some well-defined macros and per-architecture header files. =A0Some featu=


res

 are implemented in wrong part of the compiler, and will cause problems.


O_O


--=20
Iain Buclaw

*(p < e ? p++ : p) =3D (c & 0x0f) + '0';



 Feb 13 2012



  parent reply "Daniel Murphy" <yebblies nospamgmail.com>  writes:


"Iain Buclaw" <ibuclaw ubuntu.com> wrote in message 
news:mailman.287.1329145247.20196.digitalmars-d puremagic.com...

 O_O


=) Which bit's making you pull that face?  Is it the fact I think it might 
be a good idea or the fact I think it wouldn't be that hard?

It currently can translate:


import core.stdc.stdio;

__gshared int global = 3;

struct S
{
    int a;
    void fun()
    {
        printf("member a: %d\n", a);
    }
}

int main()
{
    uint x;
    foreach(i; 0..20)
    {
        x += i;
    }

    printf("%d\n", x);

    S y = S(7);
    y.a += 5;
    y.fun();
    return 0;
}

into



typedef struct __d_5testx1S __d_5testx1S;

__d_int _D5testx6globali;
struct __d_5testx1S
{
__d_int _D5testx1S1ai;
};
__d_int _Dmain();
__d_void _D5testx1S3funMFZv(__d_5testx1S* _D5testx1S3funMFZv4thisS5testx1S);

__d_int _D5testx6globali = 3;
__d_int _Dmain()
{
__d_uint _D5testx4mainFZi1xk = 0u;
for (__d_int _D5testx4mainFZi1ii = 0, _D5testx4mainFZi8__limit3i = 20;
(_D5testx4mainFZi1ii < _D5testx4mainFZi8__limit3i); (_D5testx4mainFZi1ii += 
1))
(_D5testx4mainFZi1xk += ((__d_uint)_D5testx4mainFZi1ii));
printf("%d\x0a", _D5testx4mainFZi1xk);
__d_5testx1S _D5testx4mainFZi1yS5testx1S = {7};
((_D5testx4mainFZi1yS5testx1S)._D5testx1S1ai += 5);
_D5testx1S3funMFZv(&_D5testx4mainFZi1yS5testx1S);
return 0;
}
__d_void _D5testx1S3funMFZv(__d_5testx1S* _D5testx1S3funMFZv4thisS5testx1S)
{
&*_D5testx1S3funMFZv4thisS5testx1S || __d_assert_msg(__d_array("null this", 
9), __d_array("testx.d", 7), 9);;
printf("member a: %d\x0a", 
(*_D5testx1S3funMFZv4thisS5testx1S)._D5testx1S1ai);
}


Looking at that, it seems I'd forgotten just how ugly C really is. 



 Feb 13 2012



  parent reply Iain Buclaw <ibuclaw ubuntu.com>  writes:


On 13 February 2012 15:31, Daniel Murphy <yebblies nospamgmail.com> wrote:

 "Iain Buclaw" <ibuclaw ubuntu.com> wrote in message
 news:mailman.287.1329145247.20196.digitalmars-d puremagic.com...

 O_O


 =3D) Which bit's making you pull that face? =A0Is it the fact I think it =


might

 be a good idea or the fact I think it wouldn't be that hard?


It's the fact that it does *nothing* to change code generation, as D
code compiles down to the same as C equivalent.


/* SNIP */


 Looking at that, it seems I'd forgotten just how ugly C really is.


Code represented like that is exactly what gdc emits to it's backend
for your example, albeit, a in a little bit more simplified language
(and a little bit more optimized once it goes through all codegen
passes =3D)

--=20
Iain Buclaw

*(p < e ? p++ : p) =3D (c & 0x0f) + '0';



 Feb 13 2012



  parent reply "Daniel Murphy" <yebblies nospamgmail.com>  writes:


"Iain Buclaw" <ibuclaw ubuntu.com> wrote in message 
news:mailman.288.1329151783.20196.digitalmars-d puremagic.com...

 It's the fact that it does *nothing* to change code generation, as D
 code compiles down to the same as C equivalent.


Isn't that what a C backend is supposed to do?


 Code represented like that is exactly what gdc emits to it's backend
 for your example, albeit, a in a little bit more simplified language
 (and a little bit more optimized once it goes through all codegen
 passes =)


That's a good point.  Maybe this effort would be better spent trying to 
build avr-gdc instead of the compiler centipede. 



 Feb 13 2012



  parent reply Iain Buclaw <ibuclaw ubuntu.com>  writes:


On 13 February 2012 17:22, Daniel Murphy <yebblies nospamgmail.com> wrote:

 "Iain Buclaw" <ibuclaw ubuntu.com> wrote in message
 news:mailman.288.1329151783.20196.digitalmars-d puremagic.com...

 It's the fact that it does *nothing* to change code generation, as D
 code compiles down to the same as C equivalent.


 Isn't that what a C backend is supposed to do?


My point is that D is low level / slick enough, that it generates
near-identical code to C/C++ in comparison benchmarks - recent example
I can recall, someone did a speed test on vectors in GDC vs G++, and
found both to be pretty much on par with each other.  Then again, I
wouldn't expect less when both use the same backend.



 Code represented like that is exactly what gdc emits to it's backend
 for your example, albeit, a in a little bit more simplified language
 (and a little bit more optimized once it goes through all codegen
 passes =3D)


 That's a good point. =A0Maybe this effort would be better spent trying to
 build avr-gdc instead of the compiler centipede.


I think it starts with a runtime library that is written for the given
architecture in mind.  The compiler is already there in my opinion,
and I have seen little reason for it not to be.

--=20
Iain Buclaw

*(p < e ? p++ : p) =3D (c & 0x0f) + '0';



 Feb 13 2012



  parent  "Daniel Murphy" <yebblies nospamgmail.com>  writes:


"Iain Buclaw" <ibuclaw ubuntu.com> wrote in message

 I think it starts with a runtime library that is written for the given
 architecture in mind.  The compiler is already there in my opinion,
 and I have seen little reason for it not to be.


Is the compiler really ready?

Assuming that it's possible to build gdc as (for eg) an avr cross compiler, 
you'll still need support for:
- 16 bit pointers
- program memory
- interrupts
- IO registers
- stripping out typeinfo/moduleinfo
- issuing errors for unsupported features
- inline assembler

If gdc can do most of this already, that's great - but I doubt it can do all 
of it. 



 Feb 13 2012



prev sibling  parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Sunday, 12 February 2012 at 17:45:46 UTC, Daniel Murphy wrote:

 Turns out I can't help myself:

 https://github.com/yebblies/dmd/tree/microd


hmmm....

Do you see anything wrong with using a similar strategy to


It might be a relatively easy way to get (a subset of) D
integrated into those environments.



 Feb 13 2012



  parent  "Daniel Murphy" <yebblies nospamgmail.com>  writes:


"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:rdluxkzwxsxlxfgcaqle dfeed.kimsufi.thecybershadow.net...

 On Sunday, 12 February 2012 at 17:45:46 UTC, Daniel Murphy wrote:

 Turns out I can't help myself:

 https://github.com/yebblies/dmd/tree/microd


 hmmm....

 Do you see anything wrong with using a similar strategy to


 It might be a relatively easy way to get (a subset of) D
 integrated into those environments.


C works because you can build all the high level features of D (classes, 
exceptions, etc) out of C and assembler.  You can build high-level features 
out of low-level ones, but not the other way around.  I don't know how 

pointers etc.  I'm not sure, but I think there might be some limitations in 
the underlying bytecode that prevents some of these things, and unlike C you 
can't drop down to assembler to fill in the gaps.

So I guess it depends on which features you want - you'd lose some of the 
low-level features, and might be unable to build the high-level features 
without them. 



 Feb 13 2012



prev sibling  parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 02/12/2012 12:20 PM, Paulo Pinto wrote:

 Am 12.02.2012 11:55, schrieb Daniel Murphy:

 "Paulo Pinto"<pjmlp progtools.org> wrote in message
 news:jh7v08$2chs$1 digitalmars.com...

 If you remove all of that then how good would D- be in regard with
 existing languages being used for the same tasks?


 You still have all of D's compile-time magic, which I miss every time
 I need
 to do embedded programming. You still have the simple syntax improvement.
 I would love to be able to do away with the preprocessor and
 stupidly_long_method_names_because_of_no_overloading_or_method_syntax.


 Overloading is also possible with C++.


So is garbage collection.


 I know compile-time magic is messy (to say the least) with C++, still it
 is already there.


I wouldn't go as far as to call it magic.


 So what does D- bring to the table, besides fragmenting the community?


 No need to fork the lanugage - just add a couple of pragmas and a basic C
 backend.


 How basic would this C backend be? Specially taking into account it
 would be one extra backend to support and not all embedded processors
 are even able to support full ANSI C even on this day and age.

 I am just playing a bit the devil's advocate here, as I think our
 industry suffers a lot from the "Worse is Better" principle,


Very true and very sad.


 and as such one really needs to think about ROI when proposing new solutions
for
 problems with existing solutions, even if they aren't the best ones.


The D philosophy is "The Right Thing". Therefore it is adequate to 
discuss better solutions for 'solved' problems on this NG.



 Feb 12 2012



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Daniel Murphy" <yebblies nospamgmail.com> wrote in message 
news:jh85rp$2rs4$1 digitalmars.com...

 "Paulo Pinto" <pjmlp progtools.org> wrote in message 
 news:jh7v08$2chs$1 digitalmars.com...

 If you remove all of that then how good would D- be in regard with 
 existing languages being used for the same tasks?


 You still have all of D's compile-time magic, which I miss every time I 
 need to do embedded programming.  You still have the simple syntax 
 improvement. I would love to be able to do away with the preprocessor and 
 stupidly_long_method_names_because_of_no_overloading_or_method_syntax.


Plus a module system that's actually sane.



 Feb 12 2012



  parent  Paulo Pinto <pjmlp progtools.org>  writes:


Am 12.02.2012 15:27, schrieb Nick Sabalausky:

 "Daniel Murphy"<yebblies nospamgmail.com>  wrote in message
 news:jh85rp$2rs4$1 digitalmars.com...

 "Paulo Pinto"<pjmlp progtools.org>  wrote in message
 news:jh7v08$2chs$1 digitalmars.com...

 If you remove all of that then how good would D- be in regard with
 existing languages being used for the same tasks?


 You still have all of D's compile-time magic, which I miss every time I
 need to do embedded programming.  You still have the simple syntax
 improvement. I would love to be able to do away with the preprocessor and
 stupidly_long_method_names_because_of_no_overloading_or_method_syntax.


 Plus a module system that's actually sane.


+1 on this one actually.

C, C++ and Objective-C are the only languages without proper module 
support. I really miss my Turbo Pascal days, where compilation was
just instantanious.

--
Paulo



 Feb 12 2012