[Info-vax] OS implementation languages

[Dan Cross]

In article <ucneo1$2o3hj$3 at dont-email.me>,
Simon Clubley  <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2023-08-29, Johnny Billquist <bqt at softjar.se> wrote:
>> On 2023-08-29 22:27, bill wrote:
>>> On 8/29/2023 3:18 PM, Johnny Billquist wrote:
>>>>
>>>> What a weird question. VMS in itself don't have any limits. It's all 
>>>> always just about the hardware.
>>> 
>>> Not really.  VMS has always been notoriously slow with I/O and I assume
>>> that's what Simon was hinting at.
>>
>> So? It just means that other systems might achieve higher rate of I/O 
>> throughput than VMS on a specific piece of hardware. Nothing prevents me 
>> from throwing faster hardware on the problem until I saturate the 
>> network, no matter which OS I'm using.
>
>Why would you waste serious money on extra hardware to overcome OS
>limitations instead of just using a more efficient OS for the task at hand ?

Just throwing this out there....

One reason may be that optimizing software is hard, expensive,
and can take a long time.  If you're working on a $n$-month
hardware refresh rate anyway, then you may be better off just
waiting for the next hardware generation.

Also, over time some optimizations either turn into
pessimizations or force you into a design shape that makes
future change difficult.  An example of this is the Unix system
interface; it was deliberately designed to be highly synchronous
as it was thought that asynch interfaces were cumbersome for
"workaday" programming.  However, we now have languages with
large, asynchronous runtimes; squeezing these through the
soda straw of a Unix-style system interface can be challenging.

Anyway, I agree with you that looking at system overhead is
worthwhile, but I can see an argument for opting for a
hardware solution to the problem as well.

	- Dan C.