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.

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

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

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.

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.

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

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.

The point is that the question of selecting a tool is underspecified unless specific context (job) is given. It says nothing about how easy/hard it is. It is not always true (some tools are just better in any applicable domain) but in this case (hierarchy vs. tags) it is. It is not deep but it is not a truism either.

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"?

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.

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.

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

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.

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.