Thoughts about D

[Neia Neutuladh]

On Monday, 27 November 2017 at 17:35:53 UTC, Ola Fosheim Grostad 
wrote:
> On Monday, 27 November 2017 at 16:44:41 UTC, Neia Neutuladh 
> wrote:
>> I last used C++ professionally in 2015, and we were still 
>> rolling out C++11. std::string_view is part of C++17. You're 
>> calling me stupid for not having already known about it. (Yes, 
>> yes, you were sufficiently indirect to have a fig leaf of 
>> deniability.)
>
> I'n not talking about you obviously. I am talking about using 
> languages stupidly...

You can ask your local HR representative how much better it is to 
say "your ideas are stupid" than "you are stupid".

> You could use GSL string_span or the array version span, or 
> write your own in 20 minutes. These are not language 
> constructs, but library constructs, so they dont speak to the 
> efficiency of the language...

Only for people who are happy to eschew the standard library, 
which pretty much just includes C++ users.

> C++ is very much batteries not included... Which is good for 
> low level programming.

So you're saying that having a body of well tested code that does 
what you want already but *might* be making performance tradeoffs 
that don't work for your use case, is *worse* than not having it.

Well, it's a heterodox opinion to be sure.

>> It is often useful to talk about real-world workloads when 
>> discussing performance.
>
> Well, in that case Java was sufficiently fast, so all languages 
> came out the same...

You might try reading my first post.

Java: 140ms to print "Hello world"

D: 50ms to turn a 400kb subtex document into an epub

> Assuming that your CPU can execute 20 billion instuctions per 
> second.  That means 1 billion per 50 ms, so your budget is 1 
> million instructions on 400 bytes? Doesnt that suggest that the 
> program is far from optimal or that most of the time is spent 
> on something else?

Again, you might try reading my first post. In it, I mentioned 
memory a lot, since allocating memory is relatively slow. I 
specifically called it out as the reason that the C# version of 
subtex was so slow. And allocating memory isn't slow simply 
because it requires executing a large number of instructions.