D-

[q66]

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 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.

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