Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: BGB Newsgroups: comp.lang.java.programmer Subject: Re: Managed-Code Bloat Date: Tue, 07 Jun 2011 16:18:29 -0700 Organization: albasani.net Lines: 78 Message-ID: References: <%5nHp.987$SG4.99@newsfe03.iad> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: news.albasani.net LeB/+Y+WLMnVZ8b52sIs7mypGT3OifdgOyw/3yslm+H2ndKS4e4ef1CLUgN8R0ZupLLWVcg0bi0vNi7YXjDByg== NNTP-Posting-Date: Tue, 7 Jun 2011 23:21:48 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="JdmbAQ4EdaUCoEsu4Ts/YxNAlroR+hJI3JLCrOViS4AwWhKOkhmXFw09Z1MHjycA8fNlktuE6Ezb976M/WMpEnKHkMJz4g8+x13t+hBvc6SPF+jfTdDl72Izo+l0mmL3"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 In-Reply-To: <%5nHp.987$SG4.99@newsfe03.iad> Cancel-Lock: sha1:g2sNj8dlo6TiOBW7Y/WiRW8Q1Jo= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5077 On 6/7/2011 3:31 AM, Arved Sandstrom wrote: > On 11-06-06 07:17 PM, Lawrence D'Oliveiro wrote: >> In message, Joshua Cranmer wrote: >> >>> From a programming language design concept, one thing is abundantly >>> clear: manually-managed memory is a failure. >> >> And yet managed code has failed to take off in the mass market. Why is that? > > Dude, what do you consider to be managed code? It's not just .NET and > Java. Fact is, any language system that takes care of some details for > you that you need to deal with yourself in C or assembly has aspects of > management. This is a continuous spectrum, not an all or nothing. > > As Spolsky puts it, if your language lets you concatenate strings and > not worry about how it happens, you've got managed code. > >>> Most programmers--even the very best--have very little ability to prevent >>> memory from being leaked. That's why pretty much everyone accuses every >>> very large application written in native languages as acting like a leaky >>> bucket: Windows, Firefox, etc. >> >> And yet it is the “managed” apps that tend to be the memory hogs. > > Really? So C and C++ programs have never been accused of having memory > management issues. Interesting. > > There is actually some truth to your observation however. Again, not for > the reasons you think. Since when you said "managed" you really meant > Java and .NET, I'll confine my remarks to those also. Anyway, Java and > C#, among others, can be abused by incompetent or unschooled or ignorant > programmers just like any other language can. If a programmer is shabby > at programming, and more specifically, shabby at OOP, they'll write crap > in C++ *and* Java *and* C#. With a C++ app it'll probably crash within > minutes and very possibly never ship. With Java and C# a mediocre coder > is much more likely to be able to release his poor code - humans being > humans, such a coder will blame the language for bloat and slowness and > errors. > > If you run across a Java app that's a memory hog, why do you think it's > the fault of the language? It never occurred to you that it might be the > programmers? It's not like more than 25% (being charitable) of all > programmers working today should even be let near a keyboard, after all. > well, I think it actually partly goes both ways. while many programmers do suck... both Java and C# implement things in many cases, in ways which are fairly costly... for example, in C, a string is just a glob of 8-bit characters in memory, and so doesn't really take much more memory than the space to store these characters. in Java, a "String" is a class instance containing an array of 16-bit characters... just at the outset, this is a good deal more expensive (I calculated for my own technology, reaching an approx 7x difference for the memory cost of storing the string "Hello"). granted, the JVM may have a lower base overhead, and it will drop and approach 2x as the string gets longer (a lot of the overhead was mostly related to the cost of the object instance and array headers). but, even 2x is still a significant space overhead... (due to UTF-16 vs UTF-8...). also, there are many places internally where "new" will be used in copious amounts due to the basic design of the VM architecture, ... a lot of this is still likely not exactly free either, and a lot of this may add up... or such...