Conspiracy Theory #1

[Travis Boucher]

Sean Kelly wrote:
> retard Wrote:
> 
>> Thu, 19 Nov 2009 11:47:46 -0800, Bill Baxter wrote:
>>
>>
>>> It seems to me that MS expects C++ to go the way of FORTRAN and
>>> COBAL.  Still there, still used, but by an increasingly small number of
>>> people for a small (but important!) subset of things.  Note how MS still
>>> hasn't produced a C99 compiler. They just don't see it as relevant to
>>> enough people to be financially worthwhile.
>> Even the open source community is using more and more dynamic languages 
>> such as Python on the desktop and Web 2.0 (mostly javascript, flash, 
>> silverlight, php, python) is a strongly growing platform. I expect most 
>> of the every day apps to move to the cloud during the next 10 years. 
>> Unfortunately c++ and d missed the train here. People don't care about 
>> performance anymore. Even application development has moved from library 
>> writing to high level descriptions of end user apps that make use of high 
>> quality foss/commercial off-the-shelf components. Cloud computing, real-
>> time interactive communication, and fancy visual look are the key 
>> features these days.
> 
> Performance per watt is a huge issue for server farms, and until all this talk of low power, short pipeline, massively parallel computing is realized (ie. true "cloud computing"), systems languages will have a very definite place in this arena.  I know of large-scale Java projects that go to extreme lengths to avoid garbage collection cycles because they take upwards of 30 seconds to complete, even on top-of-the-line hardware.  Using a language like C remains a huge win in these situations.

This I agree with to a certain degree.  This really only applies to 
colocated systems.  Shared hosting situations, users are often too 
stupid to understand the effects of crap code, and shared hosting 
providers tend to over commit machines.

Then comes in the virtualization providers, Amazon EC2 being a perfect 
example.  As long as income is greater then costs, EC2 users rarely get 
their code running as well as it could, even tho they'd see the most 
direct cost savings from doing so.  With today's web languages, the cost 
to make something efficient and fast (and maintain, debug, etc) is 
higher then the cost to run slow crappy code.

This is amplified by the loss of money in an emerging market where 
coming out even a month after your competitors could mean your death.

Languages like D (and even java and erlang to some degree) had the 
opportunity to change this trend 10-15 years ago when scalable clusters 
were not a common thing.  However, with the direction the web has gone 
in the past 5-10 years, to more 'web applications' the opportunity might 
come again.  We just need 'derail' all of those ruby kids, and get some 
killer web application framework for D.

Personally, I hate the Interwebs, and I don't care if it collapses under 
its own bloated weight.  As long as I still have some way of accessing 
source code.

> Even in this magical world of massively parallel computing there will be a place for systems languages.  After all, that's how interaction with hardware works, consistent performance for time-critical code is achieved, etc.  I think the real trend to consider is that projects are rarely written in just one language these days, and ease of integration between pieces is of paramount importance.  C/C++ still pretty much stinks in this respect.

Yes, the days of multi-cpu, multi-core, multi-thread hardware is here. 
I recently got a chance to do some work on a 32 hardware thread sun 
machine.  Very interesting design concepts.

This is where languages like erlang have an advantage, and D is heading 
in the right direction (but still quite far off).  D at least has the 
ability to adapt to these new architectures, where as C/C++ will soon be 
dealing with contention hell (they already do in some aspects).

The idea of a single machine with 100+ processing contexts (hardware 
threads) is not something in the distant future.  I know some of the sun 
machines (T5240) already can do 128 hardware threads in a single 
machine.  Add in certain types of high bandwidth transferring (rdma 
infiniband for example), and the concepts of things like Mosix and 
erlang and we'll have single processes with multiple threads running on 
multiple hardware threads, cores, cpus and even machines.