History of WeBWorK

From WeBWorK_wiki
Jump to navigation Jump to search
Construction.png This article is under construction. Use the information herein with caution until this message is removed.
  • Started slightly before 1996
  • Develop a course with physics department using CAPA (Frank Wolfe; Arnie Associate Chair. Coordinate section of calculus with section of physics.)
  • Used .QZ preprocessor .PZ. CAPA very restrictive. E.g. couldn't enter 0 as an answer to a problem.
  • Learned perl; idea to use CGI - make something about as good as CAPA. Morphed to something that no longer used CAPA.
  • November of 1995 "Rochester Renaisance" interupted activity. Spring 1996 started developing again. Fall 1996 had preprocessor developed.
  • WeBWorK was not a response to the attempted close of the UR grad math department, but it did accelerate development.
  • Taught courses Fall 1996, Spring 1997.
  • PZ -> PG to stand for "Pretty Good" ala PGP

Naming the software

Spring of 1996, Arnie driving into work...homework...webwork! Searched in Alta Vista for "webwork" found a lot of "webworks" plural, and one or two "webwork." But, using TeX - wait a minute, let's use the TeX capitalization.

Spread of WeBWorK

Johns Hopkins first university outside of Rochester to use WeBWorK, about 1997 probably installed over summer. Very good graduate student (name?) developed first parser for webwork.

Very early on code divided into two parts - webwork and pg. Having pdf output was inherited from CAPA.

Around 2002, perl switched from Perl 4 (not object oriented) to Perl 5 (object oriented). Mike wanted to push code to improve for maintainability. Hired two students Sam Hathaway and Dennis Lambe. Version control started in 2002. In 2004, MSRI conference brought in 7 or 8 people to. Summer 2004 Davide Cervone added jsMath.

WeBWorK 2 came out around 2004 - jsMath, MathObjects. Gavin added gateways in 2004.

National Problem Library grant 2005 - John Jones, Jeff Holt, Bill Zimer.

AIM workshop, 2007: Robin, Jason.

2009: Wrote joint grant with MAA to do national dissemination of WeBWorK. Grant awarded 2010.

Last 1.5 years: Connections with other open source projects, TOS, POSSE, Sage. Partnering with MAA has been extraordinarily successful.

Other early developers: Robert Van Damne - works for blue host.

From email to Christopher Sangwin

WeBWorK 1. started development in 1995 -- inspired by the CAPA system (since evolved into the lon-CAPA system). CAPA used

dedicated lines into a NExT machine and was written in C. WeBWorK1 took many of CAPA's ideas and recreated them using perl, CGI

and a webbrowser instead of a dedicated lines into a NExT computer. The code was developed in two branches: PG which was a rendering

language, modeled on TeX which took math questions and rendered them into either pdf or HTML format.

 The second branch consisted of  CGI scripts that handled interaction with the user.

These items listed at http://webwork.maa.org/wiki/Introduction#.T8NzlZlYs8R are essentially the same ones written in early 2000






and give some idea of the original design philosophy.

Development of the webwork2 CMS changed the front end of webwork but made little change to the basic structure of the PG language rendering code.

The gource presentation at http://www.youtube.com/watch?v=vdRsfsgHMb8 illustrates the software development from 2002 to the present. I've been

told by CS people that the webwork2 front end was among the early web applications that allowed users (instructors not students :-) ) to write code into

webpages. (Although I guess students answers were code also but of a very limited type.)

A couple of the design decisions for PG which might have been new at the time:

1. We used perl as a base language (a full fledged programming language) and then removed the most dangerous commands (which allowed access to the hard disk) rather than designing a new language and writing a parser for it (as CAPA had done). This put as few barriers as possible in front of the authors of the PG questions.

2. In principle the author wrote both the PG question and the subroutine for evaluating the student's answer in each question. The only assumption made about the student's answer is that it is a string -- and the answer evaluator accepts this string and returns a 0 or 1 depending on whether the answer is correct. The answer evaluator also emits certain error messages. --- the most important addition of MathObjects is that it unifies the error messages to students.

3. Of course you don't have to rewrite the same answer evaluator for every question -- we used libraries of subroutines for that. The pattern was taken from our

experience with TeX and with LaTeX and practice of writing macros (in the case of LaTeX elaborate macros) that lie on top TeX and make writing papers easier.

You can still use the full power of the TeX language if you want. Our idea was that perl corresponded to TeX and PG corresponded to LaTeX.

4. The idea of producing output in both HTML and pdf was used by CAPA (screen resolution at the time was horrible and printing math symbols difficult). The idea

of assuming only that the answer was a string and using plugins (or macros, or subroutines) for answer evaluators, graders and so forth so that the PG language was completely extensible was kind of new as far as I know among homework software at the time. We stole the idea from our experience using TeX. WebAssign adopted (or invented independently) some of the same ideas fairly quickly.

5. In addition to the two distinctive features you mention about WeBWorK, I would argue that the modular construction and the extensibility of PG software and of the

webwork2 front end software are the distinctive features that have allowed WeBWorK to grow and evolve more or less continuously for the last 15 years.

Here are some of the original docs: https://math.webwork.rochester.edu/docs/docs/pglanguage/

We made a couple of design decisions early. I had originally hoped we could use TeX as the basic language and program even the numeric macros in

TeX. This turned out to be difficult and in fact a typical problem had more setup code than mathematical expression code. As a result we decided to embed TeX

formulas in perl instead of embedding programming calls into TeX. The second decision was NOT to use CAS to evaluate the answer strings -- because most of the difficulties we experienced were with string handling and preprocessing of student answers, not the evaluation. (the perl parser worked fine for the initial version of WeBWorK, it was later replaced by a more flexible parser in MathObjects which gives better error messages among other things). For the kinds of math used in homework Maple and Mathematica or Macsyma were overkill in terms

of capability and used a lot of resources for the time. On the other hand a lot of string processing was necessary to insure that the student's answer was

in the correct format and the regex capabilities of perl were unmatched by any CAS of the time. We still find that comparing two functions by evaluating them

at 4 or 5 points is a more reliable check of equality than symbolic comparisons. (we also discovered that MapleTA uses this technique often as well :-) )

So while we originally planned to use CAS for complicated problems we still haven't use it much for runtime evaluation of questions. (Authors often speed up

writing questions by using CAS however). Last summer we started a joint project with sage to embed webwork questions in sage worksheets and to

allow sage interacts to appear in webwork pages and (also to allow webwork questions to be authored from within a sage worksheet). These are mostly

in the early stages of development. John Travis and Jason Aubrey can tell you some more about progress they are making this summer. see John Travis's site

at http://math.mc.edu/webwork2/sage_demos/ for current examples. You can log in as guest.

As to academic papers written about WeBWorK. Arnie Pizer is working on a project to update our list of references (the current collections are a bit out of date

and are scattered in various places. ) You can contact him at apizer@math.rochester.edu for the current collection. Here are the collections currently on the web:

http://webwork.maa.org/publications.html (pretty good but static) The Dedic, Rosenfeld, et. al publication is interesting for online homework in general,

the gage,pizer,roth publication (2003) describes the end of Webwork1 with webwork2 just getting underway. the Scharff publications describe adaption

for use in CS and the Kohe, et. al publication 2010 is a nice comparison of online homework (but not at a technical level).

There are several masters thesis written at San Diego State University -- Arnie or Vicki will have those references.

There are other reference collections at

http://webwork.maa.org/moodle/course/view.php?id=5 but most of these are duplicates of ones listed above. Vicki Roth and Arnie Pizer can fill you

in on more details of academic publications.

From email re: webwork start date

Not sure when you are counting WeBWorK as having started.

I had developed a preprocessing language (I called .pz since it's output was the .qz language used by CAPA) in order to use

WeBWorK in the MTH161Q (first year calc) that I was teaching, using CAPA, in parallel with Frank Wolfs course.

The Renaissance Plan Black Friday was on November 16, 1995. (A kind of ground zero that I use to remember when things happened during that era.)

I don't think I started doing any development on the CGI/ WebBrowser/ Perl scripts until sometime early in the spring semester of 1996 after black friday and then you[Arnie Pizer], Scott Douglass and Basem Moussa joined in during the summer of 1996.

I believe you[Arnie Pizer] taught the first class (MTH140a) actually using WeBWorK software in the fall of 1996. And then I taught one in the spring of 1997 (MTH162Q?)

I've been using Fall 1996 as the start of WeBWorK.

Quote from my[Mike Gage] faculty inactivity report Feb 2, 1996:

The course MTH161Q was run in conjunction with the PHY121 class taught by Frank Wolfs. We loosely co-ordinated the subjects we taught, and in the math course I was able to give physics oriented problems and examples which I would have avoided in a non-homogeneous class. The most time consuming aspect of the course (and the reason for the reduced course load) involved getting the computerized homework delivery system CAPA working for mathematics problems. Unfortunately CAPA was not designed with math problems in mind, and it proved rather difficult, for various reasons, to use it for math homework. Arnie Pizer and I have designed, and partially tested a new system (WeBWorK) which seems to have better potential, largely because it piggy-backs on well established or quickly developing software such as Perl and the WWW server/clent programs such as Netscape. A complete evaluation of the course is appended. Arnie and I are talking to Bill Green about further development of the WeBWorK system.

Reply from Arnie:

Your recollection is correct and 1996 was the date I was using for the start of WeBWorK before I started seeing the 1994 date. Then I figured you were counting the preliminary work and the idea for WeBWorK (which was unnamed at the time) that occurred in the fall of 1995 before the Renaissance Plan but just missed by a year. Note the idea preceded the Renaissance plan and was not a reaction to the plan as many people thought. That's why I went with 1995. The idea is from late 1995 but actual work on WeBWorK started in 1996.

The first time it was actually used was when I taught MTH 140A (if that's the correct number) in Fall 1996.

Library Browser

  • Initially, people would print pdf's of problem collections and have instructors select from the printouts.
  • An initial library browser was a program outside of the main webwork code. It did not display problems, just the DESCRIPTION field from inside problems, but could produce set definition files.
  • The first version of the real library browser was in May 2004. It mirrored the initial approach of picking problems from a pdf. It displayed problems and instructors could check off the ones they wanted.


  • In the early '00s, WeBWorK could check answers which were numbers and functions, but could not handle many other types directly (lists, ordered pairs, etc.)
  • Ad hoc solutions started to appear. Davide Cervone had code for parsing inputs, and agreed to adapt it to WeBWorK.
  • Once in place, WeBWorK's older answer checkers were rewritten to use Cervone's parser.
  • The capabilities of the parser grew, and was renamed MathObjects.