Iterators and Ranges: Comparing C++ to D to Rust

[Ola Fosheim Grøstad]

On Wednesday, 16 June 2021 at 10:20:05 UTC, Dukc wrote:
> That would explain it if the programs were as slow as before, 
> but Petar also complained about programs that are even slower. 
> There has to me more.
>
> It could be survivourmanship bias. Perhaps we just don't 
> remember the slower programs from the old days.

Yes, maybe. There might be other factors too:

1. Business people are more present as leaders now (whereas it 
used to be engineers advancing to leadership positions). As a 
result engineering quality is not appreciated to the same level. 
My opinion. You see this with Apple products too, the surface 
stuff is being focused on in their presentations. Fancy surface, 
boring interior.

2. People have become used to using web applications, so they 
have become used to latency (lag) when interacting with a system. 
Thus, the end users may not think about why an application is 
sluggish (as they don't understand the difference between slow 
code and network lag). So users expect less? This is especially 
true when you go to the 90s where Amiga users were predominantly 
geeks, and thus more demanding.

3. Programmers have become less proficient and fail to think of 
how the code they write  maps down through layers of libraries 
all the way down to CPU/GPU. Of course, more layers also makes 
this more difficult. I think many programmers now have the 
framework they use as their mental model, and not really the 
actual computer hardware.


> I think that computers (and internet connections) differ in 
> power more than they used to. The alternative explanation might 
> be that developers with powerful computers don't notice as 
> easily how slow stuff they are making.

Yep, developers should use the low end computers the application 
targets for executing their code.


> Then again, it also might be more competition as industry gets 
> bigger => tighter deadlines and less slack => software getting 
> done worse and worse.

But more competition should lead to better quality... The problem 
with this (also for other sectors) is that for capitalism to work 
well for engineered products the consumer has to be knowledgable, 
demanding and be willing to shop around. But human beings tend to 
go with the flow (fashion, marketing, social peers) when they are 
making choices on things they have limited knowledge and interest 
in. Audio software is still pretty good, for instance. I assume 
this is because consumers in that market have a fairly good 
understanding of what to expect.


> Not everything. You're certainly familiar with the D principle 
> for being BOTH a systems programming and application 
> programming language. It follows that the standard library 
> should cater for both cases, so large parts of the standard 
> library should be handy for systems programming but not 
> everything, because that would drive application programmers 
> away.
>
> And Phobos is on the right track. There are shortcomings, but 
> nothing is fundamentally wrong from systems programming 
> perspective. D ranges are totally usable at system level. I've 
> used them myself when compiling to WebAssembly, where the D 
> ecosystem is (currently) just as primitive as on some 
> microcontroller.


I understand where you are coming from,  and I agree that D/C++ 
ranges can be used for system level programming (at least as a 
starting point).

I still think everything in the standard lib should be useful for 
system level programming, so you don't have to reconsider your 
options because of standard lib deficiencies half way through.

What is needed in addition to that is a standardized application 
level library built on top of the standard library. This could 
ship with the compiler and be defined in terms of APIs (so 
different compilers can optimize the implementation for their 
backend).

Or maybe even an application framework (with keyboard, mouse, 
graphics apis).

I think it is better with a more layered eco-system of 
standardized library APIs than one big monolithic standard 
library.