Politics of IT in the U.S. government http://www.itworld.com/article/3103585/government-it/politics-blamed-for-feds-reliance-on-old-it.html
Hi all, In the preceding article, put away all the politics: That's not the subject of my email. At first I almost vomited when reading this sentence: ================================================ The Social Security Administration, for instance, has more than 60 million lines of Cobol, ================================================ My first thought: Cobol? Are you kidding? I thought I'd gotten done with that in 1985! And then a part of my mind said "sysvinit? Are you kidding? Etc. So I started thinking about it. Except for the lack of local variables (and this is a huge lack, in my opinion), Cobol was a pretty decent language. When it came to letters and numbers and data, it got the job done. For its time, it was pretty portable: You just changed the Environment Division. And it wasn't tough to learn or write, always assuming you were a fast, prolific touch typist. I looked at the "new languages." Most of their claims to fame were GUI Pretty, which doesn't matter when you're calculating peoples' checks. Then there's OOP. My opinion: OOP didn't achieve our expectations for it, it's often misused, it's vastly misunderstood. So what, rewrite the Cobol in C? I don't think anyone wants all the pointers. C++? What a mess that would be. Maybe one of the Microsoft languages. Or maybe not. Python? Meh. The only real problems with Cobol is it has no local variables, and few people will ever learn it. Gary from my LUG told me something that stuck with me forever. His applications were all logic, no presentation. They operated through a socket via a very simple API or Domain Specific Language. A front end could then be written to that same socket, the two could talk to each other. So Gary could focus exclusively on data processing, the front end guy could focus exclusively on pretty, and they meet at that one little socket with a thin, simple interface. No MVC nonsense, no having an application be part of a window (talk about the tail wagging the dog), no volleyball code, just a straight single-bolt relationship. I made a program called UMENU. It's just a keyboard driven menu program without the need to press Enter, and it has Prompted Argument Substitution so it can stop and prompt me for arguments to the program it's about to run. Because I have UMENU, I can write a program whose entire interface is its arguments: A program that would be unrememberable and undiscoverable in and of itself. But then I operate that program with UMENU, and BANG, I converted the program to an easy, menu driven application. If the government needs pretty-gui for the untrainable minimum wage workers they hire, they could make a command driven front end to the Cobol that presents the Cobol program as a pretty GUI. A lot better to leave the core as Cobol rather than risk some boze intermixing algorithm and presentation, and that happens all the time. Hey, I'm not saying we should go old for old's sake. I'm just saying sometimes there are good reasons not to rewrite old code that's still functional. And, of course, I'm also saying we shouldn't go new for new's sake. I think this is ontopic at DNG because making interfaces few and thin is a philosophy. SteveT Steve Litt August 2016 featured book: Manager's Guide to Technical Troubleshooting Brand new, second edition http://www.troubleshooters.com/mgr _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
