Why do we need modules at all? (2011)

151 点作者 matthews2大约 1 个月前

31 条评论

ludston大约 1 个月前

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 designed to scale for my use case.We need them so that people don't have to have 80 character long function names prefixed with Hungarian notation for every distinct domain that shares the same words with different meanings.

评论 #43580487 未加载

评论 #43583252 未加载

评论 #43579883 未加载

评论 #43584509 未加载

评论 #43580048 未加载

评论 #43580086 未加载

rdtsc大约 1 个月前

I miss Joe, he left us too early. He always had wild ideas like that. For a while he had this idea of a git + bittorrent he called it gittorrent, only to find out someone had already used the name. I think it was a bit of an extension of this universal functions idea.If you expand some of the comments below, he and other members of the community at the time have a nice discussion about hierarchical namespace.I particularly like his "flat beer and chips" comment:<a href="https://groups.google.com/g/erlang-programming/c/LKLesmrss2k" rel="nofollow">https://groups.google.com/g/erlang-programming/c/LKLesmrss2k</a>---> I'd like to know if there will be hierarchial modules in Erlang, because tree of packages is a rather good idea:No it's not - this has been the subject of long and heated discussion and is why packages are NOT in Erlang - many people - myself included - dislike the idea of hierarchical namespaces. The dot in the name has no semantics it's just a separator. The name could equally well be encoders.mpg.erlyvideo or mpg.applications.erlvideo.encoder - there is no logical way to organise the package name and it does not scale -erlyvideo.mpegts.encoder erlyvideo.rtp.encoderBut plain module namespace is also ok. It would be impossible for me to work with 30K LOC with plain function namespace.The English language has a flat namespace.I'd like a drink.alcoholic.beer with my food.unhealthy.hamburger and my food.unhealthy.national.french.friesI have no problem with flat beer and chips./Joe---

评论 #43586711 未加载

评论 #43587397 未加载

评论 #43585850 未加载

评论 #43588199 未加载

评论 #43590460 未加载

neongreen大约 1 个月前

> database of functionsThis is exactly what Unison (<a href="https://www.unison-lang.org/" rel="nofollow">https://www.unison-lang.org/</a>) does. It’s kinda neat. Renaming identifiers is free. Uh… probably something else is neat (I haven’t used Unison irl)

评论 #43583799 未加载

评论 #43588129 未加载

anonzzzies大约 1 个月前

Makes me think of Unison [0]. I never used it but I found it interesting to read about.[0] <a href="https://www.unison-lang.org" rel="nofollow">https://www.unison-lang.org</a>

评论 #43581168 未加载

评论 #43581635 未加载

评论 #43596797 未加载

jonnycat大约 1 个月前

This is one of those things where I don’t agree with the argument, but know the person making it knows way more than I do on the subject and has given it way more thought. In these cases it’s usually best to sit back and listen a bit...

GrantMoyer大约 1 个月前

I think Hoogle[1] is proof this concept could work. Haskell has modules, of course, but even if it didn't, Hoogle would keep it still pretty usuable.The import piece here which is mentioned but not very emphasized in TFA is that Hoogle lets you search by meta data instead of just by name. If a function takes the type I have, and transforms it to the type I want, and the docs say it does what I want, I don't really care what module or package it's from. In fact, that's often how I use Hoogle, finding the function I need across all Stack packages.That said, while I think it could work, I'm not convinced it'd have any benefit over the statys quo in practice.[1]: <a href="https://hoogle.haskell.org/" rel="nofollow">https://hoogle.haskell.org/</a>

评论 #43587561 未加载

VMG大约 1 个月前

Functions are not isolated values.They are nodes in a graph, where the other nodes are the input types, output types and other functions.It makes sense to cluster closely associated notes, hence Modules.

Etheryte大约 1 个月前

As with other similar proposals, doesn't this simply move the complexity around without changing anything else? Now instead of looking for the right module or whatnot, you'll be sifting through billions of function definitions, trying to find the very specific one that does what you need, buried between countless almost but not quite similar functions.

jasode大约 1 个月前

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 global namespace forces the functions to be named differently (maybe use underscore '_') in "audit_log()" and the other "math_log()". With modules, the names would isolated be colons "::" or a period '.' : Audit.log() and Math.log(). Audit and Math are isolated namespaces. You still have potential global namespace collisions but it happens at the higher level of module names instead of the leaf function names. Coordinating the naming at the level of modules to avoid conflicts is much less frequent and more manageable.Same issue in os file systems with proposing no folders/directories and only a flat global namespace with metadata tags. The filenames themselves would have embedded substrings with underscores to recreate fake folder names. People would reinvent hierarchy in tag names with concatenated substrings like "tag:docs_taxes_archive" to recreate pseudo folders/directories of "/docs/taxes/archive". Yes, some users could deliberately avoid hiearchies and only name tags as 1-level such as "docs", "taxes", "archive" ... but that creates new organizational problems because some have "work docs" vs "personal docs" ... which gravitates towards a hierarchical organization again.

评论 #43579955 未加载

评论 #43584440 未加载

bionhoward大约 1 个月前

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.

TOGoS大约 1 个月前

Unison of course works this way, as has been mentioned.I like Deno for similar reason. It's a coarser level of granularity, and not explicitly content-addressed, but you can import specific versions of modules that are ostensibly immutable, and if you want, you could do single-function modules.I like the idea so much that I'm now kind of put off by any language/runtime that requires users of my app/library to do a separate 'package install' step. Python being the most egregious, but even languages that I am otherwise interested in, like Racket, I avoid because "I want imports to be unambiguous and automatically downloaded."Having a one-step way to run a program where all dependencies are completely unambiguous might be my #1 requirement for programming languages. I am weird.One reason not to do things this way is if you want to be able to upgrade some library independently of other components that depend on it, but "that's what dependency injection is for". i.e. have your library take the other library as an argument, with the types/APIs being in a separate one. TypeScript's type system in particular makes this work very easily. I have done this in Deno projects to great effect. From what I've heard from Rich Hickey[1] the pattern should also work well in Clojure[1] something something union types being superior to what you might call 'sum types'; can't find the link right now. I think this causes some trouble in functional languages where instead of something being A|B it has to be a C, where C = C A | C B. In the former case an A is a valid A|B, but a C A is not an A, so you can't expand the set of values a function takes without breaking the API. Basically what union types require is that every value in the language extends some universal tagged type; if you need to add a tag to your union then it won't work.

bjourne大约 1 个月前

This is an all-time classic, but, sadly, most HN commenters just don't "get it". Perhaps because they have no experience with the Erlang VM so they don't understand Joe's premises The Erlang VM is best described as a dynamic process manager and a "function" is just a callstack template. You want to fix a bug in your executing function without stopping it? Sure, no problem. Just reload the function and have the VM seamlessly upgrade the callstack to the new template. Since data is immutable it mostly just works. Now since functions forms the basic unit of work in Erlang modules are kind of irrelevant. Recompiling a module is the same as recompiling every function in the module. Hence, what use does the abstraction serve? The proliferation of "utils" or "misc" modules in not only Erlang but many other languages supports his point.Btw, the more experienced I've gotten the more I've found that organizing code is mostly pointless. A 5000-line source file (e.g., module) isn't necessarily worse than five 1000-line files.

评论 #43584532 未加载

评论 #43585300 未加载

jiggawatts大约 1 个月前

I had a vaguely similar notion of a global proof database. Picture something like a blockchain (actually a "blockgraph") of Lean theorems built up from other theorems and axioms also on the same distributed global data structure.A use-case could be optimising compilers. These need to search for alternative (faster) series of statements that are provably equivalent to the original given some axioms about the behaviour of the underlying machine code and basic boolean algebra and integer mathematics.This could be monetised: Theorems along the shortest path from a desired proof to the axioms are rewarded. New theorems can be added by anyone at any time, but would generate zero income unless they improve the state-of-the-art. Shortest-path searches through the data structure would remain efficient because of this incentive.Client tools such as compilers could come with monthly subscriptions and/or some other mechanism for payments, possibly reusing some existing crypto coin. These tools advertise desired proofs -- just like how blockchain clients advertise transactions they like to complete along with a fee -- and then the community can find new theorems to reach those proofs, hoping not just for the one-time payment, but the ongoing reward if the theorems are general and reusable for other purposes.Imagine you're a FAANG and there's some core algorithm that uses 1% of your global compute. You could advertise a desire to improve the algorithm or the assembly code to be twice as efficient for $1M. Almost certainly, this is worth it. If no proof turns up, there's no payment. If a proof does turn up, a smart contract debits the FAANG's crypto account and they receive the chain of theorems proving that there's a more efficient algorithm, which will save them millions of USD in infrastructure costs. Maths geeks, AI bots, and whomever else contributed to the proof get their share of the $1M prize.It's like... Uber for Fields medals, used for industrial computing.Fully automated gig work for computer scientists and mathematicians.

评论 #43588139 未加载

rapjr9大约 1 个月前

Code reuse used to be thought of as the ultimate destiny for computer code. Eventually you would never have to write new code, it would all exist in some form and you would just reuse it. We may actually be getting something like that through the use of AI for coding now. The problems with code reuse are many though. A function written in C for a microcontroller often won't work in a python program, especially not without all the include files, libraries, and a wrapper. How do you find the function that matches your needs? Coding language and function parameters offer some clues but are not sufficient. For example one function may do rounding on return values while another does not. Do you need a function optimized for speed, for object size, for time latency? Will the function work in your computing space? For example one function might use a loop, another might use recursion so running on an MCU one might work and the other might crash your stack. This might be a set of problems a LLM could sort out, but it would need some most excellant training data, not random stuff off the web. Even existing, working, industrial code bases would not be sufficient since there are huge sections of code in them that are legacy and mostly no longer used or relevant. It would probably have to be a constantly curated training database. And there is an inherent ambiguity in code, who is to say one implentation is better than another if they both work? This could make debugging challenging if the coding style is different in all the code snippets.

codethief大约 1 个月前

> all functions go into a global (searchable) Key-value databaseVery much related: <a href="https://scrapscript.org/" rel="nofollow">https://scrapscript.org/</a>

lorentzoh大约 1 个月前

I sometimes want to save a useful python script, or a function in github, but don't want to create a whole repository with README, name, description and so on. This model would be nice for that. But then, the access control system (e.g. private/public repos) would be completely different. Perhaps you could have groups of users, and give group access to individual objects (classes/functions) in your repo. But giving access to each object one by one would probably be tedious, so you need some kind of modules, or other way of grouping objects (maybe tags?). I also thought of tags on one of my jobs as DevOps. We had a lot of types of repos, that we needed to organize, and enforce access control: - code repos like backend and frontend - infrastructure repos with k8s manifests, helm charts etc. - also a lot of microservice/microfrontend repos The team lead was trying to come up with a hierarchy for all this, but struggled. If github allowed for a flat namespace of repos, and tags-based access control, we could create tags like 'frontend', 'devops', 'backend', give the tags to people and repos.

surprisetalk大约 1 个月前

This post was a huge inspiration for scrapscript![0] <a href="https://scrapscript.org" rel="nofollow">https://scrapscript.org</a>

immibis大约 1 个月前

I think they already tried this "single flat key/value namespace of all functions" in the JavaScript ecosystem - it was called npm. It was a mess when someone claimed a function based on a trademark and someone else deleted the function for padding a string to a certain length with spaces on the left in retaliation.

layer8大约 1 个月前

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.

friendzis大约 1 个月前

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

评论 #43583085 未加载

kazinator大约 1 个月前

Modules are often about a single function. But the function has helper functions that are not part of the API. Then maybe some functions that are part of the API which help use that function. Sometimes functions beget families.If a function is built on several helper functions, it may be that those same helper functions can also be used to make other, related things which round out the functionality area. Perhaps they provide an API that's easier to use for different scenarios or whatever.

MrBuddyCasino大约 1 个月前

We need modules because they demarcate social units of collaboration.

评论 #43580075 未加载

gatinsama大约 1 个月前

"Namespaces are one honking great idea -- let's do more of those!" Zen of Python

waynesonfire大约 1 个月前

Here is the link for elib1_misc.erl,<a href="https://github.com/joearms/elib1/blob/master/src/elib1_misc.erl">https://github.com/joearms/elib1/blob/master/src/elib1_misc....</a>

nsonha大约 1 个月前

This is the same to "why do we need inheritance", although less obvious. Grouping things is humans' instinct, but it may not map nicely to reality where everything belongs to more than one categories.

wruza大约 1 个月前

That would be too useful. Imagine adding tags to functions and generally treat them as "items" which you can multi-categorize, search through, select, etc like with any dataset. Way too advanced.

评论 #43579823 未加载

porkbrain大约 1 个月前

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<pre><code> [signers] mojmir = "mojmir's pubkey" radislava = "radislava's pubkey" </code></pre> source.file<pre><code> // 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));</code></pre>

评论 #43583115 未加载

andrewcl大约 1 个月前

Hard to see a world without modules as a means of compartmentalization for various reasons. You do have to appreciate the exercise what a world without them looks like / the implications.

DarkNova6大约 1 个月前

Should have put on the (2011) label

unwind大约 1 个月前

Meta: this needs "(2011)" in the title, please.

landsman大约 1 个月前

What a mess