Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #5001 > unrolled thread

Managed-Code Bloat

Back to article view | Back to comp.lang.java.programmer

Contents

  Managed-Code Bloat Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-06 18:47 +1200
    Re: Managed-Code Bloat Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-06 06:40 -0300
      Re: Managed-Code Bloat Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-06 23:04 +1200
        Re: Managed-Code Bloat Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-06 17:41 -0300
          Re: Managed-Code Bloat Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-07 11:13 +1200
            Re: Managed-Code Bloat Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-07 07:08 -0300
        Re: Managed-Code Bloat Silvio <silvio@moc.com> - 2011-06-07 09:40 +0200
          Re: Managed-Code Bloat Patricia Shanahan <pats@acm.org> - 2011-06-07 06:08 -0700
    Re: Managed-Code Bloat Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-06 11:35 -0400
      Re: Managed-Code Bloat Alessio Stalla <alessiostalla@gmail.com> - 2011-06-06 10:47 -0700
        Re: Managed-Code Bloat Martin Gregorie <martin@address-in-sig.invalid> - 2011-06-06 18:21 +0000
          Re: Managed-Code Bloat Michael Wojcik <mwojcik@newsguy.com> - 2011-06-08 11:48 -0400
            Re: Managed-Code Bloat Martin Gregorie <martin@address-in-sig.invalid> - 2011-06-08 18:06 +0000
              Re: Managed-Code Bloat Michael Wojcik <mwojcik@newsguy.com> - 2011-06-11 14:00 -0400
        Re: Managed-Code Bloat Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-07 10:18 +1200
          Re: Managed-Code Bloat Michael Wojcik <mwojcik@newsguy.com> - 2011-06-08 11:59 -0400
        Re: Managed-Code Bloat Michael Wojcik <mwojcik@newsguy.com> - 2011-06-08 11:22 -0400
          Re: Managed-Code Bloat rossum <rossum48@coldmail.com> - 2011-06-08 21:45 +0100
      Re: Managed-Code Bloat Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-07 10:17 +1200
        Re: Managed-Code Bloat Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-06 16:37 -0700
          Re: Managed-Code Bloat Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-07 12:06 +1200
            Re: Managed-Code Bloat Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-06 17:44 -0700
              Re: Managed-Code Bloat Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-07 13:38 +1200
                Re: Managed-Code Bloat Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-06 20:13 -0700
                  Re: Managed-Code Bloat Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-07 15:41 +1200
                    Re: Managed-Code Bloat Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-06 20:47 -0700
                      Re: Managed-Code Bloat BGB <cr88192@hotmail.com> - 2011-06-07 01:06 -0700
                        Re: Managed-Code Bloat Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-07 23:53 +1200
                          Re: Managed-Code Bloat BGB <cr88192@hotmail.com> - 2011-06-07 16:04 -0700
                          Re: Managed-Code Bloat Michael Wojcik <mwojcik@newsguy.com> - 2011-06-08 13:04 -0400
                        Re: Managed-Code Bloat Michal Kleczek <kleku75@gmail.com> - 2011-06-08 09:23 +0200
                          Re: Managed-Code Bloat BGB <cr88192@hotmail.com> - 2011-06-08 03:54 -0700
                    Re: Managed-Code Bloat bugbear <bugbear@trim_papermule.co.uk_trim> - 2011-06-07 10:10 +0100
                  Re: Managed-Code Bloat BGB <cr88192@hotmail.com> - 2011-06-07 00:37 -0700
        Re: Managed-Code Bloat Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-07 07:31 -0300
          Re: Managed-Code Bloat BGB <cr88192@hotmail.com> - 2011-06-07 16:18 -0700
            Re: Managed-Code Bloat Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-07 20:50 -0300
            Re: Managed-Code Bloat Gene Wirchenko <genew@ocis.net> - 2011-06-08 07:53 -0700
              Re: Managed-Code Bloat BGB <cr88192@hotmail.com> - 2011-06-08 11:23 -0700
      Re: Managed-Code Bloat BGB <cr88192@hotmail.com> - 2011-06-06 16:54 -0700
    Re: Managed-Code Bloat Roedy Green <see_website@mindprod.com.invalid> - 2011-06-06 19:24 -0700
      Re: Managed-Code Bloat Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-07 15:44 +1200

Page 1 of 3  [1] 2 3  Next page →

#5001 — Managed-Code Bloat

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.

[toc] | [next] | [standalone]

#5009

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

[toc] | [prev] | [next] | [standalone]

#5011

In message <yg1Hp.353$tp.157@newsfe06.iad>, 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.

[toc] | [prev] | [next] | [standalone]

#5034

On 11-06-06 08:04 AM, Lawrence D'Oliveiro wrote:
> In message <yg1Hp.353$tp.157@newsfe06.iad>, 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

[toc] | [prev] | [next] | [standalone]

#5041

In message <BXaHp.890$SG4.480@newsfe03.iad>, Arved Sandstrom wrote:

> On 11-06-06 08:04 AM, Lawrence D'Oliveiro wrote:
>
>> In message <yg1Hp.353$tp.157@newsfe06.iad>, 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.

[toc] | [prev] | [next] | [standalone]

#5061

On 11-06-06 08:13 PM, Lawrence D'Oliveiro wrote:
> In message <BXaHp.890$SG4.480@newsfe03.iad>, Arved Sandstrom wrote:
> 
>> On 11-06-06 08:04 AM, Lawrence D'Oliveiro wrote:
>>
>>> In message <yg1Hp.353$tp.157@newsfe06.iad>, 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 concede your observation about C++ and "corporate" programmers,
because it's very likely true. Corporate programmers tend not to use C
or C++. Read Silvio's post and you may arrive at a glimmer of
understanding as to why. You may also have noticed along the way that
C++ CORBA never took off - it is of relevance to this discussion.

I don't concede your point, because I believe your point is that the
people who have become corporate programmers are the mediocre types who
would never be capable of C or C++. That's patently untrue, and it's
stupid and naive to suggest it.

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

You misunderstood. I'm making the point that you, just like any other
programmer, can only be hotshit at a handful of languages at any given
point in time. I guarantee, for example, that if you had been a
wonderful C++ programmer up until, say, 1995, spent the past 16 years
writing Python and all that good stuff, and now all of a sudden in 2011
were hit with a large app that had to be written in C++, you'd be
flailing for a while, dude. No ifs and buts, and don't insult our common
sense.

AHS

[toc] | [prev] | [next] | [standalone]

#5055

On 06/06/2011 01:04 PM, Lawrence D'Oliveiro wrote:
>
> Maybe that’s the point: such skills are less common among corporate types.
>

Not per se. I have programmed in C since 1985 and took up C++ when the 
cfront thingy became available on our (university) PDP-11 and Sun UNIX 
machines a year later. I dare to say that I am quite capable of writing 
high quality code in C/C++.

BUT, when writing large multi-threaded systems I experienced that the 
effort needed to keep everything working correctly typically grew at a 
more-than-linear rate in relation to code base size.

Using C++ I created a ref<T> templated type that exposed T* like 
semantics but implemented reference counting to simplify memory 
management of objects that where shared in such a way that it was 
difficult to determine who should control their lifespan.
Although that worked fine it was very easy to get bitten by reference 
cycles so it only solved part of the problem. The extra memory 
allocation/deallocation needed per object and the negative impact it had 
on code inlining did not help performance either.

Being pragmatic I decided to switch to Java for specific projects even 
though I had rejected it earlier as being a "fake" language with 
inferior performance characteristics.
Soon I discovered that the portion of effort needed for correct explicit 
memory management (and tracing bugs caused by the lack thereof) in C/C++ 
was so large that development times dropped drastically by using Java. 
Very soon I was convinced that only a very small part of the systems I 
wrote actually justified opting for C/C++.

A few years ago I switched to Scala. Although it runs on the same JVM 
that Java uses a similar return on investment was my reward. The reasons 
for this are very different though.

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

That was true a couple of years ago when hand-held devices where only 
just capable of doing fancy stuff. Native code was required to squeeze 
out that last x% of performance. (Which will work for such mostly small 
applications)
The early Android phones suffered from the lack of high-performing 
devices and delivered poor performance. That problem has been solved 
since then as I have experienced with my last two Android phones for 
almost two years.

Silvio

[toc] | [prev] | [next] | [standalone]

#5067

On 6/7/2011 12:40 AM, Silvio wrote:
...
> Soon I discovered that the portion of effort needed for correct explicit
> memory management (and tracing bugs caused by the lack thereof) in C/C++
> was so large that development times dropped drastically by using Java.
> Very soon I was convinced that only a very small part of the systems I
> wrote actually justified opting for C/C++.
...

I started using Java for similar reasons. I used to write performance
models simulating very complicated multiprocessor servers. A cache miss
could produce several messages causing actions in different components
of the processor-memory interconnect. The cache miss was completed when
several conditions had been all been met, and the order depended on the
states of various queues.

I wrote one in C++. It worked, and did not leak memory even when run for
several days. The problem was that I had spent significant effort to
achieve that result.

The next time I used Java, and got the same effect for zero programming
effort.

Patricia

[toc] | [prev] | [next] | [standalone]

#5016

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

[toc] | [prev] | [next] | [standalone]

#5024

On 6 Giu, 17:35, Joshua Cranmer <Pidgeo...@verizon.invalid> wrote:
> 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.

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.

[toc] | [prev] | [next] | [standalone]

#5026

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       |

[toc] | [prev] | [next] | [standalone]

#5109

Martin Gregorie wrote:
> 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. 

That hasn't been true, in general, since COBOL-85. While there
certainly are still old COBOL applications with fixed-size memory
requirements, a great many written over the past quarter-century make
use of arbitrary subroutine call (ie, out-of-line perform and call)
patterns, and a smaller number use reentrancy and/or threading.

And there have been garbage-collected COBOLs at least since the first
OO COBOLs appeared in the 1990s.

There are also managed-code COBOLs. Fujitsu has .NET COBOL; so do we,
and we also have JVM COBOL.

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

Fortran 90 added dynamic memory allocation to the standard. Prior to
that I believe some implementations offered it as an extension.

I don't know if anyone has a garbage-collected Fortran implementation.

-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

[toc] | [prev] | [next] | [standalone]

#5121

On Wed, 08 Jun 2011 11:48:22 -0400, Michael Wojcik wrote:

> Martin Gregorie wrote:
>> 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.
> 
> That hasn't been true, in general, since COBOL-85. While there certainly
> are still old COBOL applications with fixed-size memory requirements, a
> great many written over the past quarter-century make use of arbitrary
> subroutine call (ie, out-of-line perform and call) patterns, and a
> smaller number use reentrancy and/or threading.
>
OK, I'd agree about dynamically loaded subroutines, though those scarcely 
need a GC since the allocation/deallocation points are well known, but 
are you saying that the content of WORKING-STORAGE can be dynamic now? 
Last time I looked (that would have been COBOL-85 probably) you could 
specify a variable OCCURS clause in a table declaration but memory was 
always allocated for the maximum table size, in the implementations I 
knew detail for, anyway.

> And there have been garbage-collected COBOLs at least since the first OO
> COBOLs appeared in the 1990s.
>
OK - but I've never used or seen those flavours.

> There are also managed-code COBOLs. Fujitsu has .NET COBOL; so do we,
> and we also have JVM COBOL.
>
I did use multi-threading in COBOL, but we managed all that in non-POSIX 
C threads (on an NCR UNIX box with microFocus COBOL for the business 
logic). I don't know when the code was initially written, though, so a 
lot of than could have been a hang-over due to legacy code (the system 
was Shared Financial's ON/X, a UNIX port of their ON/2 ATM management 
system, which was originally written in Stratus COBOL).


> Fortran 90 added dynamic memory allocation to the standard. Prior to
> that I believe some implementations offered it as an extension.
> 
I've had a very brief exposure to Fortran 77 - little more than pumping 
XFOIL through GNU Fortran so I could run it - and that's about it. I was 
very pleased to see that the nasty IF A=B 40,50,60 conditionals had at 
last grown up into proper IF..ELSE conditionals.
 
> I don't know if anyone has a garbage-collected Fortran implementation.



-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#5212

Martin Gregorie wrote:
> On Wed, 08 Jun 2011 11:48:22 -0400, Michael Wojcik wrote:
> 
>> Martin Gregorie wrote:
>>>>
>>> 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.
>> That hasn't been true, in general, since COBOL-85. While there certainly
>> are still old COBOL applications with fixed-size memory requirements, a
>> great many written over the past quarter-century make use of arbitrary
>> subroutine call (ie, out-of-line perform and call) patterns, and a
>> smaller number use reentrancy and/or threading.
>>
> OK, I'd agree about dynamically loaded subroutines, though those scarcely 
> need a GC since the allocation/deallocation points are well known,

Agreed so far - I was more concerned with the "stack management" part
of your statement than the "garbage collection" part.

> but
> are you saying that the content of WORKING-STORAGE can be dynamic now? 

I don't have a copy of the COBOL-85 standard handy, but since the
mid-80s various COBOL implementations have provided extensions for
dynamic memory allocation, which COBOL supports through USAGE POINTER,
LINKAGE SECTION, and the SET statement. So Micro Focus COBOL has long
had the CBL_ALLOC_MEM library call; IBM mainframe COBOL has had
various environmental facilities like EXEC CICS SET ADDRESS, GETMAIN,
etc; and so on.

COBOL-2002 specifies the ALLOCATE and FREE statements (which I don't
think were in COBOL-85), standardizing this kind of explicit memory
allocation and release.

Those are *not* garbage-collected allocations, but they pointed to the
desirability of garbage collection for modern COBOL; and that's why
the first proprietary OO COBOL dialects were garbage-collected, and
that remains true with modern OO COBOL, including COBOL-2002 (see
ISO/IEC 1989:2002 9.3.14.2) and Micro Focus COBOL for .NET and JVM.

>> And there have been garbage-collected COBOLs at least since the first OO
>> COBOLs appeared in the 1990s.
>>
> OK - but I've never used or seen those flavours.

Yes, they're still relatively rarely used, compared to traditional
COBOL. I was just noting that the state of the art in the COBOL
standard and implementations has moved on since the old
static-allocation-only days.

-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

[toc] | [prev] | [next] | [standalone]

#5038

In message 
<8486d40e-0cc1-40ec-93bc-41658d22edeb@r33g2000prh.googlegroups.com>, 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.

[toc] | [prev] | [next] | [standalone]

#5108

Lawrence D'Oliveiro wrote:
> In message 
> <8486d40e-0cc1-40ec-93bc-41658d22edeb@r33g2000prh.googlegroups.com>, 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.

That's because reference counting has undesirable performance
characteristics (cache misses, pipeline stalls) due to reference
updates, and generational collectors often outperform reference counters.

There are algorithms which appear to have superior performance to
either pure generational collectors or naive hybrids (ie, a reference
counter with an occasional sweeping collector to catch dead
circular-referenced objects), such as ulterior reference counting.
(The basic idea is to pick an algorithm based on the expected
demographics of different groups of objects.) But they haven't caught
on widely; it's likely that the advantage isn't compelling for typical
applications.

In any case, I'm highly dubious of perceptions of languages as
"bloated" or otherwise. That's not likely to be a useful evaluation.


-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

[toc] | [prev] | [next] | [standalone]

#5105

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

New projects are actively being written in COBOL and Fortran. (I don't
know about FORTRAN; the name of that language went mixed-case in 1990.)

But, of course, on Usenet no one is expected to do any research or
know anything about the industry outside of their own fiefdom.

-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

[toc] | [prev] | [next] | [standalone]

#5135

On Wed, 08 Jun 2011 11:22:06 -0400, Michael Wojcik
<mwojcik@newsguy.com> wrote:

>But, of course, on Usenet no one is expected to do any research or
>know anything about the industry outside of their own fiefdom.
But, of course, on Usenet no one is expected to ...
know anything ... .

FTFY  :)

rossum

[toc] | [prev] | [next] | [standalone]

#5037

In message <isis49$cpq$1@dont-email.me>, 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.

[toc] | [prev] | [next] | [standalone]

#5042

On 6/6/2011 3:17 PM, Lawrence D'Oliveiro wrote:
> In message<isis49$cpq$1@dont-email.me>, 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?

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.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web