Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!feeds.phibee-telecom.net!usenet.ukfsn.org!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: Managed-Code Bloat Date: Wed, 8 Jun 2011 18:06:48 +0000 (UTC) Organization: UK Free Software Network Lines: 59 Message-ID: References: <8486d40e-0cc1-40ec-93bc-41658d22edeb@r33g2000prh.googlegroups.com> NNTP-Posting-Host: 84.45.235.129 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: localhost.localdomain 1307556408 5542 84.45.235.129 (8 Jun 2011 18:06:48 GMT) X-Complaints-To: usenet@localhost.localdomain NNTP-Posting-Date: Wed, 8 Jun 2011 18:06:48 +0000 (UTC) User-Agent: Pan/0.133 (House of Butterflies) Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer: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 |