Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why do we need modules at all? (2011)

groups.google.com

Post reply on HN
Print view View original

41–50 of 94 posts

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

#41

Post by rdtsc »

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:

https://groups.google.com/g/erlang-programming/c/LKLesmrss2k

---

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

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

I have no problem with flat beer and chips.

/Joe

---

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

#42

Post by bjourne »

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.

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

#43

Post by brabel »

neongreen wrote: post #18

> database of functions This is exactly what Unison ( https://www.unison-lang.org/ ) does. It’s kinda neat. Renaming identifiers is free. Uh… probably something else is neat (I haven’t used Unison irl)

A lot of things are neat because of this. Refactoring becomes trivial and safe. If you do not change the type of the refactored function, you can safely do a batch replace and everywhere the old function was used, the new one will be used after that. If you do change the type, the compiler interface will guide you through an interactive flow where you have to handle the change everywhere the function was being used. You can stop in the middle and continue later... and once you're done you just commit and push... all the while the code continues to work. Even cooler, perhaps: no unit test is re-run if not affected. And given the compiler knows the full AST of everything , it knows exactly when a test must run again.

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

#44

Post by greener_grass »

sestep wrote: post #40
greener_grass wrote: post #15

Earlier quoted context omitted.

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.

You would do something like:

    open universe.mega_corp.finance_dept.team_alpha
Then when you use `foo`, the compiler would know you mean `universe.mega_corp.finance_dept.team_alpha.foo`.

There will probably need to be some kind of lock-file or hash stored with the source-code so that we know precisely which version of `universe.mega_corp.finance_dept.team_alpha.foo` was resolved.

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

#45

Post by hombre_fatal »

taeric wrote: post #39
ludston wrote: 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?

There is a similar question about message board systems.

Instead of posting a topic in a subforum, what if subforums were turned into tags and you just post your topic globally with those tags. Now you can have a unified UI that shows all topics, and people can filter by tag.

I experimented with this with a /topics page that implemented such a UI. What I found was that it becomes one big soup that lacks the visceral structure that I quickly found to be valuable once it was missing.

There is some value to "Okay, I clicked into the WebDesign subforum and I know the norms here and the people who regularly post here. If I post a topic, I know who is likely to reply. I've learned the kind of topics that people like to discuss here which is a little different than this other microclimate in the RubyOnRails subforum. I know the topics that already exist in this subforum and I have a feel for it because it's separate from the top-level firehose of discussion."

I think something similar happens with modules and grouping like-things into the same file. Microclimates and micronorms emerge that are often useful for wrapping your brain around a subsystem, contributing to it, and extending it. Even if the norms and character change between files and modules, it's useful that there are norms and character when it comes to understanding what the local objective is and how it's trying to solve it.

Like a subforum, you also get to break down the project management side of things into manageable chunks without everything always existing at a top organizational level.

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

#46

Post by jonnycat »

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

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

#47

Post by efitz »

hombre_fatal wrote: post #45
taeric wrote: post #39

Earlier quoted context omitted.

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?

There is a similar question about message board systems. Instead of posting a topic in a subforum, what if subforums were turned into tags and you just post your topic globally with those tags. Now you can have a unified UI that shows all topics, and people can filter by tag. I experimented with this with a /topics page that implemented such a UI. What I found was that it becomes one big soup that lacks the visceral…

I agree, but go farther:

Most things have multiple kinds of interesting properties. And in general, the more complex the thing, the more interesting properties it has. Ofc "interesting" is relative to the user/observer.

The problem with hierarchical taxonomies, and with taxonomies in general, is that they try to categorize things by a single property. Not only that, the selection of the property to classify against, is relevant to the person who made the selection, but it might not be relevant, or at least the most relevant, property for others who need to categorize the same set of things.

Sometimes people discover "new" properties of things, such as when a new tool or technique for examining the things, comes into existence. And new reasons for classifying come into existence all the time. So a hierarchical taxonomy begins to become less relevant, as soon as it is invented.

Sometimes one wants to invent a new thing and needs to integrate it into an existing taxonomy. But they have a new value for the property that the taxonomy uses for classification. Think back to SNMP and MIBs and OIDs. Now the original classifier is a gatekeeper and you're at their mercy to make space for your thing in the taxonomy.

In my experience, the best way to classify things, ESPECIALLY man-made things, is to allow them to be freely tagged with zero or more tags (or if you're a stickler, one or more tags). And don't exert control over the tags, or exert as little control as you can get away with. This allows multiple organic taxonomies to be applied to the same set of things, and adapts well to supporting new use cases or not-previously-considered use cases.

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

#48

Post by skydhash »

hombre_fatal wrote: post #45
taeric wrote: post #39

Earlier quoted context omitted.

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?

There is a similar question about message board systems. Instead of posting a topic in a subforum, what if subforums were turned into tags and you just post your topic globally with those tags. Now you can have a unified UI that shows all topics, and people can filter by tag. I experimented with this with a /topics page that implemented such a UI. What I found was that it becomes one big soup that lacks the visceral…

Tags are great only when hierarchical structures becomes cumbersome. And even then, there's some limit to how much tags you can have before they become useless.

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

#49

Post by taeric »

hombre_fatal wrote: post #45
taeric wrote: post #39

Earlier quoted context omitted.

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?

There is a similar question about message board systems. Instead of posting a topic in a subforum, what if subforums were turned into tags and you just post your topic globally with those tags. Now you can have a unified UI that shows all topics, and people can filter by tag. I experimented with this with a /topics page that implemented such a UI. What I found was that it becomes one big soup that lacks the visceral…

Yeah, I suspect this is one where the general hierarchy does lift quite heavily. Such that it isn't that I would want to lose it, entirely. More that I think it is best seen as a view of the system. Not a defining fact of it.

Is a lot like genres for music and such. In broad strokes, they work really well. If taken as a requirement, though, they start to be too restrictive.

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

#50

Post by skydhash »

jasode wrote: 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…

Same thing happens to me with Bear.app (note taking). It only has tags, and the first thing I believe everyone does is to go with hierarchical structure again, because you need some tag, but also an additional specifier. Which help with grouping an location (And Bear.app have support for that naming scheme and displays it as a tree).
Post reply on HN