Article: New D language pumps up programmer productivity Options

[Sean Kelly]

Bill Baxter wrote:
> Jascha Wetzel wrote:
>> Bill Baxter wrote:
>>> Walter Bright wrote:
>>>> Article: http://www.linux.com/feature/124320
>>>>
>>>> Reddit: http://programming.reddit.com/info/65uh7/comments/
>>>>
>>>> Digg:
>>>> http://digg.com/programming/D_programming_language_pumps_up_programmer_productivity
>>>>
>>>
>>> Note in the comments how someone (not me I promise!) latches on to
>>> the specious arguments in the FAQ for why strings need to be included
>>> as a language feature.  Those dubious arguments should be removed.  A
>>> better argument is that it allows compile-time string manipulation.
>>
>> i'm not argumenting against that, but i think it's rather impressive,
>> that the mere inclusion of std::string and std::vector bloats a single
>> c++ file to >480kb after preprocessing. considering the simple and
>> fundamental nature of these things, that is already bad enough for me
>> to want built-in dynamic arrays and strings.
> 
> That's a fine argument too.  But just saying "it's 4000 lines of code
> therefore it must be buggy" is weak, considering the amount of testing
> std::string and std::vector get and the amount of resources poured into
> providing STL implementations.  I'd be much more likely to believe 100
> lines of D compiler source code is buggy than 4000 lines of a mainstream
> STL, simply because the STL has had *orders of magnitude* more use than
> DMD.

std::string and std::vector aren't terribly complex to implement either.
 In my experience, the only real sticking point in implementing STL
containers is having to use STL allocators, which makes the code a bit
more complex/weird than it would be otherwise.  But this is really only
an issue once, since the same technique applies to all containers.

That said, 480k is a pretty big deal for something so fundamental.  The
entire D runtime occupies around 70k.


Sean