Some days ago, I stated on this blog that I had a Ph.D. in mathematics (true fact) and that I didn’t know my own phone number nor did I know multiplication tables (also true). My wife knows it is true. She still claim she has superior brain power because not only does she know our phone number, but she even knows our postal code, and she knows many other things. There is not question that my wife is one of the smartest lady in Montreal. Hey! There is a reason why I fell in love with her!

Still, I claim not to be a brain-damaged moron despite these apparent short-comings. You see, I do not memorize on purpose because I think that my time is better used by solving problems and learning new tricks.

From Downes’, I got the following bit of wisdom telling I’m not alone in thinking that memorizing facts is not key to learning…

My own research – reserach that can be extended through the many resources on this site – has already convinced me that neural structures are, as they say, plastic. For me what this means is that learning based on the fostering of habits is more important than learning based on transmission of facts, that, indeed, the facts aren’t that important at all, not nearly as important modelling effective practice, paying attention to environment, immersive, experiential based education.

So, please, do me a favor: if you teach, do not ask your students to memorize. Ask them to change their neural pathways, their thinking patterns… let their PDAs and the Web be a fact storage unit, don’t waste their brains.

Update: A colleague who has a training in history and who holds a Ph.D. says he could never remember dates, and only memorized one: December 25th 800. So, I can say that I’m not alone to think that memorization is only a minor part of learning.

Through Downes’, I found another article speaking up against SOAP: Don’t Be Afraid to Drop the SOAP. Here’s a few things it holds against SOAP, all of which are things I can testify to:

• SOAP is difficult to debug. The SOAP message format is verbose even by XML standards, and decoding it by hand is a great way to waste an afternoon. As a result, development took almost twice as long as anticipated.
• The fact that all requests happened live over the network further hampered debugging. Unless the user was careful to log debugging output to a file it was difficult to determine what went wrong.
• SOAP doesn’t handle large amounts of data well. This became immediately apparent as we tried to load a large data import in a single request. Since SOAP requires the entire request to travel in one XML document, SOAP implementations usually load the entire request into memory. This required us to split large jobs into multiple requests, reducing performance and making it impossible to run a complete import inside a transaction.
• Network problems affected operations that needed to access multiple machines, such as the program responsible for moving templates and elements. Requests would frequently timeout in the middle, sometimes leaving the target system in an inconsistent state.

Here’s some comments by Joe Walnes on his experience with SOAP. The scary thing is that he comes to exactly the same conclusions as I did on my own… Any SOAP supporter out there wants to answer these:

On the last system I worked on, we were struggling with SOAP and switched to a simpler REST approach. It had a number of benefits.

Firstly, it simplified things greatly. With REST there was no need for complicated SOAP libraries on either the client or server, just use a plain HTTP call. This reduced coupling and brittleness. We had previously lost hours (possibly days) tracing problems through libraries that were outside of our control.

Secondly, it improved scalability. Though this was not the reason we moved, it was a nice side-effect. The web-server, client HTTP library and any HTTP proxy in-between understood things like the difference between GET and POST and when a resource has not been modified so they can offer effective caching – greatly reducing the amount of traffic. This is why REST is a more scalable solution than XML-RPC or SOAP over HTTP.

Thirdly, it reduced the payload over the wire. No need for SOAP envelope wrappers and it gave us the flexibility to use formats other than XML for the actual resource data. For instance a resource containing the body of an unformatted news headline is simpler to express as plain text and a table of numbers is more concise (and readable) as CSV.

Through Didier, I got to Victor Shoup’s Home Page. He has an on-line textbook called A Computational Introduction to Number Theory and Algebra. It is unclear whether he intends the textbook to remain free, but it is pretty cool to post the book on his home page. Shoup’s is an expert in cryptography.