Some of the biggest hindrances are bugs that are in fundamental functionality and impact almost every network analysis workflow.
For example, using VertexAdd/VertexDelete/EdgeAdd/EdgeDelete is like walking on eggshells. Unless one is extremely careful, they will silently break something in the internal representation of the graph and will prevent other functions from working several steps later. (This typically happens when properties are present.)
There are also instances of problems which have been reported as far back as v9, but are claimed not to be bugs, despite making practical work very inconvenient. For example, this takes ~30 seconds:
g = GridGraph[{50, 50, 50}];
NeighborhoodGraph[g, 123]; // AbsoluteTiming
This is equivalent, and it is instantaneous, as it should be:
AdjacencyList[g, 123]; // AbsoluteTiming
{0.000173, Null}
Subgraph[g, Append[AdjacencyList[g, 123], 123]]; // AbsoluteTiming
{0.000675, Null}
Why is NeighborhoodGraph
so slow then? I cannot understand how this is not considered a bug.
Another example is Graph[KaryTree[5], VertexStyle -> Blue]
, which mysteriously doesn't evaluate. There's something wrong with the output of KaryTree
. This works with almost any other graph. When I originally reported it, I was told that this is not a documented syntax of Graph
, so not a bug. I had to point out that if I use Graph3D
(explicitly used on graphs in the documentation) instead of Graph
then the same thing happens ...
But the point is what makes practical work easy and possible and what makes it painful, not the precise phrasing in the documentation. Imagine working on a deadline and hitting these sorts of problems one after the other, always having to stop, backtrack, and find out what exactly went wrong.
Yet another practical hindrance is the bad state of import/export formats. When doing network analysis, it is important to have an exchange format that can encode edge and vertex properties. The two common formats that are also supported by Mathematica are GML and GraphML. Trying to export an edge-weighted graph to GML results in a flood of error messages. Edge weights are the single most commonly used property ... As for GraphML, its implementation is not standards compliant, so most other programs won't read files written by Mathematica (even if they would, properties are written in Wolfram Language syntax, and would need to be parsed... other programs won't understand 3.14`
with the backtick at the end). Also, reading GraphML is very slow, and not feasible for as few as a few thousand vertices. All this means that I must always resort to workarounds like storing a single graph in multiple CSV files (not a graph specific format, so often a single file is not sufficient for one graph).
I think what is really missing, in addition to resuming development of this functionality area, is for developers to actually observe how people would want or need to use the system. See how people do network analysis in Python or R with packages like networkx or igraph. Is it possible to do the same task in Mathematica? Usually, it's painful, and it's not even because some graph algorithm is missing or buggy, but because the very basics are broken: import/export, data cleanup, property handling, trivial graph manipulations such adding or removing edges/vertices. Very basic operations such as directed/undirected conversion, reversing edges, taking subgraphs, etc. become unreasonably difficult for edge-weighted graphs, not to mention other stored properties. There isn't even a good way to check if a graph is edge weighted (!!) or quickly remove edge weights from a graph. These sorts of things are what take up the bulk of the time in everyday work.
Yet another complaint I have is that even though a lot of work went into implementing certain functions, they are not properly documented and therefore practically useless. Consider FindGraphCommunities
. Community finding is not a mathematically well-defined problem. What the function does is basically defined by the algorithm it is usingbut this is not documented at all. Results obtained with this function are unpublishable because we literally don't know how the function works. A few references and better documentation could go a long way. Compare functions like Integrate
, which don't have this problem: I do not need to know how Integrate
works to understand what an integral is, or to be able to verify that the result is correct. I do need to know how FindGraphCommunities
works to be able to make any use of it.
The situation is disappointing because otherwise Mathematica contains a very competitive set of network analysis functions. Until recently it was not easy to find all these integrated into the same system. If the reason why development stopped is that people were not using Mathematica to work with networks, that's misguided. If people don't use it, it's because of the problems I described above, all of which are fixable with much less effort than what was required to develop Graph
in the first place.
Finally, one of the biggest practical problems is that property handling for multigraphs is completely broken due to a fundamental design problem: edges are identified by their end vertices, which makes parallel edges indistinguishable. This is of course not going to be easy to fix.