This post is about EduSim 2021, a simple, browser-based discrete production systems simulator.

How did I get here?

Well, the story (at least for me) is very long, too long to tell it all here. So I'll try to give you only the needed background.

The background

For me, it all started about 2000. We were told to use/play a simulation game. It was an application, called "OPT Challenge" (or something like this). The app was written in mid 1990s.

The application may be somewhat challenging, if you know nothing about scheduling, production control, and optimization. It's good for teaching, and for having some fun, provided you like such simulations. The goal is to not go bankrupt after two weeks, yet for the starters, try to not go bankrupt after the first week!

The problem is, we have 2021 now, and the game is still being played. It's more and more difficult to run such old software using modern operating systems. (The "funny" thing is that I don't know of anyone else, who would try to solve this problem, and I quit the job just a few months ago.)

For years, I was trying to write my own version of this simulation. (It's a long story, and I don't want to tell it here.) In 2018 I managed to one of my students write it for me.

It was written in JavaScript, the code was horrible, it was really hard to modify, yet it worked. Until it (suddenly) stopped to work, just a couple of weeks ago. I don't know why, and I don't care about it anymore.

I had two options: try to "fix" the old, ugly code, or try to write my own simulator, once and for all.

I decided to follow the latter way.

I had a month to do it. A month (plus a week or two), before the simulation will be needed, and used during a class, by students. It didn't have to be perfect - it did just to be functional, and correct (with respect to the simulation rules).

Technologies

I was short on time, so I decided to use all assets I could:

• I knew exactly, how the simulation should work.
• I decided to use PureScript. It has a sound type system, superior to most other programming languages. It is also strongly, statically typed. For those reasons, the compiler was able to catch the vast majority of my bugs, and refactoring was a breeze.
• Whenever something was (or seemed to be) too complex in PureScript, yet trivial in JavaScript, I used JavaScript through the PureScript's FFI. In result, my codebase is 99% PureScript, and 1% JavaScript.
• I wanted to keep the UI part lightweight, so I decided to use the Preact library. It's small, simple and functional. And writing FFI wrapper for PureScript was also simple and fast.
• For production system scheme visualization, I decided to use HTML. It was, probably, my mistake, since I could do much more in SVG, than I can do in HTML. (I'm not saying, that HTML is worse than SVG. I'm saying, that I'm much worse in HTML, than I am in SVG. And, all in all, SVG is not more complex to render, than HTML.)

What went well

The choice of PureScript was, probably, one of my best decisions in professional life. It worked great, and without it, I wouldn't be able to get the work done on time. (Well, the application is not ready yet, but it's functional enough.) Unless someone persuades me to change my mind, I'm going to spread the word about PureScript wherever and whenever I can.

I'm also happy with the Preact library. It's small, it works, and it doesn't come into my way. And it's true, what is stated on the Preact's web page: my code is the largest part of my application.

I haven't mentioned it before, but I'm also happy with mini.css. HTML/CSS is not my cup of tee, so I have to use CSS frameworks. Mini.css is lightweight, in comparison to Bootstrap. (And, as for Bulma, I wasn't able to find out, how could I obtain a build cut out to my needs. I also had other problems - Bulma is more complex, than mini.css, so I'm happy to use something simpler.)

And what didn't

This project was my first experience with PureScript, and it was both learning a new language, and an experiment.

Speaking of experiments: the whole UI codebase was/is a total experiment. It works, it does its job, it's functional - that's for sure and for good. But the code is total mess, although a managable mess. I think almost everything is to rewrite (even not refactor - rewrite!):

• Mostly the architecture, which evolved during development process. It resembles the TEA, with some dirty hacks. The point is, I don't want it to be TEA-like. Also all the modules (lower-level architecture) require rewrite.
• For the production scheme visualization, SVG should've been used (instead of HTML).

As for the simulation engine, it was also an experiment, although in a different way. I know exactly, how it should work. I wasn't sure, though, how this goal could've been achieved with the sound PureScript type system. As the result, the simulation engine is tightly bound to the simulation specification. They should be completely decoupled.

(I could also write about some technical mistakes, as unnecessary mixing various data types, yet I don't want to dive into such details here.)

The only thing to say in my defense is: I was learning PureScript (as a language, and as a technology), and I was trying to get things done (and functional enough) ASAP. As for the learning PureScript part: lucky me for having some Haskell experience.