[Info-vax] OpenVMS printing to PDF

[Stephen Hoffman]

On 2015-05-20 18:38:49 +0000, Dirk Munk said:

> No, I'm always very suspicious about The Next Great Product. Most 
> programmers these days haven't got a clue about the effects of their 
> code on the working of a computer system. I have nothing against HTML5 
> and all the wonderful things you can do with it. But that doesn't mean 
> I would use it in high volume data processing.

Suspicion is best tempered with experience — see if the tools can and 
do work.  Sometimes the kids are right, and the tools really do work 
well.  Looking in a direction I'd prefer not to, there were similar 
sentiments expressed many years ago, around the folks that were then 
starting to heavily use 3GL and 4GL packages, and to how much more 
bloated that was when compared with hand-tuned assembler.    But for 
better and sometimes for worse, we're well past the expectations and 
the problems of that era, and the scale of the software involved has 
increased massively.

Alas, nobody understands the whole stack, either — the software and the 
libraries and the OS and the firmware and the ancillary processors and 
firmware and the management interfaces and the rest.  Given the scale, 
nobody really can.

> I'm sure that 90% of the computer capacity in data centres in the world 
> is waisted on bloatware.

Same thing was stated by the assembler programmers about the 3GL folks.

> Some time ago one of my colleagues was called to assist with a 
> performance problem. A team of modern programmers and database 
> administrators had set up a new application that ran on 23 x86 servers. 
> Not the fastest servers, but decent ones. With this wonderful new 
> application they were capable of doing 70 (yes, 70!!) transactions per 
> day. Lots of managers were dancing around this application, because no 
> one knew how to make it faster. With decent programming, I'm sure the 
> processing capacity of my electronic wristwatch would have been capable 
> of doing 70 transactions per day.

Ayup; I first ran into one of those designs and one of those 
designed-by-committee projects back in the 1980s.   What were simple 
and common operations took far, far, far too long.

A mid- to upper-end smartphone has more RAM and more storage and vastly 
better graphics than most VAX and many Alpha systems, too.

> I'm one of those old fashioned guys who like compact, well written 
> code. I've always been concerned with improving performance, sometimes 
> you only needed a few adjustments for a 10-fold performance increase.

True.   But sometimes tossing better hardware at the problem provides 
an equivalent or better speed-up, and for less than your own cost.  
Moving to higher-level tools and frameworks, too.

> The more lines of code you need, the more errors you will introduce. 
> And also, the more difficult it will become to understand and maintain 
> the code.

Your laudable fondness for fewer lines of code and for reliable code — 
in this era — often leads to the incorporation of into higher and 
higher-level frameworks and tools, and toward more abstraction.   The 
problems are not getting smaller, after all.   As much as some of the 
folks around here would like, we're not going back to assembler, and 
many of our 3GL compiled languages are coming up short, and our home 
grown frameworks and tools are getting bigger and more expensive and 
more complex to maintain, and we're not getting the time necessary to 
create — for instance — a PDF processing framework.   We're probably 
writing the same volume of code, but we're getting more done with it, 
and we're also increasingly integrating more commercial and of 
open-source software.   What can be accomplished in 50 lines with a 
decent framework can be tens of thousand lines of C, and hundreds of 
thousands or millions of of lines of assembler, after all.

Getting experience on other platforms and with other languages and with 
some of the available frameworks is very valuable.


-- 
Pure Personal Opinion | HoffmanLabs LLC