What do you really know about math?

Bill Kerr, a teacher/blogger I read regularly, wrote a post recently that I enjoyed immensely, called “What is maths?” He doesn’t answer the question, but what I like is he cites some other articles that talk about what math is not. They make it clear that a) we’re probably not being taught math completely in schools–even though we think we are, and b) our perception of what math is causes us to discredit it in our daily lives.

Ever since I was a teenager I heard the occasional adult who said, “I learned X, but I never used it.” We take the math skills what we learned for granted. By “math skills” I don’t just mean how to solve equations, but the mental skills we learned in order to solve equations but the mental perception that is acquired as a result of solving them. My guess is lots of people use those skills it in other aspects of their lives, but math doesn’t get the credit.

This is something I became concerned about when I wrote a post around a video M. J. McDermott produced about math education in the state of Washington. She said that high school students were not learning about higher math skills like algebra, and Trig., but instead were put into a focus on “everyday” math skills that people could use to solve arithmetic problems in their heads. I looked into this a little further and it sounded like this curriculum came out of the mindset of these people who say, “I learned quadratic equations in school, and I never used them again.” It sounded like they’ve just chucked those disciplines out, because hey, nobody’s going to use them in real life, right?

Kerr’s quotes make some really good arguments against what people think of as “math”. I’ll give a couple examples.

Kerr cites a math professor, Dr. Robert H. Lewis, who talks about the snide remarks he gets from some adults who complain they were taught quadratic equations, but never used them again–they were “useless”. His response is basically, “Yeah, so what?” He said it’s like saying, “You know, I can’t remember anymore what the name of Dick and Jane’s dog was. I’ve never used the fact that their names were Dick and Jane. Therefore you wasted my time when I was six years old.” He said the point was not to learn about Dick and Jane and their dog. The point was to learn to read.

A commenter to Kerr’s blog, named Maggie, cited another good example. Athletes use weight training to develop their bodies for their sports, like football. Does weight training have anything to do with throwing a ball, catching a ball, or running it down the field dodging linemen? No. So what relevance does it have? Exactly. It has no direct relevance to the sport, but it’s a supportive activity that promotes better performance in the sport. She said, “Math is exercise for your brain.”

There’s a larger point to Kerr’s post that I don’t really cover here, but I think is worth exploring.

As for me, I think I got an OK math education in school (public school and college). A lot of it was pattern matching and symbol manipulation, but I didn’t have a good grasp for what was going on half the time. For the courses I took where I “got it”, I was grateful. I truly enjoyed the experience of delving into the math, understanding it, and exploring by myself how it applied to problems in the real world. In the other courses, I was able to do the symbol manipulation–go through the motions–but I didn’t have the foggiest notion as to why we were doing what we were doing. What did it mean? I felt like a dumb machine. This happened mostly in my college math courses. I could produce the correct answers on a test some of the time, but when it came time to apply the math concepts to a non-theoretical problem (outside of math coursework) I was as ignorant as I was before I took the classes that taught them. This is a frustration of a different sort. It’s not that I thought the math concepts I was taught were useless. It’s that I went through the course not truly learning the math the course was ostensibly supposed to teach. To all appearances though, I’d learned it to the school’s satisfaction.

I think I’ve ended up learning more about the aspects of math I didn’t learn in school from my work as a programmer. I can compare and contrast math forms that I can work with in programs with the math forms I saw in school that were purely theoretical. Some of them are similar, and some are different. What’s helped is seeing “math in action” in my programs, not just declarative symbols.

I think the math I learned in school helped me in my programming by driving home the notion that something that looks complex can be transformed into a simplified form by deconstructing it to its essential elements, without losing any of its meaning. The symbol manipulation skills really help, too. The set theory I learned in Discrete Structures (in college) has helped out a lot. In terms of direct relevance, that was the most relevant math course I’ve had.

Anyway, Bill Kerr asks some really good questions. Check out his post.

Edit 2/29/08: I made some corrections, because I realized that in the 2nd paragraph I had mischaracterized what is really learned in math. Kerr’s post delves into this more. I realized that instead of saying “math skills” that are acquired from the activity I should’ve said that the activity helps us gain a new mental perception, which allows us to form new ideas on how to see things.

—Mark Miller, https://tekkie.wordpress.com

Advertisements

GNU Smalltalk to support Seaside

I found this item on reddit. An entry in the GNU Smalltalk FAQ, under the heading “Does GNU Smalltalk run Seaside?” says that it will support Seaside in a release scheduled for March 8th. Now, the FAQ posting that says this is dated June 20, 2007. I’ve asked about this on reddit. Has the release date slipped any since then? Anyone know?

Anyway, this is good news. It gives those who want to use Seaside more options. GNU Smalltalk offers operating options that some find more convenient for what they’re trying to do. For example it offers good scripting support. Of course, I’m not sure if the scripting support will be compatible with Seaside. I guess we’ll see.

I used GNU Smalltalk a bit in college many years ago. It was the first implementation of Smalltalk I encountered. It was really my first exposure to OOP. We used its scripting support then–just the Smalltalk language. We were told about the Smalltalk system that was developed at Xerox, but we did not use the whole system with the GUI, browsers, workspaces, transcript windows, etc. It was very compatible with the “Unix way”. You wrote your code in vi, Emacs, whatever, and then ran it through the interpreter on the command line. The code we wrote looked similar to a file-out of Squeak code. The metadata was a little simpler. One oddity (I think) was if you wanted to print something out to the console you had to wrap it inside of an array and use its printNl method. For example:

#(‘Hello world’) printNl

Yep, we even had to wrap strings. Even so I thoroughly enjoyed the experience at the time. Ah, memory lane. 🙂

Edit 2/27/08: I got a little more information. It turns out the FAQ posting about this on the GNU Smalltalk site originally said something vague about how “Seaside could be made to work with it”, but was updated just recently to say that this implementation will support Seaside on March 8th. So the release date is a firm one.

—Mark Miller, https://tekkie.wordpress.com

Presenting the XO Laptop

The XO went into production late last year, and I’ve been looking for interesting material on it to talk about here. David Pogue of the New York Times did a review of the XO last year, but I just found the video for it.

I think he does a really good job of presenting it in an approachable way. He mentions a “give one, get one” program that went on for a while, on into December as I recall. At first it was only going to go on for a few weeks, but it went for several. That’s encouraging. It must’ve been doing well. OLPC is not offering this anymore. You missed your chance. Maybe they’ll restart it again in the future. I think it’s a neat idea.

The feature that made me a bit giddy was where he said that with one keypress you can look at the source code for any program you’re running, and even change it. He also mentions that there are three programming environments on it (one of which is Squeak), but only talks about Python, which is what most of the software is written in. He notes that there’s also a “restore” button that restores things back to its “manufactured” state “in case you make a mess of things”. This could encourage programming all the more, because it takes away the risk that you could royally hose your computer so you can’t use it anymore.

Finally a computer that actually invites its users to become programmers. How long has it been since I’ve seen that in the U.S.? Only this laptop was not designed with kids in the U.S. in mind. It was designed for poor, deserving kids in developing nations. Apparently most kids in the U.S. don’t like the idea of programming, not even college students (I know the link is old, but nothing’s changed). It’s sad. Perhaps if CS programs at universities would re-think what they’re doing, take a look around them, and try something creative that really meant something to people we’d see interest return. Unfortunately too many think teaching CS means teaching Java. I pity the beginner who tries to pick that up. I think the XO is going in the right direction, because it gives users “something to chew on”, and it uses a language that is more flexible and powerful than Java. If only it was around when I was growing up.

IT: You’re doing it completely wrong

Hi guys. I’m still very busy with other stuff right now. I’ve yearned to get back to my research, and sharing my findings on here. I’ve had to be patient and persistent. It’s going to be slow-going for a while.

I found this article on reddit, called Rental Car IT, by Neal Ford. It encapsulates what I think is going on in IT, in the large. That is, companies are unwittingly making their systems more complex, not less, and therefor less manageable as time passes, due to what he calls “accidental complexity”. The reason I’m covering this here is the mindset it illustrates in our industry applies just as well to the issues of software development.

Ford talks about customers he’s done business with, and how he tries to talk them into simplifying their systems. They seem to agree in principle with the idea, but when it comes down to making a decision they consistently choose the “less risky” option of buying off-the-shelf software, which ends up making their systems more complex and unweildy than they were before.

Ford also points out that customers frequently spend millions of dollars on pre-fabbed systems to solve simple IT problems.

He talks about something which has been a bone of contention for me. He describes an incident where he suggests to a senior IT guy that they talk to the users about what they want out of the system. The IT guy scoffs at the idea, saying the users should have no say in it, because, “We’ve tried talking to them–they don’t know what they want, so we have to define it for them.” Justin James talked about a related subject in a blog post called “Enterprise software is about data–not people”. I and Justin’s other readers had a good discussion on there about this. Ford says this attitude has the effect of creating cumbersome, complex systems that hinder important things like customer service. I agree users tend to not know what they want, but that doesn’t mean they should be totally ignored. All this attitude does is hinder productivity. The users are a part of the business operation. If a system is not working in a compatible fashion with the way they think and work, it creates inefficiency, because users are having to repeatedly take their minds off the real task they’re trying to accomplish so they can “deal with the machine”.

Some of the comments to Ford’s post were interesting, too. One said that it’s all about risk to the decision-makers, not to the company. If a project goes bad and they used a package from one of the major vendors, there are a lot of other people that can be blamed for the failure. Whereas if they try to develop the solution in-house and the project fails, then the IT executives themselves will be on the chopping block.

The sense I got from reading this is that increasingly enterprise IT development is being sequestered; moved, separated from the company, precisely because of past IT project failures. In other words, our ignorance about what we’re really doing is gradually discrediting IT development. People don’t want to take the risk anymore. I am reminded of a phrase which goes, “The biggest risk is not taking a risk at all.”

This attempt to remove risk and liability from internal IT is not necessarily serving companies well. What’s being missed is that a business’s computing systems should model the business. Companies such as the ones described in the article are attempting to fall back on an Industrial Age idea of solving a problem by acquiring standardized equipment (software systems) and making it interoperate with their existing equipment (software systems). In other words, take something that was designed by a group of engineers who have no idea what your business is about, and was designed with a particular purpose in mind, while at the same time it tries to allow some customization (it isn’t always flexible/generic enough to allow the customization you want), and attempt to make it model your business. Another name for it is “the data processing mindset”. Users are mere “operators” of this equipment, just as their industrial forebearers were. Their job is to learn how to operate it, and use it the way it was designed–without them in mind.

These businesses are trying to build their computing systems using Computer Engineering and Information Systems disciplines and infrastructure almost exclusively, avoiding what Computer Science and Software Engineering have to offer to the organization–sequestering it to the major software companies. They want to deal with pre-fabbed “boxes”, not code. The reason this doesn’t work well is they’re dealing with information, not widgets. They’re delivering a unique service, one where domain-specific information and semantics are key components. This is not a manufacturing process, and in the long run it cannot be dealt with effectively using this mindset.

—Mark Miller, https://tekkie.wordpress.com