Look and think good things about D

Ary Borenszweig ary at esperanto.org.ar
Fri Nov 15 05:11:44 PST 2013


On 11/15/13 9:47 AM, bearophile wrote:
> Ary Borenszweig:
>
>> Here's what I was able to do in some minutes:
>>
>> ---
>> if ARGV.length != 1
>>   puts "missing argument: n"
>>   exit 1
>> end
>>
>> n = ARGV[0].to_i
>> str = "1"
>> buffer = String::Buffer.new(20)
>> n.times do
>>   puts str.length
>>   str.each_chunk do |digit, count|
>>     buffer << '0' + count
>>     buffer << digit
>>   end
>>   str = buffer.to_s
>>   buffer.clear
>> end
>>
>> With n=70 it takes about 4.89s. With n=45 it takes about 0.012s.
>
> This program is much longer in number of tokens to the first D program.
> You can write a D program about as fast as this in about the same number
> of tokens.

No. I just counted the tokens and D has more tokens:

http://pastebin.com/XZFf8dsj

It's even longer if I keep all the programs arguments checking (ARGV). 
If I remove that, the program has 45 tokens. The D version has 81 
tokens. And without the imports, D still has 68 tokens.

(well, I didn't count newlines as tokens, so maybe that's unfair because 
newlines in Crystal are significant)

Yes, it's not as functional as D. But only because the language is still 
young.

>
> Perhaps I should add an intermediate third version that shows code
> that's not as extreme as the two versions there. Thank you for the
> implicit suggestion.
>
>
>> And with Crystal you could do the second version as well, because you
>> have access to low level stuff like pointers.
>
> In Crystal do you have final switches, gotos, etc too?

No. In this D will always be better, if you really want your program to 
have gotos.

>> And also, the language is pretty new so there's still
>> a lot of optimizations to be done.
>
> And LDC2 will improve in the meantime.

And so LLVM, which is what Crystal uses as a backend.

>
>
>> I also thought ranges were pretty fast because of their nature.
>
> It also matters a lot how you use them, this is normal in computer
> programming.

But I thought ranges were meant to be fast. No allocations and all of 
that. In fact, I was kind of sad that Crystal doesn't have a similar 
concept so it could never get as fast as D ranges. But if D ranges are 
not fast, what's the point of having them and making everyone use them?

>
>
>> Why are they slow in this example?
>
> Just because the first example is not written for speed, I didn't even
> add run-time timings for it at first. And it's not that slow.

Ah, I thought you did. So I misunderstood your timings. Sorry.

>
> Bye,
> bearophile



More information about the Digitalmars-d mailing list