The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Paul Winalski <paul.winalski@gmail.com>
To: Warren Toomey <wkt@tuhs.org>
Cc: tuhs@tuhs.org
Subject: Re: [TUHS] Unix APIs: elegant or not?
Date: Wed, 31 Oct 2018 11:47:20 -0400	[thread overview]
Message-ID: <CABH=_VQ2U3UvtNSDtmMpfd2Ap9JT4Zbag0qYcN2yYwyYU5_TuQ@mail.gmail.com> (raw)
In-Reply-To: <20181031043810.GA10775@minnie.tuhs.org>

On 10/31/18, Warren Toomey <wkt@tuhs.org> wrote:
>
>   The POSIX file API is a great example, but not of a deep
>   interface. Rather, it’s a great example of how code with a very
>   complicated interface may look deceptively simple when reduced to C-style
>   function signatures.

For me one of the most important software design principles is that
the simple and most common use cases should be the simplest for the
user to code.  It's OK if complicated things are complicated to code,
but simple things should be kept simple.

I've always thought that the UNIX file primitives very elegantly
adhere to this principle.  Reading a file in UNIX is a simple
open()/read().../close() sequence.  Contrast that with VMS's $QIO or
IBM OS access methods, where the full complexity is not only exposed
in the interface, it must be considered, set up, and controlled by the
user for even the simplest operations.  Multibuffered, asynchronous,
interrupt-driven I/O is more complicated (if not downright clumsy) in
UNIX than in VMS or OS/VS, but that's OK, IMO--it shifts the
complexity burden to those doing complex things.

-Paul W.

  reply	other threads:[~2018-10-31 16:51 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-31  4:38 Warren Toomey
2018-10-31 15:47 ` Paul Winalski [this message]
2018-10-31 17:22   ` Clem Cole
2018-10-31 19:33     ` Lawrence Stewart
2018-10-31 20:57   ` G. Branden Robinson
2018-10-31 21:31   ` Dave Horsfall
2018-11-01  7:42     ` Pierre DAVID
2018-11-01 10:20       ` Dave Horsfall
2018-11-01 12:57         ` Clem Cole
2018-11-01 14:19           ` ron minnich
2018-11-01 14:41             ` Clem Cole
2018-11-01 16:43               ` Warner Losh
2018-11-01 16:48                 ` ron minnich
2018-11-01 16:56                   ` Warner Losh
2018-11-02  5:24                   ` Bakul Shah
2018-11-04 10:53         ` Chris Hanson
2018-11-04 15:34           ` ron minnich
2018-11-04 17:06             ` Warner Losh
2018-11-04 20:00               ` ron minnich
2018-11-04 18:52           ` Bakul Shah
2018-11-04 10:49 ` Chris Hanson
2018-11-04 12:28   ` arnold
2018-11-04 21:34     ` Chris Hanson
2018-11-05 14:11       ` Donald ODona
2018-11-04 13:35   ` Warner Losh
2018-11-04 19:47   ` Dave Horsfall
2018-11-01 15:39 Noel Chiappa
2018-11-04 22:29 Theodore Y. Ts'o
2018-11-04 22:37 Noel Chiappa
2018-11-05  4:04 ` Dave Horsfall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABH=_VQ2U3UvtNSDtmMpfd2Ap9JT4Zbag0qYcN2yYwyYU5_TuQ@mail.gmail.com' \
    --to=paul.winalski@gmail.com \
    --cc=tuhs@tuhs.org \
    --cc=wkt@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).