Dear Petri net enthusiasts,
are there any groups working on or interested in funding work on
bridging the gap between the Petri net and programming language
communities? And do you agree that there is a gap to be bridged?
My own impression, coming from the language side but with a net
background, is that awareness and use of Petri nets among
programming language researchers and practitioners is not nearly as
good as it should be. Also, attempts to interest language colleagues
in nets are hampered by needless obstacles on the net community
side. These obstacles are unintended, merely a result of differences
in cultures and approaches to communication and community building.
As a result, programming language researchers occasionally reinvent
wheels long known (or already forgotten..) in the Petri net
community. The problem is not so much the reinvention itself, but
that it is not informed by the earlier efforts and that, if the
reinvented wheels do include any new ideas, those are not fed back
into the net community. Also, partially successful reinventions
attract their own followers, publication venues and workshops,
continuing the story of duplicated development and lack of
communication. We now have several active communities working on
variations of the same theme, without being entirely aware of each
other’s work. The other side of the coin is that Petri nets do not
profit as much from programming language research as they could.
One concrete topic that I think would help, and that I would like
to be able to spend more time working on is to present and develop
high-level Petri nets as a declarative programming language.
Apart from its intrinsic potential, this could also serve as a kind of
“rosetta stone”, providing an example translation between programming
language and Petri net terminologies and concepts. So those interested
in other aspects of Petri nets or programming language research could
use this project to help them get acquainted with the other side.
Sub-topics that I am interested in pursuing include:
(1) presenting high-level Petri nets in a way that programming
language people can relate to,
(2) applying language design principles and ideas to Petri nets,
and Petri net ideas to programming languages,
(3) presenting place/transition and condition/event nets as
simplifying abstractions of high-level nets for analysis, not as intermediate models,
(4) moving beyond editing Petri nets as bipartite graphs
(emphasizing semantic over syntactic editing)
(5) promoting Petri nets as a means to communicate computational
thinking by introducing laypeople to programming concepts,
with little or no syntactic overhead or semantic complexity.
(1) is partly community building, partly developing the tools that
enable successful communication, partly reformulating the existing
formal foundations and practices in ways more accessible to the
target audience (the analysis parts of 2 are a prerequisite for this
to work, and the ‘nets as types’ slogan from 3 will help to provide
motivation); beneficiaries will be software developers who work in a
distributed context but are not yet aware of Petri nets, but also
the Petri net community as a whole, by extending their visibility
and reach into the programming language community and by gaining
access to additional expertise (enabling the exchange parts of 2).
(2) is about exchanging ideas between the two communities in order to
improve foundations and practices in both; there have been
successful, if isolated, instances of this in the past, but also
spectacular failures of communication; 1 will hopefully encourage
a wider exchange and help to reduce duplication of efforts in
future; my specific interests are in combining pure functional
languages and Petri nets, beyond the widely popular Coloured Petri
Nets in which functional languages are merely inscription languages
inside Petri net structures; but even just analyzing Petri nets wrt
language design principles and ideas will help to support 1 and 4.
(3) programming language folks value their language’s expressiveness,
which can have the surprising effect that previous exposure to
simple net types can lessen their interest in attempts to describe
higher-level nets (it can make the latter look like an insufficient
base model with “bolted on” inscriptions, or the net structures as
insignificant add-ons to the inscription language “doing the work” -
neither impression is helpful; and if someone does not succeed
immediately in “getting” the implications of high-level nets, the
interplay of net structure and inscriptions, and the modeling
options offered by this combination, they tend to fall back on their
understanding of simpler net types to base their evaluation on); the suggested alternative is to make use of the fact that
programming language folks are very familiar with simplifying
abstractions of full programming languages for analysis, eg in the
form of type systems; if we consider the separation of nets into
dynamic parts (marking) and static parts (structure), the slogan
becomes: net structures are the static types of concurrent systems.
(4) is about a problem most Petri net modellers will be familiar with:
not only does one tend to spend all too much time fiddling with the
graphical representation, but editing graphs, while sufficient to
achieve the intended model modifications, does not reflect semantic
model operations; when editing programs, there are similar problems
if the editor uses only string or syntax operations; no matter whether
the syntax is textual or graphical or hybrid, one really wants to
move beyond syntax, towards semantics-based operations.
(5) is about going even further in terms of accessibility and
promoting the advantages of “Petri net thinking” (once we can
explain high-level Petri nets to programming language folks in a way
that maintains their interest, can we also explain them to
laypeople?); many successful programming language communities have
strong beginner-focused efforts, where language fans try to promote
and support (via tools and tutorials) their favourite language as
best first-language-to-learn-programming and, more generally, recent
efforts to promote “computational thinking” seem strongly coloured
by algorithms and programming languages backgrounds;
mixing in some Petri net views into the “computational thinking”
efforts would more easily encompass understanding of concurrency,
distribution and communication, providing benefits to both the
campaigners and their audiences, while raising general awareness of
Petri nets; thinking about presenting Petri net ideas to beginners,
without immediately jumping into a specific formalization in terms
of matrix algebra, graph theory, formal multiset rewriting, and the
like, will provide benefits to anyone thinking about Petri nets, not
just beginners new to the topic, but also to experts thinking about
possible extensions and variations.
I’d appreciate pointers to existing work on any of the above topics.
Moving from research agenda to funding, it is obvious that the above
topics cover a wide enough range of work that progress without funding
specific to Petri net research and development is frustratingly slow,
and success without community involvement is impossible. In fact, I
tend to have so many ideas that, even after filtering out the bad
ones, it would be helpful if some of them could be farmed out, to
colleagues who have the background or to students who have the time to
fully realize their potential.
In the past, I have been working in declarative programming research
contexts, but I was also given a good -if somewhat dated by now-
basis in Petri nets. Ideally, I would be looking for a full-time
research position in a group that complements this background, i.e.,
a group strong and active in high-level Petri nets (so I can catch
up on recent developments and better understand and interact with
the net community), but open to declarative programming languages
and ideas (supporting my efforts to build bridges and providing a
local forum for testing and exchanging ideas).
If there are no full-time positions in these directions, I would also
be interested in suggestions on alternative routes of funding, ways
that would allow me to spend at least one day a week on pursuing my
Petri net related research & development interests while paying the
majority of my bills from other employment.
As one example of a spin-off from personal work that could be of
wider community interest, I am currently working on a simple
Javascript/SVG based Petri net editor: I mostly want to get rid of
the troublesome GUI library dependency for my own CPN simulator,
using a webbrowser as a GUI instead. As I am interested in simple
CPN simulators that can be written by embedding CPN variants into
their inscription languages, it is also important to decouple the
GUI from the inscription language. That way, the same GUI could be
re-used for Haskell-/Erlang-/Clean-/F#-/..-Coloured Petri Nets if
those language communities could be interested in applying CPN
modeling as part of their software development processes.
With some more work, the Javascript/SVG GUI could also be useful for
other groups (an alternative, common GUI, allowing smaller groups to
focus on their simulators and analysis tools), and with more work
beyond that, it opens the possibility of bringing Petri nets to the
web, making it easier to write blogs and tutorials about Petri net
models and their simulations (earlier efforts based on Java- and
Flash-based implementations have not yet resulted in ubiquitous
Petri nets on the web, where the tendency seems to be away from
plugins; the alternative of using animated gifs or sequences of pngs also does not seem to enjoy widespread use, nor does it offer
quite the same possibilities).
Working on my own resources, time available continues to be very
limited and, within that time, I have to give priority to my research
interests, keeping graphical editing features to a minimum and not
spending time on providing standard APIs or on supporting browsers
that I do not use. That means progress continues to be very slow for
me and wider opportunities for the Petri net community are going to be
missed. The same obstacles apply once I get back into the more
interesting issues, beyond the good old-fashioned graphical interface
to a good old-fashioned CPN simulator, but based on earlier
experiences, a tweakable and portable graphical representation seemed
a necessary first step towards presenting and distributing the results.
If interested research groups, projects, and companies, or the
steering group as representative, could allocate funds for
infrastructure and community development in their budgets, and use
those to fund external part-time researchers and developers, those
could then develop open-source components for community use (I expect
that there would be others willing to allocate a day or two every week
to such work, remotely, if the funds can be made available). If this
works out, it would be a more distributed approach to research and
development – groups of part-time workers could make progress where
there isn’t sufficient funding for additional full-time researchers,
or where non-academic workers have the abilities, but cannot commit
themselves full-time because of other demands.
In short, the questions are: can I do research and development in
the overlap between Petri nets and declarative programming
languages, full-time or part-time, while still making a living? And
who else is interested in or already working at the border between
Petri nets and declarative programming languages?
I feel these ideas are important but, without topic-specific funding,
I can only work on them in the gaps between other projects and am not
able to invest the amount of time they deserve.
Looking forward to your suggestions,
Claus
PS. A few more notes on my view of the community communication problem:
Occasionally, I have been able to interest programming language
colleagues to take a look at the Petri net home page and
bibliography, but not one of these has ever returned from there with
surviving interest (as far as I know, the “impact” of my efforts has
been limited to inspiring one dedicated paper and a few publications
mentioning Petri nets as related work, none of which fully explored
the implications).
A couple of colleagues, when asked about this, explained that they
would have liked to investigate further but found it difficult to
relate the specialist nomenclature and concept set used in the Petri
net literature to that used in their own areas of expertise (eg., if
you don’t know what terms to search for, you cannot even begin to
try understanding the relevant publications, and if the organisation
of concepts differs too much, important ideas can get lost in the
translation). So I have come to the impression that the general lack
of interest in Petri nets from programming language researchers
(with rare, but interesting exceptions) is not entirely due to
self-propagating biases towards process calculi or state machine
based modeling languages.
Since I remain convinced of the advantages and potential of Petri
nets in general, and of the combination of Petri nets and
declarative programming languages in particular, I am beginning to
think it is a problem of presentation, mindset, and accessibility.
There is evidence that mindset-related obstacles in the world of
programming languages can be overcome – for instance, pure
functional languages like Haskell force a different approach to
thinking about programming that many conventionally trained
programmers find difficult. With a lot of help from a friendly and
open community, however, even non-academics have seen this as a
worthwhile challenge, tackling of which will improve their general
programming skills, and so this community keeps growing.
Physical accessibility remains a problem. In addition to an
overwhelming amount of publications, there are many good books on
Petri nets, but all too many papers are not freely accessible – even
the PNML standard is hidden behind a paywall. Too many lists of
publications point to paywalls or only provide references to
hardcopies. The books and paper proceedings are expensive and not as
widely available as one might think if one only frequents the
library of a university that has a strong Petri nets group or a
consistent history of buying certain proceedings by default.
That means that privately interested (and privately funded)
newcomers can find it difficult to find enough second-stage
introductory material (beyond the mere definitions) to guide and
motivate them into choosing and buying one or more of those
expensive books, and once they want to delve into details beyond
those books, they run into the next wall (some book authors make
introductory parts available online, and some paper authors make a
copy of their papers available online as well – in programming
language circles, this is the rule, not the exception).
There is also a non-physical aspect of accessibility that links
directly into presentation: programming language folks are used to
active online communities, with mailing lists, wikis, irc channels,
blogs, blog aggregators (feeds presenting updates from multiple
blogs related to the same language), and lots of freely available
online resources, such as bibliographies that link directly to
online versions of papers, code repositories for community-provided
software packages, etc. There are also specialist discussion sites
on which links to new online resources or papers are passed on and
discussed. The vast majority of interested parties, including
privately interested persons and open-minded commercial developers,
are not able to visit the central conferences and workshops in
person and may not have easy access to a university library, either,
so online communities are key to good communication and progress.
Note that I am mainly interested in building _direct_ bridges
between _practitioners_ of programming languages and Petri nets:
programmers and modelers, language and net type designers, language
and net type implementers and tool builders. Theoreticians are often
already aware that programming languages and Petri nets are just
different instances of their theories. But trying to move between
the two fields via their theories requires multiple nontrivial
jumps – busy practitioners (who could spend all their lives just
staying abreast of their own fields) need a more direct route.
Also, precise language definitions and formal semantics are
important, but good online documentation, online examples, and lots
of short online tutorials on all topics, written not only by
experts, but often simply by fellow searchers who run into the same
issues, drive community interest. It is important to present the
benefits and pragmatics before delving into any formalisms, and it
is important that people can communicate with others in the same
learning situation and feel involved in community building.
Where are the Petri net blogs? The net repositories (PetriWeb
content seems somewhat limited)? The tools for hosting Petri net
contents? The Petri net wikis? The links to online papers in the PN
bibliography? Why do not all Petri net research groups and authors
have copies of their papers online (usually permitted for the
author’s home page), to help distributing their results and ideas?
Where are the Petri net discussions (for both beginners and experts,
not to mention specialist interests beyond specific tools)? The
Petri net HowTos (how to model a distributed software system? how to
model a web application stack? how to model xyz? how to apply Petri
net tools and techniques to situations faced by todays programmers?)? Where are the communicators that build on these tools in order to
explain the details and relevance of tricky or formalized
publications to interested practitioners? Is all Petri net
development activity restricted to universities and a few spin-offs?
Is all communication limited to workshops, conferences, and
in-person tutorials? How can non-academics keep up to date with
recent developments, or contribute to spreading the word? ..
One useful starting point might be a collection of survey articles,
providing entry points and guidance about the various areas of
research documented in the publications listed in the Petri net
bibliography. That way, newcomers would at least have an idea what
to look for.
Proofs are availabe.
