[Info-vax] OpenVMS printing to PDF

[Dirk Munk]

Stephen Hoffman wrote:
> On 2015-05-20 14:48:30 +0000, Dirk Munk said:
>
>> I don't think Javascript is the ideal tool for implementing business
>> rules in an application.
>
> JavaScript or the other scripting language is how the data is fetched.
> Whether the programmer puts the business logic there, or into the
> database as triggers or such, or embeds that logic in whatever local
> application or remote server and remote application the JavaScript is
> fetching the data from, is up to the programmer.



>
>> An application is not about fetching data, but also about generating
>> data. A billing program generates data from other data, it will not
>> only produce bills, but also update databeses etc.
>
> OK, so I might infer that you haven't particularly used a web scripting
> language, embedded rendering engines, or an ERP system?

No, I haven't. I do know that many people only know script languages and 
C, and have no idea about other languages.

>
>> I also see no need for a HTML5 detour and rendering process if it can
>> be done with PDF directly.
>
> Sure.  That'll work fine for various applications.  But if you want to
> create The Next Great Product, then you might want to be able to compare
> and contrast your approach with the existing tools and alternatives, and
> one of those is HTML5.  You might end up incorporating some of what
> you've learned from HTML5 or the other tools, or you might find ways to
> better distinguish and better market your product from those that folks
> are accustomed to on other platforms.
>

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.

I'm sure that 90% of the computer capacity in data centres in the world 
is waisted on bloatware. 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.

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.

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.