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

51–60 of 94 posts

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

#51

Post by AtlasBarfed »

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…

The article references the true granularity issue (actually the function names need a version number as well, not sure in my scan of the article if it was mentioned).

Modules being collections of types and functions obviously increases coarseness. I'm not a fan of most import mechanisms because it leaves versioning and namespace versioning (if it has namespaces at all...) out, to be picked up poorly by build systems and dependency graph resolvers and that crap.

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

#52

Post by skydhash »

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.

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

#53

Post by poincaredisk »

AtlasBarfed wrote: post #51
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…

The article references the true granularity issue (actually the function names need a version number as well, not sure in my scan of the article if it was mentioned). Modules being collections of types and functions obviously increases coarseness. I'm not a fan of most import mechanisms because it leaves versioning and namespace versioning (if it has namespaces at all...) out, to be picked up poorly by build systems…

How do you imagine importing modules by version in the code? Something like "import requests version 2.0.3"? This sounds awful when you accidentally import the same module in two different versions and chaos ensures.

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

#54

Post by 6figurelenins »

sweezyjeezy wrote: post #23
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…

I agree, but also agree with the author's statement "It's very difficult to decide which module to put an individual function in". Quite often coders optimise for searchability, so like there will be a constants file, a dataclasses file, a "reader"s file, a "writer"s file etc etc. This is great if you are trying to hunt down a single module or line of code quickly. But it can become absolute misery to actually read t…

Not to pick on Rails, sorting files into "models / views / controllers" seems to be our first instinct. My pantry is organized that way: baking stuff goes here, oils go there, etc.

A directory hierarchy feels more pleasant when it maps to features, instead. Less clutter.

Most programmers do not care about OO design, but "connascence" has some persuasive arguments.

https://randycoulman.com/blog/2013/08/27/connascence/

https://practicingruby.com/articles/connascence

https://connascence.io/

> Knowing the various kinds of connascence gives us a metric for determining the characteristics and severity of the coupling in our systems. The idea is simple: The more remote the connection between two clusters of code, the weaker the connascence between them should be.

> Good design principles encourages us to move from tight coupling to looser coupling where possible. But connascence allows us to be much more specific about what kinds of problems we’re dealing with, which makes it easier to reason about the types of refactorings that can be used to weaken the connascence between components.

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

#55

Post by igouy »

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…

Is a 5,000-line function worse than 500 10-line functions?

(Locality of reference.)

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

#57

Post by _factor »

poincaredisk wrote: post #53
AtlasBarfed wrote: post #51

Earlier quoted context omitted.

The article references the true granularity issue (actually the function names need a version number as well, not sure in my scan of the article if it was mentioned). Modules being collections of types and functions obviously increases coarseness. I'm not a fan of most import mechanisms because it leaves versioning and namespace versioning (if it has namespaces at all...) out, to be picked up poorly by build systems…

How do you imagine importing modules by version in the code? Something like "import requests version 2.0.3"? This sounds awful when you accidentally import the same module in two different versions and chaos ensures.

Import latest where signed by a trusted authority.

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

#58

Post by auggierose »

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…

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.

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

#59

Post by immibis »

I think they already tried this "single flat key/value namespace of all functions" in the JavaScript ecosystem - it was called npm. It was a mess when someone claimed a function based on a trademark and someone else deleted the function for padding a string to a certain length with spaces on the left in retaliation.

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

#60

Post by GrantMoyer »

I think Hoogle[1] is proof this concept could work. Haskell has modules, of course, but even if it didn't, Hoogle would keep it still pretty usuable.

The import piece here which is mentioned but not very emphasized in TFA is that Hoogle lets you search by meta data instead of just by name. If a function takes the type I have, and transforms it to the type I want, and the docs say it does what I want, I don't really care what module or package it's from. In fact, that's often how I use Hoogle, finding the function I need across all Stack packages.

That said, while I think it could work, I'm not convinced it'd have any benefit over the statys quo in practice.

[1]: https://hoogle.haskell.org/

Post reply on HN