GNOME Platform Stormclouds [LWN.net]

GNOME Platform Stormclouds

Posted Mar 25, 2004 16:38 UTC (Thu) by mly (guest, #2171)
Parent article: GNOME Platform Stormclouds

I'm not involved in GNOME development, and I certainly feel that those who are must solve this in a way that they are happy with. I'm sure there are a number of Python programmers involved in GNOME who understand much more about the pros and cons of using Python in that particular context better than I do, maybe it's obvious that it can't be used, but I'm really surprised to find the lack of static typing to be an argument against Python. Sure, I misspell things in Python and get name errors, but they typically surface quicker than they would in C, and I mistype less in Python since I type less in Python.

It obviously depends on what kind of code I'm writing, and in what stage of development I'm in, but I think that I generally have an edit - test cycle in Python which is much shorter than my edit - compile cycle in C, and much, much shorter than the edit - compile - link - test cycle in C. The reason for this is that you typically have to write five or ten times more in C than in Python to achieve the same result. Testing as often in C as I do in Python would be impossible, particularly in a large system: I've been involved in C++ projects where an application took an hour to build... In Python, this is not an issue at all.

In general I think Guido van Rossum has been very successful in creating a language which is helpful to the programmer in a positive way, making it easy to do things right, rather than trying to make it hard to do bad things. In C, you must often do potentially dangerous things such as playing with pointers and type casting, because the safer way of working is too limited. There are also a number of well known gotchas in C syntax that have been solved in Python, e.g. "if x = 0" is a SyntaxError in Python.

You may be wondering why languages such as Python, Perl or Ruby aren't in consideration here. Havoc's paper doesn't do much to explain why languages such as these won't be used for writing system components, because the audience that he wrote it for probably take that as a given.

Might this possibly be a mistake?

Dave Camp's one-liner in this blog post probably explains the thoughs of most developers on this issue: I have a soft spot in my heart for Python (although I have a softer spot for static type checking).

I think this is mainly a matter of getting used to another way of programming. This might be a hurdle in itself, but it's maybe more a learning issue than a technical issue. Besides, there are tools such as PyChecker and PyLint that can take the role of the compiler. It's my impression after many years of using both C and Python that Python programs typically contain much fewer bugs than C programs, and that it's far easier to find and correct them.

Automated testing can address some of these issues, but a certain type of C programmer might have trouble sleeping at night after shipping a large Python application, with the expectation of receiving bug reports containing NameErrors.

I think most programmers sleep even worse when they have shipped C applications, with the expectation of receiving bug reports containing core dumps--and maybe even worse: security holes due to buffer overflows etc. There aren't a lot of reliable studies on the subject, but I've never seen any study suggesting that C programs contain less bugs than Python programs. I've seen some study that suggest the opposite. The problem with Python is not that Python programs are so buggy. Not at all.

Python certainly doesn't fit in all situations, but for a system like GNOME, I think the reliance on an external interpreter and the inability to build native machine code executables seem like small problems. Making source code or easilly decompiled byte code available to end users doesn't seem to be a problem in GNOME either. Considering the wide use of Python in the Linux community, and how easy it is to learn, I don't think that lack of skilled python programmers or lack of "support" are issues either.

The only non-religious problem I see with adapting something like Python for GNOME is performance. If Moore's law and novelties such as pyrex and psyco doesn't fix this, Python has always been able to cooperate nicely with C++ and C... That should also be helpful in a transition period. But I guess it's still possible that performance issues in Python would be a real problem for GNOME. I appreciate that performance is a big issue in GNOME.

Of course, if we'd switch from C to Python to get rid of C's problems with memory management etc, and end up writing parts in C anyway for performance reasons, you might feel that little is gained, but typically, the bottlenecks in programs are small. Instead of 10000 lines of C code for a particular program, you might end up with 2000 lines of Python and 500 lines of C. It's much easier to maintain 2500 lines than 10000, and all the risks of C, with memory leaks etc are roughly reduced by 95% if there is 95% less C code.

Perhaps a two language solution with Python and C is the easiest way to go forward from where GNOME stands today?

Maybe Java has improved a lot since I last looked at it, but it certainly used to be a major resource hog, and Java applications that I run regularly in Windows, such as IBM's DB2 ControlCenter are so slow and memory hungry that they are almost useless.

My experience is that Python programs are significantly shorter than Java programs, and much shorter than C programs, and at the same time clearer and easier to understand. A large part of the code that I would write myself in C, is already written by someone smarter in well tested C if I use Python. In a way, writing Python can be seen as a very clever way of reusing well written and tested C code. (After all, the classic Python implementation was started almost 15 years ago, and it's certainly not been allowed to rot.)

Somehow...I have problems envisioning something that Microsoft came up with as a solution for GNOME... I'm really ignorant on the issue, but I somehow suspect that C# for Linux might backfire in a nasty way. I'd just wait for some Microsoft C# patent to emerge as GNOME had turned into a real Windows contender. Of all aspects of Linux, it's the rise of a more polished desktop "experience" that is most likely to have an impact on Windows users. I'm sure MS would do everything in their power to stop Windows from being replaced by GNOME/Linux as the leading desktop OS, and Bill Gates have explained publically that he'll use the legal system to go after Linux if he can, and he's doing it right now by funding Caldera/SCO. Don't think it'll stop there. No, I don't think Mono will make the programmer sleep any better. :(

If you really think you need static typing and memory management, you should perhaps look at Eiffel or OCaml? Although I guess OCaml's inferred typing won't stop you from mistyping a variable name...

(Log in to post comments)

GNOME Platform Stormclouds

Posted Mar 25, 2004 17:21 UTC (Thu) by tjc (subscriber, #137) [Link]

I'm really surprised to find the lack of static typing to be an argument against Python. Sure, I misspell things in Python and get name errors, but they typically surface quicker than they would in C [snip]

They show up at compile time in C, which is as fast as it gets!

I think this is mainly a matter of getting used to another way of programming.

I never have gotten used to it. I've written a fair amount of code in both PHP and Tcl, and the lack of static type checking is a language "feature" that keeps on taking. Since my spelling is unlikely to improve significantly, I appreciate a language that points out my mistakes immediately rather than producing unexpected results at runtime.

GNOME Platform Stormclouds

Posted Mar 25, 2004 18:44 UTC (Thu) by mly (guest, #2171) [Link]

tjc wrote:
> They show up at compile time in C, which is as fast as it gets!

No it's not! Honestly! For my normal programming, I run my python programs more often than I compile my C or C++ programs during development. I typically write very modular code and change it in small steps, testing it often so that I notice whatever bugs I introduce as soon as I can. Of course, only a fraction of these bugs would have been caught by the compiler anyway.

I haven't programmed so much C or C++ lately, but even if I try to use short cycles there as well, they will still be longer, since I need to type so much more in these languages to produce the same amount of functionality.

But if you like the support of the compiler in C, just use PyChecker as your Python "compiler". I would still suggest proper unit tests though. Python has good unit test support in the standard library, and no compiler or code checker can replace real tests.

> I've written a fair amount of code in both PHP and Tcl

I don't think you can draw too many conclusions about Python from Tcl or PHP. That's a bit like deciding what to think about C based on experience from COBOL.

Strange as it may sound, I mistype much more in C or C++ than in Python. There are several reasons for that. One is naturally that there will be fewer mistypings if there is less typing. Another aspect is that Python's syntax is very simple and consistent. I don't have to remember so much, and
since the code typically looks clean and regular, I'm more likely to directly spot mistakes. Python fits my brain. My little experience of Tcl and PHP suggests that they don't offer the same benefits. I'll quote what Eric Raymond said about his first experiments with Python in Linux Journal:

I noticed (allowing for pauses needed to look up new features in Programming Python) I was generating working code nearly as fast as I could type. When I realized this, I was quite startled. ... it generally means you've achieved mastery of the language. But that didn't make sense, because it was still day one ...

This was my first clue that, in Python, I was actually dealing with an exceptionally good design. Most languages have so much friction and awkwardness built into their design that you learn most of their feature set long before your misstep rate drops anywhere near zero. Python was the first general-purpose language I'd ever used that reversed this process.

Pinched from http://www.linuxjournal.com/article.php?sid=3882

GNOME Platform Stormclouds

Posted Mar 25, 2004 20:25 UTC (Thu) by tjc (subscriber, #137) [Link]

I don't think you can draw too many conclusions about Python from Tcl or PHP.

All three lack static type checking, which is the *only* thing I was comparing with C. I'd probably have more to say about Python, but I've never had a contract that required it, and C is the only thing I use on my own time.

GNOME Platform Stormclouds

Posted Mar 26, 2004 18:08 UTC (Fri) by maney (subscriber, #12630) [Link]

All three lack static type checking, which is the *only* thing I was comparing with C.

Right, and that's why it's a useless comparison. There's a great deal more that differs among the four languages, and assuming that your experience with PHP and TCL are reliable guides to what Python is like is a bad assumption. I haven't used TCL, but I have worked with PHP at some length - indeed, I worked with it until it seemed to be unable to support the application, which was why I switched to Python. Nor was that the biased reaction of a fan of X who proves that Y isn't much good and finds reverting to X clearly better, as I had had nothing but superficial exposure to either language before beginning. And so I made the mistake of taking at face value all the hype that was going around then (still is, I guess) about how PHP is such a wonderful language for web apps with database backends. Maybe for Joe Hacker's Own CD Catalog it actually is; for the middling complex scheduling app I was working on it made some early, stripped down versions easy, but the cost rose quickly as I tried to add meat to those bones.

Rather more that 20 years after my first chance to use C (anyone else remember BDS C for CP/M?), I find that there are languages that work differently than C (or C++, which in some important ways is just a false front hung in front of C to disguise it), and for these languages the static type checking that is so essential in C - because the static checking, limited as it is, is the only sanity check you get - is simply irrelevant. I know I won't convince you: this is something that everyone has to learn for themselves. At least that has been my experience.

GNOME Platform Stormclouds

Posted Mar 26, 2004 22:57 UTC (Fri) by tjc (subscriber, #137) [Link]

All three lack static type checking, which is the *only* thing I was comparing with C.

Right, and that's why it's a useless comparison.

It was a useful comparison for my purposes, since I was able to determine from an early stage that quite of few languages would not be very useful to me. This is a lot better than spending a great deal of time learning a new language and then finding out further down the road that it's not going to work very well for a particular purpose or project.

GNOME Platform Stormclouds

Posted Mar 25, 2004 18:52 UTC (Thu) by angdraug (subscriber, #7487) [Link]

Unlike Ruby and Python, PHP and Tcl are not mentioned in the context of "making it easy to do things right", and there is a reason to that: they don't.

GNOME Platform Stormclouds

Posted Mar 25, 2004 20:34 UTC (Thu) by tjc (subscriber, #137) [Link]

My experience with Tcl is restricted to Vignette V/5, one of the most unproductive development environments that I've had the displeasure of using, so in this case I agree with you. Tcl on its own may be a much better experience.

I have little bad to say about PHP -- I like it better than Perl for server-side scripting. I've never used Python, other than working through the O'Reilly book a couple years ago to see what it was about. It seemed ok.

GNOME Platform Stormclouds

Posted Mar 27, 2004 7:42 UTC (Sat) by Cato (subscriber, #7643) [Link]

For (some) static checking in a dynamic language, try Perl - most code is written with 'use strict', which catches variable name typos although the type checking is still done at run time.

Or you can just use OCaml (Objective Caml), which is garbage collected and dynamic like Perl/PHP/Tcl/Ruby/Python, but also has strong inference-based type checking (somewhat like C/C++/Pascal, except that you never have to declare types - it just infers all types, working up from the constants and operators). OCaml is almost unique in having the ease of programming of a dynamic byte-code interpreted language (a la Perl) and the option to compile to truly efficient machine code (which is sometimes faster than C, due to more optimisation enabled by stronger type checking, see link above for details). Well worth a look.

GNOME Platform Stormclouds

Posted Mar 27, 2004 10:30 UTC (Sat) by mly (guest, #2171) [Link]

Or you can just use OCaml (Objective Caml), which is garbage collected and dynamic like Perl/PHP/Tcl/Ruby/Python, but also has strong inference-based type checking...

I realize that this helps improve performance, but does it prevent spelling errors?

GNOME Platform Stormclouds

Posted Mar 28, 2004 6:40 UTC (Sun) by Cato (subscriber, #7643) [Link]

Yes, OCaml prevents spelling mistakes in variable names and any type mis-matches, just like C/C++ type checking. In addition, it can also catch more subtle errors - my OCaml page (see original post) has a link to an example where a similar language's compiler detected an infinite loop at compile time

GNOME Platform Stormclouds

Posted Mar 25, 2004 18:59 UTC (Thu) by NAR (subscriber, #1313) [Link]

I generally have an edit - test cycle in Python which is much shorter than my edit - compile cycle in C

I generally have the opposite situation - the test runs slow (because the program communicates with a remote computer which I don't have any control over so I can't make it faster) but the C++ compilation is fast (it doesn't take that long to compile a file and link an executable). In this case it's really a pain in the a** if I mistyped a variable name in the last few statements of the Python code... This is the kind of error that could be found at compile time - I see no reason why we couldn't find it. The -c option of perl is really useful for this situation.

Bye,NAR

GNOME Platform Stormclouds

Posted Mar 25, 2004 19:56 UTC (Thu) by mly (guest, #2171) [Link]

> I generally have the opposite situation - the test runs slow
> (because the program communicates with a remote computer which
> I don't have any control over so I can't make it faster) but
> the C++ compilation is fast

This will probably not be an issue very often in GNOME, but you
are certainly right that running the complete program might
be slow. Nowadays I often write programs that access databases,
and I can tell you that accessing DB2 system tables on IBM
mainframes isn't very fast...

A solution to this is to either use proper unit tests for each
class, as prescribed by extreme programming, or to just make
a stub for the communication. I don't know what your program
does, but assuming that you will follow different paths in your
program depending on what data you recieve through your
communication, you could make a stub that will replace the actual
communication with test data that will cause your all of the
paths of your program to be explored. Perhaps you can make some
command line switch, or just a global variable TEST that will
let you read a file instead of reading from a socket. Then you
can just put yor test data in a file.

As I said, PyChecker or PyLint can also find many errors, but
test driven development can be particularly useful. When your
application gets big, you will be much less worried about
changing code if you can test each class and module separately.

Writing the tests first a la XP is both good as an exercise in
trying to flesh out in a proper and interface focused way what
the various parts of the program does, and you also get examples
of how each class and method can be used. In that way, the tests
become useful documentation. Always writing the tests first also
assures that the tests actually get written, and that you get a
good regression test suite.

GNOME Platform Stormclouds

Posted Mar 26, 2004 6:56 UTC (Fri) by bronson (subscriber, #4806) [Link]

"A solution to this is to either use proper unit tests for each
class, as prescribed by extreme programming, or to just make
a stub for the communication..."

or, just use a statically typed language. Languages are tools: use the right one for the job. mly, don't you think you're laying on the Python advocacy awfully thick?

GNOME Platform Stormclouds

Posted Mar 26, 2004 13:36 UTC (Fri) by mly (guest, #2171) [Link]

> or, just use a statically typed language. Languages are tools:
> use the right one for the job. mly, don't you think you're
> laying on the Python advocacy awfully thick?

I agree that we seem to have left the subject of GNOME rather far behind. :)

I'll just summarize and then I'll try to stay away from this thred. I hope you will see my point.

* Static typing is not a full substitue for tests. The compiler will only find particular types of errors. Never logical errors.

* Whether we use a language with static or dynamic typing, we *should* write automated unit tests when we develop systems of significant size. Automated regression tests are important for the long term maintenance of any software project.

* Proper unit tests will find all errors that the compiler would. If your unit tests fail to find typing errors in your code, you either have dead code that you should remove, or incomplete tests. This is not because you write extra tests to find spelling errors, but because spelling errors you make will have an effect on the actual function of the code, which you should test.

* With an appropriate language (such as Python) and good working habits, the code/test cycle is typically faster than the code/compile cycle in e.g. Java or C.

While this might sound good in theory, I won't deny that there are problems involved. It might be difficult to maintain a large set of tests if requirements change, and some things, such as GUIs (which are certainly relevant in the case of GNOME :) aren't always easy to unit test in an automated way with current free tools.

I think the solution to this is to make the tools and methods for testing even better, not to go back to old fashioned languages where you have to write several times more code than you need with a modern language.

GNOME Platform Stormclouds

Posted Mar 28, 2004 18:18 UTC (Sun) by bronson (subscriber, #4806) [Link]

Writing a comprehensive set of unit tests is realistic only for easily-definable portions of your program. Think of the amount of code required to fully test, say, a web browser. It would take years to write and you could never hope to make it complete. The problem space is just too complex. Unit tests are excellent, but they can't be applied universally.

"...not to go back to old fashioned languages where you have to write several times more code than you need with a modern language."

And yet you advocate writing comprehensive volumes of unit tests? Even if your surprising claim of "several times more code" were true, given the length of each of your replies to this story, I'm surprised that you should be so afraid of a few more keystrokes. :-)

mly, have you ever released a project that demonstrates your approach to unit testing? I'd like very much to see an example of what you advocate. For comparison, I wrote unit tests into Trestlemail 4 years ago. It took a very long time to write and debug those 150 tests, yet they were hopelessly insufficient. And Trestlemail has a simple problem space.

GNOME Platform Stormclouds

Posted Mar 28, 2004 22:57 UTC (Sun) by mly (guest, #2171) [Link]

Writing a comprehensive set of unit tests is realistic only for easily-definable portions of your program.

I've used the term Unit Test the way it's been used in Extreme Programming. These tests are not complete functional tests for the program in question. They test small units (typically classes) in isolation. Their aim is to assert that a piece of code does what the programmer inteded. They are rarely functionally complete, but often exercise every line of the unit under test, and then they will find everything that the compiler would, and many other things. See http://www.c2.com/cgi/wiki?ProgrammerTest

Functional testing on a system level is an interesting subject, but it has nothing to do with static typing or the lack thereof.

Even if your surprising claim of "several times more code" were true...

Is that controversial? Just a few examples:

Glyph Lefkowitz rewrote Twisted in Python and went from 20000 lines to 3000 lines.
Greg Stein reported that rewriting eShop in Python led to 90% fewer lines than C++.
Bruce Eckel, author of Thinking in C++ and Thinking in Java reports a tenfold productivity gain with Python.

I'm sure there are many situations where the improvement is much smaller, the study by Prechelt I referred to before had smaller differences, but it showed more than 50% reduction in lines of code and developer time, as well as fewer bugs.

...given the length of each of your replies to this story...

I wish I was able to explain things more briefly. It's not a skill I have I'm afraid. :( It impresses me when people can get the same message through in 50 words that I need 250 for, but at least I can do that stunt in code! :)

...I'm surprised that you should be so afraid of a few more keystrokes.

Fewer lines of code means fewer bugs. Many studies verify this.
Fewer lines of code means that it's easier to understand the program.
Fewer lines of code means shorter development time. This has also been verified many times. Less time spent coding means more time to test, rewrite bad parts and relax. I.e. better program, happier programmer.

All this naturally assumes that the fewer lines of code comes from using a language which lets you use a higher level of abstraction (or from finding a simpler solution to your problem). Every seasoned C or C++ programmer knows that squeezing too much code into one line will make debugging much harder, and that it's better to use a few lines more. That might make it hard to think that another language will allow you to reduce development time and bug count while making you type much less, but it works. Just like C was a big step forward from assembly language, Python was a big step forward from C.

Among the actively used and developed languages, Python stands out as a language where readability and ease of use and learning has a high priority in its design. It's not without warts, but it's a lot better than most, even if several others reach the same level of abstraction.

have you ever released a project that demonstrates your approach to unit testing?

SystemSpecifyer is publically available at sourceforge (see also www.systematik.se). I haven't been involved for a year, but there are few checkins since then. It's a rather odd piece of software though, and it has dependencies to particular versions ZODB and wxPython, but if you want have a look at it, go ahead. It's far from perfect, but the unit test were very helpful to me.

I wrote unit tests into Trestlemail 4 years ago.

Did you write the tests before you wrote the code to test? For me that makes a big difference. I've never managed to catch up with unit tests if I rushed ahead and wrote working code before the tests. This will then come back and haunt me when I need to change the code and don't have tests that show me at once when I break things. I'm not sure extreme programming works well in all situations, but I think they are right about writing the tests first. Among other things, it makes you write programs that are testable! Having the focus on testing from the start makes a difference.

There is much more to do on the subject of testing, and I think this is a very interesting subject, but we've strayed far off the issue of GNOME now.

Suffice to say that many project show that it's possible to write dependable software in Python. That Python is one of three permitted languages on the floor of the New York Stock Exchange and that it's used to plan space shuttle launches for NASA also suggest that you can write fairly reliable code with it.

GNOME Platform Stormclouds

Posted Mar 29, 2004 21:18 UTC (Mon) by bronson (subscriber, #4806) [Link]

If unit tests only test classes in isolation, then there's no way that they could be a good substitute for static type checking (as you claimed earlier). What about inter-unit errors?

FYI, the examples you posted are contrived. They either involve a significant amount of refactoring and redesign (eShop) or a heavy reliance on standard libraries (Twisted). Python is definitely less verbose than C++, but 90% is laughable. Remember that we're comparing langauge features here, not programming environments.

GNOME Platform Stormclouds

Posted Mar 29, 2004 23:31 UTC (Mon) by mly (guest, #2171) [Link]

If unit tests only test classes in isolation, then there's no way that they could be a good substitute for static type checking (as you claimed earlier). What about inter-unit errors?

I'm sorry if I was unclear. The purpose of the unit test is only to test the unit under test. That doesn't mean that you typically replace the calls to external units with stubs. You only use stubs when there is a good reason for it, e.g. when networking or database access is too slow, and then you can probably still have some simple test included that uses the interface.

In SystemSpecifyer for instance, I use ZODB's (non-persistent) dummy storage when I test my business logic. I access ZODB through the same module (kbase) to store things, but it's never saved to disk in these tests. On the other hand, the unit tests for the kbase module use filestorage, like my real application.

Another extreme programming practice that helps solve this problem is continous integration, but this is turning into a full XP tutorial... :)

Python is definitely less verbose than C++,

Great! We agree on something! :)

but 90% is laughable.

I never claimed than a ten-fold productivity gain was typical. I quoted a number of sources claiming from 2-3 and up to 10 times improvement. Your gain will depend on your use case. I think that several times more code in e.g. C than in Python is typical though, and that's what I wrote. That's my personal experience after seven years with Python and fifteen with C/C++.

Remember that we're comparing langauge features here, not programming environments.

I've just tried to explain why programming in Python will typically lead to fewer bugs, not more bugs, than e.g. C, even though Python lacks static typing. (But I guess that's easier to experience from programming than to convince others about in a comment thread on LWN...)

I'm not sure what you mean by "programming environment", but Python's standard library is certainly a part of Python, and a significant reason for Python's success.

GNOME Platform Stormclouds

Posted Mar 30, 2004 20:24 UTC (Tue) by bronson (subscriber, #4806) [Link]

mly, I really wish you would edit your replies to a more manageable size. I now have no idea what you're trying to say.

This thread started when you were advocating using unit tests instead of static type checking. I have been saying that in most real-world situtations, unit tests are a poor substitute for static type checking, and I maintain that position.

I don't understand why you're trying to sell Python so hard. It's a language, not a used car! And I'm not even in the market...

GNOME Platform Stormclouds

Posted Mar 29, 2004 23:56 UTC (Mon) by mly (guest, #2171) [Link]

I just stumbled over a blog by Bruce Eckel that might
explain what I've tried to say better than I can.
http://mindview.net/WebLog/log-0052

GNOME Platform Stormclouds

Posted Apr 1, 2004 13:27 UTC (Thu) by joib (guest, #8541) [Link]

That was a nice argument from Bruce. He has also argued similarly before, in a previous blog entry. He even spells it out in bold font: "If it's not tested, it's broken."

GNOME Platform Stormclouds

Posted Apr 2, 2004 4:10 UTC (Fri) by dvdeug (subscriber, #10998) [Link]

Proper unit tests will find all errors that the compiler would.

That's not at all true. Compilers may find errors that no amount of testing on your system would ever find, but the instant they run on a big-endian system or a system with a different libc or different size of integer they would have failed. They can find undefined variables that would have defaulted to a value that would usually work. One problem with unit tests is that programmers frequently have blind spots; while compilers have blind spots, they're much more consistent and usually different from the programmers.

If you create a variable for seconds in a minute, and handle every case from 0 to 59, you will be wrong once every leap-second. And if you use the standard time library in Ada, it will emit a warning on compilation, whereas a language that was interfacing two integers would have no warning, and no bug unless you specifically tested that case, which many programmers might not even know exists.

What about the cases where you don't what answers to expect? A book was published about the results from an expirement done in Fortran, and afterwards it was discovered that there was two different variables (one implicitly defined) where there should have been one. If he could have written a unit test to find this, he would have noticed it before the book was published.