[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

---

[hinkley]

Software development is continually emotionally stunted by a lack of people with expertise in multiple other fields.

English absolutely has namespaces. Every in-group has shibboleths and/or jargon, words that mark membership in the group that have connotations beyond the many dictionary definitions of that word (in fact I wonder how many words with more than three definitions started out as jargon/slang words that achieved general acceptance).

You cannot correctly parse a sentence without the context in which it was written. It’s a literary device some authors use. By letting the reader assume one interpretation of a prophetic sentence early on, the surprise the reader experiences when they discover a different interpretation at the end intensifies the effect.

[rdtsc]

> Software development is continually emotionally stunted by a lack of people with expertise in multiple other fields.

I think Joe's point is about the perennial discussion whether hierarchy is better than tags. It's as old as software or as old as people started categorizing things. Some early databases were hierarchical KV stores. Email clients and services go through that too, is it better to group messages by tags or have a single hierarchy of folders?

> English absolutely has namespaces

Sure, we can pick apart the analogy, after all we're not programing in English unless we write LLM prompts (or COBOL /s). Then if English has namespaces what would you pick lager.flat.alcoholic or alcoholic.lager.flat or lager.alcoholic.flat, etc? Is there a top-level "lager" vs "ale" package, with a flat vs carbonated as next level?

[d0mine]

"whether hierarchy is better than tags" sounds like whether hammer is better than a screwdriver. Use a tool appropriate for the job.

Hierarchy seems more rigid less general than tags but when it works--it works.

[vaughan]

It’s very hard to do tags in the physical world. You need to stick different colored post-its to things and do a full table scan (with your eyes) any time you want to process all docs of one tag. Or you cluster things together depending on similar colors.

Hierarchy is easy in the physical world.

But what is crazy is since the dawn of computing we can store data however we want and project it however we want…and yet we still use hierarchy for file storage…like we still just have a filing cabinet of manilla folders.

[namaria]

When someone asks "what is the best tool for this?", the answer "the best tool is the right tool for the job" is a non answer.

[d0mine]

Ok. Do tell. If the job doesn’t matter here, what is better hammer or screwdriver?

[namaria]

Are you asking me what is the best way to organize information, trees or tags?

Do you also want me to tell you what is the best way to foresee if a given program will halt?

The point is, bringing facile statements like "just make the right choice" adds nothing to the conversation. Some problems are hard and trying to short circuit the conversation saying that's easy just pick the right tool doesn't even apply here.

[mechanicalpulse]

I'm reminded of a Final Jeopardy! clue from a few years back --

> As of 2013, this 3-letter verb common in sports, theater & politics has the largest entry in the online OED.

The correct response? What is "run"?

[froh]

yes. and math/logics trained brains confuse hierarchical namespaces with trees. names in nested namespaces should be DAGs, maybe even arbitrary graphs, meaning a chair can be a sit-on thing in several contexts, but not in all (think meeting).

in many contemporary programming languages you can express this, too, by exporting some imported name.

[0perator]

It's arguable that any group's dialect is actually a fork of English specialized for a specific culture, activity, or context. Occasionally, elements of the fork are pulled into upstream English as groups grow in popularity and jargon or shibboleths become more commonly used across dialects.

[twic]

> The dot in the name has no semantics it's just a separator.

That's not true of all module systems. It's true in Java, but not in Rust, where it establishes a parent-child relationship, and in which context [1]:

> If an item is private, it may be accessed by the current module and its descendants.

[1] https://doc.rust-lang.org/reference/visibility-and-privacy.h...

[kibwen]

And privacy in Rust is load-bearing for encapsulating unsafe operations from safe code, so it's not just a nice-to-have, its fundamental to the language.

[auggierose]

but we do have alcoholic beer, and non-alcoholic beer, and it is nice to be able to say which one you want. And yes, there is a separator here, too, it is called a space.