Stewart Stremler wrote: > begin quoting James G. Sack (jim) as of Thu, Oct 25, 2007 at 08:43:58PM > -0700: > >> Stewart Stremler wrote: >> > [snip] > >>> You want the standard DFA/NDFA description? >>> >>> Perhaps a formal languages presentation? >>> >>> Don't think I could do proofs without a lot of prepwork. >>> >> Well, I don't have a formal CS background, and although I hear these >> terms, and have _some_ basic understanding, I'm sure I don't appreciate >> the "real meaning" of it all. >> > > 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. 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. >> For instance, it's not obvious to me why one would say >> eg, "..state machines are great. They make all problems easy.." >> > 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.
--Chris -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
