Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm very curious about old programming languages, especially COBOL, and as Wikipedia couldn't really tell me much about this topic, I decided to ask it here:
Was COBOL the first programming language really being used in financial, stock and banking systems?
Where exactly was COBOL used?
Was it used more frequently than Fortran or BASIC, for example?
I don't know if you lived at that time, but how did people react to the rising COBOL? Did they expect it to be the future?
When has COBOL actually stopped being used to create new, big systems?
Are you sure that there are still important legacy apps written in COBOL out there? I can't believe that somehow.
Previous SO questions have gone a long way toward answering your questions. Please review:
What are Fortran and COBOL used for today
Why is COBOL still a preferred language in the business world
Reasons to start a new project in COBOL
What makes COBOL such a hated language
Was COBOL the first programming language used in financial, stock and banking systems
Well known languages that co-existed with early COBOL are
Fortran and Lisp. These languages were not much used much outside
of research and university facilities.
The landscape was highly fragmented within the world of business computing.
A number of proprietary low-to-medium level languages existed but generally
only ran on one vendors machine.
A few examples were: FLO-MATIC,
AIMACO and COMTRAN, all of
which heavily influenced the development of COBOL.
From this chaos emerged a strong desire to have a machine independent and common language for
developing business applications.
According to Jean E. Sammet (The Early History of COBOL), the
US Department of Defense spearheaded and funded the early development of COBOL.
Where is COBOL used
Largely in financial (banks/government) and insurance industries. Outside of these sectors, COBOL is pretty
much unheard of.
Is it used more frequently than Fortran or BASIC
I believe Fortran actually pre-dates COBOL by a little bit. Fortran is
primarily suited for high-performance numerical applications (astronomy, physics
and the like). COBOL is primarily suited for financial and record keeping
applications - the stuff of business and commerce (hence
the name: COmmon Business Oriented Language).
The two were never in "competition" so asking which is more frequently used
is kind of like comparing apples to oranges.
Putting the "apples" and "oranges" aside, it is hard to say how many lines of production
code exist for either of these languages. Estimates vary from billions to millions.
However, I don't think anybody would claim that the active code base is insignificant.
BASIC (excluding "Visual Basic") was largely a personal computer language.
There have been a few ports to
larger machines (eg. VAX BASIC - Oh that was fun) but I don't think this ever caught on.
I would be surprised if there are any significant production systems written in BASIC
today. Just say "BAISC" to any "old timer" and their minds will flood with fond
memories. Other than that it is pretty much gone.
When did COBOL stop being used
The COBOL legacy is huge. As such, there is a lot of legacy maintenance going on
today, and it will go on for many years to come.
Is there any new development? I would say less and less every year but it is
nowhere near coming to an end. I work in a very large shop and we actively develop new
COBOL applications. I don't believe we are alone.
Those that still actively develop systems in COBOL are not a bunch of "back woods"
idiots who don't know any better. They do it because COBOL "delivers the goods"
for the least cost per transaction processed. Believe me, if any other technology could
do it cheaper, faster and more reliably, COBOL would be gone tomorrow!
One can only get an appreciation for how wide spread COBOL is by
working in the financial, government or insurance industries - and then only
in an area where they have to push a lot of data around.
If you work outside of this environment it is like the language died a hundred yeas ago!
How did people react to the rise of COBOL?
In a couple of words: Not well.
COBOL came into existence just about the same time that the academic world made huge
breakthroughs in language theory and compiler design. COBOL missed that boat and has been
denigrated by everybody with an academic interest in computing ever since. I went through
university in the 70's and even at that time the word "COBOL" made us all cringe. The
hate for COBOL runs very deep.
Even the developers of COBOL could not have predicted the long term success of the
language. The original COBOL was specified by a "short range committee" so
that could it implemented with reasonable time and effort. The final "touches" would
be made by a "long range committee". The "long range committed" never materialized
and this is what we got!
The death of COBOL has been predicted as imminent since the 60's. It is still with
us and going strong.
Why? I think there are three big reasons:
Code stability. COBOL carries its legacy fairly well, major upgrades are rare. This
may not be a selling point if you are in the business of developing code. However,
if you are the one paying for it COBOL gets high marks on this one.
Performance. COBOL applications are generally developed where volume and/or
throughput are critical (eg. processing monthly bank statements, tax returns, etc.)
Track Record. Organizations that use COBOL generally know their track record. They
have a certain comfort level with cost/time estimates for major development projects
using COBOL and related technologies.
Taking on a new language and supporting technology to implement mission critical applications involves additional
and unknown risks (and unknown benefits).
Notice that all the reasons I have cited for COBOL's continued existence are driven by
cost and risk minimization. There is nothing from a developer's point of view that
makes developing in COBOL interesting. Blame corporate accountants for COBOL's
continued success.
On the brighter side, there are a few frameworks (eg. Bassett Frame Technology and XVCL) that can make COBOL development today tollerable, even, dare I say, interesting.
Was COBOL the first programming
language really being used in
financial, stock and banking systems?
For practical purposes this was all done in assembler, but Cobol was the first high level language to move into these domains.
Where exactly was COBOL used?
Any place where money changed hands, inventory was tracked, et al. Your use of the word "was" implies that it is not now used. Cobol is involved every time you swipe a credit card, ship a package, make a phone call...it is every where. Still.
Was it used more frequently than
Fortran or BASIC, for example?
Yes, very much so. Fortran is well geared for science geeks and engineers -- a noble calling -- but they don't exist in the numbers of the sales and marketing geeks, the Cobol domain.
Does anyone use BASIC? Doesn't that suck?
I don't know if you lived at that
time, but how did people react to the
rising COBOL? Did they expect it to be
the future?
People like credit cards. People like online access to their bank accounts. People like Voice Response Systems that give their balance and last 5 transactions. People like ATMS. People like fast airline and hotel bookings.
The only people who don't like what Cobol does for them are programmers that have never put the time and effort into understanding Cobol (but they hate it anyway).
When has COBOL actually stopped being
used to create new, big systems?
Ummm, never. Cobol is still actively developed and used all over the world. It isn't sexy and no Computer Science professor is going to tell you that it is "the next big thing" -- but if they knew what they were talking about they would be making money in the real world...
Are you sure that there are still
important legacy apps written in COBOL
out there? I can't believe that
somehow.
MasterCard. Visa. Naa...
No idea really, but LEO was used for payroll. It used a language similar to COBOL called CLEO.
COBOL is used all over the place. Mostly banks and big mainframe departments.
difficult to say. It was certainly popular back in the day.
Back in the days when COBOL had its heyday, the alternatives were for alternative niches - eg Fortran for scientific, Algol for academic, Cobol for financial. Did they expect it to be the future... possibly.
5,6. It still is used. Search for COBOL jobs, you'll get quite a few hits for banking and financial companies that are looking for programmers, architects, etc. Pays quite well too by all accounts.
Answering the last part:
Yes, there are certainly new COBOL applications being written at banks everyday. Large financial institutions usually have a mainframe or two around, as they (traditionally) have a much better uptime than standard servers, and can move a lot of data reliably.
Additionally, the people still doing COBOL are pretty darn good at what they do.
If you're dealing with billions of dollars of electronic transactions, reliably is worth paying for, even if it's not new or sexy to do so. Then again, I can't hotswap the processor out of my webserver; hotswapping any of the parts out of a mainframe is usually possible, and that's actually a pretty tech-sexy feature, if I gotta say so myself.
I managed to go almost 15 years in my career without touching a single line of COBOL, or even of seeing it. Until I got my last job, which is some enterprise middleware that links COBOL to web services and non-mainframe databases. My very first customer engagement at this new job was with a big-ass company with lots and lots of COBOL they wanted to integrate with newer systems.
Learning it has been a pain, mostly because there are few good PC-based COBOL engines left, but it's not really hard at all. And that is why it's still around. It does a job, does it well. It's showing it's age a bit in how it interacts with SOA frameworks, but even that problem is going away.
#Neal:
>
BASIC (excluding "Visual Basic") was largely a personal computer language.
There have been a few ports to
larger machines (eg. VAX BASIC - Oh that was fun) but I don't think this ever caught on.
BASIC also started on big machines. I remember programming with BASIC and a paper tape on a CDC back in 1974 in an environnement similar to this one http://www.museumwaalsdorp.nl/computer/en/comp742E.html.
RE code stability of cobol: Updates rare, but they are very disruptive, and are actively resisted by the installed base. When forced, conversions often are done in a compatibility mode and the testing alone can burn the entire SD budget for a year. OO cobol is a case in point as the real costs of conversion will exceed its benefits unless a total redesign is attempted. Consulting shops love this as they bill for time, but for the organization it has the potential to literally put them out of business. One of the great myths of this OO cobol exercise is the 'portability' of the skill set of cobol, but in fact it is the OOP/OOD skill which is lacking and must be taught to the legacy programmers. Learning a new paradigm is allays harder than learning a new tool ( language) and in point of fact the exercise makes no sense and is entertained only by that bastion of folly known as management ---as carefully mislead by the vendor community devoted as they are to the creation of 'value' for their shareholders. It is often an easy sale, and fools generally do deserve to be fleeced.
RE execution speed. This is not really worth a detailed response. Platforms are fast, and it is compilers that determine execution speed. I have examine the asm output from COBOL compilers and it is not any better than a good c compiler. More to the point classic COBOLS's lack of type safety , failure to support scope, failure to support parametrized procedures, failure to support explicit type conversion etc, leads to the mistaken impression that because it does not do any of this it is faster. In fact most of this requires only compile time support and the rest does not add much overhead ( and what little it does can be optimized out) where as it does make code reuse prohibitively expensive, make testing a nightmare, and produce brittle code.
It will only go away when it costs to much to fix. This may or may not happen, but it is more likely that the organizations will fail due to a major software issue which would have been trapped by a type safe language before then.( OOP will provide type safety but that will require that cobol programmers and business analysts learn to use types)
Related
Are there any good reason to learn languages such as Ada and COBOL? Are there any future in programming in those languages? I'm interested in those languages and i'm currently learning them just for fun.
Its always worthwhile learning new languages. Even if they're never useful to you professionally chances are they'll teach you something about programming you didn't know before or at very least broaden your outlook.
As for prospects from a quick bit of reading around it seems ada is still somewhat in favour for critical systems in the aviation industry and Cobol still has its place in business. I know an engineer in his mid 20's who writes all his code in fortran77 as that's what industry wants!
While the number of employers looking for these languages might be low, because there are a limited number of people who know them the salary for developers who specialise in them can be quite high. When mission critical apps developed in them could cost millions to replace having to pay more than usual for a coder to maintain the existing system is easily accepted.
Ada is used in the aerospace/defense industry. COBOL is used in the financial industry. Fortran is used in engineering. The question "is there any future" is borderline subjective/argumentative since all of those languages are still in active use.
Fortran is old, but is used in scientific programming. Ada is the basis for VHDL, a very important language in electrical engineering. You could also say that C is "old", and it's used pretty much everywhere.
Cobol and Algol are both still in widespread use. You won't find them running on your latest and greatest tech firms, but you can bet your car insurance company process' claims on it. Your health insurance company most certainly uses it. Reports of Cobol's death have been highly exaggerated.
You will find difficulty in colleges and places that will actually teach you Cobol or Algol. So finding developers for these so-called dead languages is getting harder and harder. Very tough to tell a kid coming out of high school that has been programming in Java, iOS, and Perl for half his life that Cobol is where the money is at.
Cobol/Algol developers are becoming harder and harder to come by, so if you have that language in your back pocket, it is only going to help you out. Algol is a lot harder of a language in my opinion to get good at. You can teach anyone with half a brain how to program in Cobol.
These languages are not going away any time soon at all. As long as companies like IBM and Unisys provide compilers for them on the mainframes, they will continue to thrive. So grab a book and an open source compiler and brush up. Plenty of people out there looking for Cobol/Algol developers.
Many of these 'old' languages are actively in use today. Lisp for instance is gaining popularity again in the form Clojure. Smalltalk is becoming popular again with the Seaside MVC framework.
In addition many of the hottest development lanaguages borrow heavily from Lisp and Smalltalk, both of which pioneered Object Oriented methodologies long before C++ came along. Javascript, Ruby, Perl 6 and Perl 5 Moose (Object System) all use mixins which were first used in Lisp and Smalltalk. Metaclasses, first used in Common Lisp and Smalltalk-80, are making a resurgence in Perl 5 Moose, Objective-C (iPhone development), Python and Groovy.
Much like learning Latin, it can be intriguing to understand where and how many English and other current languages' words had their roots. Also, if you know Latin and valuable new books/papers/scrolls are found that need translation, you suddenly become valuable too.
Honestly, I'd say learning them is great for a historical perspective, especially if you're a language designer, but not very much else.
There are roles out there for COBOL programmers, but in general they are looking for experienced developers. From what I have seen you are unlikely to get a first programming role in COBOL - in general, they are looking for people experienced with similar application domains and who are familiar with building an understanding of legacy systems. Knowing the limitations of the language can be useful for understanding why certain things you are asking for when connecting to mainframes are either considered difficult or problematic.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
There are a few threads about the relevance of the Cobol programming language on this forum, e.g. this thread links to a collection of them. What I am interested in here is a frequently repeated claim based on a study by Gartner from 1997: that there were around 200 billion lines of code in active use at that time!
I would like to ask some questions to verify or falsify a couple of related points. My goal is to understand if this statement has any truth to it or if it is totally unrealistic.
I apologize in advance for being a little verbose in presenting my line of thought and my own opinion on the things I am not sure about, but I think it might help to put things in context and thus highlight any wrong assumptions and conclusions I have made.
Sometimes, the "200 billion lines" number is accompanied by the added claim that this corresponded to 80% of all programming code in any language in active use. Other times, the 80% merely refer to so-called "business code" (or some other vague phrase hinting that the reader is not to count mainstream software, embedded systems or anything else where Cobol is practically non-existent). In the following I assume that the code does not include double-counting of multiple installations of the same software (since that is cheating!).
In particular in the time prior to the y2k problem, it has been noted that a lot of Cobol code is already 20 to 30 years old. That would mean it was written in the late 60ies and 70ies. At that time, the market leader was IBM with the IBM/370 mainframe. IBM has put up a historical announcement on his website quoting prices, configuration and availability. According to the sheet, prices are about one million dollars for machines with up to half a megabyte of memory.
Question 1: How many mainframes have actually been sold?
I have not found any numbers for those times; the latest numbers are for the year 2000, again by Gartner. :^(
I would guess that the actual number is in the hundreds or the low thousands; if the market size was 50 billion in 2000 and the market has grown exponentially like any other technology, it might have been merely a few billions back in 1970. Since the IBM/370 was sold for twenty years, twenty times a few thousand will result in a couple of ten-thousands of machines (and that is pretty optimistic)!
Question 2: How large were the programs in lines of code?
I don't know how many bytes of machine code result from one line of source code on that architecture. But since the IBM/370 was a 32-bit machine, any address access must have used 4 bytes plus instruction (2, maybe 3 bytes for that?). If you count in operating system and data for the program, how many lines of code would have fit into the main memory of half a megabyte?
Question 3: Was there no standard software?
Did every single machine sold run a unique hand-coded system without any standard software? Seriously, even if every machine was programmed from scratch without any reuse of legacy code (wait ... didn't that violate one of the claims we started from to begin with???) we might have O(50,000 l.o.c./machine) * O(20,000 machines) = O(1,000,000,000 l.o.c.).
That is still far, far, far away from 200 billion! Am I missing something obvious here?
Question 4: How many programmers did we need to write 200 billion lines of code?
I am really not sure about this one, but if we take an average of 10 l.o.c. per day, we would need 55 million man-years to achieve this! In the time-frame of 20 to 30 years this would mean that there must have existed two to three million programmers constantly writing, testing, debugging and documenting code. That would be about as many programmers as we have in China today, wouldn't it?
EDIT: Several people have brought up automatic templating systems/code generators or so. Could somebody elaborate on this? I have two issues with that: a) I need to tell the system what it is supposed to do for me; for that I need to communicate with the computer and the computer will output the code. This is exactly what a compiler of a programming language does. So essentially I am using a different high-level programming language to generate my Cobol code. Shouldn't I work with that other high-level language instead of Cobol? Why the middle-man? b) In the 70s and 80s the most precious commodity was memory. So if I have a programming language output something, it should better be concise. Using my hypothetical meta-language would I really generate verbose and repetitive Cobol code with it rather than bytecode/p-code like other compilers of that time did? END OF EDIT
Question 5: What about the competition?
So far, I have come up with two things here:
1) IBM had their own programming language, PL/I. Above I have assumed that the majority of code has been written exclusively using Cobol. However, all other things being equal I wonder if IBM marketing had really pushed their own development off the market in favor of Cobol on their machines. Was there really no relevant code base of PL/I?
2) Sometimes (also on this board in the thread quoted above) I come across the claim that the "200 billion lines of code" are simply invisible to anybody outside of "governments, banks ..." (and whatnot). Actually, the DoD had funded their own language in order to increase cost effectiveness and reduce the proliferation of programming language. This lead to their use of Ada. Would they really worry about having so many different programming languages if they had predominantly used Cobol? If there was any language running on "government and military" systems outside the perception of mainstream computing, wouldn't that language be Ada?
I hope someone can point out any flaws in my assumptions and/or conclusions and shed some light on whether the above claim has any truth to it or not.
On the surface, the numbers Gartner produces are akin to answering the
question: How many angels can dance on the head of a pin?.
Unless you obtain a full copy of their report (costing big bucks) you will never know how they came up
with or justified the 200 billion lines of COBOL claim. Having said that, Gartner is a well
respected information technology research and advisory
firm so I would think they would not have made such a claim without justification or
explanation.
It is amazing how this study has been quoted over the years. A Google search for "200 billion lines of COBOL"
got me about 19,500 hits. I sampled a bunch of them and most attribute the number directly to the 1997 the Gartner report.
Clearly, this figure has captured the attention of many.
The method that you have taken to "debunk" the claim has a few problems:
1) How many mainframes have been sold This is a big question in and of itself, probably just as difficult
as answering the 200 billion lines of code question. But more importantly, I don't see how determining the number of
mainframes could be used in constraing the number of lines of code running on them.
2) How large were the programs in lines of code? COBOL programs tend to be large. A modest program can
run to a few thousand lines, a big one into tens of thousands. One of the jokes COBOL programmers
often make is that only one COBOL program has ever been written, the rest are just modified
copies of it. As with many jokes there is a grain of truth in it. Most shops have a large program inventory
and a lot of those programs were built by cutting and pasting from each other. This really "fluffs" up the
size of your code base.
Your assumption that a program must fit into physical memory in order to run is wrong. The size problem
was solved in several different ways (e.g. program overlays, virtual memory etc.). It was not unusual in the
60's and 70's to run large programs on machines with tiny physical memories.
3) Was there no standard software? A lot of COBOL is written
from scratch or from templates. A number of financial packages were developed by software houses the 70's and 80's.
Most of these
were distributed as source code libraries. The customer then copied and modified the source to
fit their particular business
requirement. More "fluffing" of the code base - particularly given that large segments of that code
was logically unexecutable once the package had been "configured".
4) How many programmers did we need to write 200 billion lines of code Not as many as you might think!
Given that COBOL tends to be verbose and highly replicated, a programmer can have huge "productivity".
Program generating systems were in vogue during the 70's and early 80's.
I once worked with a product (now defunct fortunately) that let me write "business logic" and it
generated all of the "boiler plate" code around it - producing a fully functional COBOL program. The code
it generated was, to be polite, verbose in the extreme. I could produce a 15K line COBOL program from
about 200 lines of input! We are taking serious fluff here!
5) What about the competition? COBOL has never really had much serious competition in the
financial and insurance sectors. PL/1 was a major IBM initiative to produce the one programming language
that met every possible computing need. Like all such initiatives it was too ambitious and
has pretty much collapsed inward. I believe IBM still uses and supports it today. During the 70's
several other languages were predicted to replace COBOL - ALGOL, ADA and C come to mind, but
none have. Today I hear the same said of Java and .Net. I think the major reason COBOL is still with us is that it
does what it is supposed to do very well and
the huge multi billion lines of code legacy make moving to a "better" language both expensive and
risky from a business point of view.
Do I believe the 200 billion lines of code story? I find the number high but not impossibly high given
the number of ways COBOL code tends to "fluff" itself up over time.
I also think that getting too involved in analyzing these numbers quickly degrades into a
"counting angels" exercise - something people can get really wound up over but has no
significance in the real world.
EDIT
Let me address a few of the comments left below...
Never seen a COBOL program used by an investment bank. Quite possible. Depends
which application areas you were working in. Investment banks tend to have
large computing infrastructures and employ a wide range of technologies. The shop
I have been working in
for the past 20 years (although not an investment bank) is one of the largest in
the country and it has a significant
COBOL investment. It also has significant Java, C and C++ investments as
well as pockets of just about every other technology
known to man. I have also met some fairly senior applications developers here that
were completely unaware that COBOL was still in use. I did a
rough line count through our source control system and found around 70 million lines of
production COBOL. Quite a few people that have worked here for years are completely oblivious to it!
I am also aware that COBOL is rapidly declining as a language of choice, but the fact
is, there is still a lot of it around today. In 1997, the period to which this question
relates, I believe COBOL would have been the dominant language in terms of LOC. The
point of the question is: Could there have been 200 billion lines of it in 1997?
Counting mainframes. Even if one were able to obtain the number of mainframes it would
be difficult to assess the "compute" power they represented. Mainframes, like most
other computers, come in a wide range of configurations and processing capacity.
If we could say there were exactly "X" mainframes in use in 1997, you still need to
estimate the processing capacity they represented, then you need to figure out what
percentage of the work load was due to running COBOL programs and a bunch of other
confounding factors. I just don't see how this line of reasoning would ever
yield an answer with an acceptable margin of error.
Multi-counting lines of code. That was exactly my point when
referring to the COBOL "fluff" factor. Counting lines of COBOL can be a very misleading statistic
simply because a significant amount of it was never written by programmers in the
first place. Or if it was, quite a bit of it was done using the cut-paste-tinker
"design pattern".
Your observation that memory was a valuable commodity in 1997 and prior is true. One would think that
this would have lead to using the most efficient coding techniques and languages
available to maximize its use. However, there are other factors: The opportunity cost of having an application
backlog was often perceived to outweigh the cost of bringing in more memory/cpu to deal with less than
optimal code (which could be cranked out quite a bit faster). This thinking was further reinforced by the
observation that Moore's Law leads to ever
declining hardware costs whereas software development costs remain constant. The "logical" conclusion
was to crank out less than optimal code, suffer for a while, then reap the benefits
in the years to come (IMO, a lesson in bad planning and greed, still common today).
The push to deliver applications during the 70's through 90's led to the rise of a host of
code generators (today I see frameworks of various flavours fulfilling this role).
Many of these code generators emitted tons of COBOL code. Why emit COBOL code? Why not emit
assembler or p-code or something much more efficient? I believe the answer is
one of risk mitigation. Most code generators are proprietary pieces of software owned by some
third party who may or may not be in business or supporting their product 10 years from now.
It is a very hard sell if you can't provide an iron-clad guarantee that the generated application can be
supported into the distant future. The solution is to have the "generator" produce something
familiar - COBOL for example! Even if the "generator" dies, the resulting application can
be maintained by your existing staff of COBOL programmers. Problem solved ;) (today we see
open source used as a risk mitigation argument).
Returning to the LOC question. Counting lines of COBOL code is, in my opinion, open to
a wide margin of error or at least misinterpretation. Here are a few statistics from an application
I work on (quoted approximately). This
application was built with and is maintained using Basset Frame Technology (frame-work) so
we don't actually write COBOL but we generate COBOL from it.
Lines of COBOL: 7,000,000
Non-Procedure Division: 3,000,000
Procedure Division: 3,500,000
Comment/blank : 500,000
Non-expanded COPY directives: 40,000
COBOL verbs: 2,000,000
Programmer written procedure Division: 900,000
Application frame generated: 270,000
Corporate infrastructure frame generated: 2,330,000
As you can see, almost half of our COBOL programs are non-procedure Division code (data declaration
and the like). The ratio of LOC to Verbs (statement count) is about 7:2. Using our framework
leverages code production by about a factor of 7:1.
So what should you make of all this? I really don't know - except that there is a lot of room to
fluff up the COBOL line counts.
I have worked with other COBOL program generators in the past. Some of these had absolutely
stupid inflation factors (e.g. the 200 lines to 15K line fluffing mentioned earlier). Given all these
inflationary factors and the counting methodology used in by Gartner, it may very well have
been possible to "fluff" up to 200 billion lines of COBOL in 1997 - but the question
remains: Of what real use is this number? What could it really mean? I have no idea. Now
lets get back to the counting angels problem!
I would never defend those clowns at Gartner, but still:
Your ideas about IBM/370s are wrong. The 370 was an architecture, not a specific machine - it was implemented on everything from water cooled monsters to small, mini-computer sized machine (same size as a VAX). The number sold was thus probably far larger, by orders of magnitude, than you suspect.
Also, COBOL was heavily used on DEC's VAX lineup, and before that on the DEC-10 and DEC-20 lines. In the UK it was used on all ICL mainframes. Lots of other platforms also supported it.
[Usual disclaimer - I work for a COBOL vendor]
It's an interesting question and it's always difficult to get a provable number. On the number of COBOL programmers estimates - the 2 - 3 million number may not be orders of magnitude in error. I think there have been estimates of 1 or 2 million in the past. And each one of those can generate a lot of code in a 20 year career. In India tens of thousands of new COBOL programmers are added to the pool every year (perhaps every month!).
I think the automatically generated code is probably bigger than might be thought. For example PACBASE is a very popular application in the banking industry. A very large global bank I know of uses it extensively and they generate all their code into COBOL and estimate this generated code is 95% of their total code base with the other 5% being hand coded/maintained. I don't think this is uncommon. The maintenance and development of those systems is typically done at the model-level not the generated code as you say.
There is a group of applications that were missing from the original question - COBOL isn't only a mainframe language. The early years of Micro Focus were almost entirely spent in the OEM marketplace - we used to have something like 200 different OEMs (lots of long-gone names like DEC, Stratus, Bull, ...). Every OEM had to have a COBOL compiler on their box alongside C and Assembler. A lot of big applications were built at that time and are still going strong - think about the largest HR ERP systems, the largest mobile phone billing systems etc. My point is that there is a lot of COBOL code that was never on an IBM mainframe and is often overlooked.
And finally, the size of the code base may be larger in COBOL shops than the "average". That's not just because COBOL is verbose (or was - that's not been the case for a long time) but the systems are just bigger - they're in large organizations, doing a large number of disparate tasks. It's very common for sites to have 10's of millions of LoC.
I don't have figures, but my first "real" job was on IBM 370s.
First: Number sold. In 1974, a large railway ran on three 370s. These were big 370s, though, and you could get a small one for a whole lot less. (For perspective, at that time whether to get another megabyte was a decision on the VP level.)
Second: COBOL code is what you might call "fluffy", since a typical sentence (COBOLese for line) might be "ADD 1 TO MAIN-ACCOUNT OF CUSTOMER." There would be relatively few machine instructions per line. (This is especially true on the IBM 360 and onwards, which had machine instructions designed around executing COBOL.) BTW, addresses were 16 bits, four to designate a register (using the bottom 24 bits as a base address) and 12 as an offset. This meant that something under 64K could be addressed at a time, since not all of the 16 registers could be used as base registers for various reasons. Don't underestimate the ability of people to fit programs into small memory.
Also, don't underestimate the number of programs. The program library would be on disk and tape, and was essentially only limited by cost and volume. (Earlier on, they'd be on punch cards, which had serious problems as data and program storage.)
Third: Yes, most software was hand-written for the business at that time. Machines were far more expensive then, and people were cheaper. Programs were written to automate the existing business processes, and the idea that you could get outside software and change your business practices was almost heresy. This changed over time, of course.
Fourth: Programmers could go much faster than today, in lines of code per person-year, since these were largely big dumb programs for big dumb problems. In my experience, the DATA DIVISION was a large part of each COBOL program, and that would frequently take large descriptions of file layouts and repeat them in each program in the series.
I have limited experience with program generators, but it was very common at the time to use it to generate an application and then modify the output. This was partly just bad practice, and partly because a program generator couldn't do everything needed.
Fifth: PL/I was not heavily used, despite IBM's efforts. It ran into early bad press, although as far as I know the only real major problem that couldn't be fixed was figuring out the precision system. The Defense Department used Ada and COBOL for entirely different things. You are omitting assembly language as a competitor, and lots of small shops used BAL (also called ASM) instead of COBOL. After all, programmers were cheap, compilers were expensive, and there were a whole lot of things COBOL couldn't do. It was actually a very nice assembly language, and I liked it a lot.
Well, you're asking in the wrong place here. This forum is dominated by .net programmers, with a significant java minority and such a age build-up that only a very small minority has any cobol experience.
The CASE tool market consisted for a large part of cobol code generators. Most tools were write-only, not two-way. That ensures there are a lot of lines of code. This market was somewhat newer than the 70s, so the volume of cobol code grew fast in the 80s and 90s.
A lot of cobol development is done by people having no significant internet access and therefore visibility. There is no need for it. Cobol prorammers are used to having in-house programming courses and paper documentation (lots of it).
[edit] Generating cobol source made a lot of sense. Cobol is very verbose and low level. The various cobol implementations are all slightly different, so configuring the code generator eliminates a lot of potential errors.
With regards to #4: how much of that could have been machine-generated code? I don't know if template-based code was used a lot with Cobol, but I see a lot of it used now for all sorts of things. If my application has thousands of LOC that were machine generated, that doesn't mean much. The last code-generating script I wrote took 20 minutes to write, 10 minutes to format the input, 2 minutes to run, then an hour to execute a suite of automatic tests to verify it actually worked, but the code it generated would have taken several days to do by hand (or the time between the morning meeting and lunch, doin' it my way ;) ). Ok I admit it's not always that easy and there is often manual tweaking involved, but I still don't think the LOC metric has much meaning if code-generators are in heavy use.
Maybe that's how they generated so much code in so little time.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 4 years ago.
Improve this question
I know that ALGOL language is super-uber-extremely important as a theoretical language, and it also had a variety of implementations as per Wikipedia.
However, what's unclear is, was ALGOL (pure ALGOL, not any of its derivatives like Simula) ever actually used for any "real" programming in any way?
By "real", I mean used for several good-sized projects other than programming language/CS research, or by a significant number of developers (say, > 1000).
Personally, the only ALGOL programming I have ever done was on paper, thus the curiosity.
Algol58 seems to have been the most successful in terms of important applications.
From Wikipedia:
JOVIAL is an acronym for "Jules Own
Version of the International
Algorithmic Language." The
"International Algorithmic Language"
was a name originally proposed for
ALGOL 58. It was developed to compose
software for the electronics of
military aircraft by Jules Schwartz in
1959.
Then:
Notable systems using JOVIAL include
the Milstar Communications
Satellite, Advanced Cruise
Missile, B-52, B-1B,
B-2 bombers, C-130,
C-141, and C-17 transport
aircraft, F-111,
F-15, F-16 (prior to Block
50), and F-117 fighter aircraft,
LANTIRN, U-2 aircraft,
E-3 Sentry AWACS aircraft,
Navy Aegis cruisers, Army
Multiple Launch Rocket System
(MLRS), Army UH-60 Black
Hawk helicopters, F100,
F117, and F119 jet
engines, the NORAD air
defense & control system (Hughes
HME-5118ME system) and RL-10
rocket engines. Airborne radar
systems with embedded JOVIAL software
include the APG-70, APG-71
and APG-73
ALGOL 68 was used in part of DRA for the same purpose. cf. Wikipedia:
The '''Defence Research Agency'''
(normally known as '''DRA'''), was an
executive agency of the UK Ministry of Defence
(MOD) from April 1991 until April 1995. At the
time the DRA was Britain's largest science and
technology organisation.
DRA's Algol68 compiler was finally open-sourced in April 1999 and is now available for linux for download from sourceforge. (However an interpreter for "Algol68g" is easier to use).
ICL's Algol68 was/is S3 - It was developed by the UK company International Computers Limited (ICL) for its 2900 Series mainframes. It is a system programming language based on ALGOL 68 but with data types and operators aligned to those offered by the 2900 Series. It was the implementation language of the operating system VME.
There are (at least) two other British operating systems - Flex and Cambridge_CAP_computer - written in Algol68 variants. And also 1 Soviet OS: Эльбрус-1 (Elbrus-1), but I have yet to find any of their source code. (If anyone can find and distribute to this source code please let me know)
BTW: I believe that VME is still running - in production - as a Linux/Unixware guest VM. Mostly at Commonwealth of Nations Custom/Immigration services.
Also over the same period the USSR was using Algol68, c.f. history link. Algol68 is used in Russian telephone exchanges. And Algol58 was used in the Russian "Buran/Буран" Space Shuttle landing system.
ALGOL68 was internationalized in 1968. I suspect there are other Algol projects in other countries. esp in German, in Dutch Japanese and Chinese but I have no details.
If you want to actually tryout Algol68 and/or contribute your code, check out Rosettacode's ALGOL 68 repository, then as a class project try one of the "Tasks not implemented".
Nothing like responding to 2 year old threads. I program in ALGOL almost daily. I am a programmer on a Unisys ClearPath mainframe and the majority of the system code is written in ALGOL or variants. The Burroughs B5500 was really designed around the language so it is a pretty efficient language/compilation process. Granted, this version is ALGOL with some extensions like limited classes (structure blocks), etc.
i := 80;
while i > 0 do
begin
scan ptrRay:ptrRay for i:i until in ALPHA;
scan ptrEnd:ptrRay for i:i while in ALPHA;
if i > 0 then
begin
replace nextToken by ptrRay for (offset(ptrEnd) - offset(ptrRay));
end;
end;
That code scans for ALPHA only tokens. It uses the OFFSET function which is a little more costly than using the residual count math yourself (i, starti, etc);
Like Tom, I program in ALGOL almost daily - and I'm also on a Unisys Clearpath. ALGOL has been the primary source of my mortgage repayments for more years than I care to remember.
When I started programming, Algol was the only compiler available. Yes, it was mainstream till we got a Fortran compiler.
To follow up on themis' answer, the entire Burroughs "large system" family (5000, 5500, 5700, 6500, 6700...) was really designed to run Algol well. The operating system, compilers, and major system utilities were written in Algol; if that's not "real" programming, what is?
To be precise, over the life of the product family Burroughs extended Algol into a superset called ESPOL. When Burroughs brought out the "small systems" family (1700, 1800, 1900 series), they defined another Algol-like language called SDL (Systems Development Language) in which the operating software of that line was written. Access to SDL was restricted for security reasons. A variant of SDL was subsequently created with a few of the "priveleged" features removed. The resulting language, called UPL (User Programming Language), was available for customer use.
Some of us still remember when the phrase "Algol-like language" was used to describe any programming language with block-oriented control structures and variable scoping. Widely-known examples of Algol-like languages included PL/I, Pascal, and (...wait for it...) C.
Algol was the major programming language for the Burroughs B5000.
However, what's unclear is, was Algol (pure Algol, not any of its derivatives like Simula) ever actually used for any "real" programming in any way?
Please, avoid the term "real" programming. "Real" - as opposed to what ? Imaginative ?
By "real", I mean used for several good-sized projects other than programming language/CS research, or by a significant number of developers (say, > 1000).
Yes. It was used for a certain number of projects on which worked a certain number of developers.
Only, what is usually misinterpreted often today is this; in those days computers weren't exactly a household commodity. Hell, they weren't that 30 years ago, less alone 60.
Programming was done in computer centres which were either in goverment ownership (military, academic, institutes of various kinds) or in private enterprises (large companies). And programming wasn't a profession - it was something which engineers, mathematicians, scientiscs and the like used to do when their work was done on paper ... or they had specialized operators which did it for them. Often women, who may or may have not had a scientific background in that particular field - they were "language translators", in lack of a better term (and my bad english).
Programming theories and research was at its beginnings ... vendors being few (and naturally uncooperative to each other) ... each of them used their own extensions, and often programs written for one didn't work well with the other vendor's systems.
There wasn't a "right way" to do something ... you had that and that, and you used whatever catch you could figure to work around your problem.
But, I've wandered off. Let me get back to the number of people. This also goes for several other languages; fortran and cobol, for example.
People say, "very few use it". That's simply not true. What is true is that a small percentage of people uses it today, but a larger percent of people used to use it.
As I said, in those days only the sci. and eng. community used to do it. And their number was relatively small, compared to the total population. Nowadays, everybody uses computers, but the absolute number of engineers, mathematicians and the like, is pretty much the same. So it seems that nobody uses those languages anymore ... while in reality, for certain specialized languages (well, nowadays this goes for fortran and cobol, more than algol) the number of users is pretty much constant.
Personally, the only Algol programming I have ever done was on paper, thus the curiosity.
I know I didn't answer your question, but just wanted to clear this. Algol was a little "beofre my time".
My first programming experience was on a Burroughs B5500 owned by Northern Natural Gas Company starting in 1970. I started out in COBOL but switched to ALGOL (actually used both) when they needed additional support for a large Oil & Gas Lease Information system that was written almost entirely in ALGOL. At the time there were two programming departments, Business Systems and Scientific Computing. The Scientific Computing department programmed in ALGOL and FORTRAN while the Business Systems department was mostly COBOL with a smattering of ALGOL. Northern advanced from the B5500 to B6500, B6700, B6900, B7800, and B7900 while I was there. I eventually transferred to the Technical Support department and got into making and supporting MCP patches to customize the system for Northern's needs. That was fun!
Short answer to the question. Yes. Northern had a number of application systems written in ALGOL. Of course it was Burrough's version of ALGOL (extended ALGOL).
Burroughs B5500 Extended Algol was used heavily for research in astrophysics, linguistics, and statistics at my university (Monash University, Australia) in the late 60s. It was also used in commercial applications that helped pay the bills for the computer center.
As I write this I am running Algol programs in the latest release of the Burroughs B5500 emulator from the team at retro-b5500 in Tasmania. The emulator runs entirely in the browser and faithfully models the processors, disks, tapes, card readers, line printers, card punches and datacom gear!
You can read about the project at http://retro-b5500.blogspot.com/ and http://code.google.com/p/retro-b5500 and you can write Algol programs for arguably the finest Algol machine ever made (except perhaps its successor the B6700.)
One of the postdocs from Monash wrote a reverse compiler from IBM Assembler to Burroughs COBOL in Algol, which was used to migrate all the billing applications at the state-run Gas & Fuel Corporation from IBM 360s to Burroughs 6700s.
Back in 1970, I helped develop a Jovial compiler for the Royal Dutch Navy. One of its big advantages was that it was written in Jovial, hence we all got to become pretty good Jovial experts. In fact, as part of the test cycle we would compile the compiler though the latest incarnation of itself and run all our test sets on that. If it passed we would release the first compiler. Thus each release had the capability of compiling itself and that compiler could pass all tests. As every found bug was always added to our self-checking test set the quality of the compiler improved and improved. By the time we left the project we had no known bugs...my once and only time that ever happened.
I programmed in Algol/Jovial back in the 70's for the military. I loved the language. You couldn't do recursion in Fortran and I often could make a program much easier by using the correct data structure and a little recursion.
After I had left that assignment, I found that the other developers on the project didn't want to maintain the Jovial code and tried to replicate what I had done in Fortran. It just didn't work and was much slower.
I learned about compiler theory by digging into the source code for the Jovial compiler. Ah... those were the days.
Algol was well implemented on the Elliott 4100 machine and was used extensively to develop early refinery process simulations at BP Research center in the late 60s. However, at that time Input/output was not well defined (varied between machines) and at BP it was quickly overtaken by Fortran IV as programs written in strict Fortran IV would run on almost any machine variation - IBM, Univac, Atlas, etc., etc.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Developers can learn a lot from other industries. As a thought exercise, is it possible to build a passenger aircraft using agile techniques?
Forgetting cost for now; how feasible is it to use iterative and incremental development for both the hardware (fuselage, wings, etc) as well as software, and still come out with a working and safe product which meets the customer’s requirements at the time of delivery?
Does it make sense to refactor a plane?
Agile in software and Agile in manufacturing are really quite different, although they share similar principals and values.
Agile in manufacturing emerged in Japan in the 1950s. Read up on W.E. Deming and the Toyota Production System to find out more. It's all about constantly improving the process whereby a product is reproduced.
Agile in software evolved in the early 1990s as a rapid development model. It's all about constantly improving the product.
You can certainly build a plane using Agile manufacturing methods, I've no doubt that some already are. Anything built in Japan definitely will be as Agile manufacturing is very well established there (it's taught in primary schools).
You couldn't build a plane using Agile software methods because you can't afford to rapidly change the product - in software changes and mistakes are cheap and reproduction is free. This isn't the case for aviation.
You could design a prototype plane using something like Agile software methods - but it would have to be standardised in order to be reproduced (a design task in itself).
How would you work using Test Driven Development? Would you automatically build and test a plane every iteration? Would you be able to make a ten minutes build? How easy is to make changes to the airplane? Even if you are really flexible in your desing the building some components need to be sent to special factories so there is not inmmediate feedback.
From de design using CAD software you need to make a mould, take the piece of fiber, put it in the plane. Etc. So here a trivial change has a non trivial cost. In Agile you can make a very little change and have it tested, built and an ready to ship in 20 minutes. If small changes are expensive then the short development cycle and refactoring won't be so usefull. Your feedback can take longer than a week so there is a strong reason for thinking in advance like in the waterfall model. And every attempt has a cost in physical materials unless you are programming. The Idea is not new. Carpenters measure twice. Programmers just first code and then test.
In summary. There may be some similarities but it will definitively be the same.
I'm going to say "kind of". In fact there's one example right now that I think is pretty close to answering this question.
Boeing is attempting to do this now with the new 787 - see following: Boeing 787 - Specification vs. Collaboration (From the 777 to the 787, the initial specifications document supposedly went from 2500 pages to 20 pages with the change in technique.) Suppliers from around the world are working independently to develop the components for this aircraft. (We'll call this the "teams".)
So, I want to say yes, but at the same time, iterations in creating the aircraft has resulted in delays of 2+ years and has resulted in stories like this one - (787 Delayed for 5th Time)
Will the airplane ever get built? Yes, of course it will. But when you look at the rubber hitting the road here, it seems like "integration test" is having one heck of a time.
Edit: At the same time, this shift in technique has resulted in building a new breed of aircraft built out of entirely new materials that will arguably be one of the most advanced in the world. This may be a direct result of the more Agile approach. Maybe that's actually the question - not a "can you?" but a "if Agile delays complex systems, does it provide a more innovative product in the payoff?"
Toyota pioneered Lean Production which Agile methodoligies followed on from. For the building of the hardware of the aircraft lean production would be the way to go and for the software an agile methodology would be the way to go.
Pick the right tools for the job.
A great book following how TPS was created and works
http://www.amazon.com/Machine-That-Changed-World-Production/dp/0060974176
http://en.wikipedia.org/wiki/Toyota_Production_System
I think in this case you are thinking too big. Agile is about breaking things down into more managable pieces and then working against that. The whole idea of Agile (XP in particular) is that you do your testing first so that you cut the number of bugs out and because plane software needs to have a very high code coverage for its testing it fits in quite neatly I think.
You aren't going to 'refactor' the mechanics of the plane but you will tweak them if they are unsafe and thats the whole iterative approach for you.
I have heard of Air Traffic Control software written with Agile Methodologies pushing it forward.
This is taken from http://requirements.seilevel.com/blog/2008/06/incose-2008-can-you-build-airplane-with.html
***Actually, that’s not true,***
My first guess - this probably relates to some of the core differences between systems and software engineering. I am going to over simplify this and just say that it is about scale. Systems projects are just a superset of software and hardware projects, integrating and deploying some combination of these. The teams of people deploying systems projects are quite large. And many of the projects discussed here are for government or regulated systems where specification and traceability is necessary. I could see how subsets of systems projects could in fact be developed using agile (pure software components), but I’m not convinced that an entire end-to-end project can. To put this in context, imagine you are building an airplane - a very commonly referenced type of systems engineering projects. Can you see this working using agile?
All skeptism aside, I do think that iterative development most certainly could work well on systems projects, and most people here would not argue that. In fact, I would love it if we could find examples of agile working on systems projects, because the number one feeling I get at systems engineering conferences is a craving for lighter processes.
I decided to do a little research outside the conference walls, and low-and-behold, I found a great article on this exact topic – “Toward Agile Systems Engineering Processes” by Dr. Richard Turner of the Systems and Software Consortium. The article is very well laid out, and I highly recommend reading it. He defines what agile is and what he believes the issue why most systems engineering projects are not agile. For example, he suggests that executives and program managers tend to believe that the teams involved have perfect knowledge about systems we are building, so we can plan them out in advance and work to a perfect execution against a perfect schedule.
Agile Can Work With Complex Systems
He talks to how to the agile concepts can work in systems projects. Here are a few examples summarized from his article:
Learning based: The traditional V-model implies a one-time trip through, implying one time to re-learn. However, perhaps the model can be re-interpreted to allow multiple iterations through it to fulfill this.
Customer focus: Typically systems engineering processes do not support multiple interactions with the customer throughout the project (just up front to gather requirements). That said, he references a study indicating the known issues with that on systems projects. Therefore, perhaps processes should be adapted to allow for this, particularly allowing for them to help prioritize requirements throughout projects.
Short iterations: Iterations are largely unheard of because the V-model is a one-time pass through the development lifecycle. That said, iterations of prototyping through testing could be done in systems engineering in many cases. The issue is in delivering something complete at the end of each iteration. He suggests that this is not as important to the customer in large deployments as is reducing risk, validating requirements, etc. This is a great point to rememember the airplane example! Could we have even a working part of an airplane after 2 weeks? What about even the software to run a subsystem on the aircraft?
Team ownership: Systems engineering is very process driven, so this one is tricky. Dr. Turner puts the idea out that perhaps allowing the systems engineers to drive it instead of the process to drive them, while more uncomfortable for management, might produce more effective results.
There is this story of an aircraft engine plant (September 1999). Their methods seem quite agile:
http://www.fastcompany.com/magazine/28/ge.html
Yes, you could do it. If you followed Agile Software Development techniques too closely however, it would be astronomically expensive, because of the varying costs of activities.
Consider the relative costs of design and build. If we include coding as part of the software design process, then design is definitely the expensive part and build is ridiculously easy and cheap. Most Agile projects would plan to release every few iterations at least. So we can work in small iterations with a continuous build process. Not so easy when you have to assemble a plane once a fortnight. Worse if you actually plan on "releasing" it. You'd probably need to get the airworthiness & safety people on to an Agile process too.
I'd truly love to see it tried.
Yes, you can use agile techniques for building complex systems, but I don't know if I'd use it for this particular system.
The problem with aircraft is the issue of safety. This means every precaution needs to be taken, from correctly identifying and interpreting the requirements to verifying and validating each and every single line of code.
Additionally, formal methods should probably be used to make sure that the system is truly safe by making sure the programming logic is sound and satisfies its conditions properly.
I'm fairly certain the answer is irrelevant. Even if you could, you would not be allowed to. There are too many safety requirements. You would not even be allowed to develop the flight software using Agile. For instance, you do not have a Software Requirements Specification (SRS) in Agile. Yet, for any avionics software onboard an airplane that can affect flight safety you will need an SRS.
Of course one can refactor a plane.
When one refactor, one modifies the source code, not the binaries. With a plane it's exactly the same thing: one modifies the blueprints, not the plane itself.
Does anybody know of any research or benchmarks of how long it takes to develop the same application in a variety of languages? Really I'm looking for Java vs. C++ but any comparisons would be useful. I have the feeling there is a section in Code Complete about this but my copy is at work.
Edit:
There are a lot of interesting answers to this question but it seems like there is a lack of really good research. I have made a proposal over at meta about this problem.
Pratt & Whitney, purveyors of jet engines for civilian and military applications, did a study on this many years ago, without actually intending to do the study.
They went on the same metrics kick everyone else went on in the 1990s. They collected a bunch of data about their jet engine controller projects, including timecard data. They crunched it. The poor sap who got to crunch the data noticed something in the results: the military projects uniformly had twice the programmer productivity and one/fourth the defect density as the civilian projects.
This, by itself, is significant. It means you only need half as many programmers, and you aren't going to spend quite as much time fixing bugs. What is even more important is that this was an apples-to-apples comparison. A jet engine controller is a jet engine controller.
He then went looking for candidate explanations. All of the usual candidates: individual experience, team size, toolsets, software processes, requirements stability, everything, were trotted out, and they were ruled out when it was seen that the story on those items was uniformly the same on both sides of the aisle. At the end of the day, only one statistically significant difference showed up.
The civilian projects were written in every language you could think of. The military projects were all written in Ada.
IN EVERY SINGLE CASE, against every other comer, for jet engine controllers at Pratt & Whitney, using Ada gave double the productivity and one/fourth the defect density.
I know what the flying code monkeys are going to say. "You can do good work in any language." In theory, that's true. In practice, however, it appears that, at least at Pratt & Whitney, language made a difference.
Last I heard about this, Pratt & Whitney upper management decreed that ALL jet engine controller projects would be done in Ada.
No, I don't have a citation. No paper was ever written. My source on this story was the poor sap who crunched the numbers. Here's a similar study from 1995:
http://archive.adaic.com/intro/ada-vs-c/cada_art.html
This, incidentally, was BEFORE Boeing did the 777, and BEFORE the 777 brake subcontractor story happened. But that's another story.
One of the few funded scientific studies that I'm aware of on cross-language productivity, from the early 90s, funded by ARPA and the ONR,
Haskell vs. Ada Vs. C++ vs Awk vs ... An Experiment in Software Prototyping Productivity, Hudak & Jones, 1994.
We describe the results of an
experiment in which several
conventional programming languages,
together with the functional language
Haskell, were used to prototype a
Naval Surface Warfare Center (NSWC)
requirement for a Geometric Region
Server. The resulting programs and
development metrics were reviewed by a
committee chosen by the Navy. The
results indicate that the Haskell
prototype took significantly less time
to develop and was considerably more
concise and easier to understand than
the..
This article(a pdf) has some benchmarks (note that it's from 2000) between C, C++, Perl, Java, Perl, Python, Rexx and Tcl.
Some common wisdom I believe holds true (also somewhere within the article):
The number of lines written per hour is independent of the language
Opinion: more important is what is faster for a given developer, for example yourself. What you are used to, will usually be faster. If you are used to 20 years of C++ pitfalls and never skip an uninitialized variable, that will be faster than Java for anybody.
If you remember all parameters of CreateWindowEx() by heart, it will be faster than MFC or winforms.
A couple of anecdotal data points:
On Project Euler, which invites programming solutions to mathematical problems,
the shortest solutions are almost invariably written in J or K, a relative of APL; there are occasionally MatLab solutions in the same range. It can be argued, though, that these languages specialized in math.
runners up were Ruby solutions. A lot of algorithm can be wrapped in very little code, and it's much more legible than J / K.
Python and Haskell solutions also did very well, LOC-wise.
The question asked about "fastest development," not "shortest code." But it's conceivable that shorter solutions are faster to come up with - certainly for slow typists!
There's an annual competition among roboticists. Contestants are given some specs for some hardware, a practical problem to solve in software, and limited time to do so. Again very domain specific, of course. Programmers have their choice of tools, including language of course. Every year, the winning team (often a single person) used Forth.
This admittedly limited sample suggests that "development speed" and "effect of language on speed" is often very dependent on the problem domain.
See also
Are there statistical studies that indicates that Python is "more productive"?
for some discussions about this kind of question.
It would make more sense to benchmark the programmers, not the languages. The time to write a program in any mainstream language depends more on the ability of the programmer in that language than on qualities of that specific language.
I think most benchmarks and statements on this topic will mean very little.
Benchmarks can always be gamed; see the history of "Pet Store".
A language that's good at solving one kind of problem might not apply as well to another.
What matters most is the skill of your team, its knowledge of a particular technology, and how well you know the domain you're trying to solve.
UPDATE: Control software for jet engines and helicopters is a very specialized subset of computing problems. It's characterized by very rigorous, complete, detailed specs and QA that means the multi-million dollar aircraft cannot crash.
I can second the (very good) citation by John Strohm of Pratt & Whitney control software written in Ada. The control software for Kaman helicopters sold to Australia was also written in Ada.
But this does not lead to the conclusion that if you decided to write your next web site in Ada that you'd have higher productivity and fewer defects than you would if you chose C# or Java or Python or Ruby. All languages are not equally good in all problem domains.
Language/framework comparison for web applications
The Plat_Forms project provides some information of this type for web applications.
There are three studies with different tasks (done in 2007, 2011, 2012), all of the following format: Several teams of three professional developers implemented the same application under controlled conditions within two days.
It covers Java, Perl, PHP, and Ruby and has multiple teams for each language.
The evaluation reports much more than only development time.
Findings of iteration one for instance included
that experience with the language and framework appeared to be more relevant than what that framework was.
that Java tended to induce teams to make laborious constructions while Perl induced them to make pragmatic (and quite handy) constructions.
Findings of iteration two included
that Ruby on Rails was more productive in this type of project (which due to its duration was more rapid prototyping than full-blown development of a mature application)
and that the one exception to the above rule was the one team using Symfony, a PHP framework that has similar concepts to Ruby on Rails (but still the very different base language underneath it).
Look under http://www.plat-forms.org or search the web for "Plat_Forms".
There is plenty more detail in the reports, in particular the thick techreport on iteration 1.
Most programs have to interface with some other framework. It tends to be a good idea to pick the language that has libraries specifically for what you are trying to do. For instance are you trying to build a distributed redundant messaging system? If so I would use Erlang. Are you trying to make a quick and dirty data driven website, use Ruby and Rails. You get the idea. Real time DirectX where performance is key, C++/C/Asm.
If you are writing something that is algorithm based I would look to a functional language like Haskell, although it has a very high learning curve.
This question is a little old fashioned. Focusing on development time solely based on the choice of language is of limited value. There are so many other factors that have equal or more impact than the language itself:
The libraries or frameworks available / used.
The level of quality required (ie. defect count).
The type of application (eg. GUI, server, driver etc...)
The level of maintainability required.
Developer experience in the language.
The platform or OS the application is built on.
As an example, many would say Java is the better choice over C++ to build enterprise (line of business) applications. This is not normally because of the language itself, but instead it is perceived that Java has better (or more mature) web server and database frameworks available to it. This may or may not be true, but that is beside the point.
You may even find that the building an application using the same language on different operating systems or platforms gives greatly differing development time. For example using C++ on Linux to build a GUI application may take longer than a Windows based GUI application using C++ because of less extensive and mature GUI libraries avaialble on Linux (once again this is debatable).
According to Norvig, Lutz Prechelt published just such an article in the October 1999 CACM: "Comparing Java vs. C/C++ Efficiency Issues to Interpersonal Issues".
Norvig includes a link to that article. Unfortunately, the ACM, despite having a bitmap graphic proclaiming their goal of "Advancing Computing as a Science & Profession", couldn't figure out how to maintain stable links on their webpage, so it's just a 404 now. Perhaps your local library could help you out.
That Ada story might be an embellished version of this: http://www.adaic.com/whyada/ada-vs-c/cada_art.html
Erlang vs C++/Corba
"... As the Erlang DCC is less than a quarter of the size of a similar C++/CORBA implementation, the product development in Erlang should be fast, and the code maintainable. We conclude that Erlang and associated libraries are suitable for the rapid development of maintainable and highly reliable distributed products."
Paper here
There's a reason why there are no real comparisons in that aspect, except for anecdotal evidence (which can be found in favor of almost any language).
Actually writing code takes relatively small portion of developer's time. Even if language lets you cut coding time in half, it will be barely noticeable by the time project ends. Design, structure of program, development process are all much more important, and then there are libraries, tools and experience with them.
Some languages are better suited for certain development processes than the others, so if you've settled on design and process you can decide which language will be more efficient - but not before.
(didn't notice there's a similar answer already, so feel free to ignore this)