RE: Of Legal Language and CS Notation

["Anton van Straaten" <address@hidden>]

Peter J. Wasilko wrote:
> Assuming that the underlying ideas of CS are of the same order of
> complexity as those in law, a plain English movement in CS curriculum
> design might be worth exploring.

I don't know about law, but the "problem" with both CS and Math is that by
their nature, they deal with multi-level abstractions.  These are often
difficult to describe coherently in "plain English".

For example, functions are abstractions of expressions.  Types are
abstractions of sets of values.  Parameterized types are abstractions of
sets of types.  A type signature is an abstraction of sets of values which
happen to be functions, or even sets of functions.

So the type signature of a function with parameterized types is (deep
breath) an abstraction of an abstraction of an expression in which any of
the inputs or outputs may be abstractions of abstractions of values.  And
keep in mind that "values" can mean functions...

Whether as a student or a practitioner, I'd much rather deal with a type
signature like:

   ('a * 'b -> 'b) -> 'b -> 'a list -> 'b

...than an equivalent English description, such as "foldl is function which
takes a function, which takes a pair of values of parameterized types 'a and
'b and returns a value of type 'b.  foldl returns a function which takes a
value of type 'b and returns another function.  The latter function takes a
list of values of type 'a, and returns a value of type 'b."

You won't understand what's going on here unless you understand the
underlying concepts, and once you understand the concepts, then both
notation and terminology are welcome respites from having to describe such
things in a natural language such as English.  I don't think CS students are
being put off by impenetrable notation or terminology - if they're put off
by anything, it would be the underlying concepts, which CS has little choice
about.

The problem we've encountered here is something different: it's that one
cannot achieve facility with a formal discipline without spending time
actually studying it, and at least working through some examples as opposed
to just reading about it.  Type theory papers are of little use to someone
who hasn't actually spent some time studying type theory.  In the area of
type theory in particular, this is compounded by the field being "new"
enough that it has only recently begun to produce "textbooks" rather than
research papers.  For example, prior to Ben Pierce's "Types and Programming
Languages" (published 2002), I don't know of any book that covered the same
kind and breadth of material at as "introductory" a level.  (If this
statement results in a flurry of recommendations, I'll be delighted.)

> In any case, I would argue that the problems of effective notation
> and effective exposition have been conflated in more than one CS
> subdiscipline.

I'd be interested to hear your examples.  My example above is intended to
illustrate why, in these areas, effective notation and effective exposition
are closely entwined.  We need language to described concepts and entities
which are foreign to natural languages.  In fact, attempts to use seemingly
appropriate "natural" words and phrases to describe abstract entities can be
misleading, and act as a barrier to understanding.

> Just because a notation arises from the historical evolution of a field
does not mean that it
> serves its practitioners well.

For some reason I'm imagining you're talking about the type judgements which
evolved from Frege's notation.  Regardless, to really make this point you'd
need to demonstrate the ways in which a particular notation has
shortcomings, and how it could be improved.  Mathematics and CS people do
real work using their notations, and over time the rough edges tend to be
smoothed off.  Books from the 1950s, for example, contain plenty of outdated
and archaic notation that's been simplified or dropped entirely today.  The
historical artifacts that remain tend to do so because they do no harm.

Anton