Live data from Hacker News

Why do we need modules at all? (2011)

groups.google.com

31–40 of 94 posts

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

#31
1. Have a global append-only function key-value store.

2. A key of a function is something like `keccak256(function's signature + docstring)`

3. A value is a list of the function's implementation (index being the implementation's version) and some other useful metadata such as the contributor's signature and preferred function name. (Compiler emits a warning that needs to be explicitly silenced if preferred name is not used.)

4. IDE hints and the developer confirms to auto import the function from the global KV store.

5. Import hash can be prepended with a signers name that's defined in some config file. This makes it obvious in git diffs if a function changes its author. Additionally, the compiler only accepts a short hash in import statements if used with a signer.

package.toml

  [signers]
  mojmir = "mojmir's pubkey"
  radislava = "radislava's pubkey"

source.file

  // use publisher and short hash
  import "mojmir@51973ec9d4c1929b@1" as log_v1;
  // or full hash
  import "51973ec9d4c1929bdd5b149c064d46aee47e92a7e2bb5f7a20c7b9cfb0d13b39" as log_latest;
  import "radislava@c81915ad12f36c33" as ln;

  log_v1("Hello");
  log_latest(ln(0));

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

#32
IMHO, aren’t modules necessary for big projects to limit the amount of complexity we have to deal with at any one time?

Our minds can (allegedly) only handle 7+/-2 concepts in working memory at once. Your whole codebase has way more than that, right? But one module could easily fit in that range.

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

#34
Global namespace clobbering has huge implications. With modules/namespaces you have a well defined and limited blast radius: a change is limited to a module and calling code.

Now, imagine your environment of choice supported dynamic runtime loading of code where the code is just dropped to the global namespace. This screams "insecure" and "how do I know if I call the code I want to call?".

Now imagine the only mitigating mechanism was `include_once`. It would make sense software written in this environment requires own CVE namespace as new security vulns are discovered every second

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

#35
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…

> It's very difficult to decide which module to put an individual function in

It's difficult because it is a core part of software engineering; part of the fundamental value that software developers are being paid for. Just like a major part of a journalist's job is to first understand a story and then lay it out clearly in text for their readers, a major part of a software developer's job is to first understand their domain and then organize it clearly in code for other software developers (including themselves). So the act of deciding which modules different functions go in is the act of software development. Therefore, these people:

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

Those people are shirking their duty. I disdain those people. Some of us software developers actually take our jobs seriously.

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

#36
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…

One thing I experimented with was writing a tag-based filesystem for that sort of thing. Imagine, e.g., using an entity component system and being able to choose a view that does a refactor across all entities or one that hones in on some cohesive slice of functionality.

In practice, it wound up not quite being worth it (the concept requires the same file to "exist" in multiple locations for that idea to work with all your other tools in a way that actually exploits tags, but then when you reference a given file (e.g., to import it) that needs to be some sort of canonical name in the TFS so that on `cd`-esque operations you can reference the "right" one -- doable, but not agnostic of the file format, which is the point where I saw this causing more problems than it was solving).

I still think there's something there though, especially if the editing environment, programming language, and/or representation of the programming language could be brought on board (e.g., for any concrete language with a good LSP, you can re-write important statements dynamically).

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

#37

Global namespace clobbering has huge implications. With modules/namespaces you have a well defined and limited blast radius: a change is limited to a module and calling code. Now, imagine your environment of choice supported dynamic runtime loading of code where the code is just dropped to the global namespace. This screams "insecure" and "how do I know if I call the code I want to call?". Now imagine the only mitiga…

What he wound up arguing for was that everything would have a globally unique name.

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

#38

1. Have a global append-only function key-value store. 2. A key of a function is something like `keccak256(function's signature + docstring)` 3. A value is a list of the function's implementation (index being the implementation's version) and some other useful metadata such as the contributor's signature and preferred function name. (Compiler emits a warning that needs to be explicitly silenced if preferred name is n…

You've just invented Unison :)

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

#39
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…

We could get that without a hierarchical categorization of code, though?

Makes me wonder what it would look like if you gave "topics" to code as you wrote it. Where would you put some topics? And how many would you have that are part of several topics?

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

#40

We need modules because they demarcate social units of collaboration.

This could be achieved with a hierarchical namespacing scheme for functions, no? universe.mega_corp.finance_dept.team_alpha.foo But to use `universe.mega_corp.finance_dept.team_alpha.foo` in your application, you don't import a module, just the function `foo`. Who controls what goes into the namespace `universe.mega_corp.finance_dept.team_alpha`? That would be Team Alpha in the Finance Department of Mega Corp. I gues…

I'm probably just missing something obvious, but in this scenario with really long names, doesn't that just mean all code will be extremely verbose? Or are you saying there'd be some way to have shorter bindings to those longer names within a specific context? But then what would that look like? Typically we use modules to denote contexts within which you can import longer fully-qualified names with shorter aliases.
Post reply on HN