One area where D has the edge

[Laeeth Isharc via Digitalmars-d]

>  I cannot speak about small team experiences. Our projects 
> usually take around 30+ developers.

That it is a decent sized team to have to coordinate and it puts 
emphasis on very different questions.  The context I am thinking 
of is much leaner - more like special forces than the regular 
army (I mean in terms of flexibility and need to respond quickly 
to changing circumstances) - although the sums at stake are 
likely comparable to larger teams (the area is hedge fund 
portfolio management).

> In terms of server applications, yes when the applications are 
> deployed usually the memory usage might not be optimal.

For you that is less important, and I suppose that comes from the 
intrinsic nature of the situation.  You have beefy machines 
serving many users, I suppose?  I am thinking of a purpose where 
there are only a handful of users, but the data sets may be 
larger than we are used to working with, requiring more work than 
just plain map reduce, and where rapid iteration and prototyping 
is important.  Also to minimize cognitive overload and complexity.

A friend has written an article on big data in finance for Alpha 
magazine, and I will post a link here once it has been published. 
  One problem in economics is you have to forecast the present, 
because the numbers are published with a lag and themselves 
reflect decisions taken months previously.  But markets are 
forward looking and discount a future that may be imagined but 
cannot be understood based only on hard facts.

So we need all the help we can get, particularly during an epoch 
where things change all the time,  (eurchf fx rate moved forty 
percent in a day...). Bridgewater have taken the work of Hal 
Varian and applied it to use media and web analytics to get a 
good live cut of economic activity and inflation.  Although it is 
not a tough problem theoretically, people don't actually do as 
much as they could yet - I think finance is behind tech 
companies, but they are catching up.  Another fund that my friend 
writes about uses employee sentiment to pick stocks to be long 
and short of - they manage a few billion and have done quite well.

> However that is why profiling and language knowledge is 
> required.

Yes, I can imagine, and it sounds like not just that Java is the 
best option for you, but perhaps the only viable one.  I am 
curious though - what do you think the memory footprint is as a 
ratio to C++ before and after fine tuning?  And what proportion 
of development time does this take?

> Fine tuning a Java application is no different than other 
> compiled languages, it just requires to know which knobs to 
> turn.

I liked a quote by a certain C++ guru talking about the 
experience of a Facebook, to the effect that a sensible first 
draft written in C++ would perform decently, whereas this was not 
true always of other languages.  Now their trade off between 
programmer productivity and execution efficiency is extreme, but 
is this merely an edge case of little relevance for the rest of 
us, or is it a Gibsonian case of the future being already here, 
and just not evenly distributed?  I am no expert, but I wonder if 
the latter may be more true than generally appreciated.

> For example, foreach allocates and a simple for does not, so 
> choose wisely how to iterate.

Would love to hear any other insights you have on this topic.  
There ought to be a FAQ on getting along with the GC for fun and 
profit.

> The thing that Java still looses in memory management, even in 
> commercial JVMs, is lack of value types since escape analysis 
> algorithms are not very aggressive, but support is being 
> designed and will land partially in Java 9 and Java 10 time 
> frame.

That was my real point - and that it does really matter in some 
areas, and that these are growing very quickly.  (I appreciate 
that someone reading my post quickly would see the 15% power 
thing and focus on that, which was not so much my point - 
although I am still suspicious of the idea that Java will always 
keep up with native code without doing a lot of extra work).

People on the Slashdot thread were saying what is the point of D. 
  But the way I saw it, where is the real competition for my use 
case?  I can't be extravagant with memory, but I still need rapid 
development and productivity.  We all have a tendency to think 
that what we know from experience and reading is the full 
picture, but the world is a big place, and something needs to 
appeal to someone to grow, not necessarily to oneself personally

The C++ integration is the remaining piece.  Otherwise it is like 
the old Soviet Union - this is the factory that makes the steel 
that builds the factory that makes the steel that... so that 
Vladimir may have a new car.  Ie one spends too much time in 
roundabout investment before one actually reaps the benefit of 
higher productivity.


> So by Java 10 according to the planned features, there will be 
> value types and even the open source JVM will have some form of 
> JIT cache. Including the large amount of available libraries.
>
> As for D, it surely has its place and I am looking forward to 
> language adoption.


Out of interest, what do you see as characterising this place 
(abstracting away from things that are not perfect now, but will 
probably be fixed in time)?  And in an enterprise environment, 
what would you use D for today?


Laeeth.