Why don't languages auto import everything?

Question

Why is there a such thing as import in programming languages? If a package does not exist, then trying to import it would cause an error anyway. So why don't languages just auto import ALL available packages? Instead of requiring programmers to have 'redundant' import statements?

Answer 1

As a software developer, I don't want my compiler to import anything unless I tell it to. Just because a package is "available", doesn't mean I trust it. And I certainly want to be able to download a package and try it out in a test project, without it automatically being included in all my code.

The risk of such a "feature" very much outweighs the slight benefit.

PS. Consider that different developers have different packages installed. Worst case you make a change that builds and runs just fine on your machine but not on mine. That’s fun.

Answer 2

'import' allows to you select just those features you need from other packages, libraries and/or modules in your application.

Since a package is often a whole set of files and/or binaries and resources used to encapsulate or abstract some set of functions/behaviors, in order for your application to use those features, they need to be available in someway at runtime. If you tried to import all in a compiled language like C, you would be including every DLL, compiled module, and file from all of those libraries and this would dramatically increase not just the size of the application, but also the startup time, since every library would need to be processed. By importing only some parts, we can not only selective choose which modules are included, but also which versions of those modules we want to include.

Answer 3

The main reason is code organization and readability. Almost all programming languages have some idea of namespaces or modules - something that allows name reuse within a context.

By default this would have you write code like:

com.example.foo.bar.Quuz myQuuz = new com.example.foo.bar.Quuz();

Which is valid, but entirely too long. So the language allows you to write

import com.example.foo.bar.Quuz;
// ...
Quuz myQuuz = new Quuz();

As a short-hand. I've worked with multiple packages containing the same class which forced me to adopt a mixed style to disambiguate the classes.

import com.example.foo.bar.Quuz;
// ...
org.example.lib.Quuz input = retrieveQuuz();
Quuz myQuuz = new Quuz();
myQuuz.setBar(input.getBar());

A single global namespace would result in every addressable object requiring a unique name. The result would either be very long names (like the one above but for the entire codebase) or else inscrutable ones because their naming would start to resemble an alphanumeric soup.

Answer 4

Here are some advantages:

• Predictability. Today foo = 5; print(ffo) is a bug due to a variable being undefined due to a typo, but tomorrow it imports the Foreign Function Object library and prints it.
• Also, someone reading the code without an IDE for that language can see that ffo is the name of a library they need to install. This is a reason why it's good to declare everything or at least limit the scope of things that do not need to be declared. I frequently rely on this when browsing Java source on GitHub.
• Compiler speed. The compiler only has to look at the files you ask it to, not everything you type in your program that could possibly be a filename.

The last reason is probably the direct one.

Answer 5

Think about how long compilation (or starting the interpreter or whatever) would take if I have 1000s of packages installed.