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

61–70 of 94 posts

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

#61

Post by TOGoS »

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.

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

#63

Post by j_w »

greener_grass wrote: post #44
sestep wrote: post #40

Earlier quoted context omitted.

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.

This is literally just

  using universe.mega_corp.finance_dept.team_alpha;
Every argument made quickly becomes invalid because in any sufficiently complex project, the function naming scheme will end up replicating a module/namespace system.

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

#64

Post by ramses0 »

greener_grass wrote: post #44
sestep wrote: post #40

Earlier quoted context omitted.

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.

This is kindof how golang works by default. `import foo/bar/baz` then "foo" and "bar" effectively don't exist, you only refer to "baz" in the end.

`import github.com/blah/baz`, `megacorp.com/finance/baz`, ...

It all resolves to `baz.Something()`

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

#65

Post by hinkley »

rdtsc wrote: post #41

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 part…

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.

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

#66

Post by rdtsc »

hinkley wrote: post #65
rdtsc wrote: post #41

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 part…

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 ac…

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

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

#67

Post by bjourne »

skydhash wrote: post #52
bjourne wrote: post #42

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 se…

It's all related to naming. You can refer to a symbol with auth/guard/token/authenticate or auth_guard_token_authenticate, and what matters is the amount of characters you type sometimes. Also you can have encapsulation with the first option. Smalltalk have the same live experience, but do have modules, because it makes editing easier and encapsulation is nice for readability and clarity.

No, neither Smalltalk nor any of the Lisp environments that purport to support hot code reloading have the same facilities the Erlang VM has.

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

#68

Post by 0perator »

hinkley wrote: post #65
rdtsc wrote: post #41

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 part…

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 ac…

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.

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

#69

Post by d0mine »

rdtsc wrote: post #66
hinkley wrote: post #65

Earlier quoted context omitted.

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 ac…

> 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 tag…

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

Post reply on HN