Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GnuCOBOL 3.1.1

sourceforge.net

Post reply on HN
Print view View original

221–230 of 232 posts

Re: GnuCOBOL 3.1.1

#221

Post by lokedhs »

dragonwriter wrote: post #155
beezle wrote: post #152

Earlier quoted context omitted.

Back in the day... COBOL programmers were often 'analysts' as well - meeting with the end users and/or management to design and then implement the required system. Funny to me how so many in this thread rag on COBOL, yet when other languages come up it is always 'well this language is good for abc but I wouldn't really do xyz in that one'. COBOL is extremely good at what it was designed for - data processing, and lot…

> COBOL is extremely good at what it was designed for - data processing, and lots of it. Well, the hardware that COBOL usually runs on is good for that, sure. And its usually (now) running legacy systems that no one wants the risk of reimplementing from the ground up. But is the language itself particularly well-suited to the task? I think that’s less clear. Certainly, I’ve never seen a coherent argument about how th…

It's suited for a very specific kind of data processing. It's a kind which isn't typically used today.

The language combines presentation and storage in a way I've never seen in any other language. Let's say you have an 8 digit variable. You can then specify that the last two digits is represented by a different variable, and thus the second variable will only work on those last two digits.

This is useful when you have formatted fields, where you have a variable that holds an ISO 8601 date, with other variables representing the year, month and day parts.

In a language like Java, you need to create a class that holds this information, with separate methods to manipulate the individual components and formatting the output.

In COBOL you only need a few lines of declarations to do this.

The drawback is that now presentation is tightly associated with the data storage, meaning that changing presentation format can be a lot of work. This is why COBOL programs were so problematic during Y2K.

Re: GnuCOBOL 3.1.1

#222

Post by int_19h »

zozbot234 wrote: post #215
RcouF1uZ4gsC wrote: post #176

Earlier quoted context omitted.

One thing I have heard about COBOL is that it has a built in, decimal fixed point type. Very few of the modern languages have an native type like this. Having a decimal fixed point type makes monetary calculations easier to do more reliably.

I can see a case for decimal floating point types, but fixed point adds nothing beyond what can be performed directly via arithmetic on the underlying integers. It's basically a convenience feature.

Most things in modern programming languages are convenience features; loops are basically if+goto etc.

Re: GnuCOBOL 3.1.1

#223

Post by int_19h »

GnarfGnarf wrote: post #131
herodotus wrote: post #69

My first job, after graduating, was for Control Data Corporation. I was called a Systems Analyst, but what I did was write a lot of Cobol code. Many years later, I wrote a paper about a novel data structure that could be used for what is called "The Balance Line Algorithm". I illustrated the use of this data structure with some Cobol. That was the last time I even thought about Cobol until I came across a citation to…

The "MOVE CORRESPONDING" was kind of neat, don't see that in today's languages. Instead you have to tediously copy each individual field.

SCATTER/GATHER in dBase and derivatives was similar in spirit.

Re: GnuCOBOL 3.1.1

#224

Post by submeta »

Is there no way to write a DSL in Lisp for instance, and make code generation easier? That way it'd be more fun to program COBOL, no?

But I reckon the task is more code maintance and slight changes and less writing large amounts of code?

Re: GnuCOBOL 3.1.1

#225

Post by samus »

wombatpm wrote: post #204
fiftyacorn wrote: post #125

Earlier quoted context omitted.

The importance of the comments in COBOL reminds me of a developer I worked with who was famous for removing comments to 'tidy up the code' The other developers then spent time readding the comments

Comments in code are like sex. When they are good its incredible, when they are bad it’s better than nothing

The difference to sex is that comments are unnecessary if the project is in good shape otherwise. Yes, no code is really self-documenting, but requirements documents, handbooks, documentation comments, VCS logs and tests should make it possible to elucidate weird code parts.

Bad comments are detrimental: some are outdated comments that were forgotten to remove or to update, and others were wrong or misleading to begin with. Some are just redundant (they might state the obvious) and might become misleading later on. Their existence is of historical interest in the best case.

Re: GnuCOBOL 3.1.1

#226

Post by 908B64B197 »

ta988 wrote: post #195
908B64B197 wrote: post #183

Earlier quoted context omitted.

Why do you?

For me? Because it is hard to pimp myself to please recruiters, relocate, get visas (especially now)...

Trust me, it's worth it. Really, it's not that much effort and it's worth it to signal to recruiters your real worth. And don't forget not all recruiters are equal.

And the visa issue is way overblown. It's easier than you think for a real engineer with experience.

Re: GnuCOBOL 3.1.1

#228

Post by Misteur-Z »

pbourke wrote: post #134
Misteur-Z wrote: post #87

Earlier quoted context omitted.

Until some COBOL developer publishes his pay slip, I will stick to reality, top IT salaries are at tech giants. From personal experience: BNP Paribas is one of the biggest bank in the world, top 5 if you exclude Chinese state owned ones, and they pay mainframe related jobs like shit. Being young, smart and with a whole career ahead, you have no future working has a COBOL developer, no one should spend his life pickin…

> no one should spend his life picking up shitty code left by his elders decades ago. Would you say that to a civil engineer who works on infrastructure maintenance? Computing is critical infrastructure in many areas of government and business. The solution to all problems cannot be “screw it, we’ll just rewrite in Go with a React frontend.” Some things should be rewritten and some should be maintained.

Have you ever worked on an IT infrastructure where there is no comments in the source code, no documentation, no normalization, no specs? I am not talking about COBOL itself, I am talking about those COBOL jobs, it's only about fixing and/or maintaining. I hope no one is writing new things in COBOL.

Re: GnuCOBOL 3.1.1

#229

Post by roel_v »

kjs3 wrote: post #147
roel_v wrote: post #34

Earlier quoted context omitted.

Having spent much of my time in Fortan 90 the last couple of months - I'm going to have to go ahead and disagree with you on this one. You know all these people saying "when will I ever have to write mu own hash table?" Well, when you start working in Fortran.

Do you have some weird constraint where you can't use 3rd party libraries? Yeah, hash tables aren't built into the language, but libraries to provide them are all over the place. See for example http://fortranwiki.org/fortran/show/Hash+tables . Or you could a C function. Or C++ in some compilers.

I can use them in the sense that I'm allowed to, but the compiler that I use can't compile FLIBS nor most of the libraries in your link; and the ones it could compile, I had to adapt, requiring understanding of what a 'hash table' is beyond just 'it's a key to value mapping'. I didn't want to make my post all about my Fortran problems, but I still think knowing the basics of fundamental data structures is foundational knowledge.

Re: GnuCOBOL 3.1.1

#230

Post by munk-a »

wombatpm wrote: post #204
fiftyacorn wrote: post #125

Earlier quoted context omitted.

The importance of the comments in COBOL reminds me of a developer I worked with who was famous for removing comments to 'tidy up the code' The other developers then spent time readding the comments

Comments in code are like sex. When they are good its incredible, when they are bad it’s better than nothing

When comments are bad they can be actively misleading and when comments are everywhere they can do nothing but obscure logic. I like well commented code, but poorly commented code can be worse than uncommented code that's clearly written. Lastly, adding comments to code doesn't always add value.
Post reply on HN