It's not dead, ok.
Can we say it's mostly dead?
For example, is it more or less dead than perl?
Can we say it's mostly dead?
For example, is it more or less dead than perl?
>> For example, is it more or less dead than perl?
== The current state of Perl 5 for Python fans ==
Perl 5: I'm not dead!
TIOBE: 'Ere! 'E says 'e's not dead!
Internet: Yes he is.
Perl 5: I'm not!
TIOBE: 'E isn't?
Internet: Well... he will be soon--he's very ill...
Perl 5: I'm getting better!
Internet: No you're not, you'll be stone dead in a moment.
TIOBE: I can't take 'im off like that! It's against regulations!
Perl 5: I don't want to go off the chart....
Internet: Oh, don't be such a baby.
TIOBE: I can't take 'im off....
Perl 5: I feel fine!
Internet: Well, do us a favor...
TIOBE: I can't!
Internet: Can you hang around a couple of minutes? He won't be long...
TIOBE: No, gotta get to Reddit, they lost nine today.
Internet: Well, when's your next round?
TIOBE: Next year.
Perl 5: I think I'll go for a walk....
Internet: You're not fooling anyone, you know-- (to TIOBE) Look, isn't there something you can do...?
Perl 5: I feel happy! I feel happy!
Monthy Python is just pure genius :D
As somebody that grew up on C and mostly doesn't work on the applications programming side of things, it was always tough to get my head around why so many people still wanted to write COBOL. Over the years though I've concluded that its simply a better language for certain kinds of tasks than anything created since. And there has been no shortage of support in keeping it relevant and easy to integrate with modern systems.
It would be interesting to see the COBOL record IO and destructuring of files and whatnot be implemented in a more modern language. I don't think anybody particularly cares for COBOL syntax, but the programming paradigm it supports doesn't have any other major players. Nobody has ever really even tried, probably because the types of people that usually create programming languages have no connections to the somewhat closed world of COBOL enthusiasts at large corporations. Certainly an interesting idea for a hobby project though, there are a lot of interesting places you could take a mixed COBOL/functional language type thing.
For instance, a function would take one file and output another, file structures and record structures could be interpreted as data types, archiving files would be treated as a side effect of the system essentially (or potentially if you get real crazy, make that some sort of functional abstraction as well). Just spitballing here because it's a fantastic idea that I would love to see. There is no reason that working with files has to necessarily be treated as entirely external to the program/a side effect, so long as you take care to have some sort of way to deal with acquiring locks/contention issues and whatnot. Not a problem on mainframes, but there would need to be some systems features implementing to make that sort of paradigm effective in a Unix style environment. I'm not sure it could be done entirely in a runtime, a lot of that state would really need to be global.
As for handling destructuring files, how useful it is really shows when you consider how easier many tasks become when you have access to such facility - even if nowadays you might expect it to be handled by extra compilation step that uses protocol buffers or something similar.
It's basically the equivalent of ORM for relational database.
But nobody does it not because it's hard or because the language doesn't support it. They don't do it because we no longer think of file system the main "database" that stores your application state.
Instead we think of the filesystem as a lower level building block for higher level abstractions (such as relational or whatnot databases)
Most would say yes.
There's a lot of new code written in most of these languages. It might be existing systems, but the code being written is new.