begin quoting Christopher Smith as of Thu, Oct 25, 2007 at 10:26:45PM -0700: > Stewart Stremler wrote: [snip] > > I don't know if there's a lightbulb-moment or not. I think they're > > pretty simple -- the hard stuff is in the proofs and the transforms. > > > And the nice thing about a functional language (or at least *some* > functional languages), is that the language does that "hard stuff" for > you.
I completely fail to see how *any* programming language could prove that an NDFA and a DFA are equivalent. Or show why a transforms is guaranteed to work. > Of course, things like the halting problem aren't solvable (which > really begs the question of just how easy state machines are), but the > stuff that can be solved can be solved for you by the computer. Huh? How does the halting problem have anything to do with the utility of state machines? "You can't fly by flapping your arms." "What good is a teapot then?" > > Well, that egregious rhetoric. Problems don't go away, they just move > > around. It's a zero-sum game: you can push the dirt around, but you > > can't get rid of it. It's just that sometimes you can find a nice big rug. > > There is a lot of truth to this. However, some languages lend to > developers making the problem harder than it need be, some languages > focus on other problems and some languages focus on this as being the > central problem. There is something to be said for focusing on the real > problems rather than creating new ones. Yup. -- Every language has a problem domain. Some languages *are* a problem domain. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
