Live data from Hacker News

Why do we need modules at all? (2011)

groups.google.com

21–30 of 94 posts

Re: Why do we need modules at all? (2011)

#21
post #7
post #3

We need modules so that my search results aren't cluttered with contamination from code that is optimised to be found rather than designed to solve my specific problem. We need then so that we can find all functions that are core to a given purpose, and have been written with consideration of their performance and a unified purpose rather than also finding a grab bag of everybody's crappy utilities that weren't desig…

I feel like you are arguing more for namespaces than modules. Having a hierarchical naming system that spans everything makes it largely irrelevant how the functions themselves are physically organized. This also provides a pattern for disambiguating similar products by way of prefixing the real world FQDNs of each enterprise.

It is irrelevant until you have 4gb of binaries loaded from 50 repositories and then you are trying to find the definition of some cursed function that isn't defined in the same spot as everything it is related to, and now you have to download/search through all 50 repositories because any one of them could have it. (True story)

Re: Why do we need modules at all? (2011)

#22
post #12
post #8

If there are no modules but a "flat" global namespace which requires every function name to be unique to avoid collisions... it means people would inevitably re-invent pseudo/fake "modules" and hierarchy in metadata tags in large non-trivial codebases. Consider a function name: log() Is it a function to log an event for audit history? Or is it a function to get the mathematical natural logarithm of a number? The glob…

This is what Emacs Lisp has, and what indeed does happen with libraries

Same with S3 object names.

There’s no directories in S3, just object names.

The feature of the object names being hierarchical with “/“ delimiters are out of habit and easier to reason about for the avg user.

Re: Why do we need modules at all? (2011)

#23
post #3

We need modules so that my search results aren't cluttered with contamination from code that is optimised to be found rather than designed to solve my specific problem. We need then so that we can find all functions that are core to a given purpose, and have been written with consideration of their performance and a unified purpose rather than also finding a grab bag of everybody's crappy utilities that weren't desig…

I agree, but also agree with the author's statement "It's very difficult to decide which module to put an individual function in".

Quite often coders optimise for searchability, so like there will be a constants file, a dataclasses file, a "reader"s file, a "writer"s file etc etc. This is great if you are trying to hunt down a single module or line of code quickly. But it can become absolute misery to actually read the 'flow' of the codebase, because every file has a million dependencies, and the logic jumps in and out of each file for a few lines at a time. I'm a big fan of the "proximity principle" [1] for this reason - don't divide code to optimise 'searchability', put things together that actually depend on each other, as they will also need to be read / modified together.

[1] https://kula.blog/posts/proximity_principle/

Re: Why do we need modules at all? (2011)

#24
Aside from grouping functions together that work together, for example working with data types/structures also defined in or by the module, modules also serve the purpose to hide implementation-detail code (“private” functions) shared between those functions. Modules provide a form of information hiding.

Furthermore, modules are the unit of versioning. While one could version each individual function separately, that would make managing the dependency graph with version compatibility considerably more complex.

There is the adage “version together what changes together”. That carries over to modules: “group together in a module what changes together”. And typically things change together that are designed together.

Namespaces are an orthogonal issue. You can have modules without namespaces, and namespaces without modules.

Re: Why do we need modules at all? (2011)

#25
post #3

We need modules so that my search results aren't cluttered with contamination from code that is optimised to be found rather than designed to solve my specific problem. We need then so that we can find all functions that are core to a given purpose, and have been written with consideration of their performance and a unified purpose rather than also finding a grab bag of everybody's crappy utilities that weren't desig…

I agree, but also agree with the author's statement "It's very difficult to decide which module to put an individual function in". Quite often coders optimise for searchability, so like there will be a constants file, a dataclasses file, a "reader"s file, a "writer"s file etc etc. This is great if you are trying to hunt down a single module or line of code quickly. But it can become absolute misery to actually read t…

Indeed! The traditional name for the proximity principle is called "cohesion"[1].

[1] https://en.wikipedia.org/wiki/Cohesion_(computer_science)

Re: Why do we need modules at all? (2011)

#26
post #21
post #7

Earlier quoted context omitted.

I feel like you are arguing more for namespaces than modules. Having a hierarchical naming system that spans everything makes it largely irrelevant how the functions themselves are physically organized. This also provides a pattern for disambiguating similar products by way of prefixing the real world FQDNs of each enterprise.

It is irrelevant until you have 4gb of binaries loaded from 50 repositories and then you are trying to find the definition of some cursed function that isn't defined in the same spot as everything it is related to, and now you have to download/search through all 50 repositories because any one of them could have it. (True story)

Modules don’t imply namespaces. You can run into the same problem with modules. For example, C libraries don’t implicitly have namespaces. And the problem can be easily solved by the repository maintaining a function index, without having to change anything about the modules.

Re: Why do we need modules at all? (2011)

#27
post #7
post #3

We need modules so that my search results aren't cluttered with contamination from code that is optimised to be found rather than designed to solve my specific problem. We need then so that we can find all functions that are core to a given purpose, and have been written with consideration of their performance and a unified purpose rather than also finding a grab bag of everybody's crappy utilities that weren't desig…

I feel like you are arguing more for namespaces than modules. Having a hierarchical naming system that spans everything makes it largely irrelevant how the functions themselves are physically organized. This also provides a pattern for disambiguating similar products by way of prefixing the real world FQDNs of each enterprise.

As another poster already said, providing namespaces is just one of the functions of modules, the other being encapsulation, i.e. the interface of a module typically exports only a small subset of the internal symbols, the rest being protected from external accesses.

While a function may have local variables that are protected from external accesses, a module can export not only multiple functions, but any other kinds of symbols, e.g. data types or templates, while also being able to keep private any kind of symbol.

In languages like C, which have separate compilation, but without modules, you can partition code in files, then choose for each symbol whether to be public or not, but with modules you can handle groups of related symbols simultaneously, in a simpler way, which also documents the structure of the program.

Moreover, with a well-implemented module system, compilation can be much faster than when using inefficient tricks for specifying the interfaces, like header file textual inclusion.

Re: Why do we need modules at all? (2011)

#28

Makes me think of Unison [0]. I never used it but I found it interesting to read about. [0] https://www.unison-lang.org

The Bruijn language is a really cool language that takes some of theae ideas to the extreme and fundamentals.

Variables aren't named, they are beta reduced and referred to by abstraction level.

https://text.marvinborner.de/2023-04-06-01.html

Post reply on HN