On Monday, 26 January 2015 at 20:55:14 UTC, Wyatt wrote:
> On Monday, 26 January 2015 at 20:19:09 UTC, Laeeth Isharc wrote:
>>
>> Does Rust have the productivity of D?  And it doesn't have the maturity, as I understand it.
>
> This brings up something that's been bugging me.  D has a pitch for users of a lot of crappy languages, but what do we say when the competition isn't a total slouch?
>
> This exchange (names changed) is what started this train of thought:
> <chum> though i don't understand what the point of D is either because once you've already accepted a gc there are better languages you could use
> <chum> and if you refuse to accept one, then, well, you either have c++11 or you wait for rust to be usable
> <otherguy> chum: what is better than D once youre willing to have managed mem?
> <chum> it's functional, but the complaint all the gamedev folks have about fp langs is that their implementations are usually garbage collected and they can't accept gc pauses
> <chum> otherguy: f#, ocaml, haskell
>
> Particularly against F#, I'm not sure what to say (it's a pretty interesting language, even if it's kind of ugly to look at and CIL-ly).  Thoughts?
>
> -Wyatt

Which language today does something that's not done by any other language?

On Monday, 26 January 2015 at 22:53:15 UTC, Paulo Pinto wrote:
> On Monday, 26 January 2015 at 22:12:24 UTC, Laeeth Isharc wrote:
>> " If Java consumes 15% more power doing it, does
>>>> it matter on a PC? Most people don't dare. Does it matter for small-scale server environments? Maybe not. Does it matter when you deploy Hadoop on a 10,000 node cluster, and the holistic inefficiency (multiple things running concurrently) goes to 30%? Ask the people who sign the checks for the power bill. Unfortunately, inefficiency scales really well.
>>>
>>> No, Java does not consume 15% doing it, because there isn't just one implementation of Java compilers.
>>>
>>> Most comercial JVMs do offer the capability of ahead of time native code compilation or JIT caches.
>>>
>>> So when those 15% really matter, enterprises do shell out the money for such JVMs.
>>>
>>> Oracle commercial JVM and the OpenJDK are just the reference implementation.
>>
>> Thanks for the colour.  (For clarity, the content from the link wasn't by me, and I meant the general gist rather than the details).  How do commercial JVMs rate in terms of memory usage against thoughtful native (D) code implementations?  Is the basic point mistaken?
>
>
> So far I just dabbled in D, because our customers choose the platforms, not we.
>
> However, these are the kind of tools you get to analyse performance in commercial JVMs,
>
> http://www.oracle.com/technetwork/java/javaseproducts/mission-control/java-mission-control-1998576.html
>
> http://www.oracle.com/technetwork/server-storage/solarisstudio/features/performance-analyzer-2292312.html
>
> Just providing the examples from Oracle, other vendors have similar tools.
>
> With them, you can drill down the whole JVM and interactions at the OS level and find performance bottlecks all the way down to generated Assembly code.
>
>
> As for memory usage, Atego JVMs run in quite memory constrained devices.
>
> Here is the tiniest of them, http://www.atego.com/products/atego-perc-ultra/
>
> --
> Paulo

There was also this one from 1998 that was very small

http://www.javaworld.com/article/2076641/learn-java/an-introduction-to-the-java-ring.html

Java has some history running on small devices.

Cheers,
uri

On Tue, 2015-01-27 at 04:50 +0000, uri via Digitalmars-d wrote:

> 
> Java has some history running on small devices.

And, after all, Java (née Oak) was invented for programming white goods operating systems. Also set top boxes. The first tablet, Star7, appeared long before iPad.

FTR JavaCard has almost, but not quite, nothing to do with Java. A bit like JavaScript.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

> There was also this one from 1998 that was very small
>
> http://www.javaworld.com/article/2076641/learn-java/an-introduction-to-the-java-ring.html
>
> Java has some history running on small devices.
>
> Cheers,
> uri

Indeed, and I remember that well.

However I was less interested in embedded devices and what java could do under conditions of small memory, and more interested in its memory efficiency on servers in managing much larger data sets.  Since it seems to me we are still early in the unfolding of current trends, and what is true today mostly for google and Facebook may be more widely true for others tomorrow.

I do appreciate that java is comparable in execution speed to native code in many cases.  Is its memory footprint really comparable?  And if you have a small team, and not much time, how does that change things - D vs Java?  I don't think for D GC matters so much as not real time and you can easily preallocate buffers.

But don't let me stop you talking about small devices.

On Tuesday, 27 January 2015 at 06:08:34 UTC, Laeeth Isharc wrote:
>
>
>> There was also this one from 1998 that was very small
>>
>> http://www.javaworld.com/article/2076641/learn-java/an-introduction-to-the-java-ring.html
>>
>> Java has some history running on small devices.
>>
>> Cheers,
>> uri
>
> Indeed, and I remember that well.
>
> However I was less interested in embedded devices and what java could do under conditions of small memory, and more interested in its memory efficiency on servers in managing much larger data sets.  Since it seems to me we are still early in the unfolding of current trends, and what is true today mostly for google and Facebook may be more widely true for others tomorrow.
>
> I do appreciate that java is comparable in execution speed to native code in many cases.  Is its memory footprint really comparable?  And if you have a small team, and not much time, how does that change things - D vs Java?  I don't think for D GC matters so much as not real time and you can easily preallocate buffers.
>
> But don't let me stop you talking about small devices.

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

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

However that is why profiling and language knowledge is required.

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

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

If scratch arrays are required multiple times, just allocate it once for the complete lifetime of the class.

Always use StringBuilder for string manipulations.

And many other tricks.

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.

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.

--
Paulo

On Monday, 26 January 2015 at 22:05:55 UTC, Laeeth Isharc wrote:
>
> I don't know F#.  I know what you mean, but I don't think the competition to D consists of crappy languages - there are some very smart and creative people with large resources working on them (putting aside the question of the tone one should adopt in public towards peers).
>
That's exactly what I'm saying.  Against C or C++, D looks fantastic.  But those aren't great languages.  But what's the argument for D beyond that?  How can people using non-awful languages be persuaded to even have interest?

> It's not for me to say, but D isn't a product like toothpaste where you are trying to elbow aside the competition, but one where it needs to be the best 'D' it can be, and communicate that well to people and make it easy for them to take advantage of what it has to offer.

And that's what bugs me; that even if D is good and has a lot to offer, the pitch doesn't communicate it well.  The important part of that exchange that I hoped people would fixate on was this:

"I don't understand what the point of D is either because once you've already accepted a GC there are better languages you could use."

This indicates to me that there's a problem of messaging.

On Tuesday, 27 January 2015 at 02:39:03 UTC, bachmeier wrote:
>
> Which language today does something that's not done by any other language?

INTERCAL has politeness.  But what are you actually trying to say with this statement?

-Wyatt

>  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.

On Tuesday, 27 January 2015 at 13:02:06 UTC, Wyatt wrote:
> On Monday, 26 January 2015 at 22:05:55 UTC, Laeeth Isharc wrote:
>>
>> I don't know F#.  I know what you mean, but I don't think the competition to D consists of crappy languages - there are some very smart and creative people with large resources working on them (putting aside the question of the tone one should adopt in public towards peers).
>>
> That's exactly what I'm saying.  Against C or C++, D looks fantastic.  But those aren't great languages.  But what's the argument for D beyond that?  How can people using non-awful languages be persuaded to even have interest?

You will rarely hear me use the argument from popularity, but to recognise the triteness of saying they must be doing something right is not to say that people switching from C family cannot provide a nice source of fuel for D given the size of their language base, and the size of ours.  A language doesn't need to be all things to all people, just to be the best version of what it is meant to be, and to communicate that.

> And that's what bugs me; that even if D is good and has a lot to offer, the pitch doesn't communicate it well.  The important part of that exchange that I hoped people would fixate on was this:

I fully agree.  But a teenager is not as poised as the young woman she grows into.  And it may be more important at one stage in life to focus on homework than popularity.  The more complex a creature is, the longer it may take to reach full maturity.  It would have been bad for D to be 50x as popular at this stage because that would have hurt its quality.  Too much noise, politics, and lowest common denominator stuff comes with being prematurely popular.  Also often self satisfaction and complacency.

You can't say that there has not been a frenzy of emphasis on presentation and cleanup in the past months.  A long way to go to be sure, but the journey has started.  One sinks a lot of work into something before seeing results - make a note in your diary for 2018 and look back and tell me the situation is not radically better...

> "I don't understand what the point of D is either because once you've already accepted a GC there are better languages you could use."
>
> This indicates to me that there's a problem of messaging.

Especially wrt GC, and memory management where it is a highly technical topic that depends on the use case, and where it is hard to know the situation for you before having experience of the language.  So FUD is very effective, and people love to explain why the kid on the fringe deserves his status because it makes them feel better about themselves.  And there is this tribal sense of GC as a Shibboleth - I am a native programmer, and I don't use GC.  (As Walter said, he used to think GC was for loser programmers who couldn't manage memory like a man - my paraphrase).

If one reads the threads on GC (and I have been doing so the past days), one hears mostly from gaming programmers.  That's an important market deserving of respect, and handy as a stress case for the language.  But its a small part of total potential use case domain, and I would love to hear more accounts of how people are managing fine with the GC as it is.  There were some insightful posts by Adam Ruppe, and we should pull them out into a GC wiki FAQ.



Laeeth.

On Tuesday, 27 January 2015 at 13:02:06 UTC, Wyatt wrote:

> On Tuesday, 27 January 2015 at 02:39:03 UTC, bachmeier wrote:
>>
>> Which language today does something that's not done by any other language?
>
> INTERCAL has politeness.  But what are you actually trying to say with this statement?
>
> -Wyatt

Looks like I didn't post my full message. The point I intended to make is that it's hard to make a pitch like that. It used to be that for Lisp or some other language you could sell it by talking about features that aren't easily found in other languages. Today, every feature is implemented by numerous other languages, so you really have to try a language in order to know how it compares. In short, you can't convince someone that's discussing languages at that level.

On Tuesday, 27 January 2015 at 15:09:36 UTC, Laeeth Isharc wrote:
>> 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).

Out of curiosity, what is lacking in the current commercial offerings for hedge fund management? Why not use an existing engine?

Also, why D? Why not use a language or platform designed for scalability and distributed computing like http://chapel.cray.com/ ?