10
$\begingroup$

I am writing (it is my first time) and I don't understand why packages usually come in different files. I saw people saying that this is a modularization strategy, i.e. different files for functions that execute different tasks, but I don't understand why not just use Mathematica's sections and subsections, which work just fine in .wl files. Is there another reason, based on faster execution of the functions of your package or something like that?

$\endgroup$
2
  • 8
    $\begingroup$ For each bit of functionality that you think is re-usable and independent, it makes sense to have it in its own file so that you can import exactly and only what you need. Also, any fixes or improvements that you do will only need to be done once, in one place. It also makes it easier to use change management tools. $\endgroup$
    – lericr
    Commented Mar 29 at 15:40
  • $\begingroup$ Sometimes software is actually developed by a team in parallel. What about hiding implementation detail if everything is in a single notebook? Also there are infinitely many evaluation sequences within a notebook giving rise to different states. It is much more straight forward with putting sections into a separate file imo. $\endgroup$
    – gwr
    Commented Apr 2 at 22:44

3 Answers 3

5
$\begingroup$

From the documentation,

One of the important techniques for building software applications is to break up your code into different components, each of which does different things. You can then set your package to load code from other packages.

Of course, they don't explain why it's important, which is odd considering the target audience are not software engineers. So to answer the question, people split packages because that is the convention recommended by the documentation. As to why the documentation recommends this, I can explain from the perspective of software engineering.

First, when you load a package, you load everything in the package into memory. While this is convenient, it also uses more memory than just loading exactly what you need. This will become apparent when you load a package with a large number of functions. While memory is not an issue for modern machines, you cannot assume the memory constraints of everyone reusing your code.

Secondly, if there is any problem in the package, the entire load will fail. Debugging issues will be quicker if everything is segmented into pieces.

Third, when it comes to reusability and maintainability, you have to keep in mind that others will use your code. It will be easier to understand in chunks that do specific tasks as opposed to a monolith (and of course you can make an aggregator package to avoid writing a bunch of imports a bunch of times). It will also reduce runtime (loading times are the slowest part of program execution, since they read from disk) so it's helpful to split things up if you want to use a bunch of people's code in a large project. This will also reduce the amount of space used on disk if people only need specific functions as opposed to your entire set of packages.

Lastly, related to the third point, when people use your package and they use another package as well, there exist the possibility of conflicts. Reducing the amount of things per package reduces the risk from this particular issue, and allows you to still use some of the packages (the ones without collisions) while finding alternatives.

$\endgroup$
15
$\begingroup$

Because I really don't like working on code where the file has more than about 2,000 lines. It's terribly distracting and makes it hard to find that bit of code I'm looking for.

$\endgroup$
5
  • 2
    $\begingroup$ It wouldn't be a problem if there were a palette with a table of content that permits to navigate between Section/Subsection etc... . I have done such a thing and it turns out to be very usefull. I confess that I'm hobbyist and I may not be aware of some other serious problems. $\endgroup$
    – andre314
    Commented Mar 29 at 17:11
  • $\begingroup$ @andre314 that is a nice point, I think that because my code is not that big going through sections is not yet a problem. $\endgroup$
    – Felipe
    Commented Mar 29 at 19:46
  • $\begingroup$ I don't think that Mathematica can open two windows on the same file. Being able to view, for example, a function usage and its definition side by side is often very helpful. $\endgroup$
    – mikado
    Commented Mar 29 at 20:07
  • $\begingroup$ @mikado Yeah about that, I don't like to have two windows for this. So what I do is to just write the function in one cell and in the cell just below I write a small test of the function (which already shows its usage) and comment out this test cell. I don't think it is standard, but it makes it so much easier to read for me. $\endgroup$
    – Felipe
    Commented Mar 29 at 20:14
  • 2
    $\begingroup$ Regarding using sections and tables of contents: If you rely on this, you are locking yourself in to editing the file with Mathematica's front end. Many of us prefer to write code in a way that we don't need an IDE (much less a specific IDE) to be able to manage it. $\endgroup$
    – Szabolcs
    Commented Mar 30 at 10:19
2
$\begingroup$

One problem with a large file is name clashes with helper functions / variables.

You might have function f and function g that do completely different things, but both call and define a function h. The larger the file, the less likely you are to realize h was already defined somewhere else.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.