Skip to main content
Mathematica

Return to Answer

Typo
Source Link
uberhaxed
uberhaxed
  • 174
  • 3

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 proteanprogram 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.

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 protean 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.

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.

Source Link
uberhaxed
uberhaxed
  • 174
  • 3

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 protean 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.