I'm trying to understand the language design decision to include beginShape() POINTS and LINES mode, if in fact they are just encapsulated point() and line() function calls. Browsing through the Processing src seems to imply this is the case. I think there is an argument to be made for their inclusion, with regard to consistency with the other shape record functions. However, I'm wondering if I'm not missing something more significant in the implementation. The following 2 simple snippets below give identical output, yet the line() approach does it with half as many lines of code as beginShape(LINES). In what situation might it be more efficient to call the latter?

size(300, 300);
background(255);
line (20, height/2, width-20, height/2);
line (width/2, height-20, width/2, 20);

size(300, 300);
background(255);
beginShape(LINES);
vertex (20, height/2);
vertex (width-20, height/2);
vertex (width/2, height-20);
vertex (width/2, 20);
endShape();

Once we move to the other beginShape() modes, there seems to be is a clear design benefit. For example, in the next 2 snippets, LINE_STRIP seems like a less kludgy solution than having to reassign terminal points yourself, or spin your own more elaborate record function. beginShape() also provides the benefit of some join control.

// elegant vertex() appraoch
size(300, 300);
background(255);
strokeWeight(3);
smooth();
beginShape(LINE_STRIP);
for (int i=0; i< 100; i++){
 vertex(random(width), random(height));
}
endShape();

// kludgy line() approach
size(300, 300);
background(255);
strokeWeight(3);
smooth();
float x = random(width);
float y = random(height);
for (int i=0; i< 100; i++){
 float x2 = random(width);
 float y2 = random(height);
 line(x, y, x2, y2);
 x = x2;
 y = y2;
}

John,
I don't think that's correct. Check out:
http://test.processing.org/reference/line_.html
http://test.processing.org/reference/point_.html

Thanks Ben.