|
Report Program Generator (RPG) is a joke perpetrated on the programming public by some IBMer.
As a name, I mean.
Very few people understand how this language came about.
The old IBM 407 accounting machines were controlled by a plug board where one wired up a "program" to perform specific calculations.
The program always would follow this following format:
Read a card
Use the values on the card and perform the required computation
Print a line of output
Repeat.
That is exactly the format used for programming in RPG. The idea was that you could get the folks who did the plug board wiring to program the IBM System/3 which IBM hoped would wean small companies away from the electromechanical relay based accounting machines.
Later more control structures were added to this cycle and you ended up with RPG IV but the basic cycle remains unaltered.
The interesting thing is that a machine like the AS/400 could "eat DEC's lunch", to quote Ken Olson of DEC.
Other than PCs, it probably is the only machine to reach sales in excess of 1 million. Today, you could network several of them together and such a network would rival the power of mainframes.
And like COBOL, RPG is another language that would never quit.
|
|
|
|
|
Yep, when dealing with RPG, its nature is very evident (at least to someone who, as a child, saw punched cards being used to program a computer, my mother learned programming as part of a maths degree, and we a fairly endless supply of punched cards around the house that were used as partly a study aid, partly as a construction toy).
I also remember that the first few columns of a source file (if "file" can be applied to something on the AS/400) were reserved for indicators, types (single letters) and other abuses. Probably the worst programming language I've ever come across (at least amongst those that are not intentionally bad, like brainfuck).
<<shudder>>.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
No matter what your style of coding is, it should follow one rule: Keep It Simple, Stupid! There is no silver bullet (but sometimes you just need a simple bullet)
But why is the article so long (and unsimple?)
Also, where have I seen this clever fellow before?
|
|
|
|
|
Simple Programmer wrote: Keep It Simple, Stupid!
FTFT
|
|
|
|
|
And it's 25% more simple!
TTFN - Kent
|
|
|
|
|
|
But I like calling people stupid...
|
|
|
|
|
Yet it's generally not worth the effort.
|
|
|
|
|
Always followed the KISS principle and try avoid the spaghetti soup of acronymic design pattern pattern munching crap that abounds in our business.
If a design isn't simple and sensible, it's probably wrong.
|
|
|
|
|
To be fair, KISS really is an acronym. Ironically TLA (Three Letter Acronyms) isn't, its an Initialism.
(Its my new pedantry campaign, in case you were wondering).
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
TL;DR
But I do (of course) have this to say -- code is not a uniform universe with only a few microkelvin degrees of background radiation to differentiate it. I have, for example, some relatively complex code that makes my life way way simpler at higher levels.
So, for example, an asynchronous pub/sub subscriber, or a state machine with transition rules and state events, isn't necessarily simple as a concept nor simple as an implementation. But it lets me write code at the application level that is a lot simpler.
All that "simple" code does is create rapid obsolescence. And it keeps "simple" programmers employed.
(Having perused the article a wee bit now, I agree with the points Sander makes, but not with the general principle of the thing. I prefer Einstein's "Everything Should Be Made as Simple as Possible, But Not Simpler"
Marc
|
|
|
|
|
|
My signature Einstein's KISS variant.
Patrice
“Everything should be made as simple as possible, but no simpler.” Albert Einstein
|
|
|
|
|
A better rule: Code Smart!
|
|
|
|
|
Brian Kernighan wrote: Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
|
|
|
|
|
|
Fin feels like a person — actually, it feels like a multiplicity of people It didn't say if "her" is going to support .NET
|
|
|
|
|
"so much depends upon a red wheel barrow glazed with rain water beside the white chickens."
|
|
|
|
|
|
Did you notice that this article about an interactive application is signed by someone called 'Kortina', which sound suspiciously like 'Cortana' ?
|
|
|
|
|
|
Is it pronounced "EFF-in"? As in, "I don't want that EFF-in operating system".
modified 20-Aug-15 11:56am.
|
|
|
|
|
|
In a December 2014 survey of 2,100 hiring and HR managers, CareerBuilder found 50 percent of hiring managers know enough about a candidate to make a hiring decision within the first five minutes. Wait 15 minutes, and 90 percent of interviewers will have you pegged. Bonus #0: You notice the 'notes' he's taking involve Tetris
|
|
|
|
|
I hate to say it but we can usually tell how an interview is going within 30 seconds.
If you've made it through the front door for an interview chances are the company has already vetted your resume, references and technical skills (or they should have: it's simple enough to do before the interview and saves everyone time).
The interview itself is about whether you want to spend 8hrs a day for the foreseeable future, through thick and thin, with this person.
cheers
Chris Maunder
|
|
|
|