It's mostly because Linus isn't talking about the "Linux" you're talking about -- that is, a whole Linux distribution, as compared to other OSes.
He's talking about Linux itself, compared to what he thought it would be.
Basically, the original plan for Linux was never to be an OS in its own right, but to be just another POSIX kernel, one highly-tuned for the then state-of-the-art 386 chip. Even porting to PowerPC was never part of the plan. The fact that this kernel is so flexible and featureful -- that it has drivers for damned-near everything, that it runs on everything from cell phones to mainframes, from set-top boxes to thousand-machine clusters, from wristwatches to... Yeah, all that portability necessarily makes it bigger than what would strictly be needed for one architecture and a limited set of hardware.
It's also got to do with things like multiple schedulers, and it explains something of why Linus wanted one scheduler to rule them all -- the idea of pluggable schedulers is ludicrous, compared to the original idea of one kernel per platform, where you wouldn't have a Linux app, you'd have a Posix app that would run on Linux on x86, and on something entirely different on PPC, and yet another kernel on ARM. If it had been done that way, at least in theory, all of those kernels combined should've still been smaller than Linux currently is.
Good code is maintainable, no matter what language it's written in. Bad code is unmaintainable no matter the language as well.
Granted, every language is Turing-complete. That doesn't mean it's easy.
To me, the measure of a language is how easy it is to write good code, not whether it's theoretically possible to write good code. Drupal is a great example that shows PHP can be maintainable -- but Drupal is also not the usual case for PHP apps, and if I need to make any kind of significant change, PHP is still going to slow me down by about a factor of 2, compared to a decent language.
I think the proof is in the pudding: COBOL programs that have been maintained successfully for decades can continue to be maintained.
This is the success effect -- COBOL programs that made it to decades without being replaced must either be somewhat maintainable, or be seriously on life support.
I seriously doubt that a 10-minute change in Java would take 6 months in COBOL. Do you have some way to back this claim up?
I'm too lazy, but Google for "California COBOL". Six months to change a salary. Nine months to change it back.
So I suppose another important question is: What kind of code does the language encourage? I can't imagine anyone writing a mess like that in any decently modern language.
So, we're assuming 100x larger programs here. Adding 100x the RAM does not make performance equal.
Granted. However, having a binary 100x bigger doesn't necessarily imply that it's 100x slower.
as well as HDD/SSD access time.
I feel like I have to keep reminding you that we aren't in the 70's anymore. Reading ten megs from disk and caching it somewhere in a few gigabytes (terabytes?) of RAM is just not a big deal.
There's also a bit of old wisdom here: Premature optimization is the root of all evil. Build the app the way it makes sense, and build it as quickly as possible. Then you can actually profile it, get some meaningful real-world numbers, find actual (not theoretical) bottlenecks, and optimize those.
If needed, you rewrite pieces of it in C -- even assembly. But a program that's mostly high-level, with a few bottlenecks in assembly, still seems much saner to me than a program that's entirely COBOL.
You also ignore that your 100x larger program probably has additional instructions performing type-casting, error-handling, and all those other things that make the language 'safe'.
Just so.
So, instead of hiring programmers that avoid these errors in the first place,
who will sometimes fail,
your code must check for them every single operation,
only if your compiler/VM isn't particularly smart.
Hint, most of these errors are found and fixed quickly.
Key word: Most. Do you want to trust your savings to a system that has more bugs than necessary, because you chose to require programmer skill when you could've had the machine handle it?
It's a bit like a manual transmission vs an automatic. In theory, you can use your human intelligence to squeeze more performance, or more fuel efficiency, out of a manual than you could get out of an automatic. If you were racing, you might train yourself to the point where those few seconds add up, and it's worth it.
But in the rest of the world, automatic makes much more sense. It means no possibility that you'll make some mistake with the clutch and stall out your engine, or destroy it. And those few times you misjudge with a manual, resulting in wasted fuel, probably more than cover any savings you might have -- especially considering how good automatic transmissions have gotten.
Let me ask something else: Would you prefer assembly to COBOL? If not, why not?
A company who builds and sells access to such applications will have a small market to sell to -- folks like you, for whom internet bandwidth is cheap and reliable.
Tell that to Hulu. Or Netflix Watch Now.
All you have to do is be able to scale down enough that it's usable by the general population -- even to where it's almost usable by the general population -- but where you can clearly see that more bandwidth would work better. Obvious example: YouTube has an HQ and HD button. On some connections, the normal version will work, but the HQ/HD version is too slow -- but if you've got half a brain, you realize that a faster, more reliable connection would look better.
of the two chains below, the first one is more likely to have a stutter or outage - simply due to it having more moving parts
I dispute that, simply because:
Home computer (with DVD drive)
When the DVD drive fails, it has to be replaced. Mine did, in my laptop, and the tech did mention it was the highest-failure item in the machine (and complained about how it had to be completely taken apart to get to it -- stupid design).
When a game disc is scratched, it has to be replaced. Experience shows that while services like Steam may occasionally shut down, I have lost, scratched, or otherwise destroyed plenty of physical game discs, whereas I can't remember more than a temporary outage due to Steam, ever.
Obviously, YMMV. Some people have horror stories -- mostly revolving around forgetting a password (which is really their own stupid fault). But then, there are just as many horror stories revolving around DRM for games that come on DVDs. If you're not going to crack the game, the DRM is just as much an issue with or without Steam, but with Steam, you at least don't have the additional stack of DVD drive, DVD, DVD driver, DRM layer injected into DVD driver...
I'm not suggesting that this would completely replace games bought on DVD -- at least, not yet. As much as people might enjoy Netflix Watch Now (and I enjoy BitTorrent), many people still buy or rent actual DVDs. But there's very clearly a vast, gaping niche here, for games that Flash can't do (yet, and I hope it never does, narrow window of opportunity!), but which don't necessarily match what a DVD can do (yet) -- just as YouTube covers things text can't, but can't match DVD quality (unless you click "HD" on a fast enough connection).
I've seen less than a paragraph, unless you mean you wrote a bunch of text, then deleted it.
It looks kind of absurdly verbose -- makes Java look good. If your point was making something maintainable, that even a newbie can pick up later, you fail. What does this do?
DISPLAY SPACES
Half of it is just weird compared to an alternate version. The other half is just unnecessary.
There's also a classic WTF in there -- the For-Case paradigm. Here, some simple Ruby, if you really want to have that many special cases:
99.downto(3) do |bottles|
puts "#{bottles} bottles of beer on the wall, #{bottles} bottles of beer. Take one down, pass it around, #{bottles-1} bottles of beer on the wall." end
puts '2 bottles beer on the wall, 2 bottles of beer. Take one down, pass it around, 1 bottle of beer on the wall.' puts '1 bottle of beer on the wall, 1 bottle of beer. Take one down, pass it around, no more bottles of beer on the wall.' puts 'No more bottles of beer on the wall, no more bottles of beer. Go to the store and buy some more, 99 bottles of beer on the wall.'
That's essentially what the "pretty" version is doing -- but when you've got over 20 lines just allocating memory, that's not particularly pretty or maintainable.
The only reason I can think of including those special cases in the loop itself, is if you wanted to actually refactor it a bit:
def bottles count
case count
when 1
'1 bottle'
when 0
'no more bottles'
else
"#{count} bottles"
end end
99.downto(1) do |count|
b = bottles(count)
puts "#{b} bottles of beer on the wall, #{b} bottles of beer. Take one down, pass it around, #{bottles count-1} bottles of beer on the wall." end
puts 'No more bottles of beer on the wall, no more bottles of beer. Go to the store and buy some more, 99 bottles of beer on the wall.'
None of the other examples made any sense.
Now, look at my last example, there. Imagine you had no clue what the program was supposed to do. Show me an example of a COBOL version that's even half as readable.
I mean, if nothing else, it's got the verse actually there in one line that almost says what you want...
Advertising "it's got Linux" is as stupid as those bank ads I kept seeing a couple years ago boasting that their new website was using Java on the backend or something.... irrelevant technical detail of its implementation.
Since Java is on a server backend, it truly is an irrelevant technical detail.
But embedded Linux means it's much more likely to be hackable. That is useful to know.
That's why T-Mobile's Android phone is just marketed as "T-Mobile 3G, now with Google!"
Ew.
Meanwhile, I've been making it a point to ask about Android, every time I'm in contact with any cell phone company. I wonder if they notice that people want it?
Google OS is likely to make it mainstream, because that's a name people trust.
That'd be unfortunate -- partly because people are losing trust in Google, and partly because it doesn't quite express everything Linux represents, everything it can be to the consumer.
Think TiVo. Sure, it's cool, but 99.999% of everyone who's ever heard of TiVo has no idea that it runs Linux, or what relevance Linux might have elsewhere in their lives.
Get a new ISP. Seriously, if an ISP isn't software-agnostic, it's the ISP's fault -- unless you like going back to the AOL days, where each ISP had their own software.
Run my ISP's web accelerator software
Fair enough, though it seems bizarre that you'd need to -- again, the problem here is the ISP not exporting their accelerator as a simple proxy server.
Then again, "web accelerators" only really make sense on dialup. Is there a reason you haven't upgraded?
Run Internet Exploder
Mine does. But what do you need it for?
Allow me to select 1000 songs, right-click on "open", and play those songs sequentially in VLC Player. Instead the stupid OS tries to open all 1000 songs at the same time.
That's not the OS, it's VLC. Try it on Windows, you'll probably get the same thing. Or try another app on Linux.
Won't properly emulate Atari games via StellaX (which works 100% on Windows but only 70% on Linux)
Can't help you there, though given it's a recent port, that's to be expected -- also not exactly Linux's fault. You just seem to like blaming Linux for application issues.
Adjusted the screen size to 640x480, and when I tried to go back to normal 1280x1024 mode, discovered the desktop properties window did not fit the screen. Normally that'd be no big deal except the "OK" button was inaccessible so my laptop is now permanently stuck in 640x480.
Ok, couple questions:
First, why'd you go to 640x480 at all?
Second, did you even try keyboard navigation? Like, hitting ok, or alt+o, or any of the other ways to select "ok" on a dialog like that?
Third, you have a funny definition of "permanently" -- and it's really quite odd that you find this part:
wiped the c: drive with a fresh XP install.
to be easier than, say, asking someone for help, who would've told you to delete one line from/etc/X11/xorg.conf. One also has to wonder if you tried the "recovery mode" of Ubuntu -- the equivalent of Windows' Safe Mode.
Your problem appears to be, like so many others, that Linux is Not Windows. It can do most things Windows can, and many things Windows can't, but it is not Windows, and expecting it to work exactly the same way Windows does leads to problems.
There's also the fact that when faced with something behaving differently, your reaction wasn't curiosity -- it was instead rage and frustration.
And now I will be labeled "troll" because I'm a customer who speaks the truth.
Actually, you'll be modded to +5, because you whined about the fact that you might be modded "troll", because of this clever use of reverse psychology.
I'm sorry but I've tried Ubuntu Linux, and rather than put-up with all the Non-user friendly problems listed above, I'll choose Windows or Mac OS.
Question: Does Mac OS:
Connect to your ISP?
Run your ISP's web accelerator software?
Run Internet Exploder?
Properly emulate Atari games via StellaX?
Adjust the screen size to 640x480, and be usable afterward?
I'll bet it doesn't do half of those, without also running Windows in a VM, at the very least. Probably not even then.
So why'd you bring it up?
I'm not going to apologize for someone saying that Linux "can do everything Windows can", without at least mentioning some software incompatibility. That's irresponsible. But your response isn't much better.
a) "It won't. Sorry, buy a console or stick to Windows."
-or-
b) "It won't, but if you only use Windows for games, it's a LOT easier to keep it clean. Use Linux for everything else. You do use your computer for more than just gaming, right?"
And games do come out for Linux. But there is this chicken-and-egg problem. Even so, there are advantages to both gamer and developer to at least support Linux, if not be exclusive to it.
It means "unknown" and "strange" to anyone who hasn't heard of it or isn't very computer savvy.
Exactly as "unknown" and "strange" as any other technical spec, or any other marketing slogan. It's not as though TiVo is any less unknown or strange.
It means "complex" and "difficult" to anyone who has heard of it that is moderately computer savvy.
You'd have to be just the right combination of "moderately computer savvy" to not also understand that Linux powers Google, TiVos, and many HDTVs. Embedded Linux is not now difficult, nor has it ever been.
It means "shut the hell up and stop asking me stupid f'ing Linux questions every time I sit down at my desk!" to those of us who have used it and work with any one in the previous two categories.
Erm... I can't ever remember being constantly interrupted with Linux questions. I did get occasional stupid questions, but users tended to either be mostly self-sufficient with actually using Linux, or they didn't want anything to do with it. Notice I said "mostly".
All Linux really does is advertise that I know what I'm doing, or that I'm using something weird.
Oh, and in bringing my laptop to work, to school, to coffee shops, really anywhere, I haven't had a single person walk up to me and ask me what I was using. KDE just doesn't look different enough. So I kind of have to call BS here.
Seriously...I started using a Mac so I could get my nice unixy and open source goodness without having to play 20 questions every time I booted my damned laptop.
You're either lying, stupid, or you found a really cheap Mac.
Otherwise, seriously, you're willing to pay that much of a premium on hardware, and use a mostly-proprietary OS, in order to have people leave you alone? I mean, if that was ever an issue, how hard is it to put a Windows-like theme on any Linux WM/toolkit?
Or maybe there was some other reason?
Now they just look and say "oh, its a Mac, those are expensive" and walk away.
When I had a Mac, I got way more questions about that, especially because people already knew me to be reasonably knowledgeable. This was everything from people wanting to know if it was better than Windows, or worth the price, to people wanting to know why I'd sold out Linux and Open Source.
But I've certainly never let people asking for advice dictate what I use. If it ever becomes a problem, there's a shirt for that.
This was somewhat insightful, but I'm confused that it got to +5. No one thought it was a troll?
First you have to pick your preferred abstraction layer.
Eenie, meenie, miny... It really doesn't matter so much which abstraction layer you pick. You could pretty much take a list of features, look for a layer that has those features, and go -- particularly if you bias towards higher-level abstractions.
Then you have to work around the things it abstracts that you actually need to know about,
Rare.
In the original Law of Leaky Abstractions article, for example, Joel talked about things like having to iterate over each string several times -- once to find the length, then once again to copy it to a new, just-allocated string. And of course, that if you're concatenating strings all over the place, rather than using some sort of StringBuilder, this is happening a lot, and also leaving a lot of garbage to be collected, and tripping the allocator, and...
And how often does that particular problem affect the development of a desktop front-end, something that pretty much just needs to display some records in some forms, and store the updated version back in the database? Even on a five or ten year old desktop, the performance gains by using C++ versus a scripting language, or using StringBuilder versus straight concatenation, are pretty much irrelevant.
Click "parent" a few times to find this example:
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.
In what way could that be caused by a "leaky abstraction"?
before you know it, you've got a dozen layers *all of which you need to understand their subtle quirks and interactions*.
12 layers seems like a bit much. I mean, most apps I write, I've got at most...
database
model (inside server-side app)
REST API
HTML view
CSS styling
Javascript client
So, about half that. What's more, these layers are mostly isolated from each other. The model sits completely between the REST API and the database. The CSS and JavaScript don't really need to know about each other at all -- the CSS only cares about the HTML itself, and the JavaScript cares about HTML and REST.
Subtle interactions? Sure, but it's not as though adding Javascript suddenly implies a huge and subtle interaction between the model and the database, or any change to the model at all.
The point isn't that the GUI is free -- I think I implied that, and I don't think I meant to.
The point is that, look at the stack I drew again. If you're having to change model code -- the heart of your application -- because of some GUI somewhere much farther down, you're Doing It Wrong. GUIs being "much more intricate" may lead to quirks, yes, but they should not lead to data corruption in any half-decent app.
When was the last time you were able to, say, pipe the output of a bash script into a DataGrid control generated and displayed on the fly?
I have to admit, I don't have something that does this. But almost in the same breath, I also have to mention that it'd probably be very quick to do.
Perhaps because actually-existing GUI libraries are very tightly integrated with language VMs
Can't think of too many of those, and those VMs certainly allow other languages to do so.
you have to get into the cogs and gears of whether you use C++ native objects, GObjects, Qt objects, KParts, COM objects, CORBA objects, OLE/VBX/ActiveX controls, ObjectiveC objects, WxWidgets wrappers, J2EE Beans, Plain Old Java Objects, Javascript objects, Ruby objects, PHP objects,
None of these have simple bindings? Really?
Certainly, Ruby has native bindings. So does Javascript, for that matter.
I often wonder if we couldn't decouple GUIs from object systems and get back to a stream-based interface that could work equally well with multiple language backends... but that would be yet another layer of abstraction onto the whole pile.
Probably so...
I guess what I'm not seeing is where a textual interface is so much easier that the GUI is so necessarily either difficult or screwed up. My point wasn't that you can get a GUI for free, it's that GUIs don't necessarily make things more intricate.
Indeed, I've done GUIs (so to speak) in a website, and it didn't overly complicate the server-side. It got to where a view for the data was only a few lines of code, and once I had that view, exposing it via REST was damned-near automatic, and consuming it with jQuery was, again, only a few lines of code. Most of the rest of it, I let the browser handle for me.
But yes, the GUI absolutely was decoupled from the program logic, and it's difficult for me to see how anyone who even knows what MVC stands for could build the monstrosity described by MBGMorden:
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.
I mean, as hard as GUI might be, can you possibly imagine the complexities of any GUI system introducing crashes and data validation errors of this magnitude, unless the developer of this app was a complete moron? Is it that difficult to imagine that, given COBOL, this same developer might develop something equally disturbing?
Or maybe that was exactly the problem -- maybe they took a developer who knew how to write bad COBOL in any language, and they didn't quite grok VB?
show me a business case for replacing something that works.
Paper ledgers work. What's your business case for replacing them with something else?
Horse-drawn carriages work. What's your business case for replacing them with horeseless carriages?
Not all COBOL needs to be replaced immediately. However, some of it is clearly showing its age. You sure you don't see a business case in upgrading to a system where a simple fucking salary change takes several minutes, instead of over a year?
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".
The idea behind clusters is that an entire cluster doesn't go down, absent a catastrophic failure, like an airliner crashing into the data centre.
Which is, you'll note, significantly more robust than a single mainframe. (With two mainframes, you're left with exactly the same problem as before.)
Unfortunately, it doesn't always work so well in practice.
Implying that it does sometimes work really well in practice.
I don't know... I'd sleep better at night knowing there's at least two or more copies of my data floating around the cluster, and if the cluster doesn't automatically bring itself back up, the data is at least still there. A catastrophic mainframe failure, and you're relying on backups.
In practice, no, unless you limit yourself to a lowest-common denominator.
I'm not sure I see how this lowest-common denominator is going to be worse than the COBOL interface you had before.
If you want to take advantage of the GUI system you have, you pretty much have to code for GUI-specific stuff. Plus, a middle layer of indirection to "protect" one from GUI system changes
Which sounds very much like not having code for GUI-specific stuff, outside of that "middle layer", which is, again, already implemented many times over.
Only if those existing programs are sufficiently well-written. Are you seriously going to tell me that California is better off spending six months retrofitting an old COBOL app for something as simple as printing a minimum wage check, then spend something like two years rewriting it from scratch so that such changes take ten minutes in the future?
I can see where California might take the short way out now, but remember, it only takes four such changes for the new system to pay for itself.
create_table do |t|
t.string:first_name
t.string:last_name
t.string:address end
It also seems like it'd be kind of frustrating for someone with a last name of MacGhilleseatheanaich, or Featherstonehaugh. With the kind of power you're dealing with in a mainframe, why are you arbitrarily limiting yourself to 15 characters?
Performance? Really? Somehow, I don't think names are the kind of data you need to run massive reports on, crunching through thousands of records a second, with rock-solid ACID compliance. The worst I can imagine is wanting to query by name, in which case, you'd just add an index.
In other words: Either I'm missing something huge, or you really should get up on the new "sissy languages" before you knock them. It'd be a bit like me knocking C# for not having lambdas -- I've since learned my lesson.
Yup, JAVA never crashes, C# is easily understood, C++ is free of bloat, and interpreted languages run faster.
I've never had Java crash due to a language bug -- and the fact that you can't even spell it makes me question your credibility.
But I wasn't suggesting Java, or C#, or C++. And "interpreted language" is a property of the implementation, not the language.
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
Which doesn't mean it's the best for a business transaction.
and is reliable.
Which is, again, true of many modern languages.
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.
Very true. It also strongly suggests that you're Doing It Wrong.
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 underlying problem on the fly, patching an in-production application without dropping a single connection.
It's been used in things like telephone switches which have to run for decades nonstop, without dropping a single request.
Security -- what can a language do to help that, other than avoid encouraging blatantly insecure constructs? But then, Erlang doesn't ever allow non-Erlang code inside the Erlang process, save for the VM itself -- thus, any security hazards in C libraries are going to be severely limited in what they can access. And a DoS of such a library would only result in that process being restarted.
And scalability -- surely you're joking. Erlang is one of the few platforms on which you can comfortably spawn a few hundred thousand processes, and let the language itself manage scheduling -- so it scales to many cores. It's also based on message passing, which means RPC is dead simple, which means it scales about as easily to clusters as to cores.
And that's just one language. LISP is a whole other discussion, and still one worth having.
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.
Very true. However, there comes a point where the original code -- in any language -- has become so brittle that the cost of minor changes (remember the California minimum-wage fiasco?) suggests that a rewrite makes sense. If you've come to the point where a rewrite makes sense, I would think another language also makes sense.
Now, you can write good code in any language, so technically, if something is brittle, it's not COBOL's fault. COBOL is Turing-complete, after all. But the question is how easy a language makes it to write good code.
COBOL, well, tends to encourage spaghetti code. Properly structured code is a bit against the grain -- after all, what other language in popular use today has local variables as a bolted-on, after-the-fact feature? It would seem to me that local variables are kind of a huge step in the direction of developing a stable, secure, and bug-free program.
Slashdot Mirror
Maybe 10 minutes of coding time,
That was the point. All the machinery you mentioned doesn't get any easier (or harder) with COBOL.
That's just as bad as you assuming it would take 6 months of coding work to make the change in COBOL.
That wasn't my estimate.
It's mostly because Linus isn't talking about the "Linux" you're talking about -- that is, a whole Linux distribution, as compared to other OSes.
He's talking about Linux itself, compared to what he thought it would be.
Basically, the original plan for Linux was never to be an OS in its own right, but to be just another POSIX kernel, one highly-tuned for the then state-of-the-art 386 chip. Even porting to PowerPC was never part of the plan. The fact that this kernel is so flexible and featureful -- that it has drivers for damned-near everything, that it runs on everything from cell phones to mainframes, from set-top boxes to thousand-machine clusters, from wristwatches to... Yeah, all that portability necessarily makes it bigger than what would strictly be needed for one architecture and a limited set of hardware.
It's also got to do with things like multiple schedulers, and it explains something of why Linus wanted one scheduler to rule them all -- the idea of pluggable schedulers is ludicrous, compared to the original idea of one kernel per platform, where you wouldn't have a Linux app, you'd have a Posix app that would run on Linux on x86, and on something entirely different on PPC, and yet another kernel on ARM. If it had been done that way, at least in theory, all of those kernels combined should've still been smaller than Linux currently is.
Good code is maintainable, no matter what language it's written in. Bad code is unmaintainable no matter the language as well.
Granted, every language is Turing-complete. That doesn't mean it's easy.
To me, the measure of a language is how easy it is to write good code, not whether it's theoretically possible to write good code. Drupal is a great example that shows PHP can be maintainable -- but Drupal is also not the usual case for PHP apps, and if I need to make any kind of significant change, PHP is still going to slow me down by about a factor of 2, compared to a decent language.
I think the proof is in the pudding: COBOL programs that have been maintained successfully for decades can continue to be maintained.
This is the success effect -- COBOL programs that made it to decades without being replaced must either be somewhat maintainable, or be seriously on life support.
I seriously doubt that a 10-minute change in Java would take 6 months in COBOL. Do you have some way to back this claim up?
I'm too lazy, but Google for "California COBOL". Six months to change a salary. Nine months to change it back.
So I suppose another important question is: What kind of code does the language encourage? I can't imagine anyone writing a mess like that in any decently modern language.
So, we're assuming 100x larger programs here. Adding 100x the RAM does not make performance equal.
Granted. However, having a binary 100x bigger doesn't necessarily imply that it's 100x slower.
as well as HDD/SSD access time.
I feel like I have to keep reminding you that we aren't in the 70's anymore. Reading ten megs from disk and caching it somewhere in a few gigabytes (terabytes?) of RAM is just not a big deal.
There's also a bit of old wisdom here: Premature optimization is the root of all evil. Build the app the way it makes sense, and build it as quickly as possible. Then you can actually profile it, get some meaningful real-world numbers, find actual (not theoretical) bottlenecks, and optimize those.
If needed, you rewrite pieces of it in C -- even assembly. But a program that's mostly high-level, with a few bottlenecks in assembly, still seems much saner to me than a program that's entirely COBOL.
You also ignore that your 100x larger program probably has additional instructions performing type-casting, error-handling, and all those other things that make the language 'safe'.
Just so.
So, instead of hiring programmers that avoid these errors in the first place,
who will sometimes fail,
your code must check for them every single operation,
only if your compiler/VM isn't particularly smart.
Hint, most of these errors are found and fixed quickly.
Key word: Most. Do you want to trust your savings to a system that has more bugs than necessary, because you chose to require programmer skill when you could've had the machine handle it?
It's a bit like a manual transmission vs an automatic. In theory, you can use your human intelligence to squeeze more performance, or more fuel efficiency, out of a manual than you could get out of an automatic. If you were racing, you might train yourself to the point where those few seconds add up, and it's worth it.
But in the rest of the world, automatic makes much more sense. It means no possibility that you'll make some mistake with the clutch and stall out your engine, or destroy it. And those few times you misjudge with a manual, resulting in wasted fuel, probably more than cover any savings you might have -- especially considering how good automatic transmissions have gotten.
Let me ask something else: Would you prefer assembly to COBOL? If not, why not?
Whi
A company who builds and sells access to such applications will have a small market to sell to -- folks like you, for whom internet bandwidth is cheap and reliable.
Tell that to Hulu. Or Netflix Watch Now.
All you have to do is be able to scale down enough that it's usable by the general population -- even to where it's almost usable by the general population -- but where you can clearly see that more bandwidth would work better. Obvious example: YouTube has an HQ and HD button. On some connections, the normal version will work, but the HQ/HD version is too slow -- but if you've got half a brain, you realize that a faster, more reliable connection would look better.
of the two chains below, the first one is more likely to have a stutter or outage - simply due to it having more moving parts
I dispute that, simply because:
Home computer (with DVD drive)
When the DVD drive fails, it has to be replaced. Mine did, in my laptop, and the tech did mention it was the highest-failure item in the machine (and complained about how it had to be completely taken apart to get to it -- stupid design).
When a game disc is scratched, it has to be replaced. Experience shows that while services like Steam may occasionally shut down, I have lost, scratched, or otherwise destroyed plenty of physical game discs, whereas I can't remember more than a temporary outage due to Steam, ever.
Obviously, YMMV. Some people have horror stories -- mostly revolving around forgetting a password (which is really their own stupid fault). But then, there are just as many horror stories revolving around DRM for games that come on DVDs. If you're not going to crack the game, the DRM is just as much an issue with or without Steam, but with Steam, you at least don't have the additional stack of DVD drive, DVD, DVD driver, DRM layer injected into DVD driver...
I'm not suggesting that this would completely replace games bought on DVD -- at least, not yet. As much as people might enjoy Netflix Watch Now (and I enjoy BitTorrent), many people still buy or rent actual DVDs. But there's very clearly a vast, gaping niche here, for games that Flash can't do (yet, and I hope it never does, narrow window of opportunity!), but which don't necessarily match what a DVD can do (yet) -- just as YouTube covers things text can't, but can't match DVD quality (unless you click "HD" on a fast enough connection).
I've seen less than a paragraph, unless you mean you wrote a bunch of text, then deleted it.
It looks kind of absurdly verbose -- makes Java look good. If your point was making something maintainable, that even a newbie can pick up later, you fail. What does this do?
Half of it is just weird compared to an alternate version. The other half is just unnecessary.
There's also a classic WTF in there -- the For-Case paradigm. Here, some simple Ruby, if you really want to have that many special cases:
That's essentially what the "pretty" version is doing -- but when you've got over 20 lines just allocating memory, that's not particularly pretty or maintainable.
The only reason I can think of including those special cases in the loop itself, is if you wanted to actually refactor it a bit:
None of the other examples made any sense.
Now, look at my last example, there. Imagine you had no clue what the program was supposed to do. Show me an example of a COBOL version that's even half as readable.
I mean, if nothing else, it's got the verse actually there in one line that almost says what you want...
If it's a phone, I don't care.
The second I start using it for more than a phone, I care.
Right now, my phone is a phone, a camera, and an MP3 player. I'm starting to care that I can't really figure out how to hack it.
Advertising "it's got Linux" is as stupid as those bank ads I kept seeing a couple years ago boasting that their new website was using Java on the backend or something.... irrelevant technical detail of its implementation.
Since Java is on a server backend, it truly is an irrelevant technical detail.
But embedded Linux means it's much more likely to be hackable. That is useful to know.
That's why T-Mobile's Android phone is just marketed as "T-Mobile 3G, now with Google!"
Ew.
Meanwhile, I've been making it a point to ask about Android, every time I'm in contact with any cell phone company. I wonder if they notice that people want it?
Google OS is likely to make it mainstream, because that's a name people trust.
That'd be unfortunate -- partly because people are losing trust in Google, and partly because it doesn't quite express everything Linux represents, everything it can be to the consumer.
Think TiVo. Sure, it's cool, but 99.999% of everyone who's ever heard of TiVo has no idea that it runs Linux, or what relevance Linux might have elsewhere in their lives.
Connect to my ISP
Get a new ISP. Seriously, if an ISP isn't software-agnostic, it's the ISP's fault -- unless you like going back to the AOL days, where each ISP had their own software.
Run my ISP's web accelerator software
Fair enough, though it seems bizarre that you'd need to -- again, the problem here is the ISP not exporting their accelerator as a simple proxy server.
Then again, "web accelerators" only really make sense on dialup. Is there a reason you haven't upgraded?
Run Internet Exploder
Mine does. But what do you need it for?
Allow me to select 1000 songs, right-click on "open", and play those songs sequentially in VLC Player. Instead the stupid OS tries to open all 1000 songs at the same time.
That's not the OS, it's VLC. Try it on Windows, you'll probably get the same thing. Or try another app on Linux.
Won't properly emulate Atari games via StellaX (which works 100% on Windows but only 70% on Linux)
Can't help you there, though given it's a recent port, that's to be expected -- also not exactly Linux's fault. You just seem to like blaming Linux for application issues.
Adjusted the screen size to 640x480, and when I tried to go back to normal 1280x1024 mode, discovered the desktop properties window did not fit the screen. Normally that'd be no big deal except the "OK" button was inaccessible so my laptop is now permanently stuck in 640x480.
Ok, couple questions:
First, why'd you go to 640x480 at all?
Second, did you even try keyboard navigation? Like, hitting ok, or alt+o, or any of the other ways to select "ok" on a dialog like that?
Third, you have a funny definition of "permanently" -- and it's really quite odd that you find this part:
wiped the c: drive with a fresh XP install.
to be easier than, say, asking someone for help, who would've told you to delete one line from /etc/X11/xorg.conf. One also has to wonder if you tried the "recovery mode" of Ubuntu -- the equivalent of Windows' Safe Mode.
Your problem appears to be, like so many others, that Linux is Not Windows. It can do most things Windows can, and many things Windows can't, but it is not Windows, and expecting it to work exactly the same way Windows does leads to problems.
There's also the fact that when faced with something behaving differently, your reaction wasn't curiosity -- it was instead rage and frustration.
And now I will be labeled "troll" because I'm a customer who speaks the truth.
Actually, you'll be modded to +5, because you whined about the fact that you might be modded "troll", because of this clever use of reverse psychology.
I'm sorry but I've tried Ubuntu Linux, and rather than put-up with all the Non-user friendly problems listed above, I'll choose Windows or Mac OS.
Question: Does Mac OS:
I'll bet it doesn't do half of those, without also running Windows in a VM, at the very least. Probably not even then.
So why'd you bring it up?
I'm not going to apologize for someone saying that Linux "can do everything Windows can", without at least mentioning some software incompatibility. That's irresponsible. But your response isn't much better.
The correct answer to this is:
a) "It won't. Sorry, buy a console or stick to Windows."
-or-
b) "It won't, but if you only use Windows for games, it's a LOT easier to keep it clean. Use Linux for everything else. You do use your computer for more than just gaming, right?"
And games do come out for Linux. But there is this chicken-and-egg problem. Even so, there are advantages to both gamer and developer to at least support Linux, if not be exclusive to it.
It means "unknown" and "strange" to anyone who hasn't heard of it or isn't very computer savvy.
Exactly as "unknown" and "strange" as any other technical spec, or any other marketing slogan. It's not as though TiVo is any less unknown or strange.
It means "complex" and "difficult" to anyone who has heard of it that is moderately computer savvy.
You'd have to be just the right combination of "moderately computer savvy" to not also understand that Linux powers Google, TiVos, and many HDTVs. Embedded Linux is not now difficult, nor has it ever been.
It means "shut the hell up and stop asking me stupid f'ing Linux questions every time I sit down at my desk!" to those of us who have used it and work with any one in the previous two categories.
Erm... I can't ever remember being constantly interrupted with Linux questions. I did get occasional stupid questions, but users tended to either be mostly self-sufficient with actually using Linux, or they didn't want anything to do with it. Notice I said "mostly".
All Linux really does is advertise that I know what I'm doing, or that I'm using something weird.
Oh, and in bringing my laptop to work, to school, to coffee shops, really anywhere, I haven't had a single person walk up to me and ask me what I was using. KDE just doesn't look different enough. So I kind of have to call BS here.
Seriously...I started using a Mac so I could get my nice unixy and open source goodness without having to play 20 questions every time I booted my damned laptop.
You're either lying, stupid, or you found a really cheap Mac.
Otherwise, seriously, you're willing to pay that much of a premium on hardware, and use a mostly-proprietary OS, in order to have people leave you alone? I mean, if that was ever an issue, how hard is it to put a Windows-like theme on any Linux WM/toolkit?
Or maybe there was some other reason?
Now they just look and say "oh, its a Mac, those are expensive" and walk away.
When I had a Mac, I got way more questions about that, especially because people already knew me to be reasonably knowledgeable. This was everything from people wanting to know if it was better than Windows, or worth the price, to people wanting to know why I'd sold out Linux and Open Source.
But I've certainly never let people asking for advice dictate what I use. If it ever becomes a problem, there's a shirt for that.
This was somewhat insightful, but I'm confused that it got to +5. No one thought it was a troll?
Either they're a GPL violator, or this information is available somewhere, in the form of full source code.
No, this strikes me as entirely a marketing-driven decision, which begs the question, who got the idea in their head that Linux would be a bad thing?
First you have to pick your preferred abstraction layer.
Eenie, meenie, miny... It really doesn't matter so much which abstraction layer you pick. You could pretty much take a list of features, look for a layer that has those features, and go -- particularly if you bias towards higher-level abstractions.
Then you have to work around the things it abstracts that you actually need to know about,
Rare.
In the original Law of Leaky Abstractions article, for example, Joel talked about things like having to iterate over each string several times -- once to find the length, then once again to copy it to a new, just-allocated string. And of course, that if you're concatenating strings all over the place, rather than using some sort of StringBuilder, this is happening a lot, and also leaving a lot of garbage to be collected, and tripping the allocator, and...
And how often does that particular problem affect the development of a desktop front-end, something that pretty much just needs to display some records in some forms, and store the updated version back in the database? Even on a five or ten year old desktop, the performance gains by using C++ versus a scripting language, or using StringBuilder versus straight concatenation, are pretty much irrelevant.
Click "parent" a few times to find this example:
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.
In what way could that be caused by a "leaky abstraction"?
before you know it, you've got a dozen layers *all of which you need to understand their subtle quirks and interactions*.
12 layers seems like a bit much. I mean, most apps I write, I've got at most...
So, about half that. What's more, these layers are mostly isolated from each other. The model sits completely between the REST API and the database. The CSS and JavaScript don't really need to know about each other at all -- the CSS only cares about the HTML itself, and the JavaScript cares about HTML and REST.
Subtle interactions? Sure, but it's not as though adding Javascript suddenly implies a huge and subtle interaction between the model and the database, or any change to the model at all.
The point isn't that the GUI is free -- I think I implied that, and I don't think I meant to.
The point is that, look at the stack I drew again. If you're having to change model code -- the heart of your application -- because of some GUI somewhere much farther down, you're Doing It Wrong. GUIs being "much more intricate" may lead to quirks, yes, but they should not lead to data corruption in any half-decent app.
When was the last time you were able to, say, pipe the output of a bash script into a DataGrid control generated and displayed on the fly?
I have to admit, I don't have something that does this. But almost in the same breath, I also have to mention that it'd probably be very quick to do.
Perhaps because actually-existing GUI libraries are very tightly integrated with language VMs
Can't think of too many of those, and those VMs certainly allow other languages to do so.
you have to get into the cogs and gears of whether you use C++ native objects, GObjects, Qt objects, KParts, COM objects, CORBA objects, OLE/VBX/ActiveX controls, ObjectiveC objects, WxWidgets wrappers, J2EE Beans, Plain Old Java Objects, Javascript objects, Ruby objects, PHP objects,
None of these have simple bindings? Really?
Certainly, Ruby has native bindings. So does Javascript, for that matter.
I often wonder if we couldn't decouple GUIs from object systems and get back to a stream-based interface that could work equally well with multiple language backends... but that would be yet another layer of abstraction onto the whole pile.
Probably so...
I guess what I'm not seeing is where a textual interface is so much easier that the GUI is so necessarily either difficult or screwed up. My point wasn't that you can get a GUI for free, it's that GUIs don't necessarily make things more intricate.
Indeed, I've done GUIs (so to speak) in a website, and it didn't overly complicate the server-side. It got to where a view for the data was only a few lines of code, and once I had that view, exposing it via REST was damned-near automatic, and consuming it with jQuery was, again, only a few lines of code. Most of the rest of it, I let the browser handle for me.
But yes, the GUI absolutely was decoupled from the program logic, and it's difficult for me to see how anyone who even knows what MVC stands for could build the monstrosity described by MBGMorden:
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.
I mean, as hard as GUI might be, can you possibly imagine the complexities of any GUI system introducing crashes and data validation errors of this magnitude, unless the developer of this app was a complete moron? Is it that difficult to imagine that, given COBOL, this same developer might develop something equally disturbing?
Or maybe that was exactly the problem -- maybe they took a developer who knew how to write bad COBOL in any language, and they didn't quite grok VB?
show me a business case for replacing something that works.
Paper ledgers work. What's your business case for replacing them with something else?
Horse-drawn carriages work. What's your business case for replacing them with horeseless carriages?
Not all COBOL needs to be replaced immediately. However, some of it is clearly showing its age. You sure you don't see a business case in upgrading to a system where a simple fucking salary change takes several minutes, instead of over a year?
Some of both. Can you explain how my examples aren't equivalent to that COBOL declaration?
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".
The idea behind clusters is that an entire cluster doesn't go down, absent a catastrophic failure, like an airliner crashing into the data centre.
Which is, you'll note, significantly more robust than a single mainframe. (With two mainframes, you're left with exactly the same problem as before.)
Unfortunately, it doesn't always work so well in practice.
Implying that it does sometimes work really well in practice.
I don't know... I'd sleep better at night knowing there's at least two or more copies of my data floating around the cluster, and if the cluster doesn't automatically bring itself back up, the data is at least still there. A catastrophic mainframe failure, and you're relying on backups.
In practice, no, unless you limit yourself to a lowest-common denominator.
I'm not sure I see how this lowest-common denominator is going to be worse than the COBOL interface you had before.
If you want to take advantage of the GUI system you have, you pretty much have to code for GUI-specific stuff. Plus, a middle layer of indirection to "protect" one from GUI system changes
Which sounds very much like not having code for GUI-specific stuff, outside of that "middle layer", which is, again, already implemented many times over.
Hollywood seems much more controlled by Scientologists than Jews.
Sorry, try again.
Which perfectly fits the description "making the job more difficult".
What, adding a layer of abstraction? Especially one that someone else already added for you, in the form of a library?
Only if those existing programs are sufficiently well-written. Are you seriously going to tell me that California is better off spending six months retrofitting an old COBOL app for something as simple as printing a minimum wage check, then spend something like two years rewriting it from scratch so that such changes take ten minutes in the future?
I can see where California might take the short way out now, but remember, it only takes four such changes for the new system to pay for itself.
Yeah, it really does seem cumbersome, compared to this:
Or this:
Or this:
It also seems like it'd be kind of frustrating for someone with a last name of MacGhilleseatheanaich, or Featherstonehaugh. With the kind of power you're dealing with in a mainframe, why are you arbitrarily limiting yourself to 15 characters?
Performance? Really? Somehow, I don't think names are the kind of data you need to run massive reports on, crunching through thousands of records a second, with rock-solid ACID compliance. The worst I can imagine is wanting to query by name, in which case, you'd just add an index.
In other words: Either I'm missing something huge, or you really should get up on the new "sissy languages" before you knock them. It'd be a bit like me knocking C# for not having lambdas -- I've since learned my lesson.
Yup, JAVA never crashes, C# is easily understood, C++ is free of bloat, and interpreted languages run faster.
I've never had Java crash due to a language bug -- and the fact that you can't even spell it makes me question your credibility.
But I wasn't suggesting Java, or C#, or C++. And "interpreted language" is a property of the implementation, not the language.
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
Which doesn't mean it's the best for a business transaction.
and is reliable.
Which is, again, true of many modern languages.
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.
Very true. It also strongly suggests that you're Doing It Wrong.
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 underlying problem on the fly, patching an in-production application without dropping a single connection.
It's been used in things like telephone switches which have to run for decades nonstop, without dropping a single request.
Security -- what can a language do to help that, other than avoid encouraging blatantly insecure constructs? But then, Erlang doesn't ever allow non-Erlang code inside the Erlang process, save for the VM itself -- thus, any security hazards in C libraries are going to be severely limited in what they can access. And a DoS of such a library would only result in that process being restarted.
And scalability -- surely you're joking. Erlang is one of the few platforms on which you can comfortably spawn a few hundred thousand processes, and let the language itself manage scheduling -- so it scales to many cores. It's also based on message passing, which means RPC is dead simple, which means it scales about as easily to clusters as to cores.
And that's just one language. LISP is a whole other discussion, and still one worth having.
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.
Very true. However, there comes a point where the original code -- in any language -- has become so brittle that the cost of minor changes (remember the California minimum-wage fiasco?) suggests that a rewrite makes sense. If you've come to the point where a rewrite makes sense, I would think another language also makes sense.
Now, you can write good code in any language, so technically, if something is brittle, it's not COBOL's fault. COBOL is Turing-complete, after all. But the question is how easy a language makes it to write good code.
COBOL, well, tends to encourage spaghetti code. Properly structured code is a bit against the grain -- after all, what other language in popular use today has local variables as a bolted-on, after-the-fact feature? It would seem to me that local variables are kind of a huge step in the direction of developing a stable, secure, and bug-free program.