Lambda the Ultimate

The use of automata theory seems to conflict with the notion of "software".

I would characterize that differently. In a programming language context, automata are routinely used in operational specifications of programming languages, in the form of virtual machines (e.g. the SECD machine, to pick a famous example). In that context, automata theory is not so much in conflict with anything, as being an explanation at a different level. For most software, it seems to be more productive to work at the "higher" level provided by the languages which map to the automata.

Even when the goal is to develop a traditional automaton explicitly, for complex systems it may be worthwhile to develop it in a higher-level language and transform (manually or automatically) to automaton form. For example, some languages used for development of control systems, such as Esterel and Lustre, can be compiled into finite state automata.

This may account for why automata theory is rarely mentioned in computer science

Perhaps this perception comes from the fact that automata are very much taken for granted as fundamental to CS. Does the term "Turing Machine" ring a bell? ;)

I'm in my first semester as a CS grad student, and am taking a "core" course entitled "Foundations of Computer Science". The course deals exclusively with automata theory and its application to computer science on many levels (programming, parsing, verification, to name a few).

I think FSMs are regularly used in software. F.e. in our web-based XML editor Xopus we use FSMs to get high-performance (pre-)validation of XML. And when creating a new element the shortest path through the FSM of its content model gives the required children of the new element. FSMs make this quite fast, even in Javascript.

Introduction to Automata Theory, Languages, and Computation (1st ed) is one of my favourite books. Everything is a state machine for months after reading it. :-)

The Event Calculus provides an interesting new spin on the very old subject of state. In Event Calculus we start with fluents (we arn't using that old word "state" here) and we give meaning to the fluents by using axioms of persistence, domain axioms, and finally by applying a rather subtle process called "circumscription". The result is a large transition rule that looks for all the world like an automata definition (but they don't seem to use the word). There is a book: Commonsense-reasoning , and lots of stuff you can find by searching on "event calculus". Reinventing things is really not such a bad idea.

I find this link not such a big surprise, considering things like Abstract State Machines for programming, e.g.,

http://research.microsoft.com/fse/asml/

Perhaps this type of programming is better for modeling real-world situations on a larger scale.

By the way, what is a good syntax for such type of programming? I have tried using an exceptions-like syntax, but it makes the code almost unreadable, because reaction to events can be far away from the source of events.

State Chart XML (SCXML): State Machine Notation for Control Abstraction