Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Managed-Code Bloat

Reply
Thread Tools

Managed-Code Bloat

 
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      06-06-2011
Came across this item
<http://www.itwriting.com/blog/3385-lessons-from-evernotes-flight-from-net.html>
about how Evernote for Windows abandoned WPF and Dotnet when moving from
version 3.5 to 4.0, with the result that

On our test hardware, Evernote 4 starts five times faster, and uses half
the memory of Evernote 3.5.

The whole managed-code/auto-garbage-collected concept may really appeal to
corporate code-cutter types, but I think it has real trouble in the mass
market.
 
Reply With Quote
 
 
 
 
Arved Sandstrom
Guest
Posts: n/a
 
      06-06-2011
On 11-06-06 03:47 AM, Lawrence D'Oliveiro wrote:
> Came across this item
> <http://www.itwriting.com/blog/3385-lessons-from-evernotes-flight-from-net.html>
> about how Evernote for Windows abandoned WPF and Dotnet when moving from
> version 3.5 to 4.0, with the result that
>
> On our test hardware, Evernote 4 starts five times faster, and uses half
> the memory of Evernote 3.5.
>
> The whole managed-code/auto-garbage-collected concept may really appeal to
> corporate code-cutter types, but I think it has real trouble in the mass
> market.


Did you read the whole article? Right at the end the author says:

"The development team lacks the resources to build equivalent
functionality in native code.

"The last point is important. Maybe a hotshot team of C/C++ developers
could make a better job, but if you don’t have such a team or the money
to hire it, it is not so relevant."

In other words, and this has nothing whatsoever to do with corporate
software, unless you're in that 5 percent (probably less) of current
programmers who can write high-quality C++, you're much better off
sticking with VB.NET or C#, Java, Python, and Ruby (all of these are
managed code in the spirit of the term).

Point being, these "managed" languages have made the mass market
possible. The "whole managed-code/auto-garbage-collected concept" is the
only reason over 90 percent of these "mass market" apps can even exist.

Overall, maybe you really should have read the entire article. I'd also
bet you've never used WPF, so you have no idea what *it* brings to the
table compared to MFC or WinForms. Or for that matter Qt or GTK++.

AHS
 
Reply With Quote
 
 
 
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      06-06-2011
In message <yg1Hp.353$(E-Mail Removed)>, Arved Sandstrom wrote:

> Right at the end the author says:
>
> "The development team lacks the resources to build equivalent
> functionality in native code.
>
> "The last point is important. Maybe a hotshot team of C/C++ developers
> could make a better job, but if you don’t have such a team or the money
> to hire it, it is not so relevant."
>
> In other words, and this has nothing whatsoever to do with corporate
> software, unless you're in that 5 percent (probably less) of current
> programmers who can write high-quality C++, ...


Maybe that’s the point: such skills are less common among corporate types.

> Point being, these "managed" languages have made the mass market
> possible.


And yet most mass-market apps avoid them.
 
Reply With Quote
 
Joshua Cranmer
Guest
Posts: n/a
 
      06-06-2011
On 06/06/2011 02:47 AM, Lawrence D'Oliveiro wrote:
> The whole managed-code/auto-garbage-collected concept may really appeal to
> corporate code-cutter types, but I think it has real trouble in the mass
> market.


From a programming language design concept, one thing is abundantly
clear: manually-managed memory is a failure. 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.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
 
Reply With Quote
 
Alessio Stalla
Guest
Posts: n/a
 
      06-06-2011
On 6 Giu, 17:35, Joshua Cranmer <(E-Mail Removed)> wrote:
> On 06/06/2011 02:47 AM, Lawrence D'Oliveiro wrote:
>
> > The whole managed-code/auto-garbage-collected concept may really appealto
> > corporate code-cutter types, but I think it has real trouble in the mass
> > market.

>
> *From a programming language design concept, one thing is abundantly
> clear: manually-managed memory is a failure. 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.


In fact, almost every language in use today[*] - with the notable
exception of C and C++ - features either garbage collection or some
simpler form of automatic memory management. PHP, Python, Perl,
Ruby, ... are not perceived as "bloated" while Java and C# are. So,
memory management alone can't be the explanation for the (apparent)
bloat. Perhaps it has more to do with the kind of applications that
are most commonly written in each language, and the programming
paradigms, styles and patterns that are most commonly used in each
language.
Also, it should be stressed that "managed" and "native" are not
necessarily in opposition: HotSpot compiles to native code, yet it's
still managed code, for example.
[*] I mean languages in which new projects are actively being written;
maintenance of old COBOL and FORTRAN code does not count.

 
Reply With Quote
 
Martin Gregorie
Guest
Posts: n/a
 
      06-06-2011
On Mon, 06 Jun 2011 10:47:10 -0700, Alessio Stalla wrote:

>[*] I mean languages in which new projects are actively being written;
> maintenance of old COBOL and FORTRAN code does not count.
>

Garbage collection and stack management are largely irrelevant for COBOL
- all data space is declared statically and the ways in which PERFORM can
be used more or less guarantees that its use will not involve the stack.
About the only use that COBOL might make of the stack would be to call
separately compiled modules, i.e. with the CALL verb.

I've never had much to do with Fortran, but from what I've seen of it
much the same would be true: no dynamically declared off-stack data and
the stack only used for subroutine calls, parameter passing and a
subroutine's local variables.

IOW neither language needs a garbage collector.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      06-06-2011
On 11-06-06 08:04 AM, Lawrence D'Oliveiro wrote:
> In message <yg1Hp.353$(E-Mail Removed)>, Arved Sandstrom wrote:
>
>> Right at the end the author says:
>>
>> "The development team lacks the resources to build equivalent
>> functionality in native code.
>>
>> "The last point is important. Maybe a hotshot team of C/C++ developers
>> could make a better job, but if you don’t have such a team or the money
>> to hire it, it is not so relevant."
>>
>> In other words, and this has nothing whatsoever to do with corporate
>> software, unless you're in that 5 percent (probably less) of current
>> programmers who can write high-quality C++, ...

>
> Maybe that’s the point: such skills are less common among corporate types.


That's very likely true, but not for the reasons you'd like to think. In
your Weltanschauung the reason "corporate" developers aren't good at C++
is because they just don't have the chops for it - in reality, the
reason most developers who write enterprise software aren't all that
good at C++ is because C++ is a bad fit for most applications of that
sort, so why use it?

Fact of the matter is, a lot of application domains have preferred
languages. If you think that the application domain is silly, do you
also think that the associated languages are silly?

I'll hazard a guess that you suck pretty hard at a whole bunch of
programming languages. I'll be charitable and ascribe that fact to you
just not ever having used them. So do you assume that whatever types of
applications those languages are best suited for are stupid, just
because you don't know those languages? Or to return to your way of
thinking, I guess others would be right in stating that you are
substandard because you don't know those languages.

>> Point being, these "managed" languages have made the mass market
>> possible.

>
> And yet most mass-market apps avoid them.


I don't know about that - the huge majority of all websites are written
with managed code.

AHS
 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      06-06-2011
In message <isis49$cpq$(E-Mail Removed)>, 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?

> 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.
 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      06-06-2011
In message
<(E-Mail Removed)>, Alessio
Stalla wrote:

> PHP, Python, Perl, Ruby, ... are not perceived as "bloated" while Java and
> C# are.


Maybe it’s because the former do reference-counting (freeing up most things
the moment they become unreachable) while the latter don’t.
 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      06-06-2011
In message <BXaHp.890$(E-Mail Removed)>, Arved Sandstrom wrote:

> On 11-06-06 08:04 AM, Lawrence D'Oliveiro wrote:
>
>> In message <yg1Hp.353$(E-Mail Removed)>, Arved Sandstrom wrote:
>>
>>> Right at the end the author says:
>>>
>>> "The development team lacks the resources to build equivalent
>>> functionality in native code.
>>>
>>> "The last point is important. Maybe a hotshot team of C/C++ developers
>>> could make a better job, but if you don’t have such a team or the money
>>> to hire it, it is not so relevant."
>>>
>>> In other words, and this has nothing whatsoever to do with corporate
>>> software, unless you're in that 5 percent (probably less) of current
>>> programmers who can write high-quality C++, ...

>>
>> Maybe that’s the point: such skills are less common among corporate
>> types.

>
> That's very likely true, but not for the reasons you'd like to think.


So you concede my point.

> I'll hazard a guess that you suck pretty hard at a whole bunch of
> programming languages.


I have published code in a whole bunch of different languages, just in this
noisegroup alone. And there’s more in my GitHub area, as well as a patch or
two floating around elsewhere. I will happily listen to criticism from you
.... the day that you can do the same.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Exceptions and object code bloat Steven T. Hatton C++ 5 11-28-2006 09:21 AM
Which causes more code-bloat: inline virtual or template class? RainBow C++ 6 08-25-2005 11:47 PM
16bit photoshop files: why do they bloat? digiboy@mailinator.com Digital Photography 10 02-21-2005 10:50 PM
SSH/SSL Code Bloat Eric Computer Security 0 02-12-2004 06:35 PM
STL & reducing code bloat Salvador I. Ducros C++ 5 08-04-2003 11:20 PM



Advertisments