4 ms·

The sad thing is about 90% of normal back-end computing at enterprises is take data source A,B,C,etc and generate data file Z. Cobol lives because it could do

The sad thing is about 90% of normal back-end computing at enterprises is take data source A,B,C,etc and generate data file Z. Cobol lives because it could do that well. Perl did that amazingly well[1]. Its really trivial to write easy to maintain code that does that in a very standard (across programs) way. 1) Data Munging with Perl was a pretty good book for it

digi_owl 10y ago
Work is receive input, mangle input, send output once you generalize it enough. but the devil will definitely be in the details.
- protomyth 10y ago
  Oh yeah, the details are the problem. Worse, its a technical problem and a people issue for some kinds of output. Report Writing has all of the problems of graphic design and date munging with none of the rewards. Lord help you if the friggin DBA & Application Developers built the database or other data sources for transactional processing and didn't provide any help (e.g. summary tables, other data source) for batch (set) processing. I now follow a simple law when setting up a data source: If I need attribute X from an item then I better have a way to find all items with attribute X in a hurry.
Bromskloss 10y ago
> Cobol lives because it could do that well. Can't every language do that well?
- protomyth 10y ago
  Amazingly enough, not really. Quite a few don't do it at all without some really good library support. Its not really that "sexy" of a problem and often ignored by people developing languages for interactive situations.
  - nickpsecurity 10y ago
    On top of that, I know actual companies that specialize in doing this for bigger companies. The companies want to move something from form, database, file, or whatever to another. Or merge several with some analysis into a new one. You'd think this would be automated or a simple job for one, on-site programmer. Instead, these firms get paid big money to do that on a regular basis for the same companies. Mind-blowing.
    - protomyth 10y ago
      You would think, but it does take some upfront thinking about how to get data cleanly out of one system and into another. Most developers don't really care about that part so you pay big bucks later. If your report writers are struggling getting collection-style reports (e.g. "give me all open contracts"), expect to pay through the nose.
yeowMeng 10y ago
And sometimes you find out data file Z is itself a Perl script :)
- protomyth 10y ago
  Yep. It is often much easier (see UNIX pipes) to break a problem down into steps that can be paused / restarted, not to mention just making the logic of each piece much simpler. I've seen where one class of data (e.g. transactions on contracts) are broken down into subclasses (e.g. commercial, individual) then processed by a different perl program to be recombined into one set that is finished by another perl script. Its amazing how 5 very simple programs is easier to maintain code-wise and operations-wise than 1 big program sometimes.
  - unexistance 10y ago
    microservice :D
    - protomyth 10y ago
      I would so like to get a diary from a group that transitioned a overnight text batch system to a collection of microservices.

digi_owl 10y ago

Work is receive input, mangle input, send output once you generalize it enough. but the devil will definitely be in the details.

protomyth 10y ago
Oh yeah, the details are the problem. Worse, its a technical problem and a people issue for some kinds of output. Report Writing has all of the problems of graphic design and date munging with none of the rewards. Lord help you if the friggin DBA & Application Developers built the database or other data sources for transactional processing and didn't provide any help (e.g. summary tables, other data source) for batch (set) processing. I now follow a simple law when setting up a data source: If I need attribute X from an item then I better have a way to find all items with attribute X in a hurry.

Bromskloss 10y ago

> Cobol lives because it could do that well. Can't every language do that well?

protomyth 10y ago
Amazingly enough, not really. Quite a few don't do it at all without some really good library support. Its not really that "sexy" of a problem and often ignored by people developing languages for interactive situations.
- nickpsecurity 10y ago
  On top of that, I know actual companies that specialize in doing this for bigger companies. The companies want to move something from form, database, file, or whatever to another. Or merge several with some analysis into a new one. You'd think this would be automated or a simple job for one, on-site programmer. Instead, these firms get paid big money to do that on a regular basis for the same companies. Mind-blowing.
  - protomyth 10y ago
    You would think, but it does take some upfront thinking about how to get data cleanly out of one system and into another. Most developers don't really care about that part so you pay big bucks later. If your report writers are struggling getting collection-style reports (e.g. "give me all open contracts"), expect to pay through the nose.

yeowMeng 10y ago

And sometimes you find out data file Z is itself a Perl script :)

protomyth 10y ago
Yep. It is often much easier (see UNIX pipes) to break a problem down into steps that can be paused / restarted, not to mention just making the logic of each piece much simpler. I've seen where one class of data (e.g. transactions on contracts) are broken down into subclasses (e.g. commercial, individual) then processed by a different perl program to be recombined into one set that is finished by another perl script. Its amazing how 5 very simple programs is easier to maintain code-wise and operations-wise than 1 big program sometimes.
- unexistance 10y ago
  microservice :D
  - protomyth 10y ago
    I would so like to get a diary from a group that transitioned a overnight text batch system to a collection of microservices.