the-big-rewrite.md (7530B)
1 # The big rewrite 2 3 Recently I have been working on [nissy](https://nissy.tronto.net), 4 my command-line Rubik's cube solver. But things were not going the 5 way I wanted. I was trying to implement some minor but rather complex 6 optimizations. It was a challenging problem and I made some good progress, 7 but coming back to my code after not looking at it for weeks made it 8 hard to debug it. 9 10 I could work on this project more often. I rarely have long hours or days 11 in a row to spend on it, but I do have some free time here and there - 12 I write somewhat regularly in this blog, after all. So why was I not 13 spending some more time on this project that I like so much? 14 15 I think I was trying to do too much. I was trying to write this complex 16 optimization for the puzzle-solving logic basically to prove to myself 17 that I am capable of it, but at the same time I wanted to keep the 18 tool usable for the few people interested in it. As new ideas piled up, 19 I rushed through my code changes. Code quality degraded, and I was not 20 improving the tool. 21 22 It was time for... 23 [the big rewrite](https://dylanbeattie.net/songs/big_rewrite.html)! 24 25 ## What is nissy? 26 27 Nissy is a command line Rubik's cube solver and 28 *[fewest moves](https://www.speedsolving.com/wiki/index.php?title=Fewest_Moves_Challenge)* 29 solving assistant. You can find it's source code on its 30 [git page](https://git.tronto.net/nissy). 31 As a cube solver it is quite fast, faster than the classic 32 [Cube explorer](http://kociemba.org/download.htm), although it uses 33 much more RAM. But there is room for improvement. 34 Additional features related to 35 [Thistlethwaite's algorithm](https://en.wikipedia.org/wiki/Optimal_solutions_for_Rubik%27s_Cube#Thistlethwaite's_algorithm) 36 make it useful tool for a certain niche of speedcubers. Although 37 these features are appreaciated by nissy's users, the CLI interface 38 and general usability is not as well-received. 39 40 I started working on it in 2019, and after a few months of I had something 41 we could call useful, at least for me. As I added more features and tried 42 to implement a faster optimal solver, I noticed that I could make some 43 improvements to its design. So I decided to rewrite nissy from scratch. 44 45 "Rewriting from scratch" is a bit of a taboo among programmers. It is 46 exciting to start working on a new or "rebooted" project, but it is 47 usually more time-efficient to just fix the old code. Nonetheless, 48 starting over worked for me: at the end of 2021 nissy was much faster, 49 and more useful for everyone. 50 51 Fast-forward another year or so, and I was at the point I described in 52 the first paragraph. Since stopping to think, redesign and rewrite worked 53 for this project last time, I decided to do this again. I did not start 54 nissy with a clear goal in mind, so it makes sense that I come up with 55 better goals and design ideas as I go. 56 57 ## Setting a goal 58 59 Nissy has been my pet project for the last 3.5 years or so. I started 60 writing because I wanted to see if I could do it, and decided which 61 features to include along the way. I have never had a precise goal for 62 it, so I had to think about what I wanted nissy to be. 63 64 Right now, nissy's most important features for its users (including 65 myself) are: 66 67 * Analyzing a "fewest moves" solution, helping the (human) solver spot 68 mistakes, oversigths and more advanced tricks that they missed. 69 * Solving a Rubik's cube optimally, fast. 70 71 The first part is basically already implemented, though some improvements 72 can be made and some simple features can be added. Most importantly, 73 the interface should be made more accessible to people not familiar with 74 the command line - more on this later. 75 76 For the second part, the interface is less important, and I can expect the 77 users to be able to learn how to launch one single command. It is also 78 the part that I find most interesting to work on, since the optimization 79 problem is much more challenging. On the other hand, the optimal solver 80 implemented in the current version of nissy is already good enough for 81 most users. 82 83 Once I had written down these two main features, I realized that 84 I would be much happier working on this project if I just stuck to 85 those two things. And since *one* program should do *one* thing, I 86 decided to split the two features into separate projects. Any other 87 cool idea I thought of implementing (a speed-solving assitant? a 88 higher-order cube optimal solver? a generic, hackable puzzle solver like 89 [ksolve+](https://mzrg.com/rubik/ksolve+)?) is deferred to future 90 projects, or probably it will be never done. And that's OK. 91 92 ## New plan 93 94 My plan is to split the work into the following parts: 95 96 * Starting from the [stable branch](https://nissy.tronto.net/download) 97 of nissy, remove all the code that is needed only by the optimal 98 solver and other unnecessary steps. Work on a GUI and other simple 99 features useful for assisting fewest moves solvers. 100 * Branch off the optimal solver from the current 101 [working branch](https://git.tronto.net/nissy/) of nissy. Remove 102 all the code that is not needed for the optimal solver and simplify 103 the logic, where possible, to address only this use case. 104 Finish implementing the solver, basically following Tomas Rokicki's 105 [nxopt](https://github.com/rokicki/cube20src/blob/master/nxopt.md), 106 or at least parts of it. 107 108 For the user interface, I have been thinking about what would be 109 the best library / framework / technology to use. I would like 110 this to be as accessible as possible, so I have been considering 111 [WebAssembly](https://webassembly.org) so that people can just run this 112 in their browser. But apparently a WebAssembly app needs an http server 113 to work. I don't want nissy to require an internet connection, and 114 shipping a whole web server to run locally with it is overkill. I have 115 also been thinking about [Flutter](https://flutter.dev), it supports all 116 majow platforms and has the C language as a first-class citizen. I think 117 I'll try making some proof of concept app with it and see how it goes. 118 119 ## A GUI app? Is this an April fools' joke? 120 121 Am I a big fan of command line interfaces. I am such a fan of the command 122 line that I dislike TUIs (such as 123 [ncurses](https://en.wikipedia.org/wiki/Ncurses)-based programs), because 124 they are just GUIs running in a terminal. So why am I even considering 125 ruining my favourite personal project by adding a GUI? 126 127 One reason is that I don't expect my (very few) users to be familiar with 128 the command line. But this is not the main reason. I truly believe that, 129 for this specific use case, a graphical user interface would be better. 130 And it is not even a matter of showing a graphical representation of 131 the cube - my users don't need it, 132 [Singmaster notation](https://www.speedsolving.com/wiki/index.php/Singmaster_notation) 133 is enough for them. 134 135 The point is that this program is supposed to show you a bunch of 136 information. The user might want to see more details, less details, 137 group this information in different ways and so on. This information 138 should be browsable. The user should, ideally, be able to follow a 139 solution path proposed by nissy by simply selecting the suggested steps. 140 141 This could all be done with commands, of course. But it would not be 142 efficient. The command line is great when you know what information 143 you want and you ask the computer to generate it or fetch it. 144 But for interactively browsing information, especially when you do 145 not know exactly what you are looking for, a GUI is better. 146 147 ## Ok, so when is it going be ready? 148 149 Ah-ah. It will be ready when it's ready, no promises :)