Cobol today
in [Cobol]
|
Prev: How to talk like a programmer
Next: Ping Warren Simmons
From: Howard Brazee on 28 May 2010 10:14 On Thu, 27 May 2010 15:15:46 -0700 (PDT), "robertwessel2(a)yahoo.com" <robertwessel2(a)yahoo.com> wrote: >This statistic is often told as '80% of active code" or "80 percent of >the worlds data" or something like that. One of those might have been >true in 1980, but now it's just BS. We would need to definition of both "code" and of "programs" that we could agree upon. But it is clear that such definitions don't really apply. And certainly we aren't counting microcode in radios, stoplights, phones, etc. -- "In no part of the constitution is more wisdom to be found, than in the clause which confides the question of war or peace to the legislature, and not to the executive department." - James Madison
From: Howard Brazee on 28 May 2010 10:18 On Fri, 28 May 2010 14:34:41 +1200, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: >It doesn't take into account the fact that every year this "COBOL code base" >is being eroded by more and more companies refactoring their COBOL >processing, moving to OO languages like Java, VB.NET, and C#, replacing >their COBOL base with packages like Siebel and SAP, and generally >outsourcing their IT development requirements. > >It is pretty much impossible to get accurate figures as to who is using what >and I have seen silly figures quoted for Java, C++, PHP, and C#, so COBOL >is not alone in this. Every bit of Java downloaded and run within a browser on your phone is "code". As are formulae in a spread sheet, and the instructions telling your computer what you want to connect to when you boot. -- "In no part of the constitution is more wisdom to be found, than in the clause which confides the question of war or peace to the legislature, and not to the executive department." - James Madison
From: Non scrivetemi on 28 May 2010 14:51 On Thu, 27 May 2010 15:15:46 -0700 (PDT), "robertwessel2(a)yahoo.com" <robertwessel2(a)yahoo.com> wrote: > > >This statistic is often told as '80% of active code" or "80 percent of > >the worlds data" or something like that. One of those might have been > >true in 1980, but now it's just BS. True, now it's amount 90%. > We would need to definition of both "code" and of "programs" that we > could agree upon. But it is clear that such definitions don't > really apply. Definitions do apply, or somebody doesn't know what he's talking about. > And certainly we aren't counting microcode in radios, stoplights, > phones, etc. Those devices don't have much if any microcode.
From: robertwessel2 on 28 May 2010 15:08 On May 27, 9:34 pm, "Pete Dashwood" <dashw...(a)removethis.enternet.co.nz> wrote: > There seems to be some kind of "cuddle blanket" effect in thinking that a > language is popular. Should it matter? Only as far as getting practitioners > of it and support for it, I would've thought. Programming languages should > not be selected based on their popularity; they should be selected on their > cost and fit for purpose. (That's why I use C#... I really don't care if > nobody else in the world uses it, as long as I can get help and support 24/7 > for free (and I can)) It matters to the extent that popularity is a proxy for likely longevity and breadth of support. C is a perfect example. It's not a great language (although as low level languages go, it's not horrible), but you can expect, at least to a significantly higher degree than any other language, that there will be an actively supported C compiler available for whatever platform* you'll be wanting to run your code on in a decade. And popularity also impacts quality (again, it's not a direct relationships), in that many users probably equate to high quality compilers, libraries and development environments. Of course our planning horizon is not usually quite that long, but many of us work on multi-platform projects, or projects intended to be multi-platform in the not too distant future. That being said, I also like C# for stuff, especially interactive stuff, that I know is going to run on Windows. *Fully acknowledging that writing portable C or C++ code is rather harder than just writing in C or C++, but it is, with some care, possible and practical.
From: robertwessel2 on 28 May 2010 15:20
On May 28, 9:14 am, Howard Brazee <how...(a)brazee.net> wrote: > On Thu, 27 May 2010 15:15:46 -0700 (PDT), "robertwess...(a)yahoo.com" > > <robertwess...(a)yahoo.com> wrote: > >This statistic is often told as '80% of active code" or "80 percent of > >the worlds data" or something like that. One of those might have been > >true in 1980, but now it's just BS. > > We would need to definition of both "code" and of "programs" that we > could agree upon. But it is clear that such definitions don't > really apply. > > And certainly we aren't counting microcode in radios, stoplights, > phones, etc. Very little of that is what's properly called microcode. Most embedded code runs on fairly conventional processors (quite small processors, in some cases), and is not microcode. Certainly most stoplights don't have any "real" microcode (except what might be embedded in the CPU), radios (including cell phones) might well have some of the signal processing side driven by microcode, but the vast majority of code the run is ordinary (the iPhone for example, is basically a thin version of MacOS, Android is a Linux port). But we generally *do* count the code in embedded systems, but it doesn't make all that much of a difference to the totals. Small embedded systems tend to have relatively small amounts of code (although they're sometimes deployed on very large numbers of devices - whatever code Apple wrote for the iPod version X only counts once, even if the did sell 50 million of them). Larger embedded systems tend to look a lot like any other programming environment (consider the 3270 emulator on your iPhone - other than being targeted at a fairly small platform, it's not written any differently than your 3270 emulator for your PC or Mac). And while many embedded systems have unusual requirements (realtime, reliability, etc.), the larger the system, the more localized those requirements are. |