COBOL Celebrates 50 Years 277
oranghutan writes "The language used to power most of the world's ATMs, COBOL, is turning 50. It also runs about 75 per cent of the world's business applications, so COBOL should be celebrated for making it to half a century. In cricketing terms, that's a good knock. The author says: 'COBOL's fate was decided during a meeting of the Short Range Committee, the organization responsible for submitting the first version of the language in 1959. The meeting was convened after a meeting at the Pentagon first laid down the guidelines for the language. Half a century later, Micro Focus published research which showed people still use COBOL at least 10 times throughout the course of an average working day in Australia. Only 18 per cent of those surveyed, however, had ever actually heard of COBOL.'"
A good knock in deed.. (Score:5, Funny)
Re: (Score:2)
Though, to be fair, 50 years isn't quite as long as the average cricket game.
Though, to be fair, with games lasting up to 5 days, [wikipedia.org] it just seems like 50 years.
Re: (Score:3, Funny)
Yeah, I almost had time to write a hello world program in COBOL during a cricket game once. Though I couldn't find enough Libraries of Congress to save it in, so I had to chuck it. A shame, really.
75% of apps? Shaa, right! (Score:4, Interesting)
"It also runs about 75 per cent of the world's business applications"
Gee, I didn't know Windows Apps were coded in COBOL.
Come on, 75% is a HIGHLY dubious claim. Where's the source / proof / evidence? Where I work, we have nearly 200 business apps and I'm pretty sure less than 2% of business apps were made in COBOL - possibly even 0%.
Adeptus
Re:75% of apps? Shaa, right! (Score:5, Informative)
Do you accept or make payment via credit card, check or ATM debit? Congratulations, you (indirectly) use COBOL.
Re:75% of apps? Shaa, right! (Score:5, Insightful)
Can we get rid of it? Surely COBOL has developed faults over time, just like a train that's been running since 1850 would have.
Or, just maybe, it's proven itself to be stable, reliable, well-understood, suited to the purpose for which it's used and relatively bug free?
Nah, of course not. It's old and busted. Bring on the new hotness.
Re: (Score:2)
Stable, reliable, well-understood, and bug-free are true of many more recent languages.
I dispute that it's the best suited to the purpose for which it's used. Show me a construct in COBOL that wouldn't be much easier in something modern -- even Java, if we have to.
Re:75% of apps? Shaa, right! (Score:5, Insightful)
Stable, reliable, well-understood, and bug-free are true of many more recent languages.
<sarcasm>I didn't know that more modern languages had a 50 year history of reliability, scalability, and security to process transactions 24/7. Live and learn I guess...</sarcasm>
Further, the cost of developing, debugging, and testing the replacement in any language (including redeveloping the system from the ground up in COBOL) is quite expensive, no matter what language you choose. Likely more expensive than the big iron and software environments necessary to run the old code that has worked reliably for the last 20 to 40 years.
Re: (Score:3)
I didn't know that more modern languages had a 50 year history of reliability, scalability, and security to process transactions 24/7.
That's a bit like the guy who puts "10 years of Ruby on Rails experience required" in a job posting. Of course it can't have precisely the same track record if it hasn't been around that long.
It's also a bit like saying "I didn't know that modern cars had a 100+ year history of reliability, scalability
But take Erlang -- released in 1986, and has been known for consistent reliability, even in the face of programmer error -- catching errors, respawning those processes, and letting the programmer fix the under
Re:75% of apps? Shaa, right! (Score:5, Insightful)
Stable, reliable, well-understood, and bug-free are true of many more recent languages.
Yup, JAVA never crashes, C# is easily understood, C++ is free of bloat, and interpreted languages run faster. /s
I dispute that it's the best suited to the purpose for which it's used. Show me a construct in COBOL that wouldn't be much easier in something modern -- even Java, if we have to.
COBOL isn't used because it's easier to write than your JAVA or other new language. It's used because it was designed with business transactions in mind and is reliable. If you have to give up reliability or predictability to gain readability or 'modern-ness' (as has often been my experience with JAVA), it's not a good fit for businesses who can hire additional programmers to produce reliable code.
Regardless, if COBOL works well for the application already, then some modern language would have to one hell of a lot better to rewrite these applications for the incremental improvement to be worth the cost and risk involved with a complete rewrite.
Re: (Score:3, Insightful)
I've seen the JVM (that's one that is capitalized!) crash multiple times on more complex programs. One was a digital logic architect program written by a professor and several graduate students. After several years of development, it still crashed frequently on large projects, due to the JVM running out of memory. Crashes were common enough that we had to convince the professor to add an auto-save to make it less un-usable. Not saying it's due to Java specifically, but it did seem to be linked to the vi
Re:75% of apps? Shaa, right! (Score:4, Interesting)
After several years of development, it still crashed frequently on large projects, due to the JVM running out of memory.
So, JVM memory leak, or application memory leak?
Regardless, I have yet to see a compelling argument to rewrite COBOL code in Java or any other 'modern' language. If the COBOL works, and will continue to in the near future, what is the benefit of a lengthy rewrite?
Maintainability.
The question is, does the COBOL do everything you need it to do? How much does it cost (in terms of time, money, manpower) to make a change you need to make? Add up that cost, estimate it over time, compare to the cost of a rewrite and how maintainable it would be after said rewrite.
Granted, sometimes, there's not going to be a lot of justification. But when a change wages requires six months of work, it's worth seriously considering how long a rewrite would take. Six months for what should be a ten minute change (generously), no matter what the language, demands a rewrite.
It's also something that has to be thought about carefully, because it may not be immediately apparent what such flexibility could buy you.
Some bad analogies: If I did my accounting with a paper ledger, computerizing the process would probably make no sense to me -- until you realize that once it's in the computer, it can automatically do much of the math, eliminating errors, or making them much easier to fix. Similarly, if I became a fluent C/C++ programmer (especially C++), it might not be immediately obvious to me how useful garbage collection is -- but there's a whole class of bugs that just disappear when you use a garbage-collected language. If you've only ever worked with punch cards, or with a slowly-compiled language, it may not be immediately obvious how useful an interactive command prompt (read-eval-print-loop, to use the LISP terminology) can be.
So it's worth considering, just pulling something out of my ass: If it only took a few minutes to author a report, what kinds of reports could you have? How specialized would they get?
Perhaps some modern language might be a best fit for a newly written program, but I'm still not convinced. While I can't say for certain that COBOL will compile to be any faster than the equivalent Java, my experience with high-level languages tells me that they tend to create bloated executables.
Bloated by what metric?
Especially, you mentioned "bloated executables" -- if /usr/bin/myapp is ten megs instead of a few hundred kilobytes, seriously, how much does ten megs of disk/RAM cost? And how much does a team of qualified COBOL programmers cost, how much of a direct cost is there due to COBOL taking longer to implement, and how much of an indirect cost due to whole classes of bugs that simply don't show up in another language?
And, when you add it all up, if your app is the kind that would work well on a cluster, how much more are you paying for your mainframe than it would cost to build the equivalent cluster out of PC hardware? Suppose you could triple the hardware and still save money -- thus a language that's three times as slow ultimately costs exactly as much as COBOL, performance-wise.
So, tl;dr on that one: The Big Picture is much more complicated than whether your executable is "bloated".
Re: (Score:3, Informative)
GP uses the old "virtuality is reality" fallacy*. COBOL is not like a train, because it is not exposed to nature/physics. There is no natural disintegration in virtual things. It can lie there for a trillion years, and if the hardware is kept running and backups and error-correction are in place, it will not degrade in a single bit.
Also "surely" is no base for any arguments to put on top of it. :)
___
* The same one that media distribution companies use, to act as if the software on that media would be a real
Re: (Score:3, Insightful)
That assumes that programmers make well-informed, rational decisions at all times. Chuckle.
Re: (Score:2)
If you worked at the Fed, you would know that none of the things you mentioned are handled by the Fed.
I think he means fully educated dropout. Been to college, knows it all, can't hack a real job but will try to impress people on /. by saying he works for the Fed.
Re:75% of apps? Shaa, right! (Score:5, Informative)
"It also runs about 75 per cent of the world's business applications"
Gee, I didn't know Windows Apps were coded in COBOL.
They can be, using the excellent Microfocus COBOL or many other implementations.
But actually, only a very few of the world's (important) business applications run on Windows. Seriously. Big heavy-duty transaction-processing apps run overwhelmingly on mainframes, because they just work.
Re:75% of apps? Shaa, right! (Score:4, Insightful)
I think what we're arguing over here is the application of the English language. As the sentence is written, it is probably incorrect. Due to logarithmic growth, it is virtually impossible that the numbers come out right. If one said that 70% of business transactions were facilitated through COBOL at least in part then it might be true, because of all the legacy code still doing its job out there at banks and other financial institutions.
Mainframes are breathing their last gasp; they will soon exist only in cases where you need very fast access to all of very large data sets. And honestly, clustering filesystems and databases are solving that problem too. Clusters will rule nearly every aspect of large computing because they are the only thing more reliable than a mainframe.
Re:75% of apps? Shaa, right! (Score:5, Insightful)
they will soon exist only in cases where you need very fast access to all of very large data sets.
Which is quite often.
And honestly, clustering filesystems and databases are solving that problem too.
Except that clustering filesystems almost always have to compromise on one of the ACID properties. For example, Amazon's Dynamo and CouchDB are highly available, redundant, and fast, but allow conflicts, assuming the application will correct for them. Ok, but that fails for a banking application -- if I were to withdraw my entire balance from two different nodes simultaneously, I'd have a massive overdraft, but I'd also have the money.
You could imagine trying to shard it instead, but what happens when you transfer money between two shards? You still need a transaction, only now it needs to be synchronized between two nodes. What do you do? Do you lock both nodes at once? Now you've got a possibility of deadlocks.
Clusters will rule nearly every aspect of large computing because they are the only thing more reliable than a mainframe.
Reliability can be defined in several ways. Clusters are more available than a mainframe -- if your mainframe goes down, you're down. But clusters are less consistent than a mainframe, unless you're willing to take such massive hits from synchronization that the performance advantage is gone.
For the vast majority of applications, some inconsistency is acceptable. Take Amazon's example -- if you tell one node to add item A to your cart, and another node to add item B, producing two conflicting versions of your cart, the cart application should be smart enough to merge them. The only synchronization needed is checkout, and here, all you'd need to do is refer to a specific version of that record in the form that's submitted.
But for applications which can't tolerate that inconsistency, unless there's some clustering method I'm unaware of, you're still going to want something like a mainframe.
Re: (Score:2)
Re: (Score:2)
Mainframes are breathing their last gasp; they will soon exist only in cases where you need very fast access to all of very large data sets.
Why would you need a mainframe just for that? A fully upgraded SGI Altix 4700 will be faster then IBM's fastest mainframe and I also think that HP's superdrome is up there in performance.
Re: (Score:3, Interesting)
Where I work we benchmarked database performance on existing servers vs. a Linux partition on the mainframe. Performance was 5 times faster on the mainframe. Massively parallel high speed IO made the mainframe faster So now we are converting stuff over to the mainframe. And if we want near 100% uptime, it's done on the mainframe, so the most important web sites run on the mainframe.
I do agree with your comment though about the 70% of transactions.
As a side note, COBOL is an easy language, but others are mor
Re:75% of apps? Shaa, right! (Score:5, Insightful)
I have to agree. We recently switched parts of our tax billing software from an old COBOL system running on an AS400 to Windows. There were some legitimate concerns involved - creating a graphical sketch wasn't possible on a text-mode system, and tax laws change very frequently, and the old system was just becoming difficult to maintain.
So, we switched to a Windows app with a SQL Server backend. FWIW the database backend has been rock-solid, but the actual client? It's junk. That old clunky COBOL system might have been awkward to use and a bit long in the tooth, but it NEVER crashed, and its mistakes were minimal to say the least. This new Windows system crashes constantly (including crashing if you work too fast - yeah I literally have to do a "one one-thousand" count when switching between properties or the client will lock up), and it goofs up the data frequently enough that in another 5 years I think our data will be reduced to an unreliable mess.
Truthfully though, it's not the fault of Windows, or whatever language the newer apps are written in (Visual Basic in the case of our new pile o' junk). You can certainly write good stuff in new languages on new systems. I think it's a two-fold problem. One, the complexities of a GUI makes codes many times more intricate, making the job more difficult (and more error prone), but also, programmers today look at problems differently. They program for "features" first so they can give a good sales presentation. In the old days it seems like a reduced feature set was fine so long as your code was done right. That's not the case anymore, which is a shames, because on most of our newer systems we use MAYBE 20% of of the features included, and I'd gladly trade the other 80% for stability and accuracy.
Re:75% of apps? Shaa, right! (Score:4, Insightful)
I don't think its the languages that are getting worse...
Re: (Score:2)
Admit it - you skipped the last paragraph didn't you . . . ;)
Re: (Score:2)
I guess that confirms me as one of those 'new' coders. *embarassed*
Re: (Score:3, Insightful)
One, the complexities of a GUI makes codes many times more intricate, making the job more difficult (and more error prone),
I doubt this is much of an issue. GUIs can certainly be abstracted to the point where it's not an issue.
programmers today look at problems differently.
Well, some programmers. (Hire me!)
I do agree, but recent programmers certainly don't have a monopoly on WTFs. I think you've got something of the success effect here -- that is, your old COBOL system was necessarily reliable, because if it wasn't, it wouldn't have lasted this long. So the old COBOL apps that are still in production are likely at least somewhat reliable.
But reliable and maintainable are di
Re: (Score:2)
Agile programming focus on a reduced feature set that is actually tested.
I would guess there were lots of programs written 30 years ago that were crap, but you can bet that they didn't last. COBOL programs are only survivors because they got them right the first time.
My 20% isn't someone else's 20% (Score:2)
creating a graphical sketch wasn't possible on a text-mode system
Unless the text-mode system can output an SVG document for a graphical client to display.
on most of our newer systems we use MAYBE 20% of of the features included, and I'd gladly trade the other 80% for stability and accuracy.
All clients use the same basic 10% of the features, but they have a different other 10% that they use. Once software became off-the-shelf rather than bespoke, software publishers started to try to include every client's other 10% in the same product.
Re: (Score:2)
Unless the text-mode system can output an SVG document for a graphical client to display.
Well, yes, and that was sort of the case with the old system. Building dimensions were entered in a specific text format that we could easily take and convert to graphical (which we did during the data conversion), but what the users mostly wanted was a graphical input method. Rather than typing out the dimensions they just wanted to draw them, which was just not possible with a "green screen" application.
Re: (Score:2)
I think it's a two-fold problem. One, the complexities of a GUI makes codes many times more intricate, making the job more difficult (and more error prone), but also, programmers today look at problems differently.
They sure do! Naive new programmers used to write programs that handled large amounts of data as batch jobs. Naive new programmers write programs that handled large amounts of data as event-driven GUI constructs. Hint: MVC. Second hint: MVC. Need another: MVC.
Even GUI code can be pretty simple when you enforce a strict separation between the interface and the backend. Write your underlying code first and get it perfected (or as perfect as your time and money budgets allow), and only then write a GUI t
Re:75% of apps? Shaa, right! (Score:5, Insightful)
I think I see your problem here...
Here's the rest of your problem. A GUI must never bump into a difficult or mission-critical algorithm. That's supposed to be its own library, which is accessed by the GUI through a clean and solid software interface. This is a major architectural fault: a Big Ball of Mud [laputan.org], and some languages encourage that more than others.
My suggestion would be: get a language with a lower density of script kiddies, sufficiently popular and object-oriented (Python, C++, Java, ...), get some good programmers with proven track record, and rewrite the client. Specify that you want all functions and variables documented, and test suites; if they say "that will cost you more", show them the door. If they say "we do it anyway", that's a good sign.
Re: (Score:2)
Trust me I would have loved to write it, but for whatever reason, management has decided that in-house applications are a dying breed, and that any major software to be used must be purchased from a vendor. Most of the coding we do now is simply for extracts, interfacing different systems together, and small web frontends for the public to view the data. Most of our in-house programmers are being converted to database admins.
Just for kicks and giggles though I actually started writing an equivalent app at
Re:75% of apps? Shaa, right! (Score:4, Funny)
Come on, 75% is a HIGHLY dubious claim. Where's the source / proof / evidence?
Actually if just Solitaire was coded in COBOL it would seriously skew the statistics already, numerous people would spend hours poking at a COBOL app each day.
Re:75% of apps? Shaa, right! (Score:5, Insightful)
The wording is misleading. Perhaps it's more accurate to say that 75% of business computing by value depends on COBOL. I've worked at a number of places in the financial services industry and have a lot of friends who do as well. All of our core business functions are still in COBOL. A lot of the data is still in VSAM, IMS and Model 204 legacy stores. A lot of what is in DB2, an RDBMS, is VSAM files converted directly to tables instead of truly relational databases.
The fun stuff (Java, .NET, Web) runs the outward facing services and peripheral functions, but claims processing, credit card reconciliation, billing, accounting, etc. is still in COBOL. The computer industry press spends a lot of time admiring the new chrome and fins and that new built-in radio with FM, but business is still powered by the COBOL drive train running on mainframes.
Even the clued in managers want to get off of it and onto more flexible systems and more productive languages, but it's too scary (risky) because they are afraid to break something. No one knows what the business rules are because they are embedded hither and yon in COBOL programs.
Re: (Score:2)
And why would you change it? After all: Never change a working system.
You would not go an change anything foundational, if there isn't a reason to do so. What would the reason be in this case?
Maintainability does not really become harder for the same piece of code. Except if you constantly change things. Only the maintainers become more rare. But there is no reason they have to.
Hmm... what about the following solution: Stop changing *anything* in the basic COBOL code. If you change something, do the transfo
Re: (Score:2)
The fun stuff (Java, .NET, Web) ...
If by "fun", you mean "hammering #10 nails into my eyeballs", then I agree.
Lack of knowledge (Score:4, Interesting)
Most businesses did not see any need to port mainframe stuff to WinDoze.
COBOL is solid. WinDoze is flakey. RM COBOL extended COBOL to modern
programmers. If it isn't broke, you don't 'fix' it.
Get a grip, and learn. I suggest going back to school. Just my opinion
though.
"Come on, 75% is a HIGHLY dubious claim. Where's the source / proof / evidence? Where I work, we have nearly 200 business apps and I'm pretty sure less than 2% of business apps were made in COBOL - possibly even 0%."
I suggest YOU go to work for any major business and work on their accounting software. Highly dubious? Hardly. Your business 'Apps' are probably front ends for a real language on a mainframe.
Visual this or that.
Re: (Score:2)
COBOL is solid. WinDoze is flakey.
False dichotomy. Even IBM is selling Linux on mainframes these days.
If it isn't broke, you don't 'fix' it.
If it's not maintainable, it's broke.
Visual this or that.
If you pull your nose out of your COBOL for a few minutes and bother to actually learn something, you'll find that Microsoft is one small part of a large ecosystem of languages and development tools, most of which are not called "visual" anything, and most of which are better than COBOL.
Apples and Oranges (Score:2)
I agree, but so what? COBOL is a programming language; Windows is an operating system. I could replace your statement with "C++ is solid. VAX/VMS is flakey." and it would make as much sense to your argument.
How major? GM, Walmart, Citibank? Sure they have mainframes running COBOL apps, but most businesses are not that "major", and the "minor" ones outnumber them significantly. Also,
Re: (Score:3, Insightful)
What are you, a college student? You honestly believe anywhere near 75% of the world's business applications runs on Windows?
Microsoft only wishes it had the big iron servers that do the fun stuff like banking and credit card processing.
Re: (Score:2)
What Moron uses Windows for Mission Critical Enterprise applications?
I hate to tell you, but one of the big three credit bureaus has at least one MS Windows Datacenter Edition running a massive Oracle DB. And it works.
People don't "use" COBOL (Score:3, Interesting)
People "use" applications and embedded systems.
It would be more accurate to say people use applications written in the language several times a day.
I wonder how many times people use applications written in C or languages common to embedded systems? What languages, for example, are used to create the code that makes their automobiles, home entertainment centers, voicemail, etc. work?
How many times a day do people use applications that rely other languages that predate the moon landing?
Re: (Score:2)
It would be interesting to see a graph of the ages of the languages people use/encounter (even, as with COBOL, unwittingly). I expect it would be an inverse bell curve, perhaps even a bathtub curve with steep walls at each end...
It would serve as a powerful lesson for language developers and programmers to quit mucking around with the latest 'paradigms' and programming fads and to concentrate on
COBOL (Score:5, Funny)
Happy birthday, Crappy Old Bad Obsolete Language! You need to take better care of yourself, you look a lot older than fifty.
For those of you still hanging on (Score:4, Informative)
For those of you still hanging on:
http://www.amazon.com/C-COBOL-Programmers-Business-Approach/dp/0805316604/ref=sr_1_1?ie=UTF8&s=books&qid=1253538164&sr=8-1 [amazon.com]
Greetings follow COBOL programers ... (Score:3, Funny)
... and GET OFF MY LAWN!
COBOL made me what I am today (Score:5, Funny)
Re: (Score:2)
9 Years ago for me.... Wonder if they are still teaching it.
Punch cards? Luxury!? (Score:2)
How many programmers today have ever programmed Cobol, and used punch cards. That is how I started out.
Why when I was young we used we used rocks [xkcd.com] and we were grateful!
Re: (Score:2)
What is the most trendy Unix today? As it is new, Apple, it is Snow Leopard right?
Run its Terminal, type "su", you won't see password being displayed, even as "*". Why? Because damn thing (UNIX) started on actual paper outputting terminals, more like typewriters. That is also why most used commands are mostly 2-3 char things.
I mean oldness doesn't mean it is outdated. You know what "77" in Fortran 77 means right?
Re: (Score:2)
Yes, I do. Do you know what the "2003" in Fortran 2003 is?
Typo (Score:4, Funny)
"COBOL Celebrates 50 Years"
Should read:
"COBOL Bemoans 50 Years"
Re: (Score:2)
Nah! COBOL is celebrating. It's the COBOL programmers that are bemoaning. Or at least moaning.
Not So Bad (Score:5, Insightful)
COBOL did a lot of things right, things that a lot of modern languages ignored.
Little things like:
* Having a manufacturer and machine and OS-independent standard.
* Quasi human-readable code.
* "MOVE CORRESPONDING"
that said, it's just as easy for numbskulls to write bad COBOL as to write bad C++ or bad Ruby.
Re: (Score:2)
Re: (Score:2)
The one thing that COBOL does better than any mainstream modern language is record handling and formatting.
Formatting? Really?
Record handling, I dispute. Formatting, if it was really so much better, I'm sure I can build a library to replicate it.
Re: (Score:2)
My knowledge of COBOL is limited to what I remember from a summer class between my junior and senior years of high school, many years ago. I have worked extensively in the Foxbase and Foxpro variants of 'xbase', and they always felt to me like a mix of Pascal, BASIC, COBOL and Fortran - the COBOL mostly in the PICTURE clauses available to some commands.
Re: (Score:2)
People like to say the same sort of thing about PHP and VB. What they neglect to consider is that all of these languages try to be seen as and are seen as numbskull-friendly languages, and thus have a wholly disproportionate amount of numbskulls using them. Furthermore, while it may be just as easy to write bad code in any language, how easy it is to write good code is very dependent on language and just as import
Add 1 to COBOL (Score:2)
Also, many people would probably consider the second item of your list one of the greatest failings of COBOL; specialized notations are usually used for specialized purposes for good reason.
Yet we don't want all languages to become APL-style inscrutable symbol-fests either. For example, Python uses "and" where PHP and C use &&, and Python uses "is not" where (roughly) PHP uses !==. If a manager can quickly learn to read the notation without it impeding other desirable features, that's a plus (or should I say a +).
Compare "add 1 to cobol" to "c++".
Re: (Score:2)
Python is easily the language I use the most, so I'm quite familiar with it. The big difference is that Python merely uses English keywords in place of a few symbols. This isn't a particularly radical difference, most languages already make extensive usage of keywords, and using "and" instead of "&&" doesn't significantly bloat your source code (and e.g., "||" and "or" have the same length). COBOL, however, tries to be like English and not just something that uses English words here and there.
Re: (Score:3, Insightful)
* Quasi human-readable code.
Human readability doesn't count. You have to understand it too. Cobol uses English words instead of a more concise syntax with special characters, and is therefore more difficult to understand. Mathematical equations and chemical formulas have their special syntaxes, and computer programs should have them too.
that said, it's just as easy for numbskulls to write bad COBOL as to write bad C++ or bad Ruby.
Obvious. But can you show me *good* COBOL?
Re: (Score:3, Interesting)
I disagree with the assumption that it's "just as easy". In some languages, it's definitely easier to write bad code. PHP is such an example. C/C++ is another one. In PHP it comes with the retardedness of the language. In C/C++ it comes with the freedom.
A good example for a language that has certain things in place to prevent bad coding, is Haskell. Type problems in running code are (except for the external input reader) simply impossible.
Re: (Score:3, Insightful)
I have been studying some Haskell in the past few months, and while I am in awe at Haskell's type system, and how you can write a language without for and while, and lazy evaluation, and functional purity, and partial application, and so on, there are two things that made me give up:
Re:Not So Bad (Score:4, Insightful)
See, you are part of the problem. Is that supposed to be an explanation? If you cannot explain it in plain English, you do not really understand it yourself (I think I am quoting Feynman). Your explanation is also wrong (as most "explanations" about monads): Maybe has no context, and neither do lists. The general definition of monad has nothing to do with context, only with chaining.
Read, until chapter 15 where I gave up around the Reader monad. I read the Thompson before. See below for horror example.
f becomes function, e first, es rest.
However map is pretty easy to grasp. For the promised RWH horror code, here is one from chapter 14 [realworldhaskell.org]:
bindSt :: (SimpleState s a) -> (a -> SimpleState s b) -> SimpleState s b
bindSt m k = \s -> let (a, s') = m s
in (k a) s'
There are multiple issues: the SimpleState is not a state (problem common to the State monad), but a state processor, a function. I really would like to inflict pain on whomever decided the name. The authors use m presumably for a monad, then (the gods knows for which reason) k for a function. They also use a single apostrophe (the smallest character they could find, arguably) to distinguish the new state from the old. Funny thing, they actually try to follow up with a more "readable" version, in which they make a sorry attempt at readability, which fails hopelessly (step seems a noun, but is actually meant as a verb).
Argh, no, you must not keep the damn code short! The alpha and omega is keeping it readable. Ideally good code should read almost as plain English. Operators are not English, and should be used sparingly (I once thought it was silly to limit the operators in C++... now I see the wisdom). Surely you can be too verbose, but at a minimum the code must be self-explanatory. Well that's the professional coding world, where Haskell does not belong, and never will.
Funny thing, I discovered that "terse" has a different meaning in English from what I expected. In my language (from which the word comes) it means clean, transparent, so I extrapolated "readable". Guess what, it took people praising Haskell for being "terse" for me to figure out that something was amiss.
be afraid... (Score:2)
Happy 50th (Score:5, Funny)
identification division.
program-id. birthday.
environment division.
data division.
procedure division.
main section.
display "get off my lawn!"
stop run.
Re: (Score:2)
20 PRINT "Who's gonna make me, you and ALGOL?"
30 END
Re:Happy 50th (Score:5, Informative)
000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. CONGRATS.
000300
000400*
000500 ENVIRONMENT DIVISION.
000600 CONFIGURATION SECTION.
000700 SOURCE-COMPUTER. RM-COBOL.
000800 OBJECT-COMPUTER. RM-COBOL.
000900
001000 DATA DIVISION.
001100 FILE SECTION.
001200
100000 PROCEDURE DIVISION.
100100
100200 MAIN-LOGIC SECTION.
100300 BEGIN.
100400 DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
100500 DISPLAY "Congratulations with your 50th birthday" LINE 15 POSITION 10.
100600 STOP RUN.
100700 MAIN-LOGIC-EXIT.
100800 EXIT.
Longevity (Score:5, Insightful)
I worked at a company that had a Cobol-based program that went live back in 1969. A team of programmers had kept it going ever since. Shortly after I started (mid 1995), I was in a meeting when one of the Cobol programmers mentioned that so-and-so had died over the weekend. Everybody started talking about her, what a great person she was, etc. After the meeting, I asked who she was, and was told that she was the last surviving member of the original team that wrote and deployed the application. When the system was finally shut down back in 2003 or so (I had long since left, but still had some contacts there to tell me what was going on), I really felt weird about hearing it; here was this thing that had outlived its creators (and some of the later maintainers), and now it was gone too.
Isn't it strange how computer software is both unbelievably ephemeral, yet also incredibly long-lived. I've worked on both sides and I'm not sure which is more fulfilling; it apparently took several years to write the aforementioned Cobol program, but it outlived its creators. I wonder what a programmer on something like, say, Madden, would feel, knowing that this thing they're working so hard on will be totally supplanted by the next version, next year.
Strange business, this computing machinery. Strange indeed.
Re: (Score:3, Interesting)
Re: (Score:2)
Well, ideally, they'd be able to get excited about doing it differently, maybe doing it better. We have to reconcile ourselves to the fact that non-programmers may make decisions about software for less-than-optimal reasons (A: "We're using XML"; B: "Why?"; A: "Well, anything that begins with 'X' has to be cool and the industry press has talked it to death."; B: "But, but..."; A: "I pay your salary."; B: "Okay then. I'll just take our CSV data and wrap it in a 'CSVData' element."), but that we can at least
Re: (Score:3, Insightful)
Well, ideally, they'd be able to get excited about doing it differently, maybe doing it better.
Le mieux est l'ennemi du bien. (The better is the enemy of the good.) - Voltaire
Might be anecdotal but I've seen a few perfectly good system thrown out in the search for an ephemeral "better" that then failed to materialize.
Re: (Score:2)
I'm not sure where your career path has taken YOU over the years, but many (most?) of us reading this ARE that programmer you're curious about. Just about every major project I've ever worked on either failed due to a manage
Mandatory quote (Score:2, Informative)
Edsger W.Dijkstra, 18 June 1975
Not just cricket ... (Score:2)
Funnily enough, 50 years is half a century in ... you know, the ENGLISH LANGUAGE (and I'm sure it's also half of the foreign equivalents to the word century. Except in Russia, of course).
How is SNOBOL doing? (Score:3, Funny)
Re: (Score:2)
SNOBOL dropped out of high school and ended up working for a car dealership, last I heard. He was always the sleazy sort.
New survey suggestion (Score:2)
As they enjoy spending money for obvious, I suggest them to ask those general and professional Apple users (Macbook and iPhone included) if they know UNIX and if they know it celebrates its 40th year today. In fact, start with NeXT.
Declared dead for decades... (Score:2, Insightful)
and still very much alive.
You cannot kill it (quite literally, mainframes have a MTBF of what, 40 years? How is your windows box doing?).
You can sneer at it, disregard it, ridicule it. But it is still there after decades of getting bad rep and no fresh blood. That is actually pretty impressive.
Yo, COBOL, I'ma let you finish... (Score:2)
Re: (Score:2)
COBOL's Youngest Coder Celebrates 95th birthday (Score:2)
http://www.reuters.com/article/pressRelease/idUS121649+18-Sep-2009+PRN20090918 [reuters.com]
Best joke I know about Cobol (Score:2, Funny)
http://www.xent.com/FoRK-archive/spring97/0143.html [xent.com]
COBOL is a dangerous language (Score:2)
For any of you tempted to wax nostalgic about COBOL, let me explain[*] just one charming feature: Procedure calls in COBOL are not stack based. That's right, there is no call stack.
In fact, you can't even really call a procedure in COBOL. Instead, you invoke what amounts to a GOTO/COMEFROM [wikipedia.org] pair. COBOL programs are divided into "paragraphs". When you want to execute a procedure, you PERFORM PARA-1 THRU PARA-N. Yes, that's right - the return point of the invocation varies at the whim of the caller. Heck, the
COBOL Joke (Score:5, Funny)
BOLOC (Score:2)
tags (Score:3, Insightful)
Cobolscript lives! (Score:2)
This is not a joke.
Yes, server side scripting in interpreted COBOL.
It works (Score:2, Informative)
Re: (Score:3, Funny)
Now if that isn't a troll...
Re: (Score:2)
Re: (Score:2)
POBOL? If you think that's bad, then it would be interesting to see an object-oriented Perl-COBOL. I call it POOBOL.
Re: (Score:3, Insightful)
Come on, I've teed it up for you, now knock it out of the park!
Maybe we can make a touchdown from that half-court shot, as you so nicely handicapped the goalie.
Re: (Score:2)
People playing tee ball usually can't knock it out of the park, though.
Re: (Score:2, Funny)
Look, I did a class on VB in high school so I know what I'm talking about.
COBOL is so crap that you can't even create a new COBOL project in Visual Studio anymore. You really need to get up to speed.
COBOL's second purpose (Score:2)
COBOL and Mainframe stories serve a great purpose. We see how many of /. readers (commenters in fact) doesn't have the slightest clue about how real World goes on without breaking. Right, you can't logon to a bank mainframe which is likely underground in some forgotten place, monitored by armed guards but it doesn't grant you to say things like "COBOL runs on vacuum tubes" or "mainframes are dead".
If you don't have any clue, do as I do... Mute.
For example, I learned to shut up about audio processing softwar
Re: (Score:2)
it doesn't grant you to say things like "COBOL runs on vacuum tubes"
You apparently don't know what the word "analogous" means.
"mainframes are dead".
There's a difference between "are" and "should be". Mainframes are very much alive. COBOL should be dead, and I'm not sure how much longer mainframes should survive, either.
It doesn't seem like many on Slashdot are unaware of how much COBOL is used. It seems more like most of us wish it would die a well-deserved death.
Vacuum tube (Score:2)
Given how much programming in COBOL is analogous to building computers with vacuum tubes
Computers with vacuum tubes didn't die until about half a decade ago, when LCDs became the norm in desktops.
Re: (Score:2)
2. Runs on all noteworthy non-embedded platforms.
3. All languages either are in that category, or will come into it shortly (unless they're really not "good enough")
4. - not inherently. Maybe in some standard libraries, but calling any C-syntax language "verbose" is nonsense. You can't have seen Ada. ( I like Ada, BTW.)
5. Compiled? Well, not entirely, not always. Not like COBOL is compiled, anyway.
6. Goes for just about all languages except maybe Javascript...
Re: (Score:2, Interesting)
It is trendy to disparage COBOL, but it was and is a very reliable and effective language for dealing with business transactions. The only times it tended to break were when the data input contained funky characters which would precipitate a "subscript out of range" error. I found the best way to prevent that was to disable the