Algebra Driven Design Elegant

Software from Simple Building Blocks

Version 1 1 2 Sandy Maguire
Visit to download the full and correct content document:
https://textbookfull.com/product/algebra-driven-design-elegant-software-from-simple-b
uilding-blocks-version-1-1-2-sandy-maguire/
More products digital (pdf, epub, mobi) instant
download maybe you interests ...

Thinking with Types Type level Programming in Haskell

Sandy Maguire

https://textbookfull.com/product/thinking-with-types-type-level-
programming-in-haskell-sandy-maguire/

Elements of Android Jetpack Version 1 1 Mark L. Murphy

https://textbookfull.com/product/elements-of-android-jetpack-
version-1-1-mark-l-murphy/

Chemicals and fuels from bio based building blocks 1st

Edition Albonetti

https://textbookfull.com/product/chemicals-and-fuels-from-bio-
based-building-blocks-1st-edition-albonetti/

Building Green Software: A Sustainable Approach to

Software Development and Operations 1 / converted
Edition Anne Currie

https://textbookfull.com/product/building-green-software-a-
sustainable-approach-to-software-development-and-
operations-1-converted-edition-anne-currie/
Curriculum Planning with Design Language Building
Elegant Courses and Units 1st Edition Ken Badley

https://textbookfull.com/product/curriculum-planning-with-design-
language-building-elegant-courses-and-units-1st-edition-ken-
badley/

Alexandrov geometry preliminary version no 1 Alexander

S.

https://textbookfull.com/product/alexandrov-geometry-preliminary-
version-no-1-alexander-s/

Building Construction From Principle to Detail Volume 1

Fundamentals José Luis Moro

https://textbookfull.com/product/building-construction-from-
principle-to-detail-volume-1-fundamentals-jose-luis-moro/

IT infrastructure architecture infrastructure building

blocks and concepts Laan

https://textbookfull.com/product/it-infrastructure-architecture-
infrastructure-building-blocks-and-concepts-laan/

Advanced Modern Algebra Part 1 3rd Edition Joseph J.

Rotman

https://textbookfull.com/product/advanced-modern-algebra-
part-1-3rd-edition-joseph-j-rotman/
 Algebra-Driven Design
Elegant Software from Simple Building Blocks

Sandy Maguire
Copyright ©2020, Sandy Maguire
All rights reserved.

Version 1.1.2
Are you quite sure
that all those bells and whistles,
all those wonderful facilities of your so-called
“powerful” programming languages,
belong to the solution set
rather than to the problem set?

EDSGER W. DIJKSTRA
Contents

Foreword 1

Preface 7

1 Overview 10
1.1 Abstraction . . . . . . . . . . . . . . . . . . . . . . . 10
1.2 What is Algebra-Driven Design? . . . . . . . . . . . 13
1.3 Conventions . . . . . . . . . . . . . . . . . . . . . . . 20
1.3.1 Why Haskell? . . . . . . . . . . . . . . . . . . 20
1.3.2 Reading Haskell . . . . . . . . . . . . . . . . 24
1.3.3 Understanding Haskell Types . . . . . . . . . 32
1.3.4 Equational Laws . . . . . . . . . . . . . . . . 35
1.4 A Note on the Companion Library . . . . . . . . . . 40

I Designing Algebras 43

2 Tiles 44
2.1 Basic Building Blocks . . . . . . . . . . . . . . . . . 46
2.2 Subdividing Space . . . . . . . . . . . . . . . . . . . 57
2.3 Observations . . . . . . . . . . . . . . . . . . . . . . 68
2.4 Generalization . . . . . . . . . . . . . . . . . . . . . 74

3 What Makes a Good Algebra? 82

iv
CONTENTS v

4 Scavenger Hunt 86
4.1 Input Filters . . . . . . . . . . . . . . . . . . . . . . 101
4.2 Simultaneous Challenges . . . . . . . . . . . . . . . . 106
4.3 Challenge Completion . . . . . . . . . . . . . . . . . 113
4.4 Simplification . . . . . . . . . . . . . . . . . . . . . . 121
4.5 A Unified Observation . . . . . . . . . . . . . . . . . 125
4.6 Symmetry . . . . . . . . . . . . . . . . . . . . . . . . 132
4.7 Clues . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
4.8 Generalization . . . . . . . . . . . . . . . . . . . . . 147

II Deriving Implementations 154

5 Tile Implementation 155

5.1 The Initial Encoding . . . . . . . . . . . . . . . . . . 156
5.2 Generating Tests . . . . . . . . . . . . . . . . . . . . 166
5.3 An Efficient Implementation . . . . . . . . . . . . . . 182

6 Scavenger Hunt Implementation 196

6.1 The Filter Algebra . . . . . . . . . . . . . . . . . . . 198
6.2 The Challenge Algebra . . . . . . . . . . . . . . . . . 205
6.3 Testing It . . . . . . . . . . . . . . . . . . . . . . . . 216
6.4 Implementation . . . . . . . . . . . . . . . . . . . . . 224

III Reference Material 245

7 Property-Based Testing 246

7.1 Basics . . . . . . . . . . . . . . . . . . . . . . . . . . 249
7.2 Writing Good Generators . . . . . . . . . . . . . . . 253
7.3 Showing . . . . . . . . . . . . . . . . . . . . . . . . . 265
7.4 Shrinking . . . . . . . . . . . . . . . . . . . . . . . . 267
7.5 Using QuickCheck Interactively . . . . . . . . . . . . 270
CONTENTS vi

8 Effective QuickSpec 272

8.1 Signatures . . . . . . . . . . . . . . . . . . . . . . . . 274
8.2 Motivating QuickSpec . . . . . . . . . . . . . . . . . 276
8.2.1 QuickSpec for Designing Greenfield Projects . 276
8.2.2 QuickSpec for Analyzing Existing Projects . 277
8.3 Background Signatures . . . . . . . . . . . . . . . . . 278
8.4 Predicates . . . . . . . . . . . . . . . . . . . . . . . . 281
8.5 Naming Variables . . . . . . . . . . . . . . . . . . . . 282
8.6 Observing Equalities . . . . . . . . . . . . . . . . . . 283
8.7 Creating QuickCheck Tests . . . . . . . . . . . . . . 285
8.8 Variable Usage . . . . . . . . . . . . . . . . . . . . . 286
8.9 Debugging QuickSpec Output . . . . . . . . . . . . . 287
8.9.1 Common Warnings . . . . . . . . . . . . . . . 287
8.9.2 Insane Laws . . . . . . . . . . . . . . . . . . . 289
8.9.3 Poorly-Typed Laws . . . . . . . . . . . . . . 290
8.9.4 Unsimplified Laws . . . . . . . . . . . . . . . 290

9 Common Algebraic Components 292

9.1 Properties . . . . . . . . . . . . . . . . . . . . . . . . 293
9.1.1 Associativity . . . . . . . . . . . . . . . . . . 293
9.1.2 Identity . . . . . . . . . . . . . . . . . . . . . 295
9.1.3 Idempotency . . . . . . . . . . . . . . . . . . 297
9.1.4 Invertibility . . . . . . . . . . . . . . . . . . . 299
9.1.5 Distributivity . . . . . . . . . . . . . . . . . . 301
9.1.6 Commutativity . . . . . . . . . . . . . . . . . 302
9.1.7 Annihilation . . . . . . . . . . . . . . . . . . 303
9.2 Structures . . . . . . . . . . . . . . . . . . . . . . . . 304
9.2.1 Semigroups . . . . . . . . . . . . . . . . . . . 305
9.2.2 Monoids . . . . . . . . . . . . . . . . . . . . . 306
9.2.3 Groups . . . . . . . . . . . . . . . . . . . . . 308
9.2.4 Semilattices . . . . . . . . . . . . . . . . . . . 309
9.2.5 Functors . . . . . . . . . . . . . . . . . . . . . 310
9.2.6 Applicative Functors . . . . . . . . . . . . . . 312
CONTENTS vii

Back Matter 317

Acknowledgements 317

Bibliography 319

Glossary 323
Foreword

The Restoring of Broken Parts

Algebra. We all studied it at school. We learned “algebraic laws”
such as commutativity

𝑥+𝑦 =𝑦+𝑥

and associativity

(𝑥 + 𝑦) + 𝑧 = 𝑥 + (𝑦 + 𝑧)

so well that applying them became second nature, and we could

use them in long reasoning about equalities, without any need for
more complicated proof techniques such as proof-by-cases, proof-
by-induction, or proof-by-contradiction.
We may think of algebra in connection with proofs, but it is
not only useful for reasoning. It also lets us abstract away from
unimportant details. Every time we write 𝑎 + 𝑏 + 𝑐 + 𝑑 without
worrying where the brackets should go, we are taking advantage of
the associative law—the second equation above—and thinking at
a higher level of abstraction. This matters to mathematicians, and
it also matters to programmers. Every time you sum an array in
a loop,

1
CONTENTS 2

int sum(int a[], int n)

{ int sum=0;
for(int i=0;i<n;i++) sum = sum + a[i];
return sum;
}

you are relying on associativity, to guarantee that it doesn’t matter

which order you combine the array elements in. When laws break
down, there are problems. For example, the code above is actually
incorrect for summing an array of floats! Floating point addition
is not associative, and if you add up a million floats using a loop
like this one, you will get the wrong answer! Instead you can use
a clever algorithm called ‘Kahan summation’ to get a much better
one (look it up; next time you have a million floats to add up,
you’ll thank me). But the lesson is this: when algebraic laws fail,
the ground wobbles under our feet.
Computer scientists have been interested in the “algebra of pro-
grams” for more than half a century. In his classic 1966 paper ‘The
next 700 programming languages’, Peter Landin wrote:
For most programming languages there are certain
statements of the kind, ‘There is a systematic equiva-
lence between pieces of program like this, and pieces
like that,’ that nearly hold but not quite. … At first
sight it might appear pedantic to quibble about such
untidiness—‘What’s the point of having two different
ways of doing the same thing anyway? Isn’t it better to
have two facilities than just one?’ The author believes
that expressive power should be by design rather than
accident, and that there is great point in equivalences
that hold without exception.
The desire for “equivalences that hold without exception” is
one of the strong motivations for functional programming; that
𝑥 − 𝑥 = 0, but
CONTENTS 3

getchar() - getchar() == 0

will usually be false in C, is a great impediment to algebraic rea-

soning.
However, the algebra of programs extends far beyond the usual
algebra of numbers. In his 1978 Turing Award lecture, John Backus
argued that the very constructions of a programming language,
which he called “functional forms”, should be chosen to support
algebraic reasoning:

“One chooses only those functional forms that not

only provide powerful programming constructs, but
that also have attractive algebraic properties: one
chooses them to maximize the strength and utility of
the algebraic laws that relate them to other functional
forms of the system.”

Backus advocated high-level combining forms such as map and

reduce (fold), rather than low-level constructions such as sequenc-
ing or iterating statements, which is echoed in the “point-free” pro-
gramming style popular in Haskell today.
Backus favoured algebra, over other kinds of reasoning, because
it is easy and practical:

The algebra of the programs described below is the

work of an amateur in algebra, and I want to show
that it is a game amateurs can profitably play and en-
joy, a game that does not require a deep understanding
of logic and mathematics. In spite of its simplicity, it
can help one to understand and prove things about pro-
grams in a systematic, rather mechanical way.

Indeed, we can reason algebraically about programs, that one

program is the same as another, without any external notations or
tools. All we need is some middle school mathematics.
CONTENTS 4

We can go on to apply algebra not only to numeric expressions

and to programming language constructions, but to all our APIs!
In their classic 1978 paper ‘The Algebraic Specification of Abstract
Data Types’, Guttag and Horning argue that algebraic laws are the
right way to specify the behaviour of an API:

The set of axioms defines the meaning of the operations

by stating their relationships to one another.
They are easy to read and comprehend, thus facilitating
informal verification of the fact that they do indeed
conform to the intent of their creator.

When an API satisfies a rich set of laws, then the algebra gives
us freedom:

• We’re free to think at a higher level of abstraction, without

worrying about trivial differences that the algebra assures us
don’t matter.
• We’re free to optimize one piece of code to another with bet-
ter performance, without risking introducing a bug, because
the algebra assures us the two are equivalent.

Algebraic laws are a powerful approach to optimization, a key

part of Burstall and Darlington’s program transformation method,
in their classic 1977 paper ‘A Transformation System for Develop-
ing Recursive Programs’. Today you can even give performance-
enhancing algebraic laws about an API to the Glasgow Haskell
compiler, to be applied automatically by the optimizer to speed up
client programs whenever opportunity arises.
If algebraic laws are so useful, then clearly it is highly desirable
that an API should satisfy many of them. That means that algebra
can serve as a touchstone for good design. In 1982 Peter Henderson
invented “functional geometry”, a simple API for describing com-
plex pictures, with a beautifully simple algebra. Henderson later
CONTENTS 5

wrote: “It seems there is a positive correlation between the sim-

plicity of the rules and the quality of the algebra as a description
tool.” You will learn all about Henderson’s algebra later in this
book; remember his advice—when choosing between design alter-
natives, choose the one with the better algebra! If your algebra is
strong enough, you may even be able to calculate the implementa-
tion using it.
I experienced all this myself in the early 90s, when working on
a library for writing pretty-printers in Haskell. Almost every data-
structure needs a pretty-printer, and I was fed up writing the same
kind of code over and over again, and making the same kinds of
mistakes over and over again—getting the layout of pretty-printed
output right is surprisingly tricky. So I designed an API for pretty-
printers, but it wasn’t crystal clear what each operator should do,
with the result that my pretty-printers were still buggy in weird
cases! But now that I had an API, I could look for algebraic laws—
and tweak the meanings of the operators to satisfy them. That
clarified the design wonderfully, and eliminated my bugs. I was
even able to use my algebra to calculate a highly-efficient implemen-
tation, resulting in code that I could never have written by hand—
with confidence that the algebra would ensure that all the weird
corner cases were correctly handled. The paper I wrote as a result,
‘The Design of a Pretty-printing Library’ (1995) has spawned an
entire mini-field of algebraically-based pretty-printing.
Of course, when you try to apply algebra to your own code in
practice, you will immediately ask yourself questions like

• How do I know my code really satisfies this law?

• How can I figure out which laws my code satisfies?

Fortunately, today there are tools for Haskell that can answer
these questions for you—QuickCheck to test that a particular law
is satisfied, and QuickSpec to find a set of laws in the first place. So
we are in a much better position, today, to apply algebraic methods
to our code in practice, than the pioneers I quoted above.
CONTENTS 6

But to apply these methods yourself, there is much to learn—

and this is what this lovely book will teach you. What algebra is,
how to apply it, what to look for, how to let it guide your designs,
how to calculate your code, how to use the tools that are now
available to support the approach. It’s all illustrated with a new
take on Peter Henderson’s functional geometry, and a much larger-
scale and more realistic game application, with a down-to-earth
approach that you can put straight into practice. I am so glad that
Sandy has written it—it provides an excellent introduction to so
many ideas that I love.
Algebra enabled me to turn my pretty-printing code from a
useful-but-buggy mess into a thing of beauty. The word ‘algebra’
itself comes from the work of Persian mathematician Muhammad
ibn Musa al-Khwarizmi in the ninth century, and means “the restor-
ing of broken parts”. I think it’s quite appropriate.
May this book teach you how to restore broken parts.

John Hughes
Gothenburg, Sweden, September 2020.
Preface

For the last seven years, I’ve been fascinated by what I see to be
the central question in computing — “why isn’t functional program-
ming more popular?” In my eyes, functional programming (FP) is
easier to get right, requires less effort to produce, and comes with
stronger maintainability guarantees than the more conventional
paradigms afford. But if FP is so fantastic, why hasn’t it taken
over the world yet?
I can see only three possibilities.
The most obvious one is that functional programming simply
isn’t all that much better. But this flies directly in the face of
my experience and that of my colleagues in the FP community.
There are numerous stories about people coming from procedural
paradigms and falling in love with FP; but very few in which peo-
ple go the other direction. Common themes are that functional
programming is more “elegant,” and “easier to reason about,” and
that it “expands our way of thinking.”
Perhaps instead, it’s that the market doesn’t reward what func-
tional programming brings to the table. It seems a little far-fetched,
but maybe software doesn’t live and die by the speed at which it’s
written, its correctness, and its maintainability. By being smaller
than its procedural and object-oriented peers, functional program-
ming languages boast significantly fewer libraries, which is likely
part of the issue. It’s not that the market doesn’t reward speed,
merely that until we achieve library parity, the mainstream inertia

7
CONTENTS 8

will keep its adherents. There is probably some truth to this. But
I don’t think this explains the whole story.
However, the third option is that we FP-people are just not very
good at applying functional principles in large-scale, real-world ap-
plications. That is to say, maybe the problem isn’t with functional
programming; it’s that we collectively aren’t yet good enough with
it. It’s a common argument that functional programming works
well in the small, but in the large, you actually need to deal with
external systems and real-world complexity. It’s in this interaction
with reality that the cracks in FP begin to show.
I think FP’s inability to take over the world is this last point.
I believe that, as a community, we’re not very good at scaling
up functional thinking. There is no blame here; after all, we all
have significantly more experience engineering procedural systems
than we do functional ones. The issue is that it takes a lot of
false starts to move forward. In the mainstream world, these false
starts were already taken by our predecessors. But with functional
programming only now just starting to gain widespread attention,
we stand on our own, with little conventional knowledge to fall
back on.
Fortunately, we’re not alone in this endeavor. This book
presents a fundamentally different approach for thinking about
and writing software, one which plays to our strengths. It’s not a
novel idea by any means — while researching this book, I found
that most of my discoveries were first unearthed in the mid-70s
in the academic community. Academic researchers don’t have the
best track record for communicating their research outside of the
ivory tower, and I fear that’s what has happened here. An idea is
only as good insofar as it can be acted upon. But it’s important
to note that the material presented here is in no way my own
research.
To paraphrase Gwern Branwen: if this book has done anything
meritorious, it was perhaps simply putting more work into than
someone else would have. My goal has always been to help com-
CONTENTS 9

municate better ideas than the ones I come up with. That’s the
natural progression of learning, and after a year and two complete
rewrites of this book, boy have I ever learned a lot. I hope you do
too.

Sandy Maguire
Victoria, BC, Canada
September 2020
Chapter 1

Overview

1.1 Abstraction
This book is about abstractions — how to think about them, find
good ones, and wield them effectively. At first blush, this sounds
like a question of style; certainly, abstraction is abstraction is ab-
straction, right? No, not only is this not right; it is not even wrong.
When asked what abstraction is, many programmers will give one
of the following answers:

1. “It’s refactoring: pulling out duplicated code into a reusable

function.”
2. “It’s indirection: providing thin wrappers around calls, and
opening the doors for future extensibility.”
3. “It’s parameterization: putting adjustable knobs onto code
and solving the more general problem.”

Each of these is a means to a noble goal, but none of them is

the abstraction tackled here. Instead, we will take a broader, more
encompassing, easier-to-measure definition of what abstraction is.
Instead, to quote Dijkstra (1972):

The purpose of abstraction is not to be vague, but to

10
1.1. ABSTRACTION 11

create a new semantic level in which one can be abso-

lutely precise.
To us, abstraction is only that which creates new, precise se-
mantic domains. But what does this mean? A helpful abstraction
is one which gives us an interpretation of the world that we accept
as being true. All ideas are necessarily metaphors — reality is just
too complicated for human brains. No idea is, therefore, a ground
truth, but an excellent abstraction is one that never reminds you
of its falsehood. A useful abstraction fundamentally changes the
way you think and operate.
Spotting good abstractions is challenging, as they’re often mis-
taken for the way that the world really is. Perfect abstractions
are invisible. As an example, the computer hardware world makes
excellent abstractions. Software doesn’t actually proceed one in-
struction at a time: a modern CPU is decoding many hundreds of
instructions at a time, and invisibly parallelizing them. But short
of extremely-precise out-of-band timing attacks, you can’t ever ob-
serve your CPU is doing this. This one-instruction-at-a-time ab-
straction is so persuasive that we operate as though it’s true, and
thus it never violates our implicit assumptions about how the code
works. An excellent abstraction is out of sight and out of mind.
Likewise, are the fundamental building blocks of your computer
really logic gates? No — logic gates don’t really exist; they are
an abstraction describing how transistors behave when placed in
specific patterns. But the concept of logic gates is so persuasive
that we collectively forget that are they nothing but useful figments
of our collective imagination. Treat with suspicion anyone who says
abstractions are fundamentally leaky; maybe these people are just
bad at abstraction.
Other excellent abstractions are TCP/IP, Boolean algebra,
Newtonian physics — even mathematics and logic themselves.
These are good examples, not because they’re accurate reflections
of reality — but because we forget that they aren’t. Contrast
this sort of abstraction against what we usually encounter in
1.1. ABSTRACTION 12

software contexts. We’re all too familiar with wrappers promising

to unify disparate database interfaces, but which inevitably throw
exceptions when one of the backends doesn’t support an operation.
Or consider how web-servers encourage us to think of HTTP
headers as key/value pairs, but that a newline character in either
key or value will compromise its entire security model. These are
leaky abstractions, which is to say, worthless ones.
The goal of abstraction is to shield us from the reality be-
neath. If the real world somehow manages still to poke through,
the abstraction-wielder must be aware now of both ground truth
and the artificial, semantic layer on top. A careful practitioner
now has two sets of invariants he must respect. Simultaneously he
can’t be sure of how the abstraction maps to reality or whether
the leaks indicate a broken invariant somewhere. In essence, this
wrong abstraction has doubled its practitioner’s workload and her
burden of understanding. Take a moment to appreciate just how
common this is when writing software. Any system which gives you
a backdoor to escape the abstraction is necessarily one which ad-
mits its incompetence. Computer systems give us no escape hatch
to turn off instruction pipelining, nor can our programs opt-out
of logic gates and instead work directly with transistors. Good
abstractions don’t require escape hatches.
Our discussion on abstraction is merely foreplay to set the
stage for this book’s main contribution: that code is the wrong
abstraction for doing programming. There are infinitely many com-
puter programs, the astronomical majority of which we don’t want.
There are so many that we can’t want most of them. The argu-
ment is that unconstrained, implementation-first programming is
too expressive as it’s usually done. Code is just too powerful and
too low-level for even the most diligent among us to understand
truly any non-trivial program. Instead, we need better abstrac-
tions and tools for the decomposition, understanding, and solving
of problems.
If you take away nothing else from this book, it should be that
1.2. WHAT IS ALGEBRA-DRIVEN DESIGN? 13

code is a uniquely terrible tool for thought. The traditional thought

patterns taught in algorithms class — and sought out during soft-
ware interviews — is fundamentally detrimental to the problems
we’re trying to solve. It is a testament to human heroics and indus-
triousness that we can accomplish so much in the world of software
despite these handicaps. Unfortunately, it’s much more compli-
cated than it needs to be, reflected in part by how normalized bugs
are. Debugging is considered part of the job, and the vast majority
of software has security flaws. The cost of software also reflects this
pain: maintaining software is much more expensive than writing it
in the first place. In most industries, the up-front costs dominate.
Why is this? My answer is that all software tends towards
large systems and that large codebases are impossible for humans
to understand in full. Worse, there are not any widespread tools to
aid in that understanding. In an ideal world, the knowledge from
the original design is reusable, and can be reliably shared with
others. Imagine a world in which we all understood a codebase
as well as its original author. Or if we could ask the compiler to
ensure that our invariants always hold. Imagine if the abstractions
never leaked and needing to debug an underlying library were a
thing of the past. Imagine if the code were a byproduct of the
understanding, and wrote itself.
Algebra-Driven Design is a framework for making that future
the future.

1.2 What is Algebra-Driven Design?

Programs are meant to be read by humans and only
incidentally for computers to execute.
–Harold Abelson

Writing software is hard — likely one of the most difficult chal-

lenges that individual humans have ever undertaken. Our brains
1.2. WHAT IS ALGEBRA-DRIVEN DESIGN? 14

aren’t wired for it. We aren’t well-adapted for thinking about sub-
tle state interactions that accumulate over hundreds of thousands
of lines of code. Code that is pedantic, written to describe, in excru-
ciating detail, tasks which are self-evident to humans. Computers
are, by and large, idiots, and the vast majority of a software engi-
neer’s job is understanding problems so well that you can explain
them to these uncomprehending machines.
It is this comprehension that is of paramount importance. As
this book argues, the software engineer’s ability to understand prob-
lems is her primary employable skill. The code is merely a byprod-
uct, serving only to explain this understanding to the computer —
uninteresting in its own right.
While it might sound like a truism to suggest we focus on the
understanding of problems rather than the programming of solu-
tions, consider just how difficult this is with conventional tools
and best practices. Our programming languages, the primary tool
for thought for many software engineers, give us no support in this
department. Our only facilities for writing code that is “easily un-
derstood” are to use descriptive variable names, write explanatory
comments, and to optimize our code “to be read” — whatever that
means.
But notice that these are all code-centric improvements. At
their core, they still privilege the program as the fundamental unit
of study — the very thing that is first and foremost an artifact
for a computer to execute. The program is not our understand-
ing of the problem and its solution; it is the end product of that
understanding. If we’re lucky, the program comes with comments
that are simultaneously insightful and true, though ensuring this
continues to be the case over time is probably asking too much.
For better or worse (but mostly just for the worse,) documenta-
tion is our only tool for preserving institutional understanding of
a codebase. Unfortunately, there is no tool in existence to ensure
our documentation stays in sync with the system it purports to
document. Indeed, tools like doctest can help show our examples
1.2. WHAT IS ALGEBRA-DRIVEN DESIGN? 15

produce the output, but there are no tools that check the prose of
our comments.
Of course, the program still exists, and in some sense, is the
source of truth of meaning. When documentation goes stale, we
are not stuck; we can always reverse-engineer understanding from
the program itself. Unfortunately, this state of affairs is almost syn-
onymous with “programming,” at least in most professional spheres.
Over time, software engineers get quite good at this detective work
— sussing out the “what” from the “how” — but it is essential to
remember that this is inherently a lossy procedure. Rather than
being able to page in the original author’s understanding of the
code, we must reinterpret it, reading between the lines. This is
more of an exercise of psychology than of engineering, as the goal
is to recreate another human’s state of mind.
Civilizationally-speaking, we are remarkably successful in this
endeavor of reverse-psychology. It’s a testament to all of the heroic
maintenance programmers out there who manage to keep these
software systems up and running. But let’s not mince words, this
is truly a Herculean undertaking. Programming is a fundamentally
challenging undertaking, yes, but it shouldn’t be nearly as hard as
it is. Nor need it be.
The irony here is in our rush to automate away other profes-
sions by providing better tools, by and large, we’ve forgotten to
apply this same mindset to our own field. Rather than trying
to solve underlying problems, which we are reasonably blind to,
we usually find a convenient workaround. For example, why do
we still represent and edit our source code as strings? Syntacti-
cally valid programs are a vanishingly small subset of all possible
strings. The number of valid edits to a program is minuscule com-
pared to the number of possible ways we can manipulate a string.
Yes, source code does need eventually to be stored as bytes some-
where on a filesystem. But memory too is just a series of bytes,
and unless you’re a low-level C programmer, you almost certainly
never think of memory like that. We don’t manipulate instances
1.2. WHAT IS ALGEBRA-DRIVEN DESIGN? 16

of objects by explicitly twiddling their bytes in memory, so why do

we still think about the raw representation of bytes when writing
source code? Continually improving text editors are our conve-
nient workaround here — but fundamentally, we are still thinking
in terms of bytes, as indicated by our frustration when these tools
“incorrectly” change our formatting.1
My point here is to illustrate that thinking about source code
as a string of bytes is merely working at the wrong level of abstrac-
tion. It isn’t difficult to imagine vastly better program editors2
than today’s best. Tools that edited programs as a tree and which
would show only options that type-checked or were otherwise sane.
Tools that would obsolete style arguments by displaying us code
in whatever presentation we preferred. Tools that could automat-
ically test the code we write to ensure it will never crash (or at
least, only crash expectedly) when given garbage inputs. Imagine
just how spectacular our tooling could be if we stopped insisting
on seeing our code as bytes instead of structured objects that could
be manipulated, transformed, inspected, and generated.
A core theme of Algebra-Driven Design is the insistence on
working at the proper level of abstraction and on creating new
levels if the available ones aren’t sufficient. This book isn’t here to
harp on about how source code shouldn’t be represented — or, for
that matter, experienced — in bytes. No, the argument presented
is that programs themselves are the wrong level of abstraction, and
what we can do about that. This book is about learning to focus
on the understanding and offloading most of the coding to our
computer tool.
In the same way that having a structured model of source code
would enable us to perform exciting transformations that are infea-
sible in the land of bytes, having a structured model of understand-
ing affords us a great deal of flexibility. By reifying our knowledge
1
Lisp is the notable exception to this point.
2
It seems more natural to say “vastly better text editors,” but that would
be to miss the point entirely.
1.2. WHAT IS ALGEBRA-DRIVEN DESIGN? 17

of what our programs are, we can pass along machine-checked doc-

umentation that not only describes our understanding of what’s
going on, but is guaranteed to stay relevant (see chapter 8). The
same machinery allows us to automatically generate thousands of
unit tests — not only for properties we understand but also for
emergent interactions between components that are necessary for
human understanding of the system at large (chapter 7). By hav-
ing our understanding explicitly modeled, it becomes an object of
study in itself, and we can play around with the formulation to find
better asymptotics or more elegant designs. Perhaps the most ex-
citing feature of this approach is that it allows us directly to derive
implementations from our understanding, and to discover mind-
bending optimizations that are unlikely to be found by intuition
alone.
In short, Algebra-Driven Design is an entirely new way of think-
ing about software engineering. To quote Elliott (2009), whose
thinking on this topic has greatly influenced this book:

Adopting the discipline illustrated [here] requires addi-

tional up-front effort in clarity of thinking, just as static
typing does. The reward is that the resulting designs
are simple and general, and sometimes have the feel of
profound inevitability.

If you are happy toiling in the mire of source code, resigned to

semantic games of “Telephone” between you and all other techni-
cians who have touched a project over the years, then this is not
the book for you. But if the above arguments have piqued your
interest, if you’ve been dissatisfied with the way things are done in
software, maybe this book can help.

This approach has three primary benefits over the usual

intuition-driven, cowboy-coding that often dominates our pro-
fession. The first is that it allows us to focus on the fun part
1.2. WHAT IS ALGEBRA-DRIVEN DESIGN? 18

of software design, which is the design and understanding of

the problem. It spares us most of the work of dealing with the
incidental complexity, interfacing with clunky libraries, figuring
out how exactly to decompose our dependency injection, and
writing unit tests. These things are necessary for a working, ship-
pable program, but they aren’t software engineers’ comparative
advantage: understanding and dealing with complex systems.
As a byproduct of reifying our thinking, we find the second
benefit: that we can offload a great deal of our work to the com-
puter tool. By having machine-checkable artifacts, the computer
can tell us when our laws combine in nonsensical ways, when our
reference implementation doesn’t do what the laws say, or when
our real implementation doesn’t line up with the reference. By do-
ing this thinking outside of our heads, we can ask the computer to
help suggest laws we might have missed, and generate thousands of
unit tests following our specification — testing for edge cases that
no human could ever consider “manually.”
Having saved the best for last, the final benefit of ADD is that
it allows us to derive implementations, if not “for free,” then at
least “greatly discounted.” The equality laws guiding us through
this entire process are excellent at finding the best “carve” of imple-
mentation through the design. The resulting programs are often
beautiful, and more often than not, feel discovered rather than en-
gineered. Through this approach, programs are elegant in their
simplicity and generality, and playful manipulation of the laws is
eerily good at finding asymptotic improvements. In essence, this
means that the approach is a reliable generator of insights — both
in design work and in coming up with intelligent optimizations.
In a genuine sense, Algebra-Driven Design is about designing
programs for humans. The unreasonable effectiveness of mathe-
matics seems related to the fact that it models things that humans
can understand formally. Algebra is not a study of the world; it is
a study of psychology. It is the study of those systems we humans
can think clearly about.
1.2. WHAT IS ALGEBRA-DRIVEN DESIGN? 19

With all of these significant advantages of Algebra-Driven De-

sign, it’s necessary to realize what it is not. ADD is incredibly
helpful in finding reusable abstractions, which is to say, it’s good
when designing libraries. Applications are particular instantiations
of reusable library components, and if you insist on thinking of an
application as completely non-reusable code, ADD cannot help you.
Instead, it encourages separating the core logic — the bits that
make your program your program — from the chaff of program-
ming tasks necessary to connect your program to the outside world.
Strong adherence to ADD pushes library code to the forefront and
resigns applications to thin wrappers around library functionality.
If you were never particularly good at math in school, take
heart! Despite having the word “algebra” in its title, Algebra-
Driven Design is not about the sort of algebra that causes night-
mares. The algebra here has nothing to do with numbers, nor
with arcane rules handed down by fiat from on high. The word
“algebra” specifies that we are working algebraically, which is to
say, thinking about what equations should hold, and manipulating
those rules to find answers. Those answers? The implementations
of the programs we want to write.
Furthermore, Algebra-Driven Design has nothing at all to do
with visual aesthetics. It is not about “designing a good user ex-
perience” or with “designing a pleasing webpage.” ADD is about
designing excellent software — which is to say, software that is
easy to understand, guaranteed to do what it says on the tin, and
flexible enough to be used in more ways than its original authors
ever could have intended.
Algebra-Driven Design isn’t particularly prescriptive. It’s an
interactive process, a discussion between your tools and your intu-
ition, helping refine ideas until they’re beautiful.
Finally, Algebra-Driven Design need not be a solo endeavor.
The entire point of giving laws and models is to share your under-
standing with others. Doing a formal review with your team of the
design is a great way to find missed opportunities for additional
Another random document with
no related content on Scribd:
27.(a) Rind and fistulous appendages Oceanapia
present; microscleres sigmata
(b) No rind; skeleton reticulate; Gellius
microscleres sigmata and/or
toxa
28.(a) Skeleton confused or formed of 29
bundles of spicules with
echinating spined styles
(b) Skeleton fibrous or reticulate, or 45
formed of short columns
(c) Skeleton formed of a dense 52
central axis, and columns
radiating from it to the surface
29.(a) Spicules of the ectosome styles Pytheas
(b) Spicules of the ectosome oxeas Clathrissa
or absent
(c) Main skeleton confused. Spanioplon
Special ectosomal skeleton
absent
30.(a) Megascleres of the 31
choanosome not differing from
those of the ectosome
(b) Megascleres of the 32
choanosome differing from
those of the ectosome
31.(a) Chelae absent. 33
(b) Chelae present 44
32.(a) Trichodragmata present Tedania
(b) Trichodragmata absent 42
Fig. 110.—Megascleres. a-l and q-s, Modifications of monaxon type. a,
Strongyle; b, tylote; c, oxea; d, tylotoxea; e, tylostyle; f, style; g, spined
tylostyle; h, sagittal triod (a triaxon form derived from monaxon); j, oxytylote;
k, anatriaene; l, protriaene; m, sterraster (polyaxon); n, radial section
through the outer part of m, showing two actines soldered together by
intervening silica; o, desma of an Anomocladine Lithistid (polyaxon); q,
crepidial strongyle, basis of rhabdocrepid Lithistid desma; r, young form of
rhabdocrepid desma, showing crepidial strongyle coated with successive
layers of silica; s, rhabdocrepid desma.

33.(a) Skeleton reticulate or fibrous 34

(b) Skeleton radiate or diffuse 37
(c) Skeleton with radiating fibres forming a Quasillina
reticulum with others crossing them at
right angles
34.(a) No microscleres 35
(b) Microscleres sigmata and/or toxa with Desmacella
or without trichodragmata
35.(a) Sponge fan- or funnel-shaped 36
(b) Sponge not fan- or funnel-shaped Hymeniacidon
36.(a) Megascleres slender and twisted Phakellia
(b) Megascleres somewhat stout, not Tragosia
twisted
37.(a) Sigmata present, skeleton diffuse Biemma
(b) Sigmata absent 38
38.(a) Skeleton more or less radiate 39
(b) Skeleton diffuse; sponge boring Cliona
39.(a) Sponge discoid with marginal fringe Halicnemia
(b) Sponge massive or stipitate without 40
marginal fringe
40.(a) Sponge body prolonged into Polymastia
mammiform projections
(b) Sponge body without mammiform 41
projections
41.(a) No microscleres. Megascleres Suberites
tylostyles with or without styles
(b) Microscleres centrotylote. Megascleres Ficulina
styles or tylostyles
42.(a) Choanosomal megascleres smooth 43
(b) Choanosomal megascleres spined Dendoryx
43.(a) Microscleres chelae and sigmata of Lissodendoryx
about the same size
(b) Chelae, if present, smaller than the Yvesia
sigmata
44.(a) Isochelae Esperiopsis
(b) Anisochelae Esperella
45.(a) Fibres or columns plumose 46
(b) Fibres or columns ectyonine 47
46.(a) Microscleres toxa Ophlitaspongia
(b) Microscleres absent Axinella
47.(a) Skeleton reticulate 48
(b) Skeleton not reticulate 49
48.(a) Microscleres present. Spicules of the Myxilla
fibre core spined
(b) Microscleres absent. Spicules of the Lissomyxilla
fibre core smooth
49.(a) Main skeleton formed of plume-like 50
columns
(b) Main skeleton formed of horny fibres Clathria
(ectyonine). Special dermal skeleton
 wanting
50.(a) Dermal skeleton contains styles only Microciona
(b) Dermal skeleton contains diactine 51
spicules with or without styli
51.(a) Main skeleton columns with a core of Plumohalichondria
smooth oxeas
(b) Main skeleton columns with a core of Stylostichon
spined styles
52.(a) Central axis contains much spongin. Raspailia
Echinating spined styli present
(b) Central axis with little or no spongin. Ciocalypta
Spined styles absent. Pillars radiating
from the axis support dermal skeleton
53.(a) Ground substance between chambers Spongelia
clear; chambers pear-shaped or oval;
eurypylous
(b) Ground substance granular. Chambers 54
spherical with aphodi
54.(a) Fibres not pithed; sponge fan-shaped Leiosella
(b) Fibres pithed; sponge massive Aplysina
55.(a) Chambers long, tubular, branched Halisarca
(b) Chambers not much longer than Oscarella
broad; not branched
56.(a) Amphidiscs present Ephydatia
(b) Amphidiscs absent Spongilla

CHAPTER IX

PORIFERA (CONTINUED): REPRODUCTION, SEXUAL AND ASEXUAL—

PHYSIOLOGY—DISTRIBUTION—FLINTS
The reproductive processes of Sponges are of such great
importance in leading us to a true conception of the nature of a
sponge that we propose to treat them here in a special section. Both
sexual and asexual methods are common; the multiplication of
oscula we do not regard as an act of reproduction (p. 174).

Fig. 111.—A, amphiblastula larva of Sycon raphanus; B, later stage, showing

invagination of the flagellated cells. c.s, Segmentation cavity; ec, ectoderm;
en, endoderm. (After F. E. Schulze, from Balfour.)

A cursory glance at a collection of sponge larvae from different

groups would suggest the conclusion that they are divisible into two
wholly distinct types. One of these is the amphiblastula, and the
other the parenchymula. This was the conclusion accepted by
zoologists not long ago. We are indebted to Delage, Maas, and
Minchin for dispelling it, and showing that these types are but the
extreme terms of a continuous series of forms which have all the
same essential constitution and undergo the same metamorphosis.

The amphiblastula of Sycon raphanus (Fig. 111) consists of an

anterior half, formed of slender flagellated cells, and a posterior half,
of which the cells are large, non-flagellate, and rounded. These two
kinds of cell are arranged around a small internal cavity which is
largely filled up with amoebocytes. The flagellated cells are
invaginated into the dome of rounded cells during metamorphosis, in
fact, become the choanocytes or gastral cells; the rounded cells, on
the other hand, become the dermal cells—an astonishing fact to any
one acquainted only with Metazoan larvae.
A typical parenchymula is that of Clathrina blanca (Fig. 112). When
hatched it consists of a wall surrounding a large central cavity and
built up of flagellated cells interrupted at the hinder pole by two cells
(p.g.c)—the mother-cells of archaeocytes. Before the
metamorphosis, certain of the flagellated cells leave the wall and
sink into the central cavity, and undergoing certain changes establish
an inner mass of future dermal cells. By subsequent metamorphosis
the remaining flagellated cells become internal, not this time by
invagination, but by the included dermal cells breaking through the
wall of the larva, and forming themselves into a layer at the outside.

Fig. 112.—Median longitudinal section of parenchymula larva of Clathrina blanca.

p.g.c, Posterior granular cells—archaeocyte mother-cells. (After Minchin.)

In the larva of C. blanca, after a period of free-swimming existence,

the same three elements are thus recognisable as in that of Sycon at
the time of hatching; in the newly hatched larva of C. blanca,
however, one set of elements, the dermal cells, are not
distinguishable. The difference, then, between the two newly
hatched larvae is due to the earlier cell differentiation of the Sycon
larva.[254]

Now consider the larva of Leucosolenia. It is hatched as a

completely flagellated larva; its archaeocytes are internal (as in
Sycon); future dermal cells, recognisable as such, are absent. They
arise, as in C. blanca, by transformation of flagellated cells; but (1)
this process is confined to the posterior pole, and (2) the internal
cavity is small and filled up with archaeocytes. Consequently the
cells which have lost their flagella and become converted into dermal
cells cannot sink in as in C. blanca: they accumulate at the hinder
pole, and thus arises a larva half flagellated, half not; in fact, an
amphiblastula. Or, briefly, in Leucosolenia the larva at hatching is a
parenchymula, and when ready to fix is an amphiblastula; and,
again, the difference between the newly hatched larva and that of
Sycon is due to the earlier occurrence of cell differentiation in the
latter. What completer transitional series could be desired?

Turning to the Micromastictora, the developmental history already

sketched is fairly typical (p. 172). The differences between Mega-
and Micro-mastictoran larvae are referable mainly to the fact that the
dermal cells in the latter become at once differentiated among
themselves to form the main types of dermal cell of the adult.[255]
The metamorphosis is comparable to that of C. blanca. Among
Tetractinellida and Hexactinellida sexually produced larvae have not
been certainly identified.

Asexual reproduction takes place according to one of three types,

which may be alluded to as (1) "budding," (2) "gemmulation," (3)
formation of "asexual larvae."

By budding (Fig. 113) is meant the formation of reproductive bodies,

each of which contains differentiated elements of the various classes
found in the parent. A simple example of this is described by
Miklucho Maclay in Ascons, where the bud is merely the end of one
of the Ascon tubes which becomes pinched off and so set free.

In Leucosolenia botryoides[256] Vasseur describes a similar process;

in this, however, a strikingly distinctive feature is present (Fig. 114),
namely, the buds have an inverse orientation with respect to that of
the parent, so that the budding sponge presents a contrast to a
sponge in which multiplication of oscula has occurred. In fact, the
free distal end of the bud becomes the base of the young sponge,
and the osculum is formed at the opposite extremity, where the bud
is constricted from the parent.
 Fig. 113.—Lophocalyx philippensis. The specimen bears several buds attached
to it by long tufts of spicules. (After F. E. Schulze.)

Fig. 114.—Leucosolenia botryoides. A, a piece of the Sponge laden with buds, a-

f; i, the spicules of the buds directed away from their free ends; k, the
spicules of the parent directed towards the osculum, j. B, a bud which has
been set free and has become fixed by the extremity which was free or
distal in A. (After Vasseur.)

Such a reversal of the position of the bud is noteworthy in view of its

rarity, and the case is worth reinvestigating, for in other animal
groups a bud or a regenerated part retains so constantly the same
orientation as the parent that Loeb,[257] after experimenting on the
regeneration of Coelenterata and other forms, concluded that a kind
of "polarity" existed in the tissues of certain animals.

In Oscarella lobularis[258] the buds are transparent floating bladders,

derived from little prominences on the surface of the sponge.
Scattered in the walls of the bladders are flagellated chambers,
which open into the central cavity. The vesicular nature of the buds is
doubtless an adaptation, lessening their specific gravity and so
enabling them to float to a distance from the parent.

Gemmulation.—Spongilla has already afforded us a typical example

of this process. Gemmules very similar to those of Spongilla are
known in a few marine sponges, especially in Suberites and in
Ficulina. They form a layer attached to the surface of support of the
sponge—a layer which may be single or double, or even three or
four tiers deep. A micropyle is sometimes present in the spongin
coat, sometimes absent; possibly its absence may be correlated with
the piling of one layer of gemmules on another, as this, by covering
up the micropyle, would of course render it useless. Presumably
when a micropyle is present the living contents escape through it
and leave the sponge by way of the canal system (Fig. 115).

Fig. 115.—Gemmules of Ficulina. A, vertical section of gemmules in situ; B,

vertical section of upper portion of one gemmule. m, Micropyle.

The only case besides Spongilla in which the details of development

from gemmules have been traced is that of Tethya.[259] Mere
microscopic examination of a Tethya in active reproduction would
suggest that the process was simple budding, but Maas has shown
that the offspring arise from groups of archaeocytes in the cortex,
that is to say, they are typical gemmules. As they develop they
migrate outwards along the radial spicule-bundles and are finally
freed, like the buds of the Hexactinellid Lophocalyx (Fig. 113).

The comparison of the process of development on the one hand by

gemmules, and on the other by larval development, is of some
interest.[260] In both cases two cell layers—a dermal and a gastral—
are established before the young sponge has reached a functional
state. Differences of detail in the formation of the chambers occur in
the gemmule; these find parallels in the differences in the same
process exhibited by the larvae of various groups of sponges. On the
other hand, the order of tissue differentiation is not the same in the
gemmule as in the larva.

Fig. 116.—Development of the triradiate and quadriradiate spicules of Clathrina.

(1) Three scleroblasts; (2) each has divided: the spicule is seen in their
midst; (3) addition of the fourth ray by a porocyte. p, Dermal aperture of
pore; r, fourth ray. (After Minchin.)

Of the reproduction of Tetractinellida extremely little is known.

Spermatozoa occur in the tissues in profusion and are doubtless
functional, but larvae have been seldom observed.

Fig. 117.—Three stages in the development of the triradiate spicules of Sycon

setosum. × 1200. (After Maas.)

In Hexactinellida the place of sexually produced larvae is taken by

bodies of similar origin to gemmules but with the appearance of
parenchymulae. Ijima has indeed seen a few egg-cells in
Hexactinellids.[261] He finds, however, that archaeocyte congeries
occur in abundance, and there is good reason to believe with him
that these are responsible for the numerous parenchymula-like
asexually produced larvae he has observed. The discovery of
"asexual larvae" was first made by Wilson in the Monaxonid
Esperella; in this case the asexual larva is, as far as can be
detected, identical with that developed from the fertilised egg. A
similar phenomenon, the production of apparently identical larvae by
both sexual and asexual methods, has been observed in the
Coelenterate Gonionema murbachii.[262]

Artificially, sponges may be reproduced with great advantage to

commerce by means of cuttings. Cuttings of the bath sponge are fit
to gather after a seven years' growth.

The development of the various forms of spicules is a subject about

which little is yet known. Most spicules of which the development has
been traced originate in a single dermal cell. The triradiate and
quadriradiate spicules of Homocoela (Clathrinidae), as Minchin[263]
has most beautifully shown, form an exception. Three cells co-
operate to form the triradiate; these three divide to give six before
the growth of the spicule is complete. A quadriradiate is formed from
a triradiate spicule by addition of the fourth ray, which, again, has a
separate origin in an independent cell, in fact a porocyte. The
triradiate spicules of the Sycettidae, on the other hand, originate in a
single cell,[264] but the quadriradiate spicules are formed from these
by the addition of a fourth ray in a manner similar to that which has
just been described for Clathrinidae.
 Fig. 118.—Development of monaxon spicules. A, from Spongilla lacustris,
showing the single scleroblast. (After Evans.) B, a very large monaxon,
from Leucosolenia, on which many scleroblasts are at work. (After Maas.)

Monaxon spicules if not of large size undergo their entire

development within a single scleroblast (Fig. 118, A). In some cases
if their dimensions exceed certain limits, several cells take part in
their completion; some of these are derived from the division of the
original scleroblast, others are drawn from the surrounding tissue. In
Tethya, for example, and in Leucosolenia[265] the scleroblasts round
the large monaxon spicules are so numerous as to have an almost
epithelioid arrangement.

The large oxeas of Tetilla, Stelletta, and Geodia, however, are

formed each within a single scleroblast.[266]

Fig. 119.—Development of spheraster. A, of Tethya, from union of two

quadriradiate spicules. (After Maas.) B (a-e), of Chondrilla, from a spherical
globule. (After Keller.)
Triaenes have been shown[267] to originate as monaxons with one
swollen termination, from which later the cladi grow out. Information
as to the scleroblasts in this case is needed.

The value of a knowledge of the ontogeny of microscleres might be

great. Maas believes that he has shown that the spherasters of
Tethya are formed by the union of minute tetractine calthrops (Fig.
119, A). If this view should be confirmed, it would afford a very strong
argument for the Tetractinellid affinities of Tethya.

Fig. 120.—Stages in the development of the microscleres of Placospongia. (After

Keller.)

Keller,[268] on the other hand, finds that the spherasters of the

Tetractinellid Chondrilla originate as spheres (Fig. 119, B); and
spheres have been observed in the gemmule of a Tethya; no
spherasters were as yet present in the gemmule, and spheres were
absent in the adult.[269]

In the genus Placospongia certain spicules are present which

outwardly closely resemble the sterrasters so characteristic of
certain Tetractinellidae. Their development, however, as will be seen
from Fig. 120, shows that they are not polyaxon but spiny monaxon
spicules. Placospongia is consequently transferred to the
Monaxonida Spintharaphora.

Sterrasters originate within an oval cell as a number of hairlike

fibres[270] (trichites), which are united at their inner ends. The outer
ends become thickened and further modified. The position occupied
by the nucleus of the scleroblast is marked in the adult spicule by a
hilum.
 Fig. 121.—Three stages in the development of an anisochela. al, Ala; al', lower
ala; f, falx; f', lower falx; r, rostrum; r', lower rostrum. (After Vosmaer and
Pekelharing.)

The anisochela has been shown repeatedly to originate from a C-

shaped spicule.[271]

What little is known of the development of Hexactinellid spicules we

owe to Ijima.[272] Numerous cells are concerned in certain later
developmental stages of the hexaster; a hexaster passes through a
hexactin stage, and—a fact "possibly of importance for the
phylogeny of spicules in Hexactinellida"—in two species the first
formed spicules are a kind of hexactin, known as a "stauractin," and
possessing only four rays all in one plane (cf. Protospongia, p. 207).

Physiology
Production of the Current.—It is not at first sight obvious that the
lashing of flagella in chambers arranged as above described,
between an inhalant and an exhalant system of canals, will
necessarily produce a current passing inwards at the ostia and
outwards at the osculum. And the difficulty seems to be increased
when it is found[273] that the flagella in any one chamber do not
vibrate in concert, but that each keeps its own time. This, however, is
of less consequence than might seem to be the case. Two conditions
are essential to produce the observed results: (1) in order that the
water should escape at the mouth of the chamber there must be a
pressure within the chamber higher than that in the exhalant
passages; (2) in order that water may enter the chamber there must
be within it a pressure less than that in the inhalant passages. But
the pressure in the inhalant and exhalant passages is presumably
the same, at any rate before the current is started, therefore there
must be a difference of pressure within the chamber itself, and the
less pressure must be round the periphery. Such a distribution of
pressures would be set up if each flagellum caused a flow of water
directed away from its own cell and towards the centre of the
chamber; and this would be true whether the flagellum beats
synchronously with its fellows or not.

The comparative study of the canal systems of sponges[274]

acquires a greater interest in proportion as the hope of correlating
modifications with increase of efficiency seems to be realised. In a
few main issues this hope may be said to have been realised. The
points, so to speak, of a good canal system are (1) high oscular
velocity, which ensures rapid removal of waste products to a
wholesome distance; (2) a slow current without eddies in the
flagellated chambers, to allow of the choanocytes picking up food
particles (see below), and moreover to prevent injury to the delicate
collars of those cells; (3) a small area of choanocytes, and
consequent small expenditure of energy in current production.

It is then at once clear at what a disadvantage the Ascons are placed

as compared with other sponges having canal systems of the
second or third types. Their chamber and oscular currents can differ
but slightly, the difference being obtained merely by narrowing the
lumen of the distal extremity of the body to form the oscular rim.
Further, the choanocytes are acting on a volume of water which they
can only imperfectly control, and it is no doubt due to the necessity
of limiting the volume of water which the choanocytes have to set in
motion that the members of the Ascon family are so restricted in
size. The oscular rim is only a special case of a device adopted by
sponges at the very outset of their career, and retained and
perfected when they have reached their greatest heights; the volume
of water passing per second over every cross-section of the path of
the current is of course the same, therefore by narrowing the cross-
sectional area of the path at any point, the velocity of the current is
proportionally increased at that point. The lining of the oscular rim is
of pinacocytes; they determine a smooth surface, offering little
frictional resistance to the current, while choanocytes in the same
position would have been a hindrance, not only by setting up friction,
but by causing irregularities in the motion.

Canal systems of the second type show a double advance upon that
of the Ascons, namely, subdivision of the gastral cavity and much
greater length of the smooth walled exhalant passage. The
choanocytes have now a task more equal to their strength, and,
further, there is now a very great inequality between the total
sectional areas of the flagellated chambers and that of the oscular
tube.

Canal systems of the third type with tubular chambers are an

improvement on those of the second, in that the area of choanocytes
is increased by the pouching of the chamber-layer without
corresponding increase in the size of the sponge. However, the area
of choanocytes represents expenditure of energy, and the next
problem to be solved is how to retain the improved current and at the
same time to cut down expense. The first step is to change the form
of the chamber from tubular to spherical. Now the energy of all the
choanocytes is concentrated on the same small volume of water.
The area of choanocytes is less, but the end result is as good as
before. At the wide mouth of the spherical chamber there is
nevertheless still a cause of loss of energy in the form of eddies, and
it is as an obviation of these that one must regard the aphodi and
prosodi with which higher members of the Demospongiae are
provided. The correctness of this view receives support, apart from
mechanical principles, from the fact that the mass of the body of any
one of these sponges is greater relatively to the total flagellated area
than in those sponges with eurypylous chambers; that is to say, a
few aphodal and diplodal chambers are as efficient as many of the
eurypylous type.

It is manifest that the current is the bearer of the supply of food; but
it requires more care to discover (1) what is the nature of the food;
(2) by which of the cells bathed by the current the food is captured
and by which digested. The answer to the latter question has long
been sought by experimenters,[275] who supplied the living sponge
with finely powdered coloured matters, such as carmine, indigo,
charcoal, suspended in water. The results received conflicting
interpretations until it became recognised that it was essential to take
into account the length of time during which the sponge had been
fed before its tissues were subjected to microscopic examination.
Vosmaer and Pekelharing obtained the following facts: Spongilla
lacustris and Sycon ciliatum, when killed after feeding for from half
an hour to two hours with milk or carmine, contain these substances
in abundance in the bodies of the choanocytes and to a slight degree
in the deeper cells of the dermal tissue; after feeding for twenty-four
hours the proportions are reversed, and if a period of existence in
water uncharged with carmine intervenes between the long feed and
death then the chambers are completely free from carmine. These
are perhaps the most conclusive experiments yet described, and
they show that the choanocytes ingest solid particles and that the
amoeboid cells of the dermal layer receive the ingested matter from
them. In all probability it is fair to argue from these facts that solid
particles of matter suitable to form food for the sponge are similarly
dealt with by it and undergo digestion in the dermal cells.

Choanocytes are the feeding organs par excellence; but the

pinacocytes perform a small share of the function of ingestion, and in
the higher sponges where the dermal tissue has acquired a great
bulk the share is perhaps increased.

In the above experiments is implied the tacit assumption that

sponges take their food in the form of finely divided solids.
Haeckel[276] states his opinion that they feed on solid particles
derived from decaying organisms, but that possibly decaying
substances in solution may eke out their diet. Loisel, in 1898,[277]
made a new departure in the field of experiment by feeding sponges
with coloured solutions, and obtained valuable results. Thus
solutions, if presented to the sponge in a state of extreme dilution,
are subjected to choice, some being absorbed, some rejected. When
absorbed they are accumulated in vacuoles within both dermal and
gastral cells, mixed solutions are separated into their constituents
and collected into separate vacuoles. In the vacuoles the solutions
may undergo change; Congo red becomes violet, the colour which it
assumes when treated with acid, and similarly blue litmus turns red.
The contents of the vacuoles, sometimes modified, sometimes not,
are poured out into the intercellular gelatinous matrix of the dermal
layer, whence they are removed partly by amoeboid cells, partly, so
Loisel thinks, by the action of the matrix itself. It adds to the value of
these observations to learn that Loisel kept a Spongilla supplied with
filtered spring-water, to which was added the filtered juice obtained
from another crushed sponge. This Spongilla lived and budded, and
was in good health at the end of ten days.

Movement.—Sponges are capable of locomotion only in the young

stage; in the adult the only signs of movement are the exhalant
current, and in some cases movements of contraction sufficiently
marked to be visible to the naked eye. Meresjkowsky was one of the
early observers of these movements. He mentions that he stimulated
a certain corticate Monaxonid sponge by means of a needle point: a
definite response to each prick inside the oscular rim was given by
the speedy contraction of the osculum.[278]

Pigments and Spicules.—Various reasons lead one to conclude

that the spicules have some function other than that of support and
defence, probably connected with metabolism. For the spicules are
cast off, sometimes in large numbers, to be replaced rapidly by new
ones, a process for which it is difficult to find an adequate
explanation if the spicules are regarded as merely skeletal and
defensive.[279] Potts remarks upon the striking profusion with which
spicules are secreted by developing Spongillids from water in which
the percentage of silica present must have been exceedingly small.
The young sponges climbed up the strands of spicules as they
formed them, leaving the lower parts behind and adding to the upper
ends.
Of the physiology of the pigments of sponges not much is yet known:
a useful summary of facts will be found in Von Fürth's text-book.[280]

Spongin.—Von Fürth[280] points out that this term is really a

collective one, seeing that the identity of the organic skeletal
substance of all sponge species is hardly to be assumed. Spongin is
remarkable for containing iodine. The amount of iodine present in
different sponges varies widely, reaching in certain tropical species
of the Aplysinidae and Spongidae the high figure 8 to 14 per cent.
Seaweeds which are specially rich in iodine contain only 1.5 to 1.6
per cent.

In view of the fact that iodine is a specific for croup, it is of interest to

observe that the old herb doctors for many centuries recognised the
bath sponge as a cure for that disease.
 Fig. 122.—The ordinals measure (i.) the number of species, a-f, and (ii.) the
number of stations, a'-f', at which successful hauls were made. The
abscissae measure the depth: thus at I. the depth is from 0 to 50 fathoms;
at II. from 51 to 200; at III. from 201 to 1000; at IV. from 1001 upwards. a, a',
are the curves for Sponges generally; b, b', for Monaxonida; c, c', for
Hexactinellida; d, d', for Tetractinellida; e, e', for Calcarea; f, f', for Ceratosa.

Distribution in Space.—All the larger groups of Sponges are

cosmopolitan. Each group has, however, its characteristic
bathymetrical range: the facts are best displayed by means of
curves, as in Fig. 122, which is based wholly on the results obtained
by the "Challenger" Expedition. The information as to littoral species
is consequently inadequate, and we have not the data requisite for
their discussion.

Sponges generally (a) and Monaxonida in particular (b) are more

generally distributed in water of depths of 51 to 200 fathoms than in
depths of less than 50 fathoms; but localities in shallow water are
richer, for the station curve (a') rises abruptly from I. to II., while the
species curve (a) in the same region is almost horizontal.

The Hexactinellid curve (c) culminates on III., showing that the group
is characteristically deep water. That for Tetractinellida (d) reaches
its greatest height on II., i.e. between 51 and 200 fathoms. Even