Comments on: On Arc

By: washburn

washburn — Thu, 27 Mar 2008 19:51:38 +0000

@Seth: Despite having read The Mythical Man-Month some years ago, I can’t say that I can recall enough about what he means by a “table” to tell what position he (or you) is advocating.

By: Seth Tisue

Seth Tisue — Thu, 27 Mar 2008 15:45:28 +0000

“Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.” — Fred Brooks, The Mythical Man-Month, 1975

By: washburn

washburn — Wed, 27 Feb 2008 20:09:19 +0000

@Gavin: I know that there are ways to do abstract data types properly in Lisp. I just found Paul Graham’s dismissal of abstract data types naïve.

By: Gavin Mendel-Gleason

Gavin Mendel-Gleason — Wed, 20 Feb 2008 17:02:15 +0000

The notion that most literate lisp hacker make use of to avoid difficulties is to use functions to abstract data-structures. Norvig makes extensive use of this strategy in “Paradigms of Artificial Intelligence Programming”.

For instance with the point example:

(defun make-p (x y) (cons x y))
(defun x-coord (p) (car p))
(defun y-coord (p) (cdr p))

The functions then serve as the abstract interface. I think this is fairly close to the Co-Algebraic point of view, as we treat points as abstract objects coupled with operations on them, whereas Coq/Haskell/ML users would likely use a more Algebraic approach and structure things based on pattern matching. Of course the lisp approach is entirely ad-hoc and enforces no discipline. For disciplined Co-Algebraic stuff you might look at CafeOBJ.

By: Chris

Chris — Wed, 30 Jan 2008 23:19:59 +0000

My position on types is of course well-documented, but I feel the need to play devil’s (Paul Graham’s?) advocate. He did qualify it with “in exploratory programming,” which to me means throwaway code, or mostly so. If you’re prototyping and “planning to throw one away” (Brooks), then quaint ideas like representation independence are indeed less of a concern. Also, in Paul’s camp, pro-types arguments carry little weight when they refer to fancy new features fresh out of POPL, like polytypic functions or rank-2 polymorphism. Whenever you need 10 dense POPL pages to justify some trick that Lisp hackers have been doing quite successfully since 1965, you lose.

That said, I have read a passage or two in Paul’s works (too lazy to find them now) that led me to believe he’s a bit misguided about modern type systems.

By: washburn

washburn — Wed, 30 Jan 2008 20:20:10 +0000

@Matt: I do not know that it should truly be considered an exaggeration. There are many operations that naturally defined inductively over a structure, and if the definition of the data type is well specified, the code pretty much writes itself.

However, some would argue that this is a weakness of the approach because it leads to repetitive boilerplate code. This is where type-directed programming comes into the picture. You can’t very well eliminate the boilerplate by recursively walking over and ignoring everything in a data structure except the “points” if you can’t tell the difference between a point and any old two element list containing integers.

By: Matt Hellige

Matt Hellige — Wed, 30 Jan 2008 18:03:38 +0000

I’m afraid it will take even longer for people to learn that telling the compiler about the structure of your data is telling it about the control flow… (Yes, I admit I’m exaggerating for effect, but you know what I mean.)