Managed-Code Bloat

[Lawrence D'Oliveiro]

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.

 

[Arved Sandstrom]

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

 

[Lawrence D'Oliveiro]

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.

 

[Joshua Cranmer]

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.

 

[Alessio Stalla]

 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.

 

[Martin Gregorie]

[*] 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.

 

[Arved Sandstrom]

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.

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

 

[Lawrence D'Oliveiro]

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.

 

[Lawrence D'Oliveiro]

In message

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.

 

[Lawrence D'Oliveiro]

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.

 

[Joshua Cranmer]

And yet managed code has failed to take off in the mass market. Why is that?

Because you can't see the mass market. The use of HTML 5 and
JavaScript-based applications is taking off. And what is JavaScript? Why
managed code. To deny that this is the case is to deny the success of
the iPhone, Android, et al: hell, even Microsoft is pushing for HTML 5-y
things in Windows 8.

 

[BGB]

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.

you know... some of us use garbage collectors in C...

 

[Lawrence D'Oliveiro]

Because you can't see the mass market. The use of HTML 5 and
JavaScript-based applications is taking off. And what is JavaScript? Why
managed code.

I think JavaScript uses reference-counting, too. Why else would it have a
“delete†statement
<http://developer.apple.com/library/...cript.html#//apple_ref/doc/uid/TP40006539-SW1>?

 

[Joshua Cranmer]

I think JavaScript uses reference-counting, too. Why else would it have a
“delete†statement

Both SpiderMonkey and V8 are garbage-collected. Don't believe me? Here
is their garbage collector:
<http://mxr.mozilla.org/mozilla-central/source/js/src/jsgc.cpp>
<http://code.google.com/apis/v8/design.html> (I don't actually work with
V8, so I don't know it's class layout so well).

If you want more evidence, the ECMAScript committee talks about some JS
things in the context of garbage collection:
<http://wiki.ecmascript.org/doku.php?id=strawman:gc_semantics>.

As for python, Python does have a garbage collector because it is very
easy to accidentally create cycles in references, the big bane of
reference-counted systems.

 

[Lawrence D'Oliveiro]

As for python, Python does have a garbage collector because it is very
easy to accidentally create cycles in references, the big bane of
reference-counted systems.

Yes, but like Perl, the garbage collector only gets invoked in those less-
common cases where you do indeed have such cycles. The rest of the time
(which is most of the time), reference-counting works just fine.

Both SpiderMonkey and V8 are garbage-collected.

Probably same here.

 

[Roedy Green]

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

I remember how DOS->Windows evolved recapitulating the evolution of
mainframes, but requiring hundreds of times the amount of RAM for the
same functionality. (we still don't have sequential lookahead double
buffering we had back in the 16K machine days.)

I think we are doing another round of this recapitulation with
cellphones and PDAs.
--
Roedy Green Canadian Mind Products
http://mindprod.com
How long did it take after the car was invented before owners understood
cars would not work unless you regularly changed the oil and the tires?
We have gone 33 years and still it is rare to uncover a user who
understands computers don't work without regular backups.

 

[Joshua Cranmer]

Probably same here.

That is not the case. I have actually patched the source code to
SpiderMonkey myself, I have literally sat next to the people who work on
the engine, SpiderMonkey is garbage-collected. Mark-and-trace, although
the plan is to move to generational GC. I'm not so sure about V8, but
the page I linked to explicitly mentions generational garbage
collection, so I'm sure it's in the same boat.

If you don't believe that, what would it take to get you to believe the
truth? A signed note from Brendan Eich himself?

 

[Lawrence D'Oliveiro]

That is not the case.

So why have a “delete†statement, then?

 

[Lawrence D'Oliveiro]

I remember how DOS->Windows evolved recapitulating the evolution of
mainframes, but requiring hundreds of times the amount of RAM for the
same functionality. (we still don't have sequential lookahead double
buffering we had back in the 16K machine days.)

Maybe because there is no benefit to it on current platforms.

I think we are doing another round of this recapitulation with
cellphones and PDAs.

“PDAs� Now there’s a term from the 1990s.

Cellphones don’t need to “recapitulate†anything, because they are mostly
built on adaptations of kernels that have already been used on PCs
(certainly true of Android and the Apple products).

 

[Joshua Cranmer]

So why have a “delete†statement, then?

JavaScript objects are basically hashmaps. The delete statement is the
JS equivalent of map.remove.