As you say Not for:
"Real time programming where latency must be guaranteed",

I haven't spent any time with the language except for a quick read of the DDJ article but D looks a lot like the vapor-ware language I have been designing in my head for the last year (I am not a compiler writer, I do real-time programming) except that you have garbage collection. Why couldn't garbage collection be designed to run as a low-priority background task? Real time programming requires deterministic behavior but we almost always have some dead-time. We have recently started to use C++ for real-time programming and of course we have a very fat programming guidelines manual.

I don't think the language itself has to be open source but the definition must absolutely be. I like to see both open source compilers like GNU and commercial ones like Greenhills. GNU keeps the commercial guys "honest".

Either way good luck with your language, the world doesn't need another slow VM language.

     Mark

"Mark T" <mt@nospam.com> wrote in message news:a181j1$1hj6$1@digitaldaemon.com...
> As you say Not for:
> "Real time programming where latency must be guaranteed",
>
> I haven't spent any time with the language except for a quick read of the DDJ article but D looks a lot like the vapor-ware language I have been designing in my head for the last year (I am not a compiler writer, I do real-time programming) except that you have garbage collection. Why
couldn't
> garbage collection be designed to run as a low-priority background task?

Nobody has figured out how to make that work!

> Real time programming requires deterministic behavior but we almost always have some dead-time. We have recently started to use C++ for real-time programming and of course we have a very fat programming guidelines
manual.
>
> I don't think the language itself has to be open source but the definition must absolutely be. I like to see both open source compilers like GNU and commercial ones like Greenhills. GNU keeps the commercial guys "honest".
>
> Either way good luck with your language, the world doesn't need another
slow
> VM language.

Thanks!

> > As you say Not for:
> > "Real time programming where latency must be guaranteed",

Maybe this could be changed to :

"Real time programming is not in spec, but could be in the future". This could be a point of competition between many implementations of language.

"Walter" <walter@digitalmars.com> wrote in message news:a187tl$1lm7$1@digitaldaemon.com...
>
> "Mark T" <mt@nospam.com> wrote in message news:a181j1$1hj6$1@digitaldaemon.com...
> > As you say Not for:
> > "Real time programming where latency must be guaranteed",
> >
> > I haven't spent any time with the language except for a quick read of
the
> > DDJ article but D looks a lot like the vapor-ware language I have been designing in my head for the last year (I am not a compiler writer, I do real-time programming) except that you have garbage collection. Why
> couldn't
> > garbage collection be designed to run as a low-priority background task?
>
> Nobody has figured out how to make that work!
>
Several Java implementaions do have semi realtime behaviour,
Insignia for instance have a fully concurrent garbage collector,
the requirement on the OS is that you can place return barriers onto someone
elses stack and can see another threads stacks.
it is also not as simple as having the GC as a low prority task, there are
times when GC much run (if you are geting low on memory becuase there are a
lot of unclaimed objects)
some of these can be solved by allowing the real time thread to interact
with the GC, either triggering it early, or allowing a thread to not be
paused for a given time, but there can still be condidtions when the GC will
be unable to finish before the realtime thread requires it time slice back.
(concurrent and incremental GC do go partway to solving this)
there is also problems with heap management, Java had a realtime extension
that allowed a thread to preallocate memory (basically a thread local cache)
that would the satisfy allocations within a determined time. but only if
only that memory was used.

depending on how realtime you want to be,  you can do it,
I wrote, and have seen running a serial UART interrupt handler that was
written in Java, It was on VxWork x86 and was used by Insignia as a demo of
how realtime Java could be.. policeing the allowable operations was the
biggest hurdle in Java.

IMHO, if D as a language want to get popular commersial appeal it has to make public the interface to the GC, and allow people access to implement their own GC stratergies.

Mike

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:a2h51p$1f4p$1@digitaldaemon.com...
> IMHO, if D as a language want to get popular commersial appeal it has to make public the interface to the GC, and allow people access to implement their own GC stratergies.

There won't be any barrier to this. Even in the alpha version, complete source to the gc is included.