Outcast_Searcher wrote:Things change. One no longer has to use old style procedural programming languages to write programs, much less have a college degree in "Computer Science" as I did, to get LOTS of productivity out of programming, which has been true for decades.
What does "old style procedural programming languages to write programs" mean? Is that like dbase II, or Visual Basic, FoxPro?
I get plenty of productivity out of automated mathematical instructions as well, not sure I could build stochastic simulators without the automation part.
Outcast_Searcher wrote:And it's especially ludicrous when people bemoan inefficient programming that comes from high level languages, vs. using Assembler, which I got yelled at a lot for in the 80's, since I preferred GETTING THINGS DONE to saving 3 or 30 bytes of storage or a microsecond of CPU time, given the way computers expand exponentially in processing power and storage per dollar.
Yeah, I've seen the contractors get all excited over something running in one microsecond instead of two. Quite important I imagine in the right circumstances. Here is the kicker from my perspective though.
A new idea that takes 5 hours of run time beats old ideas running in a micro-second. My world revolves around the new idea, each and every time. Let the coders clean up run time issues as their own measure of performance, I've got no beef, because until I do my job, theirs is irrelevant.
For the record, my last full scale start to finish new idea was in about 6 sequential pieces, and took 2 days to run, assuming I didn't screw something up along the way. Runs in about 4 minutes how in Python.