Comment On The Program-Generator Program

Matt Westwood:

trtrwtf:

Ryan:

People got tired of saying "application programs" so they just used "applications" as a shortcut. I think that's called nouning an adjective. (barf) Then it got cut further to "app". But all that happened well after the true COBOL programmers learned their craft.

Last night I walked into a bar with some friends, and the nice lady who greeted us asked us if we were just drinking, or if we wanted some apps too.
All four of use are developers. All four of us were very confused for a few seconds, until we realized she was talking about food, not code.

What! In what language does "apps" mean "food"?

Appetizers. Are you new?

JJ:

Ryan:

Soon this was shortened to "system programs" and "application programs". It was still an adjective, not a noun. (Apologies to the 95% of you who don't understand English sentence structure.)

Count yourself in that 95%, then. "System" and "application" are both nouns which are part of a noun phrase. While they are describing another noun, they are not adjectives; rather they are simply considered "modifiers."

Even taking into account the environment, this entire train of argument is both pedantic and assinine.

eros: I love you too.

Ryan:

mwa mwa mwa - pompous and patronising lecture about what people used to call stuff in like 1955 - mwa mwa mwa

I see what you are saying. People should continue to use terminology that is 50 years out of date, because that is what you fondly imagine is "correct".

Smatta, damn kids on your lawn again?

trtrwtf:

Ryan:

People got tired of saying "application programs" so they just used "applications" as a shortcut. I think that's called nouning an adjective. (barf) Then it got cut further to "app". But all that happened well after the true COBOL programmers learned their craft.

Last night I walked into a bar with some friends, and the nice lady who greeted us asked us if we were just drinking, or if we wanted some apps too.
All four of use are developers. All four of us were very confused for a few seconds, until we realized she was talking about food, not code.

She didn't seem concerned about the bumps on your head?

David:

Ryan:

mwa mwa mwa - pompous and patronising lecture about what people used to call stuff in like 1955 - mwa mwa mwa

I see what you are saying. People should continue to use terminology that is 50 years out of date, because that is what you fondly imagine is "correct".

Smatta, damn kids on your lawn again?

I mostly agree with you, except that to me a kilobyte will ALWAYS be 1024 bytes. Retroactively defining it to be 1000 just to keep the metriphiles(new word!) happy was idiotic and pointless.

Kibibytes sounds like pet food.

M:

I mostly agree with you, except that to me a kilobyte will ALWAYS be 1024 bytes. Retroactively defining it to be 1000 just to keep the metriphiles(new word!) happy was idiotic and pointless.

I think the word you are looking for is "salespeople".

The ones who want to sell 931 GB for the price of a "Terabyte".

DCRoss:

M:

I mostly agree with you, except that to me a kilobyte will ALWAYS be 1024 bytes. Retroactively defining it to be 1000 just to keep the metriphiles(new word!) happy was idiotic and pointless.

I think the word you are looking for is "salespeople".

The ones who want to sell 931 GB for the price of a "Terabyte".

That may be where it started, but there are some weirdos out there as well. I've argued with people who insisted that kilobytes were always 1000 bytes and people were just 'using it wrong'. I suspect these kinds of people never saw a computer before the 1990's.

Just to clarify for future generations:
Kilobyte = 1024 bytes
Megabyte = 1048576 bytes
Kibibyte = Pet food
Mebibyte = What your dog might do if he doesn't get his Kibibytes

Steven Seagal's ponytail:

The real WTF is the attempt at a general solution to the problem (lexer, parser, SED script, C/C++ code - really?)

The problem was really that the lexer and parser were not entirely up to spec on their COBOL. The "idiosyncracies" were accepted by the COBOL compiler, after all, weren't they?

Yes, the attempt at a general solution was the right way to go about it, but it should have been done while having the documentation for the COBOL system handy. And, ideally, at least using previous revisions of the COBOL source code as test cases. You know, to make sure that all the "idiosyncracies" were all handled.

Writing a lexer and a parser is quite often the right thing to do, instead of some manual or half-baked process that's usually the replacement. Admittedly, lex and yacc are horrible tools to work with, the various modern C++-using equivalents are much nicer to work with.

Who the heck calls themselves a software engineer without having a multitude of tools in their toolbox -- lexer and parser generators being among those. Yeah, I know that the reality is such that people either never learn it, or they leave that knowledge among dusty college memories, best forgotten about. Lexing and parsing: it's not hard, just requires not having an irrational fear of it. This statement applies to most things in life, BTW.

Addendum (2012-06-21 16:37):
I also presume that some normalization and key selection was needed instead of just dumping the records straight into an SQL database. Both could be done entirely automatically, after the data got imported temporarily into a flat table that had 1:1 mapping to input from the COBOL system.

I presume it'd be done in steps:

1. Extract strucure from the COBOL source code.
2. Dump data into tables that match COBOL records 1:1.
3. Using structure from #1 and data from #2, run queries to determine keys and functional relationships between columns. This extracts normal forms out of the original mess.
4. A set of fixed, use-oriented rules is added to denormalize the data for performance. This would be based on the use patterns of the data.
5. Final tables are built from #2 and #3+#4.

M:

DCRoss:

M:

I mostly agree with you, except that to me a kilobyte will ALWAYS be 1024 bytes. Retroactively defining it to be 1000 just to keep the metriphiles(new word!) happy was idiotic and pointless.

I think the word you are looking for is "salespeople".

The ones who want to sell 931 GB for the price of a "Terabyte".

That may be where it started, but there are some weirdos out there as well. I've argued with people who insisted that kilobytes were always 1000 bytes and people were just 'using it wrong'. I suspect these kinds of people never saw a computer before the 1990's.

Just to clarify for future generations:
Kilobyte = 1024 bytes
Megabyte = 1048576 bytes
Kibibyte = Pet food
Mebibyte = What your dog might do if he doesn't get his Kibibytes

The interesting thing about this is that you're both right in such an argument. a "Kb" has always been 1024 bytes, but based on what "kilo" means, it was also being used wrong. You know, just so the water is good and muddy.

Jay:

herby:

So, let me get this straight...
You write a program to parse Cobol data definitions.
Isn't that what a Cobol compiler does?
So, you are just writing a Cobol compiler (or a small, or not so small, subset of it)? Sounds like inventing a wheel here.

I presume you mean "re-inventing the wheel here". But anyway: Maybe so, but so what?

Agreed. Every time someone starts turning something on a lathe, they "reinvent" the wheel :)

While COBOL is certainly not the worst platform to develop software on (MUMPS will most certainly hold that title through at least our grandchildren’s lifetimes)

Actual MUMPS (as opposed to Strawman MUMPS, a language that exists only on this site) isn't bad at all. It's no more difficult to develop in than C, and in fact for the domains it normally handles (database and string operations) it's probably easier than C.

It sounds like the problem is that the customer has not been forced into signing a contract that means it's more expensive for them if someone has spend lots of time doing manual fiddles.

Customers are generally driven by money and if they can see that there's a way to save mutual time and money then they will always go for it.

Otherwise you can't blame the customer for "getting away" with sending data of random format if they know that someone will sort it out for free.

Sayer:

M:

DCRoss:

M:

I mostly agree with you, except that to me a kilobyte will ALWAYS be 1024 bytes. Retroactively defining it to be 1000 just to keep the metriphiles(new word!) happy was idiotic and pointless.

I think the word you are looking for is "salespeople".

The ones who want to sell 931 GB for the price of a "Terabyte".

That may be where it started, but there are some weirdos out there as well. I've argued with people who insisted that kilobytes were always 1000 bytes and people were just 'using it wrong'. I suspect these kinds of people never saw a computer before the 1990's.

Just to clarify for future generations:
Kilobyte = 1024 bytes
Megabyte = 1048576 bytes
Kibibyte = Pet food
Mebibyte = What your dog might do if he doesn't get his Kibibytes

The interesting thing about this is that you're both right in such an argument. a "Kb" has always been 1024 bytes, but based on what "kilo" means, it was also being used wrong. You know, just so the water is good and muddy.

I strongly disagree.

KB means kilobyte which means 1024 bytes. They are all the same thing.

"Based on what 'kilo' means" - it means 1024 when used in the context of bytes. It always has. What it means in other contexts, historical or not, is irrelevant. It was deliberately chosen to represent 1024 in this context and has enjoyed popular usage ever since. That is the only true measure of correctness any language has, despite what grammar nazis might have you believe. So no, it has never been used wrong, unless you count the revisionist attempts to redefine it to mean 1000.

To clear things up a bit.

There is KB, kB, Kb and kb.

They all have different meanings and are used by different peoples for different reasons

KB = 1024 bytes (this is what ordinary people will use)
Kb = 128 bytes
kB = 1000 bytes (used by hard drive manufaturer to make you think the drive is bigger than it actually is)
kb = 125 bytes (used by ISP to screw you on your download speed, that 30mbps connection only goes at about 3MB/s)

Matt Westwood:

(*yawn*) yeah yeah bin there dun that. Except back in 1998 we converted a COBOL system to a FORTRAN one. Writing a parser for the general COBOL record descriptor was rather more worthwhile than creating a separate program for each COBOL file we were given. The difference between this story and that one is that after 3 weeks the program worked like a dream and didn't need to be touched for a decade, no matter how many times the source file changed.

Oh, and we never converted the FORTRAN program to a more modern language. It was supposed to be upgraded to a C++ / Java / whatever-bollocks system but it worked so well the customer didn't see the benefit of changing it.

Basic are the most similar languague to fortran that exists now. There is no benefit in converting to java.
First, upgrade to old basic, then no classic visual basic (6), then to new vb.net. Perhaps convert to csharp, csharp is almost 98% like vb.net, i dont see benefit in using csharp, only because some programmers think that comma terminated languages are better, this is bullshit.

Anonymouse:

They should have simply used a neural network; after an initial training periog for learning how to make the necessary changes it should be able to to them on its own...

This is the reason they contracted you, that is what people does, if you dont like this stupid work, then you can quit.

David Emery:

He should have dug around the Open Source community. There's a bunch of code in Ada as part of the GNAT (open source) Ada compiler that interprets COBOL PIC statements (that I helped write about 15 years ago.) With that code, he could have fed the PIC statements and generated the associated read/write routines, reusing the design even if he didn't want to link the Ada routines in to C or C++ (another feature of Ada...) The syntax for PIC clauses is quite static, you should capture the grammar/semantics of COBOL once.

But someone show me a similar big fat ugly messy data structure definition in some other language. Do you think that struc definitions for this data in C would be less readable? He should be grateful for COBOL's ability to represent this structure, even if it was un-normalized....

Yeah, Ada's got some surprisingly good design behind it; it's shame that more people aren't looking into [using] it.

Eldon:

To clear things up a bit.

There is KB, kB, Kb and kb.

They all have different meanings and are used by different peoples for different reasons

KB = 1024 bytes (this is what ordinary people will use)
Kb = 128 bytes
kB = 1000 bytes (used by hard drive manufaturer to make you think the drive is bigger than it actually is)
kb = 125 bytes (used by ISP to screw you on your download speed, that 30mbps connection only goes at about 3MB/s)

Always use KB, MB, GB etc. Ignore those pretenders.

One time, when working as an intern for a suburban city, I was given several days to work on organizing a database. I did it with a SQL command in 15 minutes. (and if I were better at SQL, it would have been faster)