OT: Nature on the 'end' of Moore's Law

[Laeeth Isharc via Digitalmars-d]

On Tuesday, 16 February 2016 at 11:43:05 UTC, Joakim wrote:
> On Tuesday, 16 February 2016 at 10:20:57 UTC, Laeeth Isharc 
> wrote:
>> http://www.nature.com/news/the-chips-are-down-for-moore-s-law-1.19338
>
> Good news for D and other AoT-compiled languages, as software 
> will have to take up the slack.  Software has been able to get 
> much more inefficient over the years because the faster 
> hardware from Moore's law would come in and make it all run 
> just as fast.  Now, devs will have to actually start worrying 
> about efficiency in their code again.
>
> We've already seen Intel and x86 hit hard by the mobile shift, 
> because they cannot hit the performance to battery power ratio 
> that Qualcomm and other ARM vendors routinely hit, which is why 
> Intel has AMD-like share on mobile devices. :) I'm guessing 
> it's a similar situation for Microsoft with Windows, they just 
> couldn't get it turned around fast enough for mobile.
>
> This is going to affect inefficient programming languages in 
> the same way.

Seems likely.

If one treats a cheap resource as if it were free then eventually 
it won't be cheap anymore.

I doubt very much the phase transition is a consequence of market 
structure.  More like the natural way that technology unfolds 
(see Theodore Modis).  No doubt at some point something else will 
come along, but there may be an energy gap in the meantime.  A 
pity given data sets keep getting bigger.

GPU programming in D is just a matter of time.  People are ready 
to pay to sponsor it, and on the other hand I am familiar with 
people who have written such libraries and done GPU work in D.  
But there are many things to work on, and it's a matter of 
priorities.

If people who spent time moaning about D's perceived weaknesses 
would spend just a little time actually trying to make a 
contribution to improve things, we'd all be better off.  Amazing 
the importance of the work you have done, Joakim, when in the 
beginning I guess you were just trying to solve your own problem. 
  I wonder why others don't have this kind of constructive spirit.

I am reminded a bit of a close associate of Chuck Moore's very 
funny (although it turns out slightly unfair) comments on a 
particular colorforth enthusiast (and thereby language geeks in 
general):

http://yosefk.com/blog/my-history-with-forth-stack-machines.html

     Forth seems to mean programming applications to some and 
porting Forth or dissecting Forth to others. And these groups 
don't seem to have much in common.

     …One learns one set of things about frogs from studying them 
in their natural environment or by getting a doctorate in zoology 
and specializing in frogs. And people who spend an hour 
dissecting a dead frog in a pan of formaldehyde in a biology 
class learn something else about frogs.

     …One of my favorite examples was that one notable colorforth 
[a Forth dialect] enthusiast who had spent years studying it, 
disassembling it, reassembling it and modifying it, and made a 
lot of public comments about it, but had never bothered running 
it and in two years of 'study' had not been able to figure out 
how to do something in colorforth as simple as:

     1 dup +

     …[such Forth users] seem to have little interest in what it 
does, how it is used, or what people using it do with it. But 
some spend years doing an autopsy on dead code that they don't 
even run.

     Live frogs are just very different than dead frogs.

I guess I feel that I could say that if it isn't solving a 
significant real problem in the real world it isn't really Forth.