April 28, 2016 byMichael
When you run the statement
import this in Python, you get an opinionated list of principles that guide the programming language’s design. Much in the same spirit, here are the core values driving fman:
Extending must be easy.
Customisability is important.
But not at the expense of speed.
I/O is better asynchronous.
Updates should be transparent and continuous.
Development speed matters more than program size.
These principles impact fman profoundly: It is fast, beautiful and extensible. It’s also customisable, but you can’t change it completely. The reason for this is that customisability costs performance. For example, the Atom text editor is very adaptable but suffers from severe performance issues. The next point on the list – that I/O should never block the GUI – is obvious for a file manager. The item that follows is more interesting: Have you ever really needed to get something done and the app / OS interrupts you for some updates? You don’t care. Manual updates are also tedious. Unless you disable this feature, fman updates itself in the background (only while running) similarly to Google Chrome. Finally, program size – both on disk and in RAM – affect your workflow much less than some extra polish in the other areas mentioned above. Sublime Text for instance is very efficient on resources but has been criticised for its slow development. Part of the reason for this is likely that it is developed in C++ with a custom UI toolkit. All else being equal, fman therefore prefers ready made solutions even if this increases its size.
The next post explains how these principles affect the technology behind fman. Stay tuned!