Skip to content. | Skip to navigation

Personal tools

You are here: Home / Think Evolvix

Think Evolvix

Deep thought - coherently applying all relevant reasoning - that is what it takes to fully develop an area of Evolvix. Here are some surprising ways how you can contribute.


How to become an Evolvix Thinker

It's easy to start anywhere.

It's a global challenge to perfect,

even if everybody keeps being helpful!

Connecting the dots that matter is all the work.
It sounds so simple. Yet, simplicity is the ultimate form of sophistication, and it requires many eyes, brains, and much expertise!  After all, it is necessary to consider all relevant reasoning that applies to a proposed new feature in order to explore how it fits into the broader context of Evolvix.

Initially, it was not clear if anybody can make measurable progress in refining important features of a language architecture for long-term stability by such intense advanced-stage review.
The most exciting research result from the NSF funded work on Evolvix in the Loewe Lab in WID at UW-Madison is:
Yes, we can - but only with the right combination of tools and approaches!  

Surprisingly, it turns out that broad participation is an important part of it. Many tasks are ideal for beginners. At the same time, highly specialized experts can contribute important review services in their area of expertise. In fact there are tasks for almost any skill level, for very many different disciplinary backgrounds, and for almost all ages from 7th grade students - onwards.
This page offers a one-stop-shop for all you need before deciding about when, where, why, and how you may want to engage to support the unique approach of Evolvix.


A complete description would be a very long book and might read like a

Manifesto for the Importance of Deep Thought.

It would add pivotal sections, explain the role of widely inter-disciplinary (wid) research in facilitating the biodata science compiler construction it takes to enable efficient evolutionary systems biology - but that’s too much for here. Those keen to know more, can jump right in with the following list of overviews of diverse research results produced by the work of Laurence Loewe with various Evolvix Thinkers and other independent scientists:

For those, who wish there was a book to read that offered more background, here is a list that may serve as a start; the most book-like products are the publications in (1) and (6), both worth revisiting.  The last (7th) point in the list below points to the remainder of this webpage (that you are reading right now). It is recommended to read this whole webpage, because it contains a distilled introduction to diverse  approaches that reviewers and other contributors might need to be aware of:


  1. Evolvix BESTnaming and DesignFlip
    These methodology have been reasonably well described in a 2017 study in the Annals of the New York Academy of Sciences, including extensive supplementary material (95 page introduction to these and some other key aspects of Evolvix architecture).
  2. Proposed Concepts
    under review for Evolvix are in the list of Evolvix Concepts published here.
  3. Overviews of research in the Loewe Lab 
    that review diverse aspects of work on Evolvix and its background from different perspectives:
    main Loewe Lab main website
    broader Loewe Lab research overview
    shorter updated research overview of the Loewe Lab
    evolutionary systems biology motivating interests and background
    evolution@home global computing motivation and background.
  4. Diverse scientific publications from Laurence Loewe
    as listed by academic database services like
    Google Scholar, or Pubmed, or DBLP, or others;
    Evolvix would not exist if it was not for the broad diversity of computational biology and evolutionary systems biology research documented in these papers.
    These publications ...
    1. ... add biological depth to the conclusion that biology needs a dedicated general-purpose programming language for making computational biology efficient;
    2. ... document diversity of requirements and use-cases for a broad cross-biology sample of challenges likely encountered by any general-purpose programming language for biology; this diversity is key to avoiding the a priori exclusion of broad areas language designs must address; since no 1 person can meet all use-cases first hand, in-depth familiarity with more diverse ones simplify language design: it is easier for architects to add key details by interpolating between ‘language pillars’ when reviewers point those out late; the same is harder or impossible when broad ‘pillars’ are missing from an architects’ conscious awareness; see more on the need to review early and review often under ‘random collision of ideas’;
    3. ... represent a key part of the training record for the Evolvix Core Language Architect (Laurence Loewe); it is impossible to work on a language without making architectural decisions (as known by all language developers);languages aiming for long-term backwards compatibility with the methodology pioneered by Evolvix require one core language architect; its task is to decide when a foundational aspect of the language has reached the stability required to serve unchanged over the long-term (and is, thus, ready to freeze). Making this call responsibly requires a steep learning curve. Much of it is documented for the 2-decade-long training of the Evolvix Core Language Architect. It is unclear, if shortening this duration is possible without sacrificing essential breadth or depth in training - and likely resulting in language blind spots likely to haunt users with complex biodata science requirements;

  5. Evolvix Design Decision Discussions (EDDDs)
    EDDD files and notes are another essential source of core information about Evolvix. Some of them are part of the Core Language Architect training, especially when new designs are explored, e.g. by reading relevant literature. However, many more jump right into the architectural design work required for exploring the space of ideas that need to be explored for developing groundbreaking innovative designs. These materials contain the most complete current overview of the Evolvix language architecture. 
    For conceptual and technical reasons, it is impossible to make this large quantity of materials openly accessible on the web easily. Moving as much EDDD online as possible is an important goal for Evolvix development, but doing so efficiently requires addressing a number of design challenges themselves. Hence, it has to remain open at this point, when most of these materials might be able to move online. 
    In the meantime, if you think that your review of these numerous design materials could significantly advance the design of Evolvix, then you first need to convince the Core Language Architect of Evolvix that providing you with such an overview is not wasting precious development time. You will have to become thoroughly familiar with the foundational Evolvix BEST Names paper (see above), you will need to demonstrate some design skills by suggesting a few clear improvements to designs proposed in the BEST Names paper), and you will need to provide a list of reasons for why it might benefit Evolvix to invest the several days of valuable development time in order to provide you with this costly overview. Send all this with a bit more background about yourself in an email to and prepare for having to do a bit of convincing if you really want to jump in at the deep end of Evolvix architecture development. 
    The usually more efficient and certainly much gentler approach for most people to contribute to Evolvix development is described below in more detail. Evolvix can massively benefit from an extraordinarily range of expertise: most native English speakers who have read as far as this statement on this webpage are more than qualified for being highly efficient Usability Reviewers; in addition, many can easily offer assistance as Expert Reviewers to compensate in one of the many areas of human expertise not known to the Core Language Architect from first hand experience. If you are interested, please read on and send a note of interest as described at the end of this page.
  6. The FlyClockbase study (2017), 220 pages on BioRxiv,
    which is currently in the process of being transformed into a series of 16 papers on important concepts for shaping the future of biodata science. It describes an advanced wid compiler construction process for exploring a the random collisions of ideas described below in some particular way. More details upon request.
  7. The remainder of this page (sections below)
    and other pages on this website, such as the title page and a page with more in-depth information about the DesignFlip methodology.


Please do not feel that you have to study all of linked information above for productively contributing to Usability or Expert Review. Reading the rest of this page should tell you enough of what you need to know; hence, keep going if  you wish to engage as some type of volunteer reviewer after reading the rest of this page. All other relevant Evolvix background will be provided for you at the time of review on an as need basis.

Starting to Think in Evolvix Concepts


The following points provides a small journey into some concepts and approaches that shape how models are constructed in Evolvix, and by extension, how Evolvix is being constructed in order to support more efficient modeling work. This composes thoughts from a number of texts and offers extensions in order to facilitate whether you might want indeed to get involved. 

Simply put, we start to explore the world around us by using Evolvix Concepts. It is best described accurately how it is, and not how it 'ought to be' when we record observations or make measurements. The same commitment to accuracy is also important we use our intuition to develop our notions about what might be going on in a system of interest to us. These "notions of what might be going on", are for our minds what a "Model" is for Evolvix.


Often, our mind can imagine what might happen next, because we know enough about "the rules of the game". We can sometimes even continue to play out longer scenarios and thereby anticipate surprising outcomes - if we can track all relevant details. Yet, as hard as it can be to accurately predict how complex situations unfold, as easy it is for all of us to do so on a daily basis. We tend to think about it as much as fish might think about water, but we carry a pretty impressive supercomputer between our ears that comes with a free, built-in mental 'forecasting machinery'! And while we all have complaints about things we can't (or couldn't) predict, it can be good to occasionally ponder the jaw-dropping amount of correct predictions and complex analyses most people take for granted. We all routinely analyze many what-if scenarios for ensuring our "simple" day-to-day decisions are as reasonable and as responsible as we can make them. This would be impossible without building on our inner forecasting machinery that anticipates likely consequences of decisions in order to improve their quality. We couldn't even make it through kinder-garden without this general ability to forecast at least some future events with this hard-wired internal machinery that shows some interesting parallels to what Evolvix does!


In a similar way, Evolvix can forecast some future events. To do so, it requires a Model that describes all Parts that matter for a system we are interested in. We then describe at which intervals recurrent Actions in this system keep changing the respective Parts they affect. Maybe we also want to highlight interesting Parts for observation, so Evolvix can extract and show how their amounts change over time (simply for convenience). That's it - typed up in a plain text file. Now Evolvix can get to work. First, the Evolvix Compiler will read it all in, analyze our Model, connect all its loose ends, check for some errors, and then transform our Model into a form that is more suitable for our designated Evolvix Simulator. Such a simulator has code, carefully designed for using the best mathematical methods in order to simulate what happens next, step by step. Overall, it's fair to say that Evolvix relies in it's built-in rules for spelling out all necessary details that are implied by our more concise high-level descriptions of the Actions in our model.


Analyzing levels of abstraction across the systems above: we can use Evolvix to expand our thinking capabilities, because in important ways, our minds and Evolvix think alike! This remarkable similarity applies at least to the abstraction of time series, which describe, how much amounts of Parts in a system change over time as Actions occur. This shared abstraction greatly simplifies comparisons between the timing of amount changes we might intuitively predict to happen over time, the changes Evolvix predicts to happen over time, and the actual changes over time that we can observe in our real-world system of interest. Let's combine these abstractions with the general insight that everything that exists or happens in any physical, chemical, or biological system can always also be described in the form of a time series (even if that is not the most efficient description we might naturally choose). Integrating all this information is greatly simplified by the shared abstraction of how the amounts of Parts change over time. We merely need to precisely define all equivalent quantities and how to compare them! Such comparisons unlock access to something new entirely! Enter the idea of triangulation as used in the social sciences.


Triangulation is a powerful approach for investigating the unknown. Long used in spatial surveying by determining the location of unknown points, a more general notion of triangulation was adopted in social sciences for investigating phenomena that are hard to pin down by a single method. This is the sense in which we use triangulation here: it's a natural, robust approach for determining how much wiggle-room remains for re-interpreting evidence on an underpinning invisible reality that can only be observed indirectly. To triangulate, completely different, independent approaches are required for observing the same system. Each has its own biases and blind-spots, revealing the invisible reality only in part. Yet, by combining serious investigation from different perspectives pushes back the veil of invisibility for a better rounded, more reliable view of the system studied, whether social science phenomenon or unknown dynamics of biochemical reaction networks. It may even be used naturally by children asked to keep a new incomprehensible rule for reasons they don't understand; they may need to hear similar explanations from independent sources like their mom, dad, and trusted aunt, before their innate 'evidence checker' can accept it. Thus, it's a strength to use more diverse methodologies for developing an integrative view of otherwise invisible aspects of reality - assuming a framework exists for handling contradictory evidence that might be encountered. Enabled by this broad view of triangulation, let's revisit what happens when we independently forecast what may come next by methodologies as diverse as the mathematical approach used by Evolvix and our brain's intuitive supercomputer.


Evolvix aims to support different types of triangulation that are highly informative. After learning to read the signs, it is usually very instructive to compare our intuitive Model expectations with the mathematical simulations in Evolvix that build on the best Model description available so far. The comparison is possible, because both convey their output through the same abstraction of time-series. Otherwise these two approaches could arguably not be much more different - from implementation to the complementarity of their strengths and weaknesses. 

Our brain's intuitive approach to prediction can sometimes easily highlight when 'something  is off', and thereby trigger the work required for identifying well-hidden problems in simulations; if we start with simple models and keep getting to the root cause of discrepancies we observe, we train our intuitions and progress on our way to becoming experts. If we keep learning in that way, we might even develop such deep intuitions about the inner connections of models in our research area, that we can predict more accurate answers by intuition than less knowledgable experts by long-running simulations. Thus, intuitive predictions are often used by world experts for quickly proposing and evaluating promising research directions. Such use of their intuition is possible, because they spent much time to carefully train their intuitive insights by pondering the details of modeling situations, where their intuitions broke down. Experts in their area usually learned the hard way or the smart way, where trust in their intuition would be misplaced. This ability of experts to know when more rigorous simulations are required, is less pronounced at the margins of their area of expertise; in other areas it may be missing entirely. Experts have mapped the unknown in their area, while beginners tend to be excited about the many new possibilities they discover. Therefore, expert tend to apply the caution required for using intuition, while experts-to-be easily get carried away by they not-yet-well-trained intuitions. Thus, by and large, much caution is appropriate when evaluating any intuitive claims: chances are that the intuitions of others are quite useless. 


Two Evolvix Simulators for contributing to triangulation. Evolvix already comes with two simulators, that build on two completely independent software stacks and differ in whether they assume that individuals in simulations remain divisible (without killing them!) or not. Each simulator has an independent approach to simulating a given Evolvix Model (that is formulated as a so-called Continuous-Time Markov Chain (CTMC) model). The shared CTMC abstraction of both Simulators serves as conceptual point of integration. However, it is up to us as users, to describe this CTMC model as an Evolvix Model, about what we think is going on in those systems that interests us. This intention to spell out in the Evolvix Model source code what we already think about in our Minds, serves as additional point of reference; if all went well, going back and forth should be straight-forward!


Yet, despite all training we may have, our intuitive predictions are usually not quantitative enough to be of much use on their own: it is much too easy to forget obscure quantitative aspects or to mis-estimate, where the results of a more exacting analysis will appear. These difficulties might be manageable for very simple models in the hands of very experienced modelers; yet, by and large, biological systems of any interest tend to be much too complex for intuitive assessments to be reliable, even those of the most experienced modelers on the globe. Thus, independent approaches are essential and many researchers have been looking towards mathematics, for identifying systematic mathematical approaches that offer reproducible and rigorously justified alternatives to our brain's more intuitive approach to predicting future events. Modularity plays a particularly special role in this context. 


When constructing a model, the fastest approach is often gradually build it up from simpler components that are easier to understand intuitively. As the models we build become more complicated, it becomes increasingly important to check for errors and potential discrepancies between our expectation and the actual simulation results. During modeling it is a wide-spread practice to intuitively anticipate what can happen next, based on the best mental model we can think of. Then, we compare that to what Evolvix predicts from radically different approaches implemented by computer simulation software like Evolvix. How that works conceptually is worth considering a bit, because major insights about how to divide up work between human operators and they machines they control (in principle).


After describing our model's details in a simple plain text file, Evolvix takes over and determines what happens next. This is one of the most fruitful and exciting parts of building models if done right.

Checking for errors comes first. More often than not, we, the people, forget something: a typo here, an omission there, and pretty quickly, it can get very confusing. Mostly, that is because Evolvix cannot see what we mean by reading our minds (thankfully, phew!). It can only interpret - very literally - what we typed into our Model. This general limitation is in place, because computers are both: perfect servants that quickly do exactly what we say, and also, complete idiots when it comes to interpreting what may have been meant. Our modern word 'idiot' is derived from the ancient Greek word for 'private person'; it perfectly illustrates what computers always do: they only ever follow their own private rules for interpreting any instructions they receive - without any regard at all for whatever the consequences might be. "What do you mean 'not crashing that plane into the ground'? I was only following orders ... that I received at the time and interpreted exactly according to the rules I had been given. 'Crashing' was neither mentioned in the orders nor in the rules! " An idiotic 'explanation' like this one is, unfortunately, the truest and only ultimate explanation people can ever get from a machine - if people could ask the computers that triggered the two dramatic crashes of new planes shortly after take-off. It's worth to dissect this idiocity for a moment, because it encapsulates important lessons for how to better structure interactions between computers and reasonably intelligent, responsible people of flesh and blood.  





For example, in Evolvix any Model is simply meant to mirror, what its equivalent system does in the real world. For Evolvix, such a Model is build by describing the Parts and the Actions that matter in a real-world system of interest. Hence, pick any system in which some of its Parts can change over time in a way you care about. List all Actions that are connected with that change of Parts, directly or indirectly. List all Parts affected by each Action and make a reasonable guess about how often it might occur. Combine all these descriptions in a Model by using the quite straight-forward Evolvix grammar for describing Parts and Actions. Now you are almost ready to simulate in your computer, what the real-world system might do next - that is if indeed you listed all Parts and Actions that matter for your system of interest and your guesses were reasonable. All that's left is to enter your descriptions into a simple plain text file and tell the latest available Evolvix system to report a time series that documents how the interesting Parts in your Model change over time. Download the latest Evolvix prototype here, and check the manual for details on its grammar for writing down a model


Congratulations, you did it! You are now well on your way to become an                                      Evolvix Thinker!
Why?      Because you started to think about something while using terms that are defined for Evolvix!                      
This would even be true if you only made it half-way through the example above! That's because any type of thinking linked directly or indirectly to Evolvix is sufficient to turn someone into an Evolvix Thinker. 

Why such a broad definition? Shouldn't Evolvix Thinkers have some results to point to, such as constructing a correct model? The answer is a resounding: No! It would cripple the development of Evolvix and lead to many unnecessary confusions. For starters, all models of reality are wrong, only some are useful; hence, nobody could ever become an Evolvix Thinker if correctness was required. Lowering the bar to "usefulness" doesn't help either. It is too hard to define "useful" in the context of challenging Evolvix language architecture development work. Formally defined "useful advances" easily overlook large amounts of hard work with negative results, while making it too easy for those who tend to game systems of evaluation in order to appear more successful. The creative diversity of work required for successful modeling is not easily captured by formal criteria, which can unduly praise the usefulness of modeling results, even though these were obtained by trivial work in a generally uninteresting system. 





All relevant reasoning...?

Sounds great, but isn't it a bit too hard to aim for the inclusion of all relevant reasoning? There is an enormous amount of knowledge from an overwhelmingly large number of disciplines out there and applicable reasoning could be found anywhere. So, it seems reasonable to question this aim.

Why this aim matters. It's key to remember that Evolvix is being designed by biologists for biologists in order to simplify accurate modeling. An important insight resulting from this work was the need for general-purpose programming capabilities in any declarative modeling language (like Evolvix) that aims to simplify the analysis of biological simulation results as well. Focus on biology's requirements for modeling in Evolvix may seem like a simplification, suggesting to skip complexities of other disciplines. However, that would ignore the following insight about the nature of biology.

Biology is the discipline of diversity, of complexity, and of almost all conceivable exceptions to the rules. Of course, biology is first and foremost about studying (carbon-based) Life on Earth. It just turns out that Life on Earth is so diverse and so complex that it applies almost any rule conceivable, including almost all exceptions imaginable. Thus, in first approximation, a general-purpose programming language for biology can't afford to ignore any major approach that has proven useful for interpreting complex patterns observed in any discipline - chances are high that similar patterns have already been found in some area of biology (or will be found) and that it will thus show up as a use-case for any language claiming to offer general-purpose programming capabilities for Evolvix).  Does that render hopeless any attempt to define a general language for biology? Fortunately, biology has long been facing similar problems and thus found ways for continuing productively.

Biology has developed methodologies for venturing into such a vast unknown. For example, as biologists we use them all the time when measuring the unknown size of a new population of some species.  The problem is tricky because it is impossible to track all individuals. So what do we do? We apply the well-known mark and recapture technique.  It’s secret is to observe individuals as they come along and mark each one with a unique tag for re-identification. Then, as a significant part of the population gets marked, individuals who already have been marked begin to reappear.  The observing biologist keeps track of these rates of reappearance which allow, with some statistical inference, to estimate how many individuals are out there that have not yet been marked. Methods like these all have their assumptions, such as a near random mixing of individuals in such populations.  However, there is no reason why the principles cannot be applied to different settings where novelty is estimated. In biology, they have been used to estimate how many different species might exist in various contexts. There is no reason to assume these cannot work in principle to measure progress towards identifying all relevant ideas for a given topic.  Obviously, the assumption of random mixing is important for this approach and obviously, ideas in one person’s mind are not randomly mixed. That is where diversity and collaboration come into play: every person brings their own view to a given topic. The more diverse the background of persons, the more diverse views on a given topic they will likely hold. Thus, more eyes from different perspectives on the same topic will improve the overall better mixing of ideas and thereby accelerates the goal of looking at all relevant ideas. Therefore, this approach could also be called by what it facilitates: the Random Collision of Ideas.

The Random Collision of Ideas

It doesn’t matter where the ideas come from or how polished they are, as long as their applicability to the topic can be recognized and someone can track whether this idea has been explored before in this context.  Therefore, the key ingredients for accelerating random collisions of ideas are:

  1. Input from more diverse perspectives reduces the waiting time for new random collisions 
    Random collisions are more likely when input is more diverse than from a group of persons with similar perspectives. Contributions can take many different forms: from fleeting comments to in-depth discussions, from email replies to books on the topics. The form does not matter, the substance of the ideas does.  

  2. Broader inclusion helps to detect the unexpected
    Obviously not all topics are relevant for all other topics, so some limit for the useful inclusion of diversity likely exists. However, in the absence of certainty, it is better to air on the side of exploring more broadly as a powerful method for facilitating the discovery of unexpected contributions. Examples abound throughout research and are particularly tangible in technologies inspired by nature.  

  3. One place to track progress
    Exploring and reviewing new perspectives as described above (see 1, 2) would continue indefinitely or until exhaustion. To turn it into a systematic search methodology, a place of a decision must determine when to stop in some principled way. The pragmatic approach taken by Evolvix is inspired by the mark and recapture principle pioneered in biology: if an applicable idea has already been seen by the brain responsible for architecting corresponding features, then it counts as ‘marked and recaptured’.

  4. When to stop
    Given the challenges of formally annotating ideas, it is currently impossible to derive a rigorous equation for calculating stopping points of comparable quality for different features. Therefore, in Evolvix, the decision to finalize important parts of fundamental language design is made by the Core Language Architect. It is a call of the person in that role to decide when sufficient conceptual integration has been reached and clear enough words have been found for expressing those concepts unambiguously in the broader context of Evolvix language design.  

  5. Milestones
    Ingredients 4 and 5 above are fastest while inside of a single brain where possible without compromising rigor. Outside feedback and review is then only invited by the Core Language Architect for resolving questions that do not already have obvious answers. To avoid confusing ad hoc nomenclature or “this” vs “that” idea comparisons and to measure progress towards long-term stability, work on Evolvix has led to the definition of a Stabilizing Versioning System (StabVS) as described elsewhere. Its double-caps prefixes range from 

          MockupModel (MM) to
          ReviewedRelease (RR

    and document how far in the professional assessment of the Core Language Architect a given feature design has progressed. While BaC OLT needs to be envisioned from the start as a goal, it is still impossible to make any BaC OLT claims for RR releases. Think of them as typical production-grade software that should work reliably as it is, albeit without any claims about the future. However, if a Core Language Architect has been doing their work, any such releases are serious candidates for the next levels and RR merely serves as an additional extensive review-stage in the wild that preserves some maneuverability in case important aspects have been overlooked. The precise steps for reaching the next stage have not yet been defined precisely enough, but will certainly involve additional extensive opportunities for review and feedback. The intention is to publish the next level,

          StableSource (SS

    only, once there is no reason to suspect that any more changes will be necessary; so SS is intended for all practical purposes to as good as TT, but there is no guarantee.

          TrustedTested (TT)

    is the last stage that can only be reached after very extensive review and input. It is the main job of the Core Language Architect to protect code at this stability level to accumulate any avoidable complexity. Reaching TT completely locks-in all defined ways of using a TT feature, as well as what exactly it means to do so. To reach TT, after sufficiently extensive review, there has to be a  committed Core Language Architect who has to vouch for the stability of that feature, not by mere fiat, but by having reached the well-argued conviction that this feature can no longer be improved in how it contributes to the language in its broader context.


Why are there unpublished Evolvix Design Decision Discussions? 


An accumulation of Evolvix Design Decision Discussion (EDDD) materials is a natural consequence of the following hierarchy of velocities that are all required for efficiently processing ideas for Evolvix: 

    1 speed of thought        (evaluate idea in brain)              exceeds 
    2 speed of talk               (quickly explain to insiders)        exceeds
    3 speed of pencil           (fleeting sketch on paper)           exceeds 
    4 speed of rough doc    (too confusing for sharing)          exceeds
    5 speed of clear draft    (enabling reasonable feedback).

Publishing EDDDs on the web makes only sense for (5), as ideas have to be described well enough for efficient review by external experts. By their very definition, external experts do not work on Evolvix non-stop, and hence will have a rather limited capacity for commenting on the many small decisions required for a design that works. Thus, limited reviewer bandwidth and the slow speed of refining EDDDs for external review conspire to create a bottleneck. This bottleneck naturally keeps most ideas on internal rough docs. Rough docs are sufficiently clear to allow the core language architect who wrote them to quickly reactivate the ideas they contain. This usually only occurs, if they fit well into a broader design that is worth reviewing more thoroughly. Usually, problems in isolation are easily solved in many different ways; however, finding solutions of sufficient quality for long-term stability tends to be much harder. 
The gradient of ideas considered for vs ideas included in is particularly steep for Evolvix, because of the immense importance for Evolvix to stay BaC OLT

      BaC    =   Backwards Compatible 
      OLT    =   Over the Long Term. 

Remember these shortcuts.
Evolvix discussions use them a lot.

It is not clear if over 95%, 99% or 99.99% of reasonably good ideas relevant for designing a particular feature of Evolvix language architecture should never end up as long-term stable in Evolvix; the precise fraction is also irrelevant and likely to vary from feature to feature. 

What remains is the strict requirement to identify the best of all possible approaches for expressing a given functionality in the overall context of the Core Evolvix Syntax and its various requirements, ideally while adding no avoidable complexity. Such avoidable complexity is the ultimate poison of all languages that remain extensible. As they accumulate features OLT, their complexity increases. Without rigorously removing all avoidable complexities from their long-term code base, the cognitive load of using or maintaining it keeps rising until its burdens outweigh benefits. It then retires to ‘legacy status’ and ‘fossilizes’ when it stops running on current operating systems. It usually takes on the order of a couple of decades before such death by complexity occurs. 

Biology has been paying dearly, because the death of languages has been killing OLT uncounted applications managing even more biological research results. The complexity of many interesting questions in mechanistic EvoSysBio effectively places them outside of our reach if we continue to waste research efforts OLT on such large scales because our implementation languages struggle to stay BaC OLT. The problem is not easy to fix.

Evolvix aims to eventually offer a credible alternative for biologists who wish to save their research results and modeling code from fossilizing with many of today’s popular language implementation versions (some of which will likely survive by breaking backwards compatibility for some of their features). 

There are enough great open source programming languages out there for those who need a language now. Evolvix also offers some elegant solutions within its domain (i.e. efficiently recording time series output from pure mass-action simulations). Yet, for biology as a discipline OLT, those benefits pale compared to the question of whether Evolvix can deliver benefits reliably OLT. 

Thus, at least for architecting a core language infrastructure for Evolvix that can support EvoSysBio OLT, it is more important to find stable high-quality solutions that are worth implementing, than to implement faster a hurried design that was not been sufficiently reviewed to get a reasonable chance at staying BaC OLT.  Sometimes, slower is faster. Maybe this observation was made often enough to even inspire the old story of the Hare and the Tortoise


Are you interested in supporting the Evolvix approach of evolving by participatory design and before implementation, slowly and steadily, a set of high-quality language features that aim to keep Evolvix stable BaC OLT?

Then please read on for exploring how to best contribute in either of the two most important external roles, namely as a 

  • Usability Reviewer (in any area) or 
  • Expert Reviewer (in your domain of expertise).

To understand this special type of work, you need to understand a bit more about the background.


Therefore, the most important contribution you could make for advancing Evolvix, is to serve as a volunteer reviewer of language feature proposals to assist in deciding their fate, usually long before they are to be implemented. To do so, see below for how you can signal your availability as a

  • Usability Reviewer, for discussions of how user-friendly a potential language feature design might be (no particular expertise required, ideal for newcomers in many respects; sometimes for efficient review, complete newcomers are also required, because they cannot program - since Evolvix aims to develop efficient approaches for teaching non-programmers how to jump-start the growth of their coding skills;
  • Expert Reviewer, for discussions reviewing detailed questions of how to design or implement solutions that build on expertise in their domain (you have to register at least one domain of expertise and self-rate your skill-level on a scale from 9 to 1 (where 9 is for leading word experts and 1 is for beginners with no skills yet, but a huge desire to learn and time to do so if pointed to introductory material; 0 on this scale is the usual default for all areas of expertise not specified by an expert: equivalent to usability reviewers, this not only implies beginner status, but also a near-complete lack of interest in developing any expertise beyond seems to be completely obvious already anyway - no patience for any learning). 

After your area of review is registered, the Laurence Loewe, the Core Language Architect for Evolvix, will contact you for setting up a Skype meeting (or equivalent), when there is something to be reviewed in your area of interest.



Decisions on the way to becoming an Independent Volunteer Reviewer for Evolvix

In addition to deciding on which type of review you may wish to offer (Usability or Expert), you can customize if there are particular areas for reviewing you may wish to highlight. Please also consider the options for customizing the times and types of review capabilities you may want to offer and where in the life-cycle of ideas you may prefer to get involved.



Is it better to get involved earlier or later in the life-cycle of feature ideas?

It depends. When signing up, please indicate, if you have an interest in fast-moving, early stage discussions of feature development. To efficiently review at early stages you need to be able to work with the style used for getting this work done. While details may change and can probably be improved, the following broad generalizations might help you to make a decision. 

  • You have to be comfortable with review discussions that can be rather unstructured, serendipitous, and move at a high speed across diverse topics linked to the features discussed. 
  • Consider if the necessarily very informal nature shaping such discussions actually works for you. From experience, this is not for everybody
  • Can you welcome such heterogeneity? How hard can a problem be without becoming too frustrating and it overtaxes your patience in search for solutions? Tom Edison tried thousands of combinations and ideas, before they got a working lightbulb. How many ideas can you explore before you might run out of patience? The Evolvix default approach keeps harder problems for those who indicate where they might have picked up the experience to handle the territory.
  • Are you motivated by the chance for an opportunity to observe feature growth first hand (and maybe even influence it)? Do you enjoy observing how ideas for Evolvix are being shaped as they may or may not grow into full language feature proposals (offered only later for broader review)? 
  • These very early, informal stages of review may offer excellent training opportunities for student volunteers interested in deepening expertise or filling gaps between areas they already studied so far. 
  • Likewise, these early stages also invite pitches of ideas from programming language experts or domain experts, who may not have the time for discussing other features, but would like to propose for potential inclusion by Evolvix any solutions they developed for avoiding at the level of language architecture design any programming-related or domain-specific problems they have come to know first hand. 
  • Other types of similarly informal pre-discussions (in addition to those above) were found to offer extraordinary efficient ways for improving Evolvix; sometimes they can be so flexible, that they might even mix review of features in some areas with brainstorming in others.

Therefore, please indicate to what extent you might be available for such informal discussions. Essentially, the earlier in the design process you can contribute, the more Evolvix will likely benefit from your input - if you have the time and patience for working with this necessarily somewhat peculiar format. If you're still undecided but are willing to experiment a bit via Skype, please say so. It's easy to test how well it works for you.  


Signing up 

To sign up, please send an email to , where you clearly indicate:

  • Your decision to become an Independent Volunteer Reviewer, either in the role of Usability Reviewer or Expert Reviewer or both; 
  • Potential areas, domains, or types of features you might be willing to review (be as general or as specific as you may like);
  • How much time might you be willing to volunteer for the role you defined (per week, month, or per year)? Any preferred times for contacting you during a week?
  • Are you interested in early-stage discussions (see above for details)? Unless you say otherwise, the default is to assume no, and there by only contact you at a later review-stage. 
  • Please never submit what Evolvix can't use! It does not matter how elegant or important your idea may be: if intellectual property is involved that you are not prepared or empowered to share with all Evolvix users, then Please Do Not Submit! However, if you feel strongly that an exception should be made from this no-submit rule, then you will be expected to ask for permission first. Please always clearly ask for a specific one-time permission to submit materials that require any exception from this no-submit rule above. Briefly describe, why you still think Evolvix should expose anyone of its architects, developers, or users to the complications imposed on those who see them. Please clarify your recommendations for how to cut all risks from accidentally violating intellectual properly rights linked to your submission. 


After sign up, you will be contacted about:

  • ECLA to sign, the Evolvix Contributors License Agreement (or a Temporary variant while work on the final one goes on). The ECLA (or for the time being the TECLA) clarifies the rights and responsibilities of all parties involved. Most people lack patience for legalese; if that's you, here is a ECLA oneliner: don't submit what you are not happy for Evolvix to release as open source software under any OSI license, don't teal code, you grant Evolvix all rights it needs for using your contributions, you keep all your rights (except for the right to stop Evolvix users from using what you donated). 
    It's text has been refined to a high degree, yet still requires a few finishing touches before locking it in; please get in touch if you would like to assist with finalizing this legal agreement that aims to combine the best properties of existing CLAs in order to generate a legal basis for releasing new code in any combination of open source licenses (which might otherwise not co-exist within one project). Think of it as being currently in an early draft form that aims to evolve into a CreativeCommons styled license for source code.  
  • Relevant Review needs in your area when Evolvix has something for you to review; pending on a multitude of factors, it may take a long or a short time, until you get contacted for reviewing anything; hence don't be surprised if you might not hear anything for a while. In the mean time, 
  • Please feel free to adjust as many times as you may want your declared areas of expertise to which you may be able to speak, or which you may be willing to contribute as a reviewer with your focus.

Become an 
Evolvix Thinker! In return for volunteering your time you can become an official Evolvix Thinker, including an entry on the page of Evolvix Thinkers - if you would like that. That page is evolving in order to find a good format for allowing you to add a brief description of your relevant expertise that you contribute to the army of reviewers who continue to improve Evolvix.