Vegetable empire 2013

By popular demand, I have resurrected this phylogeny from my old website for Easter 2013. I have added a number of extra groups, updated the angiosperms according to APG-III, and repositioned the Gnetales according the apparently ascendent gnetifer hypothesis. The rotated titles in the table appear to work in IE9, Chrome and Safari, but YMMV.


Classification Image Description


Charophytes (stoneworts)

Chara globularis. Stoneworts (this is Chara globularis), are the closest relatives to the land plants amongst the green algae. They differ from most other green algae in growing from a well-defined meristem: the ‘bud’ at the top of a land plant’s stem.
[CC-BY-SA-3.0 Christian Fischer]


Marchantiophytes (liverworts)


Marchantia polymorpha. Thalloid liverworts like Marchantia polymorpha grow as a flattened, branching leaf-like thallus, held to the ground by rhizoids, which are similar to the root hairs of larger plants. The reproductive structures (the ‘umbrellas’ in this image) are the result of fertilisation of the liverwort by sperm from another of the same species.
[CC-BY-SA-3.0 Manfred Morgner]


Scapania aspera. Leafy liverworts like Scapenia asperalook rather more like mosses. Like other liverworts, they have no cuticle, the waxy coat on plant leaves that stop them drying out. Consequently liverworts often live in damp places, such as
greenhouses, forest floors and near streams.
[Copyright-free, image credit Hermann Schachner].

Bryophytes sensu stricto (mosses)


Core bryopsids

Bryum capillare. The majority of mosses (over 10 000 species) fall in the bryopsid group. They are small, easily overlooked, but absolutely ubiquitous. This is Bryum capillare, growing on a tombstone.
[CC-BY-2.0 ndrwfgg@Flickr]


Dawsonia superba. Some of the polytrichoid mosses, like this Dawsonia superba have water-conducting tissues similar to those in vascular plants, which allow them to grow much taller than most other mosses.
[CC-BY-SA-2.5 Velela]


Sphagnum flexuosum. Sphagnum flexuosum and related species of moss are the dominant species of vast tracts of mire and bog, and their dead bodies are a major contributor to the peat that you really shouldn’t be using to pot your houseplants.
[CC-BY-SA-2.5 James Lindsey at Ecology of Commanster]

Anthocerophytes (hornworts)

Anthoceros agrestis. The gorns of hornworts, like this Anthoceros agrestis are the diploid reproductive structures. In mosses and liverworts, most of plant you see is haploid (only has one set of chromosomes): the diploid stage (two sets like humans and most other plants) is generally small; in hornworts it is rather larger.
[CC-BY-SA-3.0 BerndH]



Clubmosses sensu stricto

Lycopodium pinifolia The true clubmosses, like this Lycopodium pinifolia look something like a stretched pinecone. Clubmosses are not mosses at all: they are actually more closely related to daisies than they are to mosses, as the cladogram on the left shows. They are fully vascular and reproduce by spores, like ferns.
[CC-BY-2.0 Alex Lomas]



Selaginella martensii watsoniana. Spikemosses, like this Selaginella martensii watsoniana,
show a beautiful fractal structure. The resurrection plant (S. lepidophyllus, withstands drying that would kill most other plants. Extinct relatives of spikemosses and clubmosses include Zosterophyllum and Sawdonia, which like these plants, lack true leaves.
[CC-BY-2.0 Alex Lomas]


Isoetes melanospora. The squashed trunks of Lepidodendron and Sigillaria are major contributors to coal, formed in coal forests during the Carboniferous period. The last remaining close relatives of these giant clubmosses are quillworts, like Isoetes melanospora. Many are endangered, but not quite as photogenic as a panda.
[CC-BY-SA-3.0 ARH12]


Ferns sensu lato


Psilotum nudum. Whiskferns have had a chequered classificatory history. For many years, the similarity of whiskferns (this is Psilotum nudum; the other main genus is Tmesepteris spp.) to the first vascular plants (Cooksonia and Rhynia) led botanists to think they were the sister group of the rest of the vascular plants. However, molecular evidence points to their being closely related to ferns.
[Copyright-free, image credit Peter Woodard]


Botrychium lunaria. The adders-tongue fern Botrychium lunaria and its allies have been traditionally classified with the rest of the ferns, but molecular evidence groups them with the whiskferns.
[CC-BY-SA-3.0 Abalg]

Equisetophytes (horsetails)

Equisetum telmateia. The horsetails (this is Equisetum telmateia) are the tiny remnants of a once hugely important plant group, which included the Carboniferous giant horsetail Calamites. The ferns and other vascular plants differ from the clubmosses in having true leaves, probably formed by webbing across small branches. One of the first plants with this feature was Trimerophyton.
[CC-BY-SA-3.0 Steve Cook]

sensu stricto


Marattia sp. Marattia is a tropical fern, one of this large group of overlooked plants. Ferns are actually very common, and although often associated with damp places, there are desert species, and one of the most successful plant species on Earth is bracken.
[CC-BY-2.0 Alex Lomas]


Asplenium bulbiferum. The ferns are the second most diverse of the three groups of vascular plants. The largest group, of some 10 000 species are the leptosporangiate ferns: this one is Asplenium bulbiferum.
[CC-BY-2.0 Alex Lomas]




Victoria amazonica. The waterlilies (this is a giant, Victoria amazonica), are sister group to most of the rest of the flowering plants, although Amborella trichopoda is currently fingered as sister to all of them. Being denigrated as the most ‘primitive’ living angiosperm is an honour previously bestowed upon Magnolia, Ceratophyllum and others.
[CC-BY-2.0 Alex Lomas]



Liriodendron tulipifera. This is Liriodendron tulipifera, a close relative of the magnolia. The evolution of the angiosperms has always been contentious: the Gondwanan tongue-ferns (Glossopteris), Pentoxylon, Caytonia and Cycadeoidea have all been touted as close relatives, but the jury is very much still out.
[CC-BY-2.0 Alex Lomas]



Arisaema ringens. The aroids, including Arisaema ringens are members of the huge and important group of monocot plants, which bear seeds with only one seed-leaf. Aroids exploit insects, which is a common strategy amongst the flowering plants.
[CC-BY-2.0 Alex Lomas]

Core monocots


Paphiopedilum cv. It’s difficult to do justice to the diversity of 300 000 species of flowering plants, but you all know what irises, daffodils, orchids (this is a Paphiopedilum cultivar), and agaves look like, so I’m trying to give more space to the things you’ve never heard of instead.
[CC-BY-2.0 Alex Lomas]



Johannesteijsmannia magnifica. The palms (e.g. Johannesteijsmannia magnifica), are an exception to the rule that monocots are herbs not trees. Monocots in general cannot make true wood: the trunk of a palm-tree cannot get thicker with age, like those of dicot trees like oaks.
[CC-BY-2.0 Alex Lomas]


Zea mays. Zea mays, an economically important grass (maize), will represent the huge commelinid clade, which includes grasses, sedges, rushes, bromeliads (pineapples), and a vast number of other important monocot plants.
[CC-BY-2.0 Alex Lomas]



Papaver orientale. The ranunculids branch deeply from the other major lineages of dicots. This is Papaver orientale, the oriental poppy; other ranuculids include the buttercups.
[CC-BY-2.0 Alex Lomas]

Core eudicots


Nepenthes cv. The caryophyllids include many of the carnivorous plants, like this Nepenthes cultivar, and all the cactuses.
[CC-BY-2.0 Alex Lomas]



Silybum marianum The campanulids are a sub-clade of the asterids, containing bellflowers, ivy, composites like daisies, and umbellifers like carrots. Many of these species have reduced flowers clumped into larger inflorescences: thistle ‘flowers’ (this is Silybum marianumare actually hundreds of tiny flowers squished into a spikey cup.
[CC-BY-2.0 Alex Lomas]


Digitalis purpurea. The lamiids are the other main group of asterids, including the economically important mint and potato families. This is Digitalis purpurea, the foxglove, source of the drug digoxin.
[CC-BY-2.0 Alex Lomas]



Ulex europaeus. Ulex europaeus, the gorse, is a member of the fabid sub-clade of the rosids. The fabids include many familiar flowering plants, such as roses, beans, apples and oaks. The rosids and asterids are the main groups of dicot plants, which are those with two seed leaves. Many of the fabids are symbiotic with nitrogen-fixing bacteria.
[CC-BY-2.0 Alex Lomas]


Citrus spp. The second main group of rosids are the malvids, which
include mallows, cabbages, Citrus fruits, and mango. I was going to illustrate this with dear old Arabidopsis, but the botantists’ fruit-fly is a little dreary-looking.
[CC-BY-2.0 Alex Lomas]




Cycas revoluta. Cycads like Cycas revoluta and the other 1 000 species of
gymnosperms (plants with ‘naked’ seeds not enclosed in  fruits) seem to be the sister group of an extinct lineage of ‘progymnosperms’, which includes Archaeopteris (one of the first trees) and other ‘seed-ferns’.
[CC-BY-2.0 Alex Lomas]


Encephalartos ferox. The other main lineage of cycads (the Zamiaceae) includes Encephalartos ferox. Like other cycads, the plants are either male or female, and look much like palms, to which they are not at all closely related.
[CC-BY-SA-3.0 Steve Cook]


Ginkgo biloba. Ginkgos are the last remaining species of maidenhair tree, a once common group. Ginkgo biloba is now only found in captivity. This one is called Fanny and lives in my parent’s garden.
[CC-BY-SA-3.0 Steve Cook]




Pinus sp. Pinus and its relatives are conifers, characterised by their cones and needle-like leaves. Many of these species are found in the northern (Laurasian) hemisphere, named after the northern continent of the Carboniferous period. The flora of Laurasia is quite distinct from…
[CC-BY-2.0 Alex Lomas]

Monkey puzzles

Araucaria araucaroides. …the flora of the southern (Gondwanan) hemisphere, including the monkey puzzle Araucaria araucaroides. The Gondwanan fauna is also quite distinct: marsupials are also found mostly in South America and Australasia.
[CC-BY-2.0 Alex Lomas]



Taxus baccata. The yews (Taxus baccata), are often found in churchyards in England. However, the trees are actually older than the churches in many cases, and are probably associated with
pre-Christian sites of pagan worship.
[CC-BY-2.0 Alex Lomas]


Sequoia sempervirens The cypresses include Sequoia sempervirens, the tallest plant on earth, and the Cupressus × leylandii, the scourge of suburban gardens.
[CC-BY-2.0 Alex Lomas]



Welwitschia mirabilis. Welwitschia mirabilis is one of the gnetophytes, a group whose placement has been contentious for decades. Morphological and molecular data conflict wildly, the currently favoured position is sister to the conifers. Welwitschia only ever grows two huge ribbon like leaves, and has cone-like flowers.
[CC-BY-2.0 Alex Lomas]


Gnetum gnemon. Gnetum gnemon is a member of the type genus of this group, the gnetophytes. Welwitschia is a desert shrub, whereas Gnetum are tropical trees and vines. All gnetophytes have an unusual double-fertilisation that is only otherwise found in angiosperms.
[CC-BY-2.0 Alex Lomas]


Ephedra sinica. Ephedra sinica is a final member of this group. The drug ephedrine, which is used as a nasal decongestant, is extracted from this grass-like herb.
[CC-BY-2.0 Alex Lomas]

Organism of the week #10 – The shapeless cock-of-the-gods

I missed last week, so this week’s is a biggun, to make up for my tardiness.

Bow down before The Shapeless Cock-of-the-Gods:

Amorphophallus titanum inflorescence [CC-BY-2.0 Alex Lomas]

Amorphophallus titanum inflorescence

Apparently, when this plant was filmed for The Private Life of Plants in 1995, David Attenborough decided to invent the term “titan arum” to avoid using the plant’s Latin (well, Greek, really) name on prime-time BBC-1:

Amorphophallus titanum

  • ἄμορφος (amorphos) = without form, shapeless
  • φαλλός (phallos) = phallus, penis, cock
  • Τιτάν (Titan) = primaeval Greek god

Coming from Croydon, euphemism has never been my strong point. The titan arum will always be the shapeless cock-of-the-gods to me.

Interestingly, the closest British relative of the cock-of-the-gods is lords-and-ladies, otherwise known as the cuckoo-pint. The “pint” here does not refer to the unit of volume, but is a contraction of the Old English word pintle, which also means phallus, penis or cock. There’s evidently something about the flowers of arum lilies that brings out the grubby little school-boy in taxonomists.

Arum maculatum [CC-BY-SA-3.0 Sannse@Wikipedia]

Arum maculatum [CC-BY-SA-3.0 Sannse@Wikipedia]

The cock-of-the-gods is rather rare – possibly even endangered – in its native Sumatra, but Kew Gardens have a number of potted cocks in the Princess of Wales Conservatory. Its leaves are no less impressive than its inflorescence. The photo below might look like a small tree, but is in fact one massive, much-subdivided leaf.

Amorphophallus titanum leaf [CC-BY-2.0 Alex Lomas]

Amorphophallus titanum leaf

The cock-of-the-gods often gets touted as the largest flower in the world. This is technically untrue: the largest flower in the word is that of the parasitic em>Rafflesia:

Rafflesia arnoldii [CC-BY-2.0 ma_suska@Wikipedia]

Rafflesia arnoldii [CC-BY-2.0 ma_suska@Wikipedia] Two things this plant shares with the cock-of-the-gods are its home (Sumatra) and its foul odour: both are pollinated by flies attracted by an odour mimicking rotting carrion

What looks like the flower of the cock-of-the-gods is really a mass of tiny flowers on a central spike (the spadix) entirely surrounded by a large colourful leaf (the spathe). The same arrangement is found in most other arum lilies, including Swiss cheese plants, skunk cabbage, and peace lilies:

Unidentified aroid [CC-BY-SA-3.0 Steve Cook]

Some arum lily or other. You can see the tiny unopened flowers on the surface of the spadix: they’re packed together so tightly they are squished into hexagons.

Kew’s potted cocks are often in flower around May. The inflorescence doesn’t last for long, and they don’t get produced every year, so if @KewGardens tweet that it’s about to flower, you’ve got about a week to see it before it collapses into a rancid sack of squelch.

Amorphophallus titanum bud [CC-BY-2.0 Alex Lomas]

Amorphophallus titanum bud

Strangely enough, the smallest flower in the world belongs to a relative of the cock-of-the-gods, a kind of duckweed called Wolffia:

Wolffia colombiana [CC-BY-2.0 Alex Lomas]

Wolffia colombiana, each barely visible speck of green in the beaker is an entire duck-weed plant

The ubiquity of duckweed and the rarity of the cock-of-the-gods is clear evidence that that it’s not size that matters, but what you do with it.

Educational RCTs

Around a decade ago I did a PGCE. Part of that PGCE involved a small-scale investigative study, from which I learnt a great deal about educational research, but not – I suspect – any of the intended learning outcomes.

I was teaching a year-7 class, whose graphing skills needed improvement. Students would often forget to give meaningful titles* to graphs. They would forget to label axes; they would join-the-dots rather than adding a line of best fit; and so on.

So I prepared a model scatter-plot crib for them to stick in the back of their exercise books, as an educational intervention. I intended telling them to compare their own graphs with it each time they drew one. But then I thought, “might it not be better if I could highlight the things they forget most often too?” So I collected four sets of data from each student before the intervention so I could tailor each crib to the individual student.

Practice makes perfect [CC-BY-SA-3.0 Steve Cook]

The generic crib would remind Zainab-Zahra about the most commonly forgotten things; the specific crib would remind Billy-Bob to put in a line of best fit. I am quite aware this crib contains unironic use of Comic Sans. The shame still burns inside like thrush.

The hassle involved in collecting and classifying their errors to prepare individual cribs was large. Was it worth it?

The obvious answer was to randomly assign the students in the class to receive either the specific crib, or the generic crib, and then to measure the change (if any) in their graphing ability on the next four graphs they plotted. If the specific crib caused a marked improvement compared to the generic crib, and – particularly – if the time I spent correcting poor graphs in the generic crib group was larger than the time I spent preparing the specific cribs, then maybe the specific crib was worth the hassle.

I was not allowed to run this trial. The reasons I was given by (some, by no means all) teachers, my PGCE tutors and (implicitly) by the educational literature made me despair:

It is unethical to give students the generic crib, because the specific crib will give an advantage to those students receiving it.

This is doubly begging the question. How can we possibly know what intervention improves their graphing without testing it? How can we possibly know whether the more student-effective intervention is also the more cost-effective?

I wanted to do this intervention in my year-7 classes, but the year-7 classes down the corridor would be receiving a completely different focus on graphing skills (or none at all!) It wasn’t as if I would leave the students in the disadvantaged group (should there even be one) high-and-dry afterwards, but the same could not be said of the students down the corridor.

You cannot measure a student’s learning by ticking off features on a graph.

Goodhart’s Law (a.k.a. the Lucas Critique, or Campbell’s Law) is the observation that if you put pressure on a surrogate measure of an outcome for regulatory purposes, the surrogate measure will lose its value as a measure of that outcome.

In educational terms, if you measure ‘educational success’ as the number of students gaining A*-to-C grade GCSEs, it is quite rational to do whatever is necessary to ensure more students get A*-to-C grades. This might mean better teaching across the board, but it could equally well mean a disproportionate focus on students heading for D’s to the detriment of those heading for E’s and A’s. The latter is a completely rational response, but the number of students getting A*-to-C grades will lose the value it once had as a measure of overall ‘educational success’.

It is quite true that reducing ‘graphing ability’ to ticking eight boxes:

  • correct placement of outcome variable on y and input variable on x
  • consistent axis scales
  • properly labelled axes
  • use of units if appropriate
  • meaningful title describing the trend
  • correct plotting
  • appropriate line of best fit, not merely a joining up of points
  • general clarity

cannot measure a student’s true ‘graphing ability’. Certainly, it is important that a student knows when a scatter-plot is appropriate (instead of a histogram or pie-chart), and that s/he grasps the point of plotting data graphically.

However, mis/labelling axes is something even my undergraduates frequently forget to do: it’s a trivial skill, but clearly one many students struggle with. A score out of eight for a graph is not going to perfectly capture ‘graphing ability’; but it is not meaningless, and the pressure to devalue ‘ticks on graph features’ as a surrogate measure of ‘graphing ability’ was already present from the tick-boxy nature of the GCSE coursework mark-schemes.

Oddly, objections I did not hear from anyone considering my proposal were:

  • The sample size would be very small (about 30). The difference in the effect size would need to be enormous to be detectable.
  • The study is unblinded: both the teacher and the students would know which group each student was in. This would introduce bias, and the students with the generic cribs might create their own specific cribs, reducing the effect-size further.

I had answers for these objections (mostly: recruit more year-7 classes to the trial), but never had to use them. The fact that a ‘small-scale investigative study’ was part of my PGCE at all indicates that unmeasurably small effects were not a overriding concern. I am still not entirely sure what the ‘small-scale investigative study’ was actually supposed to achieve, for the (school or PGCE) students, given the tiny sample size, and the reticence of all concerned to do anything mildly scientific.

In reading the comments on Ben Goldacre’s piece on The Guardian‘s website, I see the same objections being raised to the sort of RCTs currently being supported by the EEF as were raised against my modest (trivial!) proposal ten years ago. These misconceptions should be challenged.

I was not allowed to do my trial. Instead I was made to give all the students the time-intensive specific crib. This intervention was deemed a success because the students’ graphing ability improved after the intervention.

If you force a class of year-7s to draw eight graphs in eight weeks, it is almost inconceivable that they would get worse at it. This study-eviscerating flaw was not noted in the critique of my write-up for the PGCE, but the fact I had not really “reflected on my experience as a teacher” was.

Perhaps this blog post is that reflection, a decade late.


* As an aside, “A graph to show how y varies with x” is not – and has never been – meaningful. I was made to teach this junk-title template. Judging by my undergraduate’s graph titles, someone is still getting teachers to teach this junk-title template. Whoever this malign force is – please stop. Please.

Organism of the week #9 – Not even what it doesn’t seem to be

See Roridula‘s glistening leaves. See the fly suffocating in her sticky embrace. Quake at her insecticidal prowess.

Roridula gorgonias [CC-BY-SA-3.0 Steve Cook]

Roridula gorgonias at Kew Gardens

Or not. Things are not quite what they seem with Roridula. For sure, she can catch flies, but her carnivory is impotent. She cannot make the enzymes she needs to break down her prey, so they remain stuck to her leaves, and do not give up their fertilising innards to her.

Or not. Things are doubly not quite what they seem with Roridula. We cannot take her out of her natural environment, and still expect her to behave precisely as she does in the wild.

In the wild, Roridula is not alone. She has an army of helpers:

Pameridea roridulae [CC-BY-SA-3.0 Denis Barthel]

Pameridea roridulae, an assassin bug [CC-BY-SA-3.0 Denis Barthel]

 Roridula is a home to assassin bugs and spiders. She cannot digest the flies she catches, but the assassin bugs and spiders make short work of them. And they turn the flies into manure, and this is what Roridula eats. She has outsourced her digestion to her helpers, and they benefit from the protection of her glue.

Or not. Things are triply not quite what they seem with Roridula. Although the assassin bugs have the decency to (ahem) fertilise on her leaves, the spiders don’t. Worse, they even eat the assassin bugs, adding insult to injury.

The spiders are cheats, free-loading on the outsourcing arrangement between the plant and the bugs.

And this is why the word “ecology” shares the same Greek root as “economics”.

Organism of the week #8 – Brought to you by the number 5 and the letters L, S and D

If sea cumbers are an example of intelligent design, then God – sorry, an unspecified supernatural intelligence that somehow doesn’t infringe on the First Amendment – needs to lay off the acid. Echinoderms are what you get when you give evolution the number 5 and half a billion years to piss around.

Pseudocolochirus violaceus [CC-BY-2.0 Alex Lomas]

A sea apple (Pseudocolochirus violaceus) at the Monterey Bay Aquarium

You’ve simply got to love any animal that can vomit up its own bowels crap out its own gills to annoy predators.

Classes and objects

Mr Wall’s Olde Fashioned Objeckts

Caveat lector. Despite some cosmetic surgery, this post, like the previous one on writing modules, may show its age. It was originally written when Perl 5 wasn’t even 10 years old, and things have moved on substantially since then (and no, I don’t mean Perl 6). However, there’s a lot of code out there using blessed hashref objects, so before I post something about using the Moose object framework (quick-ref guide), this post will explain how to use objects, and how to hand-roll “traditional” Perl 5 hashref objects.

From a usage standpoint, a Perl object is simply a variable that contains some data, and which has some associated methods, which do something with that data when you invoke them. From a coding standpoint, a Perl object is usually just a reference to a data structure (often a hash) that has been “blessed” into a class (which is just a package), in which the methods are defined as simple subroutines.

Instantiating an object and invoking methods on it

By convention, Perl objects are created (instantiated) with a ‘class method’ called new:

my $kitty = Cat->new(); # create new object $kitty of class Cat

and then manipulated by invoking “object methods” on them, such as feed:

$kitty->feed( "Mechanically recovered meat sludge" );

If you were writing this in procedural  Perl, you might create a hashref called $kitty:

$kitty= { stomach_contents => "nothing" };

and write a function called feed():

sub feed {
    my ( $cat, $food ) = @_;
    $cat->{ 'stomach_contents' } = $food;

so you could call:

feed( $kitty, "Mechanically recovered meat sludge" );

to feed the cat.

Although the procedural program above with $kitty and sub feed works perfectly well, you have to worry about the internal structure of the $kitty, what its keys and values are, what the return value of sub feed is, and know that the cat is a hashref (not an arrayref), and so on. The same would apply to anyone else trying to write new functions for the cat such as worm and spay. Furthermore, if you had a  $puppy hashref too, which inconveniently had an attribute called last_meal rather than stomach_contents, you’d need a specific feed_dog function to avoid a name-space clash with the feed function you’ve written for the cat.


In object-oriented code, the object encapsulates all the details of what is going on, so the user of the object need not care about the $kitty‘s innards, it just need to know which button buttons (methods) are available to press.

As a user of the code anyway. If you want to write the code, you’ll have to know the guts intimately. Objects are implemented in the following way:

  • A class is just a package.
  • An object is just a reference (usually a hashref).
  • A method is just a subroutine.

Here is the start of an simple Cat class:

package Cat;
use strict;
use warnings;
# We'll fill in the gaps here presently

There’s no need to worry about exporting subroutines, as the whole point of objects is that objects look after their own subroutines (methods). Hence, no @EXPORT, etc.

Classes and objects and methods

As you may have gathered, Cat is a class, not an object. An object is a particular instance of a class. The class provides the code to instantiate new objects, so the package that defines a class needs to supply a subroutine that makes and returns new objects, i.e. a constructor that instantiates new objects. You can call this method anything you like, but it’s generally best to call it new like everyone else does:

sub new {
    my $class = shift;
    my $self = { };
    bless $self, $class;
    return $self;

This method can be called in two ways in a script:

use Cat;
my $mr_tibbles  = new Cat; # avoid
my $mrs_tibbles = Cat->new();

You should always use the latter, as the former can lead to some nasty syntactic ambiguities. The new method is just a subroutine, a factory for making objects of class Cat. When you invoke a class method, the name of the class is the first thing in the @_ of the subroutine that implements it. Similarly, when you invoke an object method, the object upon which the method is invoked is the first thing in the @_ of the subroutine that implements it. So:


will do something along the lines of calling the function new( "Cat" ) in package Cat. The new() method we wrote above therefore gets “Cat” when it it called and it shifts this into $class. So it will know what sort of an object it should make. Do not be tempted to hard-code the class, as in:

$class = "Cat"; # b0rken

because this will break should anyone want to subclass your class: if someone wants to implement a class called Tabby and borrow (‘inherit’) your new() constructor, the hard-coded new() will make objects of the wrong class (i.e. Cat, not Tabby). This is a Bad Thing.

Next, the constructor creates the data structure the object needs. This is conventionally called $self, but doesn’t have to be. This is conventionally a hashref, but doesn’t have to be.

Then comes the important bit. We know our class. We have our (empty) data structure. We need to glue these together to form an object. bless does this:

bless $self, $class;

makes the data in $self an instance of class $class.

Now the data structure has been blessed into the appropriate class, you can invoke methods upon it. Here, we invoke the object method feed to fill the cat’s stomach with nothing:


Obviously, for this to work out, we also need to define that object method in our package:

sub feed {
    my ( $self, $food ) = @_;
    $self->{ 'stomach_contents' } = $food if defined $food;
    return $self->{ 'stomach_contents' };

The constructor then returns this blessed hashref, to be captured by our user’s script in $mr_tibbles. That is all there is to constructing an object.
If you want to see what $mr_tibbles actually looks like on the inside, you can investigate him using the arrow de-referencing operator, so:

$contents = $mr_tibbles->{ 'stomach_contents' };

will get you ‘nothing’, and …

use Data::Dumper;
Dumper( $mr_tibbles );

…will spray $mr_tibbles ‘s guts out all over the screen. However, such direct dissection of object is generally considered bad form (although it is useful when debugging). The only way to investigate $mr_tibbles should be via his object methods. feed() is just such a method. You call the method with a -> (which is the same as . for most other programming languages that support object-orientation):

$mr_tibbles->feed( "Mechanically recovered meat sludge" );

The -> here is being used not to dereference a reference, but to call a method on $mr_tibbles. This dual use for -> confused the life out of me at first, but if you’re careful to note the brackets, you’ll be OK:

$thing->{ key };
    # hashref dereference, note the {}
$thing->[ index ];
    # arrayref dereference, note the []
$thing->( args );
    #coderef dereference, note the ()
$thing->method( args );
    # method call on object $thing, optional arguments in ()

The object ($mr_tibbles) upon which you invoke a method is the first item put into @_. So for the method feed, the @_ is ( $mr_tibbles, "Mechanically recovered meat sludge" ). These are assigned to $self and $food respectively. Then, if the $food is defined, it’s put into $mr_tibbles ‘s stomach with $self->{ 'stomach_contents' } = $food;

If no food is passed:

$contents = $mr_tibbles->feed();

does nothing to $mr_tibbles: the stomach contents are unchanged. However, via return $self->{ 'stomach_contents' }; the method can both alter (mutate) $mr_tibbles‘s stomach contents and just report (access) what he ate last.

The ref operator will usually return what a reference refers to (ARRAY, SCALAR, HASH, etc.), as you know. However, if we call it on an object, it will return the class the object belongs to:

ref( $mr_tibbles );

This can be useful for debugging. We will now add some more object methods:

sub vomit {
    my ( $self ) = @_;
    my $vomit = $self->feed(); # returns whatever he last ate
    $self->feed( 'nothing' );
    return $vomit;

This demonstrates that you can (and should) use methods even within the class. You could’ve written:

sub vomit {
    my ( $self ) = @_;
    my $vomit = $self->{ 'stomach_contents' };
    $self->{ 'stomach_contents'} = 'empty';
    return $vomit;

and manipulated the cat’s innards directly, but using the first version protects you from your own changes to your own code: let your methods do everything for you and it will save you a lot of grief when you decide to rearrange the innards of the cat later.

Cat class

So here is our Cat class, which we should save to a file called somewhere in the @INC path.

package Cat;
use strict;
use warnings;

sub new {
    my $class = shift;
    my $self = { };
    bless $self, $class;
    return $self;

sub feed {
    my ( $self, $food ) = @_;
    $self->{ 'stomach_contents' } = $food if defined $food;
    return $self->{ 'stomach_contents' };

sub vomit {
    my ( $self ) = @_;
    my $vomit = $self->feed();
    $self->feed( 'nothing' );
    return $vomit;



Let’s now implement a rudimentary Manx class that inherits from Cat, which we should save to a file called somewhere in the @INC path.

package Manx;
use strict;
use warnings;
use base 'Cat';

sub new {
    my $class = shift;
        # This will be 'Manx' unless this constructor itself is inherited by a subclass!
    my $self = $class->SUPER::new( @_ );
        # This will call the constructor of the Cat class, generating a Manx object,
        # but only adding the attributes of the generic Cat, as that's all the parent
        # class knows how to do
    $self->tail_type( 'stumpy' );
    $self->_secret_name( time % 2 ? 'Odette' : 'Evelyn' );
        # Now we add the Manx-specific attributes
    return $self;

sub tail_type {
    my( $self, $tail_type ) = @_;
    $self->{ 'tail_type' } = $tail_type;

sub miaow {
    my( $self ) = @_;
    print "Miaow\n";

sub _secret_name {
    my( $self, $name ) = @_;
    $self->{ '_secret_name' } = $name if defined $name;
    return $self->{ '_secret_name' };


The @ISA array takes on a special importance in classes. @ISA contains places to look if you can’t find a function in the module itself. In object oriented programming, looking somewhere else is called inheritance. The:

package Manx;
use base( 'Cat' );

is a shorthand for:

package Manx;
    our @ISA = ( 'Cat' );
    require Cat;

So when you:

use Manx;
my $tabitha = Manx->new();

you’ll get a new Manx cat that can puke and vocalise. Even though there’s no method called vomit() in package Manx$tabitha can still vomit because this method is defined in the Cat class from which it inherits: a Manx IS A Cat, and if the relevant method can’t be found in Manx, the packages in @ISA will be searched to find the method instead.

You will note that this subclass defines its own new constructor, because it wants to set the tail_type attribute at the time the object is instantiated. The proper way to do this is to call the constructor of the Manx’s superclass using the SUPER:: pseudoclass:

sub new {
    my $class = shift;
        # This will be 'Manx' unless this constructor itself is inherited by a subclass!
    my $self = $class->SUPER::new( @_ );
        # This will call the constructor of the Cat class, generating a Manx object,
        # but only adding the attributes of the generic Cat, as that's all the parent
        # class knows how to do
    $self->tail_type( 'stumpy' );
    $self->_secret_name( time % 2 ? 'Odette' : 'Evelyn' );
        # Now we add the Manx-specific attributes
    return $self;

You may also be wondering why the underscore in _secret_name. The reason for the underscore is that _hashkeys and _methods look special to C++ programmers, since they indicate that the data or method are private to the class and should not be used outside of it (i.e. they are for internal use only, and do not comprise part of the class’s API). In Perl, it’s considered bad form for a script to mess with the insides of an object (like the $self->{ 'stomach_contents' }) directly. It’s not expressly forbidden, but it is considered unforgivably bad form to mess with a private $self->{ '_secret_name' } attribute.

As you can see, there is a great deal of boilerplate here, and much that you might get wrong by accident. Consequently, I would recommend that you use an object framework such as Moose to create objects by declaration, rather than hand-rolling them as you have see here. And that’s what will be…

Next up…Moose objects and roles.

Organism of the week #7 – Bringing the kids up on junk

Another quick one this week. Life finds a way

Fulica atra nest [CC-BY-2.0 Alex Lomas]

Coot brings up its kids on junk

The neighbourhood coots build these landfill nests annually, and I’m never quite sure whether to be impressed or appalled.

Packages and writing modules

Modularisation is a virtue

The previous post showed you how to install and use other people’s modules; this post will address how to write your own.

At some point, you will probably find yourself copying-and-pasting code from one script to another. When you find yourself doing that, you should consider what would happen if it later turns out there is a bug in that pasted code. Ten copy-and-pastes down the line, you’re going to wish like hell you’d put that bit of code into a module, so you only needed to fix the bug in one place rather than ten.

  • If you ever use the same bit of code two or more times in a single script, you should probably put it in a subroutine.
  • If you ever find yourself using the same subroutine in more than one script, you should definitely put it into a module.

If you’ve not seen CPAN yet, now is a good time to do so. It’s always a good idea (if not essential!), to have a look on CPAN before you start any significant project, as the chances are, someone else will have been there before you, written the code, worried about it, debugged it, put fifteen bells and twelve whistles onto it, and released it for all and sundry to use.

Creating a module

There’re many things you can mess up if you’re writing a module from scratch, so the best way to do it, even for ‘personal’ modules you have no intention of unleashing on the world, is to use a module-building command-line utility. There are two types of these in common usage; the older is a utility called h2xs; the newer is exemplified by the module-starter utility that comes with Module::Starter.

Change to a directory you don’t mind creating a directory called MyModule in, and type:

h2xs -AXn MyModule

at the command prompt. The A and X switches create a vanilla module, not an XS C-extension (don’t ask). The n switch names your module. The equivalent for module-starter requires you to supply a little bit of extra information, which you’ll have to edit manually later if you use h2xs:

module-starter --module MyModule --author="Some One" --email=""

If all goes well, you will now have a directory called MyModule containing the files:

Makefile.PL  or  Build.PL

These files will be slightly different if you use module-starter but the same main items will be there:

  • Changes lists the changes since your previous release, i.e. none so far!
  • Makefile.PL is a script that uses the module ExtUtils::MakeMaker to create a makefile suitable for installing your module with the Unix utility make. It also details the modules and versions upon which your own module depends in the PREREQ_PM hashref. The use of ExtUtils::MakeMaker and make to install modules is on its way to deprecation: if you are planning on distributing the module, you may want to pass the additional --builder=Module::Build switch to module-starter to specifies the use of a more modern building system, such as Module::Build. This will generate a file called Build.PL (rather than Makefile.PL) in which prerequisites can be defined using the requires hashref.
  • MANIFEST is a list of the files in the distribution
  • README explains what the module does
  • t/MyModule.t is a script using the module Test::More to ensure the module works.

The most important part of the module distribution is (pm is ‘perl module’), which will contain a template something along the lines of:

package MyModule;

use 5.012001;
use strict;
use warnings;

require Exporter;
our @ISA         = qw(Exporter);
our %EXPORT_TAGS = ( 'all' => [ qw( ) ] );
our @EXPORT_OK   = ( @{ $EXPORT_TAGS{'all'} } );
our @EXPORT      = qw( );

our $VERSION = '0.01';

# Preloaded methods go here.


=head1 NAME

MyModule - Perl extension for blah blah blah


use MyModule;
blah blah blah


Stub documentation for MyModule, created by h2xs.

=head2 EXPORT

None by default.

=head1 AUTHOR

A. U. Thor, E<lt>a.u.thor@a.galaxy.far.far.awayE<gt>

=head1 SEE ALSO

Mention other useful documentation...



Let’s take this a bit at a time:

package MyModule;

The first thing that should be at the top of any module is a package statement. A package is a name-space, which is a way of letting you use the same names for variables and subroutines in different parts of a program. For example:

package Foo;
$e = "hello";
print "In package Foo, \$e is $e\n";

package Bar;
$e = "goodbye";
print "But in package Bar, \$e is $e\n";
print "You can still see \$e in package Foo if you fully qualify it...\n";
print "\$Foo::e is still $Foo::e\n";
In package Foo, $e is hello
But in package Bar, $e is goodbye
But you can still see $e in package Foo if you fully qualify it...
$Foo::e is still hello

In the same way that a command shell will assume you mean the file.ext in the current working directory, perl assumes you mean the variable called $e in the current package. The reason you’ve not seen the word package at the top of every script so far is that perl automatically assumes you are working in package main; unless you tell it otherwise explicitly. Think of main as your home package. If you want to fiddle with things from other packages, you’ll need to fully qualify their names with :: double colons, which are similar to the / delimiter in the shell. Think of package like chdir, and :: as the / path delimiter. So the package variable:


in package Foo is called:


and the subroutine:


in package Foo::Parp is called:


if you have to fully qualify them. Note in the second case that you can have sub-packages (of a sort – there is no real hierarchy here) with more than one :: double colon. The reason we create modules in new packages is that if we wrote this:

# my module
$x = "blah";

# my script
$x = "bobble";

then when we used the module, our script would overwrite the module’s definition of $x, because they would share the same namespace. When you create modules, you create a new namespace where you can make and manipulate variables to your heart’s content without having to worry about trashing other people’s variables and subroutines of the same name in other packages. Note that lexical my variables don’t suffer from this problem, which is another reason to use strict.

That’s pretty largely all there is to packages. You can define several in one file, or spread one over several files, but the ‘natural’ size of one package is one file, i.e. if you create a file called, it should generally contain the package MyModule.


The next few lines specify the version of perl you’re using and turn on some sensible restrictions:

use 5.012001;
use strict;
use warnings;

use 5.012001; means ‘die if the version of perl you’re running is less than 5.012001′. This is particularly important if you’re using something new, like say or given/when, that old versions of perl don’t support. use strict; use warnings; is something you ought to have been doing for a while now. If you hadn’t realised, every time you’ve written use strict; or use ANYTHING; at the top of a script, you’ve been using other people’s modules. Modules written with lowercase names like strict are called pragmata or pragma modules: they generally affect how perl deals with your script itself, rather than giving you extra functionality.

Exporting functions


require Exporter;

Now we get into the slightly more complex stuff. Exporter is simply a module that helps exports symbols, particularly subroutines, from one package to another. require is very similar to use in that it loads in the contents of a module, so that you have access to its functions from your scripts.

A difference between require and use is that require doesn’t import any functions into your package. If you were writing a script (which by default would define itself in package main), and you wanted to use the function parse() from package MyModule, you have two ways of doing it. You can require MyModule; and then call the function with ‘fully qualified’ names (the :: double colon syntax):

# we're in package main if we don't say we're not
require MyModule;
my ( @parsed ) = MyModule::parse( @things_to_parse );

Alternatively, you can use MyModule; which (if suitably set up) will automatically export the function parse() from package MyModule into package main (or wherever you’re working), so you can use it more easily:

# use exports the functions from package MyModule to package main
use MyModule;
my ( @parsed ) = parse( @things_to_parse );

without any need to fully qualify the function name. When you require Exporter; you are asking perl to read in the Exporter module, but not to import any functions from it. As we don’t actually want to import functions from the Exporter module, we require, not use it.

The other thing about use its that it does its thing at compile-time, rather than at run-time: this means that when your script is compiled by perl, it will check to see if you have all the requisite modules before executing anything, and if you don’t have them all, it will die. require doesn’t do this compile-time checking.

use MyModule; is exactly equivalent to:

BEGIN { require MyModule; import( MyModule ) }

where BEGIN{} is a special block that is automatically called by perl when it starts: it makes things happen at the very beginning of compiling a script.

import() is just a subroutine in the file that tells perl which functions to import into the caller’s namespace (i.e. the package, probably main, that the script use-ing the module is working in).

Now it’s all very well saying perl will import functions from one package to another, but where does it ‘physically’ look for these packages in the first place? When you create a module, you need to save it somewhere it can be found:

print "$_\n" foreach @INC;

will list the places in your computer’s file-system that are searched for modules in. @INC is therefore rather like the PATH environmental variable but for modules. You’ll notice that ".", the current working directory (CWD), is one of the places on this list. So if you put in your CWD, it will be found and used when a script says use MyModule;. What about that Package::Subpackage business? If you create a directory called MyModule in the CWD (say D:/flapdoodle/), then create a file called, perl would look for the package MyModule::Subpackage in D:/flapdoodle/MyModule/

Writing a simple module, which contains some utility subroutines that are to be used by several scripts, is simple a matter of writing those subroutines , and then writing another subroutine called import that exports these functions from one package to another.

The latter is a simple matter of setting a typeglob in the caller’s symbol table to a reference to the subroutine you wish to export.

Erm, yeah. Almost no-one rolls their own import function. Almost everyone just borrows the one in Exporter, which is what:

our @ISA = qw( Exporter );

is for. @ISA (that’s @rray ‘is a’) is where you can put the names of modules that you want  perl to search in, to find functions you can’t be bothered to define. So, if you can’t be bothered to define import() yourself, you can tell  perl to look for this function in instead, hence:

our @ISA = qw( Exporter );
# MyModule IS A Exporter
# It inherits functions that I can't be bothered to define from Exporter

So now, when a script use-s MyModule, it will use the import() method from the Exporter module to furnish the script with whatever functions you chose to export from

Global variables

The final bit to understand here is the our which is – as you may have guessed – related to my. When you use strict; all variables have to be nailed down to a particular lexical scope with my, and will disappear from the symbol table, making them inaccessible from other scopes and packages. However, what happens if you do want someone to be able to see the value of a variable in your module? For example, in the module File::Find, the variable $dir contains the current directory being processed, which is a useful bit of information for scripts using the module. But if you make $dir a lexically scoped my variable, it will be invisible outside of the scope in which it is created. For modules, this means invisible outside of the module itself.

This is what our is for. our explicitly allows you to share global variables, which is exactly what strict doesn’t usually allow. our allows you to circumvent strict for variables you really do want to be accessible from anywhere using the $Package::variable or @MyModule::ISA notation. Since @ISA needs to be visible outside the scope in which it is defined (Exporter uses it), we must our it, not my it.

Defining an interface

That’s the worst bit over. The rest of it is just defining the interface:

our %EXPORT_TAGS = ( 'all' => [ qw( ) ] );
our @EXPORT_OK   = ( @{ $EXPORT_TAGS{'all'} } );
our @EXPORT      = qw( );
our $VERSION     = '0.01';

$VERSION is obvious. Like use 5.012001; you can also use MyModule 0.02; This makes your script die if the version of MyModule you have is older than the version you want to use.

@EXPORT is the easiest way of exporting functions. If your module contained three functions sublime(), boil() and melt(), and you wanted to export all of them to the caller’s namespace:

our @EXPORT = qw( sublime boil melt );

would do just that. However, people usually prefer to selectively import functions, and the use of @EXPORT is discouraged unless your module is just one or two functions (like File::Find or File::Path). This is what @EXPORT_OK is for. If you wanted people to be able to import these three functions selectively, you could do this:

our @EXPORT_OK = qw( sublime boil melt );

Then users of your module could:

use MyModule "sublime", "boil";  # or
use MyModule qw( sublime boil ); # avoid all those quotes

if they had no interest in importing the melt() function and polluting their namespace.

Finally, %EXPORT_TAGS allows you to define groups of functions to export. Say you want people to be able to import your three functions as a lump without having to go to all the trouble of writing three whole things:

use MyModule qw( sublime boil melt );

you can create an export tag called all, which contains all three functions. %EXPORT_TAGS is just a hash of key/value pairs. The keys are the names of the tags you want to define, and the values are an arrayref of the functions you want to dump in the tag:

our %EXPORT_TAGS = ( 'all' => [ qw( sublime boil melt ) ]   ); # or
our %EXPORT_TAGS = ( 'all' => [ "sublime", "boil", "melt" ] );

With this defined, you can:

use MyModule qw( :all );

and Exporter will conveniently translate the tag :all into the list of three functions you have defined with the all key in the %EXPORT_TAGS hash. If you do define an :all tag, which is good practice, you can then use it in @EXPORT_OK:

our @EXPORT_OK = ( @{ $EXPORT_TAGS{'all'} } );

Finally, after all the package, exportation and global variables nonsense, we finally get onto the non-boilerplate stuff:

# Preloaded methods go here.

This bit is just a program. Go write it in the space # Preloaded methods go here. Mostly, you’ll only be defining subroutines here, since these are what you usually want to export. The 1; is needed because all modules have to return TRUE when they load: this ensures they do. The __END__ token is a signal to perl to stop parsing, since after this comes the documentation for the module, and this is of interest only to perldoc, not to perl itself.

Documentation with POD

Talking of which:

=head1 NAME

MyModule - Perl extension for blah blah blah


use MyModule;
blah blah blah


Stub documentation for MyModule, created by h2xs.

=head2 EXPORT

None by default.

=head1 AUTHOR

A. U. Thor, E<lt>a.u.thor@a.galaxy.far.far.awayE<gt>

=head1 SEE ALSO

Mention other useful documentation...


Perl documentation is written in POD (plain old documentation) format, which is a markup language like HTML, but simpler. perldoc can read and display the POD embedded in a module, which makes it the perfect tool for documenting your module so you don’t forget how it works, and so others can use it without getting up close and personal with the source code. Things starting = are processing directives. I think you can guess what head1 and head2 do. =cut is the signal for the end of the POD. Some other useful directives are:

=over 4



=over indents the text by some amount (here 4 spaces), and =back restores the indent to 0. You’ll notice that if you want a newline in your POD, you need a blank line: POD is otherwise newline-insensitive.

=item * function()

is used to create itemised lists, with a pretty * as a bullet point. Like HTML, POD uses angle brackets to mark up certain bits of text, but unlike HTML/XML (with its <open-tag> </close-tag> syntax), the thing you want to italicise, or whatever, goes inside the brackets:


will put text in italics. B<text> does bold, C<blah> does code, L<foobar> does links (L<perl> links to the perl manpages), and E<> does escapes like E<lt> and E<gt> for < and >. Documenting your code is essential if you want people to use it: don’t fall into the trap of assuming a) everyone’s stupid and you’re going to let them wallow in it or b) everyone will know how to use your code by osmosing it in. If you have a memory like mine, you won’t remember how to use your own scripts in six month’s time, so write the documentation now, so you don’t have to labouriously re-learn your own code later. The easiest way to learn POD documentation is to use perldoc to read some prettily formatted, then look at the module itself to see what it looks like in code.

So, here’s the inevitable hello world module. I think this should all be very obvious (srand seeds a random number generator, rand(NUMBER) generates a random number between 0 and NUMBER, and ||= is an assignment operator for ||, which is an idiom for ‘default’: A ||= B is the shorthand for A = A || B, which means ‘A equals B unless A already equals something other than 0 or undef‘):

package Hello;
use 5.012001;
use strict;
use warnings;
require Exporter;
our @ISA = qw( Exporter );
our @EXPORT = qw( hello ); # no need for :tags, only one function!
our $VERSION = '0.01';
sub hello {
    my $name = shift;
    $name ||= "you";
    my $message = rand(1) > 0.5 ? "a waste of time" : "a lot of fun";
    return "Hello, $name, isn't this $message?\n";

=head1 NAME

Hello - Perl extension for printing a stupid message      

  use Hello;
  $msg = hello( "Steve" );
  print $msg;


Stub documentation for MyModule, created by h2xs. It looks like the author 
of the module took careful note of the importance of documentation, 
and here it is:


=item * hello( $arg )

=over 4

Randomly prints one of two stupid message for $arg, which should be a name,
but will default to 'you'.


=head1 AUTHOR

Steve Cook

=head1 SEE ALSO



Then all we need to do is save the module in the root of one of the directories in @INC (i.e. the CWD, or similar) and:

use strict;
use warnings;
use Hello;
hello( "Perl novice" );

Next up…classes and objects


Love my new Dalek t-shirt:

Dalek chromatic t-shirt [by J. William Grantham]

This is also relevant to my interests.

Organism of the week # 6 – Enigmata of the Gnetales

Three for the price of one this week.

Most seed-bearing plants fall into one of two main groups: the flowering plants (grasses and magnolias and butterworts and so on), or the conifers (pines and yews and monkey-puzzles and so on). However, there are three smaller groups of seed-bearing plants that don’t fit into this neat division: the cycads, the ginkgo, and an enigmatic group of plants that are sufficiently obscure they haven’t attracted a nice englishified name, so we shall have to stick with calling them the “Gnetales”.

The member of the Gnetales you’re most likely to have heard of is Ephedra, if only because it gives its name to the drug ephedrine, a decongestant used as a precursor to the illegal synthesis of methamphetamine. Outwardly, it’s a rather nondescript shrub, despite its stimulating interior:

Ephedra sp. [CC-BY-2.0 Alex Lomas]

Ephedra sp. I think this was taken at Kew.

Rather more impressive than Ephedra is the genus that gives its name to the Gnetales, Gnetum.

That’s pronounced “Ngnehtum” not “Neetum”. Latin names should – of course – be pronounced as if they were being announced by Cicero, rather than in the bastardised dialect of the mediaeval Church.

And breathe.

Most species of Gnetum are vines (lianas), but Gnetum gnemon is a rather attractive tree:

Gnetum gnemon [CC-BY-.2.0 Alex Lomas]

Gnetum gnemon. Taken at Edinburgh botanical gardens.

The third and final member of this group is arguably the weirdest-looking plant on earth, which – gratifyingly – also has one of the weirdest names: the miraculous Welwitschia. It looks like the stump of a tree, and produces little red cones that look something like those of a pine tree, but there the outward similarity ends. It only ever produces two continuously-growing long strap-like leaves, which – in the Namib desert where it lives – usually shred into ribbons, giving it the most dishevelled appearance. It is the plant equivalent of the animals on WTF, Evolution? and therefore has a special place in my heart.

Welwitschia mirabilis [CC-BY-2.0 Alex Lomas]

Welwitschia mirabilis. Amsterdam botanical gardens, I think.  It appears my poor husband has been made to march around botanical gardens in half the capital cities of Europe. Pity him.

Quite how these three plants slot into the rest of the plant family tree is not well understood. At various times they’ve been proposed as the sister group of the flowering plants, as the sister group of conifers as a whole, and – despite their very un-pine-like form – as more closely related to pine trees than pine trees are to monkey-puzzles. With the ever increasing amount of molecular data on plant relationships, the question will probably be settled soon one way or another. I shouldn’t get all mystical, but it does seem a pity that soon we’ll be pinning these enigmata down. Ah well. Progress marches on. But the correct plural of a third-declension Greek noun with an -a(t) stem shall remain -ata forever.

Load more