Structure is great for a well understood problem space, but this is not usually the case when working working something novel. As a researcher your focus should be on learning and problem solving, not creating a beautiful code base. Imposing too many constraints early on can negatively impact your project later on. In the worse case, your code starts to limit the way you think about your research. I agree that there are some general best practices that should be applied to nearly all forms of coding, but beyond that it's a balance.

The same thinking should be used when adding regulation to an industry. Heavy regulation on a rapid developing industry can stifle innovation. Regulation (if needed), should be applied as our understanding of the industry increases.

Results need to be refined so that the way they were first formulated doesn't get in the way of their replication. At scale, this too becomes a cost to industry.

In the small, this isn't different from taking a lab notebook and making it clearer and better summarized so that it can be passed on to the poor sucker who has to do what you did after you move on to another project.

Furthermore, software projects that are put under the same iterative stress you imply for R&D inevitably go through a refactoring phase so that performance isn't affected in the long run.

Agreed that there should be a minimum bar for "completed" research code such as reproducibility and a clear summary, but engineers shouldn't expect the first version of a new algorithm to be easy to understand without additional material or ready for production without a complete rewrite.

I agree. Both the simulation and the analysis are quite useless for two reasons.

1) It doesn't perform any analysis of the individual population members between time-steps. A members of the population jumps randomly within the income distribution after a transaction and the plots don't account for this. I would like to see the average wealth of each of the population members over time. I'm guessing it will be 100.

2) The transaction function is entirely unrealistic causing and making addressing 1) pointless since each population member is essentially a new born between time steps.

That said, it an interesting exercise in how one can generate a beta-like distribution.

Overall, this is too far removed from reality to be of use in debating how to address income inequality.

I've been using Joplin for a few months now. So far it seems to fit my requirements better than any other note taking app I've tried - and I've tried plenty - including my own Jupyter based solution. - future proof (it's open source) - standard/open format for notes (uses mark down which is easy to write and easy enough to parse if needed in the future) - sync support and conflict detection - Kudos to their implementation here, it's very versatile. I use Syncthing and it's worked very well for me. - support for multiple clients (I use Linux, Android, OS X and Windows) - stable (no issues so far)

The major issue I have is it doesn't support stylus based notes like Onenote. A partial solution would be to extend Joplin to support additional file types so I can keep all my notes together when they are different types. For now, I keep my written notes separate.

If stylus support isn't a requirement for you, I strongly recommend Joplin. I've tried a number of closed and open source note taking tools - Joplin hits the sweet spot for me. For a long time I used Jupyter for taking notes with custom scripts for Search. It's been pretty good however it had two major shortcomings: no android client and the Jupyter client had poor conflict detection when using a a file based sync tool like Syncthing.