Fork me on GitHub
#off-topic
<
2020-04-12
>
emccue00:04:48

im learning cobol right now

emccue00:04:50

and hoo boy

emccue00:04:54

IDENTIFICATION DIVISION.
       PROGRAM-ID. COLLATZ.

       ENVIRONMENT DIVISION.

       DATA DIVISION.
       WORKING-STORAGE SECTION.
       77  N PICTURE 9999.
       77  DIV-BY-2 PICTURE 9999.
       77  MODULUS PICTURE 9.
       77  STEPS-TAKEN PICTURE 9999.

       LINKAGE SECTION.
       77  N-PARAM PICTURE 9999.
       77  STEPS-NEEDED-OUT PICTURE 999.

       PROCEDURE DIVISION USING N-PARAM, STEPS-NEEDED-OUT.
           MOVE N-PARAM TO N.
           SET STEPS-NEEDED-OUT TO 0.

           PERFORM UNTIL N <= 1
               DISPLAY N
               DIVIDE N BY 2 GIVING DIV-BY-2 REMAINDER MODULUS
               IF MODULUS = 0 THEN
                   MOVE DIV-BY-2 TO N
               ELSE
                   COMPUTE N = (N * 3) + 1
               END-IF
               ADD 1 TO STEPS-NEEDED-OUT
           END-PERFORM.
           DISPLAY N.
       END PROGRAM COLLATZ.

emccue00:04:20

I think i can see how i can make a single file be a sort of "function" using C style out-params

emccue00:04:06

but the file handling, sql extensions, and object oriented systems still elude me slash aren't supported on Gnu cobol

andy.fingerhut00:04:00

Out of curiosity, why learning Cobol? And which version of that language? The last time I looked at it was in the 1980s, and I only ever looked at it because it was part of a course required for undergraduate degree. I did the minimum amount of time writing code in it that I could get by with, which was not much given my earlier experience with other programming languages. All I could see were the limitations.

emccue00:04:36

New Jersey and other states are in the news because their unemployment systems, written in cobol, aren't keeping up and they are having trouble finding people to maintain them

andy.fingerhut00:04:13

Making $ is a perfectly valid reason to learn Cobol, and the one I guessed as most likely ๐Ÿ™‚

emccue00:04:32

I'm mentioning it here because well

emccue00:04:44

I figured someone here had a history with it

emccue00:04:13

(iirc sean corfield, but that might be wrong and i don't want to bug them without a targeted question)

andy.fingerhut00:04:14

My experience is only what I mention above -- I suspect there are likely to be at least one or two others with much more experience than I have had.

Cameron00:04:21

welp time to make a clojure-to-cobol transpiler

emccue00:04:36

i know DoD has a Cobol to java transpiler

emccue00:04:31

and they were doing refactors however long ago that went...somewhere

emccue00:04:16

this is probably just another pit or pointlessness

seancorfield01:04:13

Yup, twas me @emccue I did COBOL in my first job in very early '80s.

seancorfield01:04:10

COBOL for an insurance company and then I worked for a compiler company and we ported a COBOL compiler to the Sun 4 (SPARC) and Motorola 88000 chips. It was mostly written in COBOL so it was a bootstrapped compiler.

seancorfield01:04:07

COBOL came close to being the first ANSI OOP language. For a while it looked like our C++ effort would drag on and COBOL would get there first... but then they slipped too and we got over the line first (X3J16).

seancorfield01:04:46

All my friends pinged me when they saw the New Jersey stuff about hiring COBOL devs ๐Ÿ™‚

๐Ÿ˜ 4
emccue01:04:39

am i kinda sorta on the right track about seperating code?

emccue01:04:06

single function per file w/ in params and out params for functions?

andy.fingerhut01:04:21

Depending upon what features that version of COBOL was that you implemented a compiler in, that sounds very limiting. But then, I did not go looking for what data structures COBOL enabled when I learned it. The subset I learned was basically limited to records with fields that were strings or numbers.

seancorfield01:04:00

@emccue We tended to have one program per file, for small to medium programs and PERFORM PARAGRAPH to have procedures within a single file.

seancorfield01:04:25

For larger systems, we built libraries (with LINKAGE SECTION etc).

emccue01:04:56

Im going off a Cobol for Dummies book published in 97 and "records with strings or numbers" is all i see in the "standard" as well

seancorfield01:04:07

(I never learned OO COBOL so there may well be much better practice than we used to do back in the '80s)

emccue01:04:45

though google led me to a MicroFocus (whoever they are) page where they described an OO system

seancorfield01:04:40

Yeah, Microfocus were the king of COBOL compilers back in the day. They had a virtual machine, and their compiler could produce IM bytecode, C, assembler, or native binaries.

emccue01:04:43

but someof what they have in their examples doesn't compile in gnu cobol

seancorfield01:04:05

It was that compiler that I ported to SPARC and 88000 chips. The former was rebadged as Sun COBOL 1.0

emccue01:04:05

(which i'm not attached to, but its what i found)

seancorfield01:04:39

MF led a lot of the innovation back then. Small company, very smart people. Their VM was very nice.

seancorfield01:04:51

Allowed COBOL to run on pretty much anything.

emccue01:04:44

Managed COBOL, which is the collective term for .NET COBOL and JVM COBOL

emccue01:04:49

wow, no kidding

seancorfield01:04:18

I actually quite enjoyed writing COBOL, since it was my first programming job. I liked assembler too. Did a lot of that in my first job too.

seancorfield01:04:28

So, you're learning it seriously enough to get hired by NJ (or another state) to work on their employment system? Or was that part a joke? ๐Ÿ™‚

emccue01:04:07

well, no that would be kinda harmful

emccue01:04:28

they will get people and arrogantly throwing myself at that will definitely make the istuation worse

emccue01:04:52

but i want to know enough that i could write a program in it and can read an existing codebase

seancorfield01:04:09

Well, Pragmatic Programmer does say to learn a new language every year! ๐Ÿ™‚

emccue01:04:30

since, at the end of the day, im not super young anymore but chances are there won't be all that many left pretty soon

emccue01:04:39

which is a morbid calculus

seancorfield01:04:18

The real mind blowing thing in COBOL is ALTER PARAGRAPH FOO TO PROCEED TO BAR. which rewrites a GO TO on the fly at runtime.

henrik07:04:50

Holy mutation, Batman

๐Ÿฆ‡ 4
emccue01:04:52

I'm getting an error "Alter is obsolete in Gnu Cobol"

emccue01:04:20

also, as far as storage

emccue01:04:35

the book i have goes into detail about storing data in files

emccue01:04:57

which kinda makes sense in a mainframe world

emccue01:04:13

but alot of the microfocus/oracle/ibm docs focus on sql/db2 interaction

emccue01:04:32

which am I most likely to see

seancorfield01:04:20

We ran everything via JCL which was a scripting language. Everything had to be submitted as a background job. There was almost no interactive scripting. It was very primitive.

seancorfield01:04:50

IBM had a very cool hierarchical database that we used a lot...

emccue01:04:20

these docs show the JCL for submitting the jobs

seancorfield01:04:56

Oh wow... happy memories ๐Ÿ™‚ Not.

emccue01:04:36

i guess the new JCL would be nomad

emccue01:04:16

what was the IBM database? is it still relevant for modern stuff or is it kinda abandonware

seancorfield01:04:33

IMS. No idea if it's still around.

emccue01:04:50

seems to be

emccue01:04:01

"The mix of Java and COBOL in the IMS environment is a good way to modernize the core applications on the mainframe."

Thomas Bauer, Computer Scientist
Fiducia & Gad IT AG

Read how to modernize the mainframe

seancorfield01:04:07

My team (at the insurance company) wrote a mini-IMS database in assembler for use on the 8100 series which was a departmental minicomputer we used. That was fun. Got to write a lot of recursive routines in assembler!

seancorfield01:04:33

The mainframe world is a strange place...

emccue01:04:37

I live in fear of code people write in "modern" languages

emccue01:04:05

the idea that there are billions of lines of cobol code terrifies me

emccue01:04:36

Like, "disciplined" cobol is already a bit of a mess

seancorfield01:04:48

Even when I was at Sun Alliance in the early '80s, they already had production apps that had been running for decades.

emccue01:04:57

and I have zero reasons to believe that was how the code that exists was written

emccue01:04:59

and how were their code? From a practical perspective

emccue01:04:25

was it just a whole bunch of tiny applications scheduled with JCL

emccue01:04:30

or some mammouths

seancorfield01:04:54

Monolithic slabs of procedural code (at best). Usually patched left, right, and center over the decades because these were "critical" systems and no one would ever sanction a rewrite.

emccue01:04:14

so huge single files

emccue01:04:34

we talking 1000, 10000, or 100000

seancorfield01:04:47

Dozens of files, many tens of thousands of lines long.

seancorfield01:04:30

Millions of lines overall in each "stage" (Sun Alliance organized its teams into "stages" that each took care of a "generation" of COBOL monoliths).

emccue01:04:37

(in my head im dividing by like 5 for information density)

emccue01:04:16

wait, what would generation N do versus generation N + 1

emccue01:04:29

or was it just "next mainframe on the pile"

emccue01:04:49

"port some jobs write all new jobs here"

seancorfield01:04:16

Stage 4 was the "new projects" team when I was there. Stage 3 maintained the stuff that had gone into production in the last five years or so. Stage 2 dealt with the next oldest. Stage 1 with the real legacy stuff.

seancorfield01:04:35

If you think millions of lines of COBOL running a business is scary, consider that there are lots of companies out whose businesses run on millions of lines of ColdFusion ๐Ÿ™‚

seancorfield01:04:30

(I did CFML on and off for a decade and a half because I was working at Macromedia when they bought Allaire and I left after Adobe bought Macromedia and went freelance as a CF dev for a while)

seancorfield01:04:44

My current employer was originally a CF shop when I joined a decade ago -- and still has two CF apps (that I'm steadily rewriting in Clojure -- I got rid of all the others over time).

emccue01:04:02

Almost afraid to ask

emccue01:04:07

What's wrong with cold fusion

emccue01:04:53

And also it feels like clojures "data oriented situated systems" pitch kinda lends itself to "replace your cobol with this" pitches

seancorfield01:04:54

It was originally a proprietary tag-based language that let you write dynamic web apps in a mix of HTML and <CF...> tags.

emccue01:04:43

So kinda like php or jsp?

seancorfield01:04:43

Over time, it migrated to the JVM and added a JS-like scripting dialog with metaprogramming etc.

seancorfield01:04:02

PHP was the main competitor, yeah.

emccue01:04:09

component extends="framework.one" was with it until that

seancorfield02:04:22

CFML calls classes "components". class extends=framework.one { ... }

seancorfield02:04:36

(the class name is implied by the filename)

seancorfield02:04:43

How we got from there (CFML land) to here (Clojure land): https://github.com/framework-one/cfmljure ๐Ÿ™‚

andy.fingerhut05:04:39

On the ALTER example, I can only imagine Dijkstra's companion article to the well known "Go to considered harmful" that he might write. Perhaps "Run-time modifiable Go to considered abso-fricking-lutely insanely hard to reason about" ?

sogaiu05:04:10

what a great word!

jaide16:04:53

Anyone have any tutorials they can link on implementing a lazy stream library for collections? Iโ€™m working on a project in fennel and theres some async tasks that would largely benefit from stream programming. Iโ€™ve found some patterns implementation to look into but itโ€™s typically all about the observable pattern and Iโ€™m not sure if thatโ€™s a must or just a popular choice.

jaide18:04:15

Documented it and hypothesized an interface here https://github.com/agzam/spacehammer/issues/51

๐Ÿ‘ 4
leonoel09:04:28

I don't really have any resource to share but I've been working on this topic pretty hard and I still consider it to be an open problem. Most popular abstractions make serious tradeoffs (e.g RxJS observables don't support backpressure nor lazy sampling). If you have specific questions about what I've come up with for https://github.com/leonoel/missionary, feel free to ask.

jaide15:04:01

Thanks! I think https://highlandjs.org/#backpressure supports backpressure but Iโ€™m not sure what other tradeoffs it makes.

leonoel15:04:32

I'm not familiar with it

leonoel15:04:00

in the JVM land, https://www.reactive-streams.org/ is worth consideration too, as it's explicitly designed to be library agnostic