Live data from Hacker News

Micro web-framework for COBOL

github.com

41–50 of 66 posts

Re: Micro web-framework for COBOL

#41
post #36

Earlier quoted context omitted.

In the late 80's, my academic advisor said he wouldn't sign off on me taking a COBOL class because that was a business department IT class and would not go with the rest of my studies[1]. I wasn't really into the idea anyway and filled my schedule with other classes. I do wonder what other CompSci departments at the time were doing. 1) EE was the sole teacher of FORTRAN and I decided against that also, more from a te…

Why the business department? Were they still under the illusion that COBOL would allow business types to write their own code?

We had it too (I went to a mixed IT-business university). I think the idea was to get some perspective on what COBOL is, so if you're managing a company one day and IT people you hire tell you that something is hard to do, or takes too much time because the system is in COBOL, you know what they're talking about and don't think that they're just messing with you.

Re: Micro web-framework for COBOL

#44
post #22

I once had the pleasure to meet a young person (~30 years old at the time) who had learned to program at a bank, so I had to ask her about COBOL. Her reply was interesting, if I looked at it as a general-purpose language like C++/C#/Java, then, yes, it sucks really hard. But if you look at COBOL as a DSL for building specific business applications, it does not look all that bad. Having never used COBOL beyond a simpl…

Indeed, it's an excellent language for what it was designed for: mainline data processing, consisting primarily of reading databases and creating reports.

Re: Micro web-framework for COBOL

#45

Earlier quoted context omitted.

There is a large market for maintaining legacy COBOL, SNOBOL, and various esoteric assembly codebases. Additionally APL and its derivatives are not entirely dead.

SNOBOL should be looked at, if for nothing else, for its string handling (add a brief look at Icon right afterwards). I would have killed to take APL in college, but despite having to program on an IBM 370 mainframe, no classes were offered. I'm still a little ticked.

It's never too late to start playing with APL. I started around the time GNU APL was released (a few years ago), and I'm having fun with it.

I also ended up writing the Emacs integration for it. Please give it a try.

Re: Micro web-framework for COBOL

#47
post #45

Earlier quoted context omitted.

SNOBOL should be looked at, if for nothing else, for its string handling (add a brief look at Icon right afterwards). I would have killed to take APL in college, but despite having to program on an IBM 370 mainframe, no classes were offered. I'm still a little ticked.

It's never too late to start playing with APL. I started around the time GNU APL was released (a few years ago), and I'm having fun with it. I also ended up writing the Emacs integration for it. Please give it a try.

I have over the years played with it, but I was rather annoyed that having to put up with all the disadvantages of using an IBM 370 that we didn't get some advantages.

Re: Micro web-framework for COBOL

#48
post #17

I remember showing my "systems analyst" brother-in-law my second year university schedule when I was planning which courses I would take that fall. "You don't have any Cobol, PL/1, OS360 Assembly Language or APL on here", he observed. "I am going to focus on C, Unix and operating systems. I want to write compilers for microprocessor based computers". When he finished laughing, he called me "unemployable" and said, "m…

There was once a programmer who wrote software for personal computers. "Look at how well off I am here," he said to a mainframe programmer who came to visit. "I have my own operating system and file storage device. I do not have to share my resources with anyone. The software is self-consistent and easy-to-use. Why do you not quit your present job and join me here?" The mainframe programmer then began to describe his…

From the Tao of programming, 1.2:

The Tao gave birth to machine language. Machine language gave birth to the assembler.

The assembler gave birth to the compiler. Now there are ten thousand languages.

Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.

But do not program in COBOL if you can avoid it.

Re: Micro web-framework for COBOL

#49

From the tutorial: >> the-values hold information about variables received. At the moment, these come from PATH (GET and POST are on the way). You can access them in the same order they occur in path. Well, this is kinda the crux of the situation isn't it? Query parameter parsing, and POST body parsing, can't do much without these. Is this to be implemented in cobol? I really hope not, parsing anything is quiet unten…

>> Query parameter parsing, and POST body parsing, can't do much without these. Is this to be implemented in cobol? I'd have thought they're to be implemented in Rexx, which is really great for writing parsers in.

You're first I run into saying that who isn't a mainframe programmer. It was an interesting language in summaries I read but I never really dug into it. What was good about Rexx for writing parsers?

Re: Micro web-framework for COBOL

#50

Earlier quoted context omitted.

My brain just ABENDed.

You folks think you're being funny but I have vary off the interface on our iSeries to move it to a different ethernet switch then do an IPL over the weekend.

What's the reliability of the iSeries models in terms of the per-server failures? And have they worsened or gotten better on reliability or admin side than the AS/400's that preceded them? Just curious about such things.
Post reply on HN