- The minimal required Java version 1.8 . Oracle has dropped support for older versions long ago
- Website makes minimal use of CSS3, but older browsers should still be able to use the website.
- Internet explorer is not supported, because Microsoft stopped developing it.
- We did not test website for Safari and Edge, but they should work as well.
- build system and commandline interface works on all systems that can run Java. Embedded devices are not supported, as such a use case is unlikely. In the future we might add lightweight runtime that can execute automata on embedded envronments.
Justifications:
- initially we started writing compiler in C for best performance. Over the course of development it turned out that performance gains were minimal compared to Java, while the speed writing C code was much slower compared to ease of higher level development in Java. Moreover, the Samsung infrastructure heavily relies on Java and we found out that Java libraries are always preferred over C. Later we also established cooperation with LearnLib from Dortmund university and their entire library is written purely in Java. Hence we decided to switch to Java for better compatibility.
- we decided to make a website, because this technology is universaly accessible to everyone. A mobile app would require installation (and touch screen would be uncomfortable for writing regexes), command-line interface is only accessible to advanced users and desktop GUI apps require downloading, installation and setup. An online REPL would make Solomonoff easily accessible to masses.
- The build system was implemented in Java for compatibility with compiler backend. It is primarly targeted at more advanced users and large projects. Build system allows for working with multiple files, which extends the compiler backend that is only capable of working with monolithic streams of code.
- We considered using user authorization but we decided to keep it simple. Cookies and downloads are out only mean of permanent storage. Hiding our REPL behind "login wall" could potentially turn away some impatient users. There are many demo websites similar to ours that follow similar strategy and don't retain any user data.
- There are plenty of compiler features that we purposely did not implement. We do not support probabilistic automata, because their semantics tend to be unpredictable and difficult to control by regexes. We don't allow epsilon transitions and it allows for many optimisations. More such examples and technical details can be found in our documentation.
- Build system does not support namespaces. Instead we took approach similar to C, where "modules" are not a first-class language feature and are instead based on naming convention. When it comes to language features we are strong believers that simplicity and follow the mantra of "less means more".
- create multiple independent instances of compiler that can work in parallel
- Build system
- load one or more files
- use transducers defined in other files
- compile files in project in parallel
- define list of source files in build configuration
- store many independent configuration files, even in the same directory
- run REPL after building project
- Online REPL
- open website and follow tutorial (shows additional tips for first time)
- compile a larger piece of code and then experiment with it in REPL
- compile code line by line in REPL
- read the technical documentation
- reopen website and continue where you left off (depending on time limit some things might be lost. The server should not store compiler instances indefinitely)
- download work progress locally
- go to GitHub page/download compiler and build system JAR
Initially our team attempted to use Scrum, but later we switched to incremental methodology, because workflow relied heavily on specification and long-term planning. Scrum's main advantage lies in its flexibility, which wasn't the key for this project. It also imposed unrealistic and unnatural team dynamics, which only made work more complicated than it had to be. Scrum gives all team memebrs high degree of independence and autonomy. In scrumchat, implementators describe the progress they made. On the other hand, in our project the specification is more rigid and work progresses according to it. Hence, it's always well understood who does what at which moment. The future tasks are generally known ahead of time.
We created a full detailed list of planned tasks at the beginning of semester and tried to follow it, but we also added more unforseen tasks on the rolling basis according to necessity.
Every task corresponded to some palpable feature and its implementation allowed for closing the task.
- The most important risk of our project was its heavy reliance on advanced theoretical concepts. It required plenty of rigour to make sure our foundations are correct and well defined. Should anything in our understanding of automata be wrong, the whole project would at risk of becoming irrelevant.
- The second most critical concern was time. There was plenty to do and very little time. It was haard to estimate how much any of the tasks would take. While missing initial deadlines due to unforseen complications is typical for software engineering projects, our project was exposed to a such risks at a much larger scale. Should anything be wrong in the formal specification, it could require months of additional research. In the worst case, if there was a mistake, some goals might turn out to be mathematically impossible. For this reason our team had to be rigorous about their promises.
- The organization of work was a challenge. Project requirements often required us to learn new technologies and solve nontrivial problems. Our team often got stuck on challenging problems and sometimes we had to change plans as some of our plans turned out to be technically impossible:
- we struggled with JWebAssembly and in the end switched to Spring
- the low-level C implementation was going too slow and we faced the risk of not delivering on time
- after the first semester we gained plenty of experience developing Java prototype and we noticed a galore of details that could be done better than we initially planned. We took a drastic decision to rewrite the compiler in Java, which was seen as risky.
- Our project is very niche and finding clients is not easy. If any of our clients lost interest in our solution, finding a new one might become impossible.
- proof of concept and first implementation of Glushkov's construction (Deadline: end of first semester)
- proof of concept for type system (Deadline: end of first semester)
- establishing relations with Dortmund University
- preparing code for adoption in Samsung. It requires writing a very specific feature that allows for converting legacy codebase from Thrax to Solomonoff. (Deadline: end of 2020)
- getting build system ready (Deadline: end of 2020)
- testing (Deadline: end of January 2021)
- full integration in Samsung (Deadline: February 2021)
