February 11, 2012
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"

February 11, 2012
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 handles in C++/CX. Then there is also C# for systems programming, when 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
February 11, 2012
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
February 11, 2012
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
February 11, 2012
"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++!!!!


February 11, 2012
"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.


February 11, 2012
"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.


February 11, 2012
"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.


February 11, 2012
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.


February 11, 2012
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