Normally I would use my my Twitter feed to share links such as this one, but this TED Talk by Conrad Wolfram of Wolfram Research warrants more discussion than I could fit into 140 characters. The gist of his talk is that schools shouldn’t teach students math by making them do tons of tedious calculations. Instead, that should be left to computers, so people are free to focus on learning how to formulate real-world problems in mathematical terms, have a computer perform the calculations and then apply the result to their real-world problem, and I couldn’t agree more.
When I was an exchange student in the U.S. in 2000/2001, I was at first excited to see graphing and programmable calculators be used in math class. Back at home we only had simple scientific calculators and I think to this day that’s all students are allowed to use on math exams. However, in spite of these very capable computing machines, the problems we were given to solve were pretty dumbed down, as Wolfram also noted in his talk. As it turns out, technology was merely used to make us do more problems, not empower us work on more difficult and interesting ones.
I think Wolfram is really onto something when he suggests that once we have basic arithmetic covered (the kind of math you would need in everyday activities like shopping), we should use computers and in particular programming, to teach people to formulate tough problems in a way that computers can solve them and then interpret the results.
Excursus: Domain-specific languages
I don’t suggest that everybody learn a general purpose programming language like C# or Java in school, of course, because let’s face it, not everybody is cut out to be a programmer (at least by today’s definition of programmer). But with the advent of domain-specific languages (or DSLs for short), I think programming in a language specifically designed for a certain problem area could become common in many professions that would traditionally enlist the services of programmers to write custom software for them.
As a software developer at a bank I regularly talk with people on the business side that rely on my software in their day-to-day work. They know the business-side of their problem area and I know the technical side and somehow we have to come together to build a program that provides a technical solution for their business problem. Traditionally, there has been a huge disconnect between business people and us technical folks. Many a times it seems we are speaking two completely different languages. Of course, it’s hard to write software to solve a problem one doesn’t fully understand, and this is one of the reasons many software projects are finished late, over-budget or outright fail. But I don’t think it has to be that way, if we can somehow narrow the gap between the business and the technical side. Enter DSLs:
Let me give you a simple example from my own experience: One of the departments I have been working with is responsible for reconciling front- and back-office systems. Basically they are making sure that every transaction from the front-office system is accounted for in the back-office system and vice-versa. There are a lot of different transactions taking place in a bank, so there is a lot of reconciling to be done, but most jobs follow the same kind of pattern: There are two lists of transactions (one from the front-office system, one from the back-office system) and each transaction has certain properties that need to match in the two lists. For instance for a money transfer this would be source account number, destination account number, amount, currency, value date et cetera. Of course, there a bunch of little details, exceptions and corner-cases that need to be taken into account, but let’s ignore those for simplicity’s sake.
From a business perspective this is to the reconciliation job. Yet using a general purpose programming language it’s still hard to write a program to perform this job. So what I ended up doing was creating a sort of reconciliation framework that one can configure to perform any job that fits this general pattern plus some advanced functionality to cover the other gritty details. The configuration is declarative, based on XML, which is a vast improvement over the previous approach of using Delphi to hand-code a new application based on a few shared components for every single job. However, it still requires a rather technical person to configure the framework for use as the business people don’t even want to go near the XML.
So wouldn’t it be great if there was a language of sorts that would allow the reconciliation department to create their own reconciliation jobs? I wouldn’t even call it a programming language as that would imply one needed to be a programmer to use it. No, this would be a language for people on the business side that knew the ins and outs of problem area but currently lack the tools to develop the solution themselves. It would be a language with first class support for strongly-typed variables such as “Todays money transfers from system A” and operations such as ”Compare data from systems A and B based on the fields source account number, destination account number, amount, currency and value date”. The compiler for this language would then translate this into the proper SQL query required to actually retrieve the data and some kind of list iteration to execute the comparison; but that would be an implementation detail no business person would have to concern themselves with. All they would see were a couple of commands that almost read like sentences. The closer such a DSL was to a natural language, the easier it would be for practitioners to use. Also, it would almost eliminate the need to write documentation for the program, because it says right there in plain English what it is this job does. Of course, as in any programming language, the user to would have to adhere to certain semantics and syntax. This is where it gets difficult for non-technical users that are not used to using precise language to describe their problems; a common source of frustration for programmers working with business people.
More mathematical practitioners, more practical math
But getting back to Wolfram’s point about teaching programming in school: I think that narrowing the gap between business and technical people needs to be done from both sides. For one, we as software developers need to develop tools that are better tailored to the problem area of our users and that give them the power to solve their own problems without relying on us to develop individual solutions for them every time. Second, as Wolfram suggests, we should enable all people to develop the quantitative skills necessary to use these tools (precise problem formulation among them) by making math class more about developing quantitative solutions rather than performing calculations by hand, a skill no one needs ever again once they leave school.