Live data from Hacker News

Why do we need modules at all? (2011)

groups.google.com

91–94 of 94 posts

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

#91
post #90
post #89

Earlier quoted context omitted.

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.

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

#93
post #91
post #90

Earlier quoted context omitted.

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.

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

#94
post #63

Earlier quoted context omitted.

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.

Very few languages let you have multiple versions of the same package in one project; fewer let you use functions from both versions together; and even fewer make this easy!

This is something that would be enabled with hash identifiers and no modules:

    let foo_1 = universe.mega_corp.finance_dept.team_alpha@v1.0.0.foo
    let foo_2 = universe.mega_corp.finance_dept.team_alpha@v2.0.0.foo

    let compare_old_new_foo(x) =
      foo_2(x) - foo_1(x)
There would be a corresponding lock-file to make this reproducible:

    {
      "universe.mega_corp.finance_dept.team_alpha": {
        "v1.0.0": "aabbcc",
        "v2.0.0": "xxyyzz"
      }
    }
I think this is pretty neat!
Post reply on HN