D-

[Nick Sabalausky]

"Jacob Carlborg" <doob at me.com> wrote in message 
news:jh63p2$17li$1 at digitalmars.com...
> On 2012-02-11 15:36, Nick Sabalausky wrote:
>> "Era Scarecrow"<rtcvb32 at yahoo.com>  wrote in message
>> news:jzavmzbmjoyujhqyfvhp at 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.