Can a Biologist Fix a Radio?

From the title Can a Biologist Fix a Radio? — or, What I Learned while Studying Apoptosis(Y. Lazebnik 2004) would seem pretty off topic for LtU. It starts with a humorous take on how biologist might try to understand the workings of a radio, but it ends in a plea for (computer aided) formal languages and quantitative modeling of biological systems.

The question is how to facilitate this change, which is not exactly welcomed by many experimental biologists, to put it mildly. Learning computer programming was greatly facilitated by BASIC, a language that was not very useful to solve complex problems, but was very efficient in making one comfortable with using a computer language and demonstrating its analytical power. Similarly, a simple language that experimental scientists can use to introduce themselves to formal descriptions of biological processes would be very helpful in overcoming a fear of long forgotten mathematical symbols. Several such languages have been suggested but they are not quantitative, which limits their value. Others are designed with modeling in mind but are too new to judge as to whether they are user friendly. However, I hope that it is only a question of time before a user friendly and flexible formal language will be taught to biology students, as it is taught to engineers, as a basic requirement for their future studies. My advice to experimental biologists is to be prepared.

Further, at a meta-level, the issues he raises seem to directly mirror the challenges software developers and researchers face in trying to understand and design complex computing systems. If nothing else it's good to know we're not alone.

And it doesn't hurt at all that it's a fun read.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I was sure your plan was to

I was sure your plan was to end with a link to Luca Cardelli's Can a Systems Biologist Fix a Tamagotchi?, Cardelli being one of us PL folk.

While we are discussing biology . . .

Thanks. This looks fun.

Thanks. This looks fun.


until i get to be the maintenance programmer who has to debug the thing... :-P

Ah? I guess you mean you

Ah? I guess you mean you agree with Lamport. Right?


if only i were smart enough to be as logical as he suggests. if only all the others involved were, as well.

Ok, good. I'd have been

Ok, good. I'd have been surprised if it turned out you were saying the opposite.

So the predicament is systems that are smarter than us. It seems then, as I have been thinking all along, that what we need urgently are better ways for understanding and studying systems (including systems that are up and running; in vivo SE if you will), not only better construction methods. How's that as a suggestion for the in-the-large thread?

yes, agreed, akin to...

"no obvious bugs" vs. "obviously no bugs"


"debugging is twice as hard as writing" so you have to write it half as smartly to avoid screwing future self




Amusing articles, but the truth is that methods and tools developed in one discipline are rarely applicable in the other. A classic example is UML where the motivation was to mimic engineering methods in software design. Unlike electrical circuits, however, which is based on physics science, namely electricity and magnetism, UML lacks any foundation. There is more to revolutionizing the field than just analogy vision, otherwise the result is cargo cult.

A classic example is UML

A classic example is UML where the motivation was to mimic engineering methods in software design.

This would make sense, if not for the fact that the first page of the UML's official first book (by Rumbaugh) states completely different goals.

Well, there is no google

Well, there is no google book preview of any title by that author, so I must resort to a decade old memory of Rumbaugh's presentation of UML goals when drawing analogies to blueprints used by mechanical engineers and trying to carry over these ideas to programming.

Software engineering always

Software engineering always likes to pretend to be like grownup engineering disciplines. But that's just rhetoric. UML's roots are in the software world. And it shows.

software engineering vs. others

getting OT, and maybe more about in the large, i'd like to ask if you think there could be a version of SE today like Grownup Engineering? something that is known but is just not used, because e.g. not enough of us know Coq yet (or whatever other magic bulletish if you get abstract enough trick we need)? i mean, i presume day to day use of real math is mostly what makes for Grownup Engineering, but i'm curious if there's something else.

I've been known to argue

I've been known to argue that SE is an incoherent goal. Put simply, one argument is that software is a medium, not a category of artifacts or products. Just as there is no "concrete engineering" for buildings made using concrete, there is never going to be a SE.

Before the flames begin,let me remind everyone that this subthread is for the most part offtopic...

Before the flames begin,let

Before the flames begin,let me remind everyone that this subthread is for the most part offtopic...

That's a great way to seek the last word. ;-)

The point on SE relates well to the topic of the paper you posted: Can a Systems Biologist Fix a Tamagotchi? by Cardelli.

I'm a bit curious why you assert software is a medium. Now, if you said that a programming language is a medium (or a platform), I'd probably agree. And you could point out that developing software is very much like developing a 'program language', and I'd grant that, too. But the result of all this development is some sort of service - possibly an important, reproducible, and reusable component of another product. And components of products are products.

Besides, we have 'materials engineering' and 'chemical engineering' and 'broadcast engineering' and 'electronics engineering' and 'electrical engineering' and 'traffic engineering' and 'aerospace engineering'. There is precedent for engineering disciplines named by mediums or services.

Perhaps it is 'Engineering' that has grown incoherent...

Of course the plan was to

Of course the plan was to have the last word :-)

Saying that software is a medium is meant to reflect the enormous variety of systems whose only commonality is that they are (or include) "software". The claim is that this not enough to lead to a sound engineering discipline.

I expected the argument about things like "chemical engineering". Without going to the details of each case, my inclination is to agree that in many of these cases the term engineering is either incoherent, or the name simply reflects a set of related but distinct engineering disciplines. (We should keep in mind that we are interested in the disciplinary aspects of engineering, not with the word, hence "Sanitation Engineer" etc. do not count as counter-examples!)


Please, let's just focus on quality solutions to problems and having awareness of why other approaches are inferior. Leave taxonomy discussions out of it. I don't care if you call what you do computer science, pure mathematics, computational biology, or software engineering. I care that you can develop quality solutions to problems and explain why those solutions have qualities that other solutions would require an order of magnitude or more effort to achieve. I also care if you can generalize your results.

can you start a training franchise?

that was such a wonderful way to put it, and i want to become better able to answer that question.

Functional flow diagrams

I assume that by "magic bulletish" you mean some kind of UMLish software design methodology. Functional flow diagrams can (most likely) be put on a solid mathematical foundation using category theory. See these papers:

Incidentally, John C. Baez has been discussing categorical foundations for circuit diagrams (and generalizations such as bond graphs) in the latest issues of 'This Week's Finds in Mathematical Physics'.

Ehud, what on earth does

Ehud, what on earth does that even mean? What is a "software world"? It sounds like you are making a value judgment, based on your surrounding words.

If by "UML's roots are in the software world", you mean object technology, then absolutely. Describing systems via Characteristic functions is a really good way to model problem domains. For example, a Generalization is then guaranteed to contain all elements in a set of classes. If UML does not use either abstract data types or objects, then that would be something else altogether!

I somehow think that people who criticize visual programming somehow imagine it has a wild departure from data abstraction altogether.

As a side note, I don't really use UML drawings at work, ever. However, I think clearly in terms of objects and therefore when I design systems I can see the drawings in my head.

What is a "software

What is a "software world"?

I meant that Rumbaugh, Booch and Jacobson, and their respective methodologies, did not come from electrical engineering.

Small note

I hope I didn't sound rude above.

Anyway, a methodology is different from a notation.

The major problem with notation is that it can quickly be hijacked to mean different things to different people. Schlaer-Mellor, prior to UML, had their own ideas for executable visual specifications. Many people who adopted UML saw it as a standard for executable visual specifications. However, the three amigos (Rumbaugh, Booch, Jacobson) saw it as a way for "specifying, visualizing, and documents artifacts". Issues like round-trip engineering aren't even really mentioned, which is a testament to how advanced Real-time Object-Oriented Modeling's ideas were in the early 1990s (before UML even existed). The unverifiability of UML's semantics is a testament to how little focus on execution there was.

I also think that for asynchronous communication and incremental specification, you can't beat a visual notation. Directional text doesn't cut it. People find it too confusing. Especially for repairing "living systems" you describe. Karl Fant wrote a textbook on the subject of clockless and concurrent systems, and just about everybody on Slashdot who heard about the book via a front page article basically ripped it without even bothering to read it. Really, you don't NEED to read a 400 page book to understand the ideas. All you need is perspective. But most people are so habituated in their thinking that it really might take 400 pages, plus some training and experience, before they drop their existing habits and belief system.

Karl Fant's textbook

Does Karl Fant's book actually discuss models for concurrent systems in detail? From what I could make of the /. discussion (as well as other references to Fant's work) it is mostly a strange polemic against mathematics as a foundation for computer science. This is not a good sign, to put it mildly: there is a vast and expanding literature on the best ways to understand and express concurrent processes, but the bulk of this literature obviously relies on mathematics and the theory of computation. It's true that mathematics tends to come up short in some areas, but these tend to involve pragmatics and user interaction.

Does Karl Fant's book

Does Karl Fant's book actually discuss models for concurrent systems in detail?

Yes, but not in a deep mathematical sense e.g. such as you might see in action refinement algebra. Fant's solution is essentially monolithic in that he uses his "NULL convention logic" to provide monotonicity to all Boolean expressions; a data path and association relationships among circuits either "are-data" or "not-data". This is done to detect update even when a value doesn't change. Thus, he directly encodes behavior into the meaning function of a Boolean expression. His argument is that this allows better symbolic manipulation, akin to that of what a mathematician is used to, because it precisely defines boundaries between computational steps and does not require managing propagation delays throughout the system in order to achieve determinancy.

From what I could make of the /. discussion (as well as other references to Fant's work) it is mostly a strange polemic against mathematics as a foundation for computer science.

It definitely comes off that way, even in the book. However, his basic point is *how* you think about math as applied to process calculi is what matters, and will ultimately effect many (early) design decisions.

I am not too familiar with similar books. Milner's recent book (2009) -- I'm not done reading yet -- is good and deep in math but assumes more about the audience.

So Rational could sell CASE tools?

I've not read the book so I can't comment, but I always thought the purpose of UML was so companies like Rational could sell CASE tools.

Yes, indeed. I've been

Yes, indeed. I've been unhappy using UML design derivatives for ten years or so. Tools provided by the likes of Rational are clearly targeted at managers, rather than at developers/testers.

There's a possible Lambda discussion out there that addresses the interface between graphical representation and language. UML, RR, and the rest don't do that. Until they do, I will continue to swallow my pride and put this irritating nonsense on my CV.

Visual programming languages

the interface between graphical representation and language

Visual programming languages have been discussed here on LtU several times. The papers I linked above show how dataflow notation can be directly mapped to typed lambda calculus (or rather, its multiplicative fragment; trying to model bicartesian categories is a bit harder).

There may even be a way of using similar diagrams to reason about monads and monadic code (see Dan Piponi on Commutative Monads, Diagrams and Knots [video]), including stateful computation.

In addition, there are some specialized diagram types which can be useful in some contexts, such as state-transition diagrams, Petri nets and others.

Data design is also well understood, and graphical notations for it have been perfected. UML incorporates much of this work in its Structure diagrams, which seems to account for most of its practical utility. Unfortunately, the theoretical foundations of Object Oriented design are mostly unknown or undeveloped, so other parts of the UML spec lack a clear semantics and are only useful as a shared visual grammar for self-styled 'software architects'.

Computer Science under the Microscope

For some reason this discussion reminds me of the book Mathematics Under the Microscope. The arguement seems to be that computer science by modeling itself on algorithmetic mathematics inherits most of the issues discussed in this book.

but it ends in a plea for

but it ends in a plea for (computer aided) formal languages and quantitative modeling of biological system

This does seem to be happening. Here's a recent arxiv preprint that uses the Bio-PEPA process algebra to model a plant's circadian rhythm.

If you know the history of Radio Engineering, you laugh ...

... at his holding up that field as evidence of "goodness."

Sure *now* we have mixer, antenna, superheterodyne, and transistor as vocabulary.

However, at the turn of the century when all this silly "radio" and "vacuum tube" stuff was being figured out, the kind of crappy phenomenological descriptions the author rails against were exactly what was being published *FOR DECADES*.

This is not to say that biology doesn't need this common vocabulary. However, this vocabulary takes time to develop. It appears slowly over time.