11–20 of 63 posts
Looking at COBOL code such as PERFORM N TIMES ADD 1 TO I DIVIDE X2 INTO 1500 GIVING Y SUBTRACT Y FROM 815 GIVING Y DIVIDE X1 INTO Y MOVE X1 TO X2 SUBTRACT Y FROM 108 GIVING X1 DISPLAY I'|'X1 END-PERFORM. I wonder if someone has written a Python-to-Cobol translator so that you can program using regular math notation and then translate that into wordy Cobol.
Maybe it's because I'm not a native English speaker but what does "divide into" mean?
Looking at COBOL code such as PERFORM N TIMES ADD 1 TO I DIVIDE X2 INTO 1500 GIVING Y SUBTRACT Y FROM 815 GIVING Y DIVIDE X1 INTO Y MOVE X1 TO X2 SUBTRACT Y FROM 108 GIVING X1 DISPLAY I'|'X1 END-PERFORM. I wonder if someone has written a Python-to-Cobol translator so that you can program using regular math notation and then translate that into wordy Cobol.
Maybe it's because I'm not a native English speaker but what does "divide into" mean?
Isn't it a good case for visual programming? If you can't afford programmers, then you go for something less demanding and throw more cheap bodies at the problem.
Almost every time I see an expression builder in a UI, I think it would be better off with SQL syntax and autocomplete because the dropdowns get old fast, and SQL expressions aren't that hard.
Looking at COBOL code such as PERFORM N TIMES ADD 1 TO I DIVIDE X2 INTO 1500 GIVING Y SUBTRACT Y FROM 815 GIVING Y DIVIDE X1 INTO Y MOVE X1 TO X2 SUBTRACT Y FROM 108 GIVING X1 DISPLAY I'|'X1 END-PERFORM. I wonder if someone has written a Python-to-Cobol translator so that you can program using regular math notation and then translate that into wordy Cobol.
> I wonder if someone has written a Python-to-Cobol translator so that you can program using regular math notation and then translate that into wordy Cobol. Yes. But worse. And used in the real world. Whilst I cannot give all the details for obvious reasons, when I was assisting a particular bank with translating some of their stack from COBOL to modern Fortran, part of the problem was that a large amount of their CO…
Isn't it a good case for visual programming? If you can't afford programmers, then you go for something less demanding and throw more cheap bodies at the problem.
My take on visual programming is it's easier to start out with, but you're quickly better off using a conventional language once you reach a certain scale or you need to manipulate your program in certain ways. Almost every time I see an expression builder in a UI, I think it would be better off with SQL syntax and autocomplete because the dropdowns get old fast, and SQL expressions aren't that hard.
I took COBOL in school and enjoyed it. The JCL is the harder part. I thought about doing COBOL as a career, but there weren't any entry level positions.
I remember the government's plea for COBOL programmers last year and was surprised we haven't seen that many more posts about it since then. https://nymag.com/intelligencer/2020/04/what-is-cobol-what-d... https://onezero.medium.com/our-government-runs-on-a-60-year-... Just this one yesterday: https://www.govtech.com/opinion/An-Apology-to-COBOL-Maybe-Ol...
I remember the government's plea for COBOL programmers last year and was surprised we haven't seen that many more posts about it since then. https://nymag.com/intelligencer/2020/04/what-is-cobol-what-d... https://onezero.medium.com/our-government-runs-on-a-60-year-... Just this one yesterday: https://www.govtech.com/opinion/An-Apology-to-COBOL-Maybe-Ol...
But which COBOL? Microfocus now own RM/COBOL and AccuCOBOl, as well as their own MicrFocus Cobol. These are for the IBM PC and run on Windows, Unix, and Linux. Old code usually uses compiler dependent extensions, and without a good amount of work, I can not just recompile using a diffrent vendor's cobol. And if it does happrn to compile it may not work because the expected behaviour of implrmented language key words…
That's a name I haven't read in a long time.
I wrote a bunch of this when I was in the USAF, 81st Medical Group, back in the early/mid 1990s.
It had some neat features, including a robust, platform independent GUI, and platform independent bytecode.
Specifically, you could write a GUI program in AcuCOBOL and compile it, which resulted in a compact file that could then be put on any other kind of computer that had the AcuCOBOL runtime installed and then executed.
The GUI your program produced depended on the platform it was running on. If, like us, running on https://en.wikipedia.org/wiki/Aviion UNIX with nice big x-terms, you'd get an X11 GUI, unless you set a specific environment variable, in which case you'd get a nice curses-like GUI. The DOS runtime produced...if memory serves...a kind of curses-like, somewhat text based GUI.
Pretty neat stuff for the time.
Younger programmers aren't taking up the language because most schools don't teach it and companies aren't interested in training people. Most of the postings want experienced people like senior devs, whether it's for COBOL or some other language. I took COBOL in school and enjoyed it. The JCL is the harder part. I thought about doing COBOL as a career, but there weren't any entry level positions.
Even its creators say JCL is the worst language ever invented.