Hi Folks,

I am reading the "Little Languages and Tools" book. (I can't remember who, on
this list, recommended the book, but whoever it was thank you! It is an
awesome book!)

The first chapter was written by Jon Bentley. Incredible writer! The thing
that struck me most from reading his chapter is that writing little tools
(using little languages such as AWK, Lex, Yacc, pic (picture language),
scatter (scatter plot language), troff, sed) and then assembling them together
via pipes, e.g.,

scatter infile | pic | troff >outfile

is a powerful way to quickly get robust tools implemented.

My impression is that this style of development is no longer in vogue. Today's
developers want to use big languages like Java and Python and implement large,
monolithic tools/application.

That's sad.

To my way of thinking the old style of development is far superior.

But perhaps I am wrong. Perhaps today's developers are implementing
tools/applications using the old style. What say you? Do you use the old style
of implementing tools/applications?

/Roger

On 2022-07-04, Roger L Costello <costello@mitre.org> wrote:
> Hi Folks,
>
> I am reading the "Little Languages and Tools" book. (I can't remember who, on
> this list, recommended the book, but whoever it was thank you! It is an
> awesome book!)
>
> The first chapter was written by Jon Bentley. Incredible writer! The thing
> that struck me most from reading his chapter is that writing little tools
> (using little languages such as AWK, Lex, Yacc, pic (picture language),
> scatter (scatter plot language), troff, sed) and then assembling them together
> via pipes, e.g.,
>
> scatter infile | pic | troff >outfile

The problem with this is that, for instance, I can't use a clever
troff macro to generate input foir scatter or pic, because they
are earlier in the pipeline. Unless maybe I cob together some
sort of multi-pass hack.

The Lisp macro approach for small domain languages is superior;
all macros are expanded by the same code walker, and can nest
with each other.

Pipes are wasteful; everything has to convert to the character level and
be sent to the operating system (several buffer copies), and then
lexically analyzed again.

How pic should have been designed is not as a separate pipeline element
that just recognizes some pic commands and produces "pic-free" output
fed to troff, but as a utility program which provides services invoked
by a package of pic macros executed by troff.

Like say you just want something simple, like use troff's .if/.el to
conditionally select a picture. Because pic runs first, it will be
oblivious to the conditional and wastefully process the picture
specification in both branches.

That might even be a nonstarter: say that you want the pic code to
refer to some files, but only the files for the taken branch of the
..if/.el actually exist.

Speaking of macros, pic wastefully implements its own macro language,
and one which is quite different from the troff one.