Le 03/08/2016 20:41, Steve Litt a écrit :
> 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.
>
COBOL has fixed point base 10 operations, which is mandatory for
financial computation. C hasn't. I've heared that, in the US at least,
floating point operations are illegal in the finance area. The only
other language I know which also features this kind of operations is
guess which... Ada.
I remember, though, I have noticed that the GCC C compiler (or
maybe C++) can be built with fixed point operations, but I'm afraid it
implies some extension of the language.
Didier
::
Re: [DNG] Politics of IT in the U.S…
